Passive reading of attributes.

[ezequiel-umu]

Is it done yet? If I register Led as passive attribute and I ask for it from Context Broker, IoTAMQTT shows this debug

time=2016-02-04T17:17:25.922Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NorthboundServer | msg=Body:

{
    "entities": [
        {
            "type": "Device",
            "isPattern": "false",
            "id": "MQTT Device"
        }
    ],
    "attributes": [
        "Led"
    ]
}


time=2016-02-04T17:17:25.922Z | lvl=ERROR | corr=n/a | trans=n/a | op=IoTAgentNGSI.ContextServer | msg=Tried to handle a query before the query handler was stablished.
time=2016-02-04T17:17:25.922Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NorthboundServer | msg=Error [Error] handing request: [object Object]

After that, context broker replies with:

{
    "errorCode": {
        "code": "404",
        "reasonPhrase": "No context element found"
    }
}

[drasko]

@ezequiel-umu can you please describe the procedure of registering LED. I would like to try on my side, but with lacking documentation I find it a bit difficult to get going. I could use your knowledge to put me on the track and test your problem in my set-up.

[ezequiel-umu]

Of course. I just used the passive option in type configuration, as described in other iota project which I can't remember now. The configuration follows:

    types: {
        'Device': {
            "service": "/",
            "subservice": "/mqtt",
            "removeSuffix": true,
            "active": [{
                "name": "Boton",
                "type": "Integer"
            }],
            "lazy": [{
                "name": "Led",
                "type": "Integer"
            }],
            "commands": [],
        }
    }

This configuration works if you use lwm2m IoTAgent, because reading of passive (aka lazy) attributes is well defined using CoAP Get method.

Y also used this curl script to provision the device:

(curl localhost:4041/iot/devices -s -S --header 'Content-Type: application/json' \
  --header 'Accept: application/json' --header 'fiware-service: /' --header 'fiware-servicepath: /mqtt' \
  -d @- | python -mjson.tool) <<EOF
{
  "devices": [
    {
      "device_id": "MQTT",
      "protocol": "GENERIC_PROTO",
      "entity_name": "MQTT Device",
      "entity_type": "Device",
      "timezone": "America/Santiago"
    }
  ]
}
EOF

You can simulate Boton changes using mosquitto_pub with topic /apikey/MQTT/attributes/Boton.

[drasko]

@ezequiel-umu I have made some progress, documented at #87.

However - what is apikey in /apikey/MQTT/attributes/Boton and how do I obtain one?

[dmoranj]

A global API Key can be configured for this case in the config.js file in the defaultKey attribute. Specific API Keys for each service can be provisioned using the Configuration API.

[drasko]

@dmoranj you said in #85 : "Devices must be provisioned via Device Provisioning API. The IoT Agent model gives the option of creating a Configuration for groups of devices, so to allow autoprovisionig of those devices in possesion of the API Key. That should ease the application from the burden of provisioning each one of the devices. But a configuration for each Service must be created in any case."

Is apikey a security token, or is it just a group ID? I.e. do we use it for security purposes or just to mark a specific group?

[dmoranj]

Kind of both. The idea is to provide a way to separate requests coming from devices of different customers, thus grouping them (to be able to separate them in the CB and other components, also) and also to forbid devices not knowing the APIKey from accessing devices of other customers. That last part stands as part of a security mechanism, but a bit insecure on its own... In order to have a properly secured south bound, access to topics with a particular API Key should also be authenticated using the mechanisms provided by the MQTT broker (certificates, credentials, and so) with ACLs for all the topics of a particular APIKey.

[ezequiel-umu]

About the main question. Is it planned to be done passive (or lazy) reading for MQTT's IoTA?

Thank you.

[dmoranj]

There is a kind of proactive passive reading with this IoTA (that was needed on a prototype for an incoming project) that probably could be transformed into support for the lazy attributes. I have created an issue for that particular feature, and we will try to push it (as I found it interesting to cover all the IOTALib functionality in the IOTA), but I can't guarantee you a date (it will heavily depend on our team backlog, that is changing pretty fast these days).

[dmoranj]

The issue is #89

[dmoranj]

Closing the issue, as an issue with the proposed enhancement has been created. We will update the issue number #89 in case there are updates on this subject.