Hi Julian.
Adding MQTT as additional channel / MessagingProvider to the Ditto client totally makes sense.
We already abstracted the MessagingProvider as interface for such additions:
https://github.com/eclipse/ditto-clients/blob/master/java/src/main/java/org/eclipse/ditto/client/messaging/MessagingProvider.java
So it should be possible to implement a MQTT based MessagingProvider in addition to the WebSocket one:
https://github.com/eclipse/ditto-clients/blob/master/java/src/main/java/org/eclipse/ditto/client/messaging/internal/WebSocketMessagingProvider.java
A few additional thoughts:
-
As MQTT 3.1.1 has no support for headers, setting something like a “reply-to” address (required for getting responses when sending commands from the client to Ditto)
or a “correlation-id” must be all part of the payload JSON (as “header” section in the Ditto Protocol, but this should already work)
-
Please use the HiveMQ MQTT client – and also the async API of that – because we already use that as well in the Ditto backend and don’t want to support another MQTT
client J
Would be great if you or your bachelor thesant starts working on this.
Mit freundlichen Grüßen / Best regards
Thomas Jaeckle
Engineering Cloud Services 1 Bosch IoT Things (INST/ECS1)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad |
GERMANY |
www.bosch.io
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling
From: ditto-dev-bounces@xxxxxxxxxxx <ditto-dev-bounces@xxxxxxxxxxx>
On Behalf Of Julian Feinauer
Sent: Mittwoch, 15. Januar 2020 08:18
To: ditto developer discussions <ditto-dev@xxxxxxxxxxx>; Musti El-Sari <musti-@xxxxxxx>
Subject: [ditto-dev] Support for MQTT in ditto-client
Hi all,
in my example for plc4x and ditto I used the ditto-client project as its awesome, easy and typesafe handling of ditto json messages.
But as discussed in Gitter for a real world example the transport from the edge gateway next to the PLC to the ditto instance should happen over some kind of messaging system (we usually
use MQTT and already have it in place in multiple facilities).
Thus, could we simply add a Provider for MQTT and enable MQTT transport that way via the ditto-client or are there any considerations I am missing in my thoughts?
Or are there even plans to implement that already?
We have the luck that
@Musti El-Sari just joined us to write his BA Thesis on this topic, so he could jump in a bit, I guess and it would be more sustainable
than just concatenating jsons on our own.
What do you think?
Julian