search

eclipse-hono / hono

Eclipse Hono™ Project
https://eclipse.dev/hono
Eclipse Public License 2.0
452 stars 137 forks source link

Device Registry API provides possibility to add/find device IDs by a specific Vorto Information Model #1008

Closed aedelmann closed 5 years ago

aedelmann commented 5 years ago

A connector / gateway has a way to dynamically retrieve all registered device IDs which are of a certain device type, e.g. XDK, Bosch Camera X. A gateway/connector would then be able to request additional meta-data about the device (e.g. capabilities , bindinginfo, etc) from the Vorto Repository.

I would propose here to have a special device registry attribute , e.g. vorto-model-id

zubairhamed commented 5 years ago

Or perhaps generically simply a "type" atribute or "model"

sophokles73 commented 5 years ago

@aedelmann My understanding is that you would like to see such a feature being added, right?

aedelmann commented 5 years ago

@sophokles73 : Yes :)

sophokles73 commented 5 years ago

I am not sure if I understand the use case. Can you describe in more detail what is supposed to be happening and what the setup (devices, protocol adapter) would be?

aedelmann commented 5 years ago

Given the possibility, that the Device Registry accepts an optional model-id of the device, I can see the following 2 use cases:

Use Case 1: Device - specific Payload Conversion on AMQP Consumer side When a device sends data to Hono, the protocol adapter would read the configured model-id from the registry, make it part of the AMQP header and pass it to the AMQP consumer which in turn would now have possibility to resolve a vorto payload mapping specification for the provided model-id and convert the payload to Vorto compliant / semantic payload (I could contribute a demo AMQP consumer to Hono which does that :)

Use Case 2: Device Type Discovery + Payload Conversion on Gateway A device-type specific gateway is able to find out via the Device Registry API, what devices are registered that the gateway is able to process. This information would allow the gateway to build up an internal mapping table (device id -> model-id -> payload mapping specification) to perform device - specific payload conversions, before it sends it to the protocol adapter. I currently have a vorto-connector that processes security camera binary data, converts it to Vorto/Ditto payload and sends it to Hono + Ditto (https://github.com/eclipse/vorto-examples/tree/master/vorto-connector). This feature would be very useful here, because then the connector would find out from Hono dynamically, all device IDs which are cameras, as opposed to (currently) statically configure it in the connector.

sophokles73 commented 5 years ago

When a device sends data to Hono, the protocol adapter would read the configured model-id from the registry, make it part of the AMQP header and pass it to the AMQP consumer

You can already do that. All you have to do is add the model-id property as one of the device's default properties which are included in the response to the assert device registration operation. The protocol adapters include the default properties in the downstream AMQP message as application-properties. Refer to the HTTP adapter user guide for details.The other protocol adapters support this as well ...

Use Case 2: Device Type Discovery + Payload Conversion on Gateway

When you write gateway, are you talking about a component in the cloud that the device connects to, i.e. what we would usually call a protocol adapter, or are you referring to a component in the device's vicinity? In the former case: see above, in the latter case: the above mechanism could be used by the gateway as well (given that the gateway is authorized to retrieve data via the Device Registration API, which it normally would/should not be).

aedelmann commented 5 years ago

Regarding use case 1: brilliant. Regarding use case 2: yes, I mean the latter whereby a gateway like Kura would upon Initialization make an API call to the registry to find all device IDs by model ID. So you are saying that would be possible by the registry API ? I am only aware of the GET command where u need to pass in the device ID. This however wouldn’t help much as I wouldn’t know the device ID.

sophokles73 commented 5 years ago

a gateway like Kura would upon Initialization make an API call to the registry to find all device IDs by model ID

No, that is not possible using the Device Registry API. I wonder why the gateway would want to do that. Why does the gateway need to retrieve device IDs for a model ID? Why would a device be connected to a gateway in the first place if the gateway can't handle it?

aedelmann commented 5 years ago

1) Because IMO the gateway should only handle device data if the device is registered in the device registry. It should discard device data otherwise for security reasons. 2) in the scenario of the camera gateway, the cameras always speak to the gateway because it handles the data conversion expected by the cloud solution. The gateway would need to make a call to the camera to get the data from the device and send it to the backend. For that it needs the device ID to know where to connect to. But only the device ids for gateway known device types

sophokles73 commented 5 years ago

Because IMO the gateway should only handle device data if the device is registered in the device registry. It should discard device data otherwise for security reasons

If you set up a gateway and device that connect to the gateway, wouldn't the devices be known to the gateway anyway? Otherwise, how could the devices connect to the gateway, or doesn't the gateway authenticate the devices, i.e. can every device connect to the gateway?

The gateway would need to make a call to the camera to get the data from the device and send it to the backend. For that it needs the device ID to know where to connect to. But only the device ids for gateway known device types

This, again, sounds like the gateway needs to know about the cameras that are connected to the gateway, i.e. the gateway needs to be configured with the cameras that are allowed to connect to the gateway, right?

aedelmann commented 5 years ago

You are right. I was going through the gateway scenarios in my head and it led to the conclusion that, as you said, the gateway must always know the device ID already, since the devices undergo a "pairing" process with the gateway first which would make this device ID information available there. I guess you can mark this issue as 'won't fix'. But thanks for the clarifications ;)