Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Command and control
Hi Marc,

first of all thanks for starting the discussion even drawing those useful pictures for showing the scenarios :-)

I think that we are more or less on the same page in terms of patterns and in terms of problems we have to address (ordering, scalability and so on).

Few other thoughts ... but nothing new for now.

I think that finally we have different use cases :

1. a command that can be sent only if the device is online otherwise the application should not be able to do that. The "direct messaging" fits well here but then a couple of sub-cases can happen:
    1. the command doesn't have a "real" result but it's enough for the device just accepting it and giving the feedback to the business application about that. Using "direct messaging" at AMQP level it could mean that just an ACCEPTED disposition could be enough
    2. the command has a result that the device could provide immediately or later (it depends if the command needs a long or short running). In this case an ACCEPTED disposition isn't enough and a reply path is needed for the application to get the result (as Dejan mentioned)
2. a command that can be sent even if the device is offline. The "store and forward" fits well in this case where the message is put into a queue but with a TTL. Even in this case I can see the above sub-cases but with a difference : if the command doesn't have a result, the ACCEPTED disposition isn't enough (because it will be something for the broker and not for the final application), so in any case a reply address/queue is needed (as the above 2nd sub-cases).

We should try to factor out a common/shared way for addressing both scenarios (i.e. maybe just having always a reply address/queue and not relying on the simple ACCEPTD disposition even if it's enough in 1.1.

Regarding Jens suggestion, it sounds to me like the "retain" / "last well known" message provided by the MQTT protocol out of box. In my mind it doesn't fall into the "command & control" pattern but more in the "notification" one : the service can push notifications to devices but it's not sending a command for having them doing "something". Having the last notification for a new client can be useful. In this case the service doesn't want really a reply/result but maybe or maybe not just an ack on delivery.

Thanks,
Paolo.


From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Jens Reimann <jreimann@xxxxxxxxxx>
Sent: Thursday, February 15, 2018 9:47 AM
To: hono developer discussions
Subject: Re: [hono-dev] Command and control
 
I wouldn't see this as a shadow or twin. Of course this can be used to implement shadows/twins. And I agree, this can be a fine line between both sides.

But I would see this more like a communication pattern supported by Hono in a native way. More like a setpoint.

Hono provides support for MQTT and HTTP. And I think this pattern would have an impact on both. Simple with MQTT, not so simple with HTTP. Unless maybe using HTTP/2 or websockets.

On Thu, Feb 15, 2018 at 10:07 AM, Marc Pellmann <pellmann@xxxxxxxxx> wrote:
So you mean like a shadow or twin? Like Ditto in the Eclipse IoT, Shadows in AWS IoT etc.? 

I think such a pattern is very useful from an application point of view. But in my understanding it should be out-of-focus for Hono and the providing system (like Ditto) is an application from the Hono point-point-of-view. Then the question would be which pattern is be needed from such an shadow/twin application.


2018-02-15 9:22 GMT+01:00 Jens Reimann <jreimann@xxxxxxxxxx>:
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.

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.

Use cases are: A wind park receiving a setpoint for active power cap (single device), a car infotainment system receiving weather updates (multiple devices).

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/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

    • example: “light:on”, “door:open”, “alarm:on”

  2. 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



_______________________________________________
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

Back to the top