|Re: [ditto-dev] Support for MQTT in ditto-client|
Adding MQTT as additional channel / MessagingProvider to the Ditto client totally makes sense.
We already abstracted the MessagingProvider as interface for such additions:
So it should be possible to implement a MQTT based MessagingProvider in addition to the WebSocket one:
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
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?
Back to the top