| Re: [hono-dev] Command and control |
Use cases are: A wind park receiving a setpoint for active power cap (single device), a car infotainment system receiving weather updates (multiple devices).So instead of continuously requesting a device to switch to some state, the device has a more intelligent way to acquire this information. This could be directed to one single device, or the address/topc/information be directed to multiple devices as well.I would like to suggest to look at another command&control pattern which sometimes is rather useful.The sensor/device describing to a cloud system value. In a sense that the device at some point in time (or over a longer period of time) is interested in a value and would like to get the last known value and receive further updates.On Wed, Feb 14, 2018 at 7:06 PM, Marc Pellmann <pellmann@xxxxxxxxx> wrote: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/a
pi/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).
send a direct command to a device
example: “light:on”, “door:open”, “alarm:on”
send a new/changed configuration to a device
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
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
--Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
____________________________________________________________ _________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev