Re: [hono-dev] Command and Control / Cloud to Device

[Marc Pellmann <pellmann@xxxxxxxxx>]

For completeness, I would like to point out that while the event for a device connecting can be guaranteed, this “only” highly increases the probability that a command can be successfully sent to the device. It still may fail, since the device could directly disconnect again, loose its connection, and so on.

Yes, the event that the device has connected does not include a guarantee - the application need always handle the case that it is not connected at the moment, the command was send.

 

So to me the question arises: do we want any acknowledgement for the command?

 

For me there seems to be following options:

2a) only best effort – as soon as the connect event comes, the application sends the command and then forgets about it

2b) best effort for protocol adapters to devices – the application gets an acknowledgement that the command reached the protocol adapter, but does not know if it ever reached the device itself

2c) full device acknowledgement – the device acknowledges the command and this will be forwarded up to the application

 

I propose we focus on 2a) and 2b) and may look for 2c) later for special cases.

To make it clear - we talk now about the command sending (after the event, that the device is online has arrived or at any time - does not matter). I think we need 2c. If you send something like alarm=on, you need to be sure it has arrived.

  

> 3.      Mechanism needed to give the application time to send a command to shortly connected devices.

 

Again for completeness, I think there were the following ideas already:

 

3a) All protocol adapters are able to keep “one” command per device in memory.

 

So, if an application sends a command, then

3b) the protocol adapter may be able to deliver it directly (since the device is connected), or

3c) if the device is not connected currently, the protocol adapter has to buffer it (exactly one command per device)

 

Additional points:

3d) If a (i.e. exactly one) command was buffered, it will be tried to be delivered the next time the device comes online

3e) If a new command is sent, before the previous command could be delivered, it is just overwritten by the new one

 

Delivery of the command has also different variants IMHO:

3f) connection oriented protocols – could be able to directly deliver the command via a message to the device, BUT

3g) for protocols like HTTP (without Websockets) a command possibly must be in the response payload of an upstream message, e.g. a telemetry message.

 

If we have a command in the response payload of an upstream message, IMHO there are again variants:

3h) the full command is in the payload (e.g. in defined parts of the response payload)

3i) only a “hint” for the device that a command is waiting is included, and the device has the responsibility to fetch the command (from the buffer of the protocol adapter)

 

These are my current thoughts regarding first steps towards command and control.

WDYT?

Storing the last command at the adapter will not work, if we have more than one instance. The next time the device connects, it may be at an other instance. I think in the first version we should not store any commands but give the application the possibility to send it again and be sure it gets all needed information about the delivery.

WDYT?