Open jason-fox opened 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>...
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>...}
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
Currently when I provision a device like this using the Ultralight or JSON IoT Agent:
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 existingcommandHandler
) 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 GEThttp://iot-sensors/iot/lamp001/b
(whereb
is theobject_id
for `batteryLevel). correct?It doesn't make sense to add an equivalent for MQTT or AMPQ because message queues are not synchronous.