eclipse-honoeclipse-ditto

Sending events form edge-device to ditto via hono

I did followings successfully:

Sending telemtery data from the edge-device to ditto through hono works perfectly.

I also send a pseudo event every second form edge-device to ditto through hono as follows:

# sending an event from edge-device to ditto through hono-mqtt-adapter
correlation_id = ''.join(random.choices(string.ascii_uppercase + string.digits, k=10))
data = {
    "topic": "de.iot1/dev1/things/live/messages/fire",
    "headers": {
        "content-type": "text/plain",
        "correlation-id": correlation_id
     },
     "path": "/outbox/messages/fire",
     "value": "Fire detected"
}
payload = json.dumps(data)
mqtt_client.publish("event", payload=payload, qos=1)

On the other side I wrote a simple ditto-amqp-client which just receives all dittos incomming messages. I receive all incoming telemetry messages as their correct interval - i.e. every second. In the case of events messages they seems to be buffered by ditto and sent to amqp-client every couple of seconds and not at the time they are send from the device! Why?

As far as I understood from the ditto-doc, ditto offers two communication channels. twin-channel for communicating with the twin through commands and events and a live-channel to communicate with the device directly through messages. But in the section protocol-topics the channel can be either twin or live also for events or commands, which is confusing.

Thanks in advance for any suggestion!

Solution

  • I receive all incoming telemetry messages as their correct interval - i.e. every second. In the case of events messages they seems to be buffered by ditto and sent to amqp-client every couple of seconds and not at the time they are send from the device! Why?

    As Ditto does not do a "store-and-forward", but publishes applied events immediately, I can't really explain from Ditto side. Maybe by sending events (which in Hono are persisted using an AMQP broker), those are consumed with some delay (after persisted by the broker), however I can't explain the "every couple of seconds".
    You could enable DEBUG logging in Ditto's connectivity service by setting the environment variable LOG_LEVEL_APPLICATION to DEBUG - that way you'll see when the messages are received and when they are forwarded again to your AMQP endpoint.

    • I would like to know what is the recommended way to send an event form the device to ditto?
    • Should one send it through live channels using events or messages (outbox)?

    When you talk about the "fire detected" event (containing a payload which shall not be stored in a twin managed by Ditto), I would send it as live message from the device (using Hono event channel with "QoS 1" - at least once - semantics).
    However, an application connected to Ditto (e.g. via Websocket or via HTTP webhook) must be consuming the live message and acknowledging that it received the message.

    Events in Ditto are the entity which is persisted as part of the CQRS architecture style. After persisting, interested parties can be notified about them.
    So live events are meant to be in the same Ditto event format and must not be confused with Hono events.

    • Is it better to define the event as a feature in the twin and send normal command/modify to its value?

    It depends on your requirements.
    You could also make the "fireDetected" a boolean property in a feature and subscribe to changes of this property. But then this should be only settable via the device (using an appropriate Ditto Policy) - and the "QoS 1" guarantees you get by combining Hono and Ditto cannot be used any longer.