eclipse-hono
[idea] Allow devices to indicate their type/capabilities
The devices connecting to Hono usually only provide credentials for authenticating with a protocol adapter. Hono currently does not maintain information about the devices' type, make, model and/or capabilities. That said, such information may very well be maintained in any particular device registry implementation that Hono's adapters are connecting to. LWM2M for example requires devices connecting to a server to report their capabilities using a well defined encoding. In a similar fashion, Hono could define a specific event type which could be used by devices to report their capabilities, e.g. by means of references to Eclipse Vorto information models. Based on such information, Hono and other downstream applications could start making reasonable assumptions regarding the semantics of payload contained in telemetry messages and events originating from the devices in a generic way. This might also be helpful with just-in-time provisioning (#1296) in order to be able to create things in Ditto on-the-fly ...
@thjaeckle @aedelmann WDYT?
Hi @sophokles73 I like the idea. You mentioned that a device can send any kind of ID information that identifies the payload semantic information, so for example an Vorto Model ID or something else. I could imagine that Hono and as part of your mentioned event handler, could automatically resolve the ID for the Vorto Model schema document from the Vorto Repository and passes this info to downstream applications. So let's say, it was a LWM2M identifier, Vorto can lookup the LWM2M object ID and return a full Vorto Model for it. Of course caching can be enabled for released Vorto models, as they do not change anymore over time. I can see another benefit ,aside from what your mentioned just-in-time provisioning, namely routing to subscribers for specific semantic information :)
That could be very useful for the just-in-time provisioning, indeed. Or for payload transformations which should be done in between Hono and Ditto based on the "type" information the device sends along.
I would however keep the transmitted information to an identifier (I assume as defined application property from AMQP 1.0 perspective) in order to keep the added payload (which is potentially transmitted for each telemetry message) to a minimum.
Should the information also contain information about which parts of a model were updated e.g. in a telemetry message? From what I see it is rarely the case that a device sends its complete payload as one telemetry message, but issues telemetry updates for single scalar values e.g. whenever they changed. For such scalar updates it would be very useful to identify the part of the model which the update "targeted".
I would however keep the transmitted information to an identifier (I assume as defined application property from AMQP 1.0 perspective) in order to keep the added payload (which is potentially transmitted for each telemetry message) to a minimum.
My original idea was to let devices send a dedicated event with a specific content-type which would then contain all relevant information in the payload. Very similar to how LWM2M does it. I do not think I know enough about Vorto in order to tell whether it is sufficient for a device to just include a single Info Model Indentifier in order for downstream applications being able to determine the device's capabilities. If so, then we could indeed simply include such an identifier with each telemetry message that contains data. Depending on the scope of the data, i.e. whether it represents the full state of the device or just a function block, the identifier included could either be an info model or function block ID.
Would that work @aedelmann?
@sophokles73 Sure that works. And you are right, the ID could either be a Function Block ID or Information Model ID. I agree that keeping the info to a minimum is a good design choice. 👍
Ok, so a transport data logger could initially send an event with a to-be-defined content-type which contains information like:
com.bosch.bcds:TDL:1.0.0
either in the payload or in an application-property (e.g. vorto-info-model). In subsequent telemetry messages which contain some sensor data, the messages could include an application-property indicating the semantics of the data, e.g.
vorto-function-block: "org.eclipse.vorto:Rotation:1.0.0"
-----
payload
My understanding is that this is not really helpful if the device sends data in the Ditto format already, right? But for devices that send binary data only, these properties could be added by Hono on-the-fly based on defaults that are registered for the device in Hono.