telefonicaid / iotagent-ul

IoT Agent for a UltraLight 2.0 based protocol (with HTTP, MQTT and AMQP transports)
https://fiware-iotagent-ul.rtfd.io/
GNU Affero General Public License v3.0
37 stars 55 forks source link

Question: Define an HTTP Protocol to Support Lazy Attributes. #574

Open jason-fox opened 2 years ago

jason-fox commented 2 years ago

Currently when I provision a device like this using the Ultralight or JSON IoT Agent:

{
     "endpoint": "http://iot-sensors/iot/lamp001",
...      
     "commands": [ 
        {"name": "on","type": "command"},
        {"name": "off","type": "command"}
     ],
     "lazy": [
        {"object_id": "b", "name": "batteryLevel", "type":"Number",
          "metadata": {"unitCode": {"type": "Text","value": "C62"}}
        }
     ],
     "attributes": [
        {"object_id": "s", "name": "state", "type":"Text"},
        {"object_id": "l", "name": "luminosity", "type":"Integer",
          "metadata": {"unitCode": {"type": "Text","value": "CDL"}}
        }
     ]
   }

I can successfully send HTTP Commands to my device using the endpoint http://iot-sensors/iot/lamp001, however retrieving the entity the lazy attribute is always blank (yes, I know #23 is still open). If I had provisioned the same device using the OPC-UA IoT Agent, it would make an OPC request for the lazy attribute to the OPC-UA server.

Is there any good reason why at least the HTTP Binding couldn't have a queryHandler (similar to the existing commandHandler) to make a GET request on <endpoint>/<lazy-attribute> ?

So in this case a GET http://orion:1026/v2/entities/Lamp:001?attrs=batteryLevel should result in a GET http://iot-sensors/iot/lamp001/b (where b is the object_id for `batteryLevel). correct?

It doesn't make sense to add an equivalent for MQTT or AMPQ because message queues are not synchronous.

jason-fox commented 2 years ago

The alternative would be to use the same endpoint and ultralight syntax as the existing command:

So in this case a GET http://orion:1026/v2/entities/Lamp:001?attrs=batteryLevel should result in a POST http://iot-sensors/iot/lamp001/ with payload Lamp:001@b (where b is the object_id for batteryLevel).

ultralight syntax normally being <id>@<attribute>|<value>...

jason-fox commented 2 years ago

The equivalent payload in JSON syntax:

So in this case a GET http://orion:1026/v2/entities/Lamp:001?attrs=batteryLevel should result in a POST http://iot-sensors/iot/lamp001/ with payload {"b": null} (where b is the object_id for batteryLevel).

JSON syntax normally being{"<attribute>": <value>...}

mapedraza commented 2 years ago

As you noticed, the iotagent-node-lib supports the Lazy Atttributes but they are not implemented in some IoT agents (like UL and JSON).

As you described, using a command would have the same behavior that a lazy attribute. The difference between them is Lazy Attributes are synchronous and commands asynchronous. We are using commands for retrieving information from devices for that reason.

Implementing Lazy Attributes in those agents is an option. The other options is to use the commands for retrieving the data