[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Device online status API for Command And Control
|
My two cents ...
On Mon, 2018-03-19 at 10:26 +0100, Jens Reimann wrote:
> Hi,
>
> I drafted up a few thoughts around that a few minutes ago :) Here is what I
> came up with:
>
> ---
> Address: notification/$tenant_id
>
+1
> -> "at least once"
>
> Properties:
> content-type = "hono/connectivity"
I would rather use a content type that follows the rules layed out in RFC 6838
[1]. Something like application/vnd.eclipse-hono-notification+json. The content
type would then define/describe the semantics of the body/payload.
Therefore, if we use a specific content type for this kind of message, then I
think that we should include all relevant information in the body (and not in an
AMQP application-property, which is a transport protocol specific mechanism)
[1] https://tools.ietf.org/html/rfc6838
> content-encoding = "application/json"
content encoding is usually used that the payload is e.g. zipped using gzip etc.
I do not think that we need this.
> 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>
> }
Based on what I wrote above this should FMPOV also include tenant-id and the
"cause" of the notification, e.g.
{
"tenant-id": "my-tenant",
"device-id": "my-device",
"cause": "connect"
}
This way, a consumer of this notification can easily forward just the payload to
a component responsibly for processing it without the need to first retrieve all
missing information from the application properties and add it to the payload.
> ---
>
> 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@bosc
> h-si.com> 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
> >
>
>
>
> _______________________________________________
> 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
