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?