Re: [hono-dev] Device online status API for Command And Control

[Jens Reimann <jreimann@xxxxxxxxxx>]

Hi,

I drafted up a few thoughts around that a few minutes ago :) Here is what I came up with:

---
Address: notification/$tenant_id

 -> "at least once"

Properties:
    content-type = "hono/connectivity"
    content-encoding = "application/json"
    subject = "connected" | "disconnected"
Application Properties
    device_id = <device id>
    tenant_id = <tenant_id>

Payload format (JSON):
{
    "device-id": <device-id>,
    "message": <optional, plain text (error) message>
}
---

The idea behind that was, that we can use this address for additional (future) events as well. Right now we have two, maybe someone else wants to add custom ones as well.

I do like option b), so I changed my proposal to use that as an address. I originally had "connectivity", but "notification" follows the idea of allowing future additions in that area.

Thinking about the QoS, I guess you are right and the sender of such notifications would probably never act on a "failure". Except maybe writing a log entry. The question to me is: If we would queue those messages in a broker, would QoS 0 make any difference?

Cheers

Jens

On Mon, Mar 19, 2018 at 9:49 AM, Frank Karsten (INST/ECS4) <Karsten.Frank2@xxxxxxxxxxxx> wrote:

Hi all,

 

regarding one aspect of Command and Control (device notifications about their online state) I would like to start a short discussion here.

 

1.) Naming

We decided to define an own API for the online status of a device.

IMHO there are several possible namings for this API where I would like to get your opinions:

 

a) Device Status API

b) Device Notification API

c) Device Alert API

 

I would vote for b). What are your opinions? Or maybe none of them , but an option d)?

 

2.) Delivery guarantees:

 

We all agreed IMHO that we want to guarantee the delivery of notifications when devices are coming online (a lot of further aspects of C&C rely on that).

And have a best effort for the disconnect of a device.

 

But what does that mean in particular regarding the guaranteed notification?

 

I am not sure if there is any good value if we deliver this notification with QoS 1 (like events),

since the protocol adapter receiving an acknowledgement would not do much with it. If the delivery would be acknowledged with "no success", it would still deliver e.g. telemetry data.

 

So to me the guarantee to send the online notification means "we will send the notification, but we do not treat a not successful delivery".

 

So it looks to me like we send telemetry data - if no one listens to this API or the notification is somehow lost, there would be no consequences except for that no command could be sent.

WDYT?

 

Thanks Karsten

 

Mit freundlichen Grüßen / Best regards

Karsten Frank

(INST/ECS4)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

_______________________________________________
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