| Re: [hono-dev] Command and Control in Custom Protocol Adapter for indirectly connected devices |
|
Hi Chris,
We see two possible implementations to integrate “Network Managers” (systems that bundle specific devices that can be accessed by a digital twin like pattern)
like LoRaWAN providers :
1.)
Commands can be sent to the Network Manager in reaction to a downstream message that was sent to Hono (like we implement it in the HTTP adapter)
This would work out of the box by implementing a custom PA that receives such a command for the device. Instead of putting it to the HTTP response, it
calls the Network Manager (that probably buffers it in the case of LoRa devices until the device is ready to receive it).
2.)
All custom PA instances keep a link open for the network manager. The network manager is registered as a Hono gateway device and is always open to receive commands.
This would enable that applications can always send a command to a device, no matter if the device sent data downstream before.
For Hono’s AMQP endpoint definition of ‘control/TENANT/DEVICEID’ this would mean that a component has to be implemented that does the (probably trivial) mapping
of ‘control/TENANT/DEVICEID’ to ‘control/TENANT/gw-id’ by using the ‘via’ property in the device registry. This component would not be part of Hono.
In both cases the devices of the Network Manager should be created in the device registry – this could e.g. be done by creating it “on the fly”, or (if possible) by providing them via bulk
commands to build up Hono’s registry.
The mapping component of 2.) could be part of the device registry.
>Does our custom adapter have to create an AMQP link for command messages for each possible device and keep it permanently (hono-ttd = -1) open?
>For such a scenario maybe a single generic AMQP link for gateway devices to distribute it to the concrete devices behind the gateway would be nicer.
Both questions: see above!
Best regards
Karsten
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of
Schmid Christian (INST/ECS4)
Hi Hono Devs,
We have recently started to use the new command and control feature of Hono.
Based on the HTTP Adapter provided by Hono we have a custom protocol adapter in place to support the integration of LoRaWAN providers.
The interaction model currently looks as follows:
+--------+ Lora +---------------+ HTTP 1.1 POST /loraData +---------------------+
| Device +---------> | Lora Provider +-----------------------------> | Custom Hono Adapter |
+--------+ +---------------+ +---------------------+
In Body: - Device ID
- Actual Payload
·
For the authentication of the provider we make use of the Hono "gateway device"-feature.
·
To send commands to a LoRa device, one has to send a message via HTTP POST to the LoRa provider, which takes care of the further handling of the command (queuing, etc.).
·
The HTTP api of the LoRa provider can be invoked independently from previous interactions (It does not have to be the same instance of the adapter; Device doesn’t have to send telemetry first).
My question now: Could you please give as a hint how we could implement C&C of Hono in such a scenario?
Does our custom adapter have to create an AMQP link for command messages for each possible device and keep it permanently (hono-ttd = -1) open?
For such a scenario maybe a single generic AMQP link for gateway devices to distribute it to the concrete devices behind the gateway would be nicer.
Thanks
Chris |