| Re: [hono-dev] Command and control |
|
To focus on 1. (sending a command to a device) I think is a very good idea, but IMHO several points are important:
a)
The device is NOT replying synchronously, all is asynchronous (by applying the usual Future patterns). But it should have a timeout. When we rely on synchronous pattern, we would block the thread, which would cause problems in controlling a lot of devices simultaneously e.g. So we would be very limited in how many devices we may control from one application, the time a device needs to answer directly influences the application, and so on.
b)
Commands should be separated into “connected” and “currently possibly not connected” (e.g. calling them “modes”). The sender could decide what he would like to demand
for the device – IMHO it will often be not so important if the device is connected “just now”, or a little time later, but both possibilities need to be considered. So I propose to first only discuss “Commands” (with two modes), and not so much “software upgrades”. A certificate update would be a command
im my eyes as well.
c)
Command mode “connected” could be implemented without any brokering (no Artemis involved), the “currently possibly not connected” needs a broker (Artemis involved).
d)
From the beginning on, we should have the gateway support in mind. I think it is unrealistic for non trivial setups that we have devices all directly connected to protocol
adapters. These are my “initial” thoughts on the topic, hope it makes some sense to you all
J Mit freundlichen Grüßen / Best regards
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Pellmann Hi all, I would like to share some thoughts and start a discussion about command and control, since it is a big topic for Hono after we created the
first release, now. We have a draft API spec. at https://www.eclipse.org/hono/api/command-and-control-api/. From the API level this is a very good starting point, but we should discuss the implementation options and what expectations are behind it.
Also what should and could be the targets (and limitations) for a first implementation. I see the following main use cases for command and control (to be discussed).
1.
send a direct command to a device
o
example: “light:on”, “door:open”, “alarm:on”
2.
send a new/changed configuration to a device
o
example: upgrade a software component, use new certificate from next month on For 1) I would expect the device to be connected while the command is send - if not, the command will fail. The response is send back synchronously. For 2) it is not needed, that the device is connected all the time. The device can connect in time intervals. The command could be long running.
Commands need to be buffered and the response is complicated - a lifecycle with states for Hono and the sender of the command need to be handled. It seems to be easier to start with 1), since we do not need to care about lifecycle/state and the persistence. But maybe we have some other
problems - if we do this straight with AMQP, we could get in trouble with the number of links needed and also I am not sure about guaranteed ordering. I have created overview graphics for both scenarios:
Direct
and brokered. I would be very interested in your opinions about the scenarios as well as the potential problems and implementation options. Especially in
regards to the AMQP components - the Dispatch Router and the Artemis broker - what are your expectations? Best regards, Marc |