| Re: [hono-dev] Command and Control / Cloud to Device |
|
>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. I think: we need all of them. I agree that for important commands like "alarm = on", 2c) is necessary. But IMHO there are also commands that could live with not being acknowledged, like "set light dim to 70%". 10 seconds later there might be the command "set light dim to 69%" which will outrule the previous command, making it not so important if the previous
command did not reach the device. This would release the burden of acks for constrained devices IMHO (?). >
>> 3. Mechanism needed to give the application time to send a command to shortly connected devices. >
> >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. Yes, that is a problem. If we force all devices to acknowledge a command (2c), the application can control itself when the command can be removed from its own "buffer". So, let me summarize my view on what we discussed to try to reach in the first step: - we hope to be able to open sender/receiver links for every device connecting from the protocol adapter to the AMQP network - we send guaranteed event for every device coming online - we always do acks on sending a command from the device back to the application (require devices to support the ack) - at least for connection less protocols like HTTP we postpone the answer to upstream messages some time to give the application some time to send a command, which will be put to the response payload then. The device is then required to ack this "command inside an upstream response payload" again. Is that correctly summarized currently? Thanks, Karsten |