openLuup: MQTT server
-
A couple of screen snaps that show an MQTT explorer http://mqtt-explorer.com/ connecting to Mosquitto, and to openLuup. No topics on openLuup but all topics on Mosquitto are displayed. Also, the UI for openLuup shows the connection to both machines--Mosquitto and explorer.
-
This post is deleted!
-
This post is deleted!
-
Thanks for those. So lots of things are working, it seems, but apparently (from the logs) not everything. I’ll give MQTT Explorer a go.
-
Yes, everything suggests that there are only minor issues to resolve. Try connecting to mosquitto on a machine running docker and docker compose (my compose cfg above is pretty solid). That should be informative.
-
I now have an alpha version of openLuup using MQTT to send ALL device variable status updates in real time. This beats the heck out of almost any other approach in terms of latency.
It publishes to topics named
openLuup/device_no/short_service_id/var_name
(where short_service_name is the useful part of the serviceId – ie. the last alphanumeric bit.) Here's a screen shot of MQTT Explorer watching this test system which is linked to a Vera. -
Awesome AK. This will integrate all my MQTT devices. Have you tackled the Mosquitto bridge issue.
-
akbooerreplied to Buxton on Mar 9, 2021, 9:04 PM last edited by akbooer Mar 9, 2021, 4:13 PM
@buxton said in openLuup: MQTT server:
Have you tackled the Mosquitto bridge issue.
There have been some refinements in the MQTT server implementation, but I couldn’t say that I’ve changed anything significant. I did voice some questions about your Mosquitto settings, but I’m not at all knowledgeable about Mosquitto, so I can’t really say. What I do believe is that the implementation is sufficiently compliant with the standard to be working really well with straightforward clients like the Shelly switches
(and the MQTT Explorer application.)Have you ever successfully bridged two Mosquitto instances?
-
OK --successfully bridged two Mosquitto instances -- yes. Comes right up. FYI influxdb 2.0 has removed auto graphite compatibility--that is according to their website. I don't know what changed. I do know that they are jumping on the must use credentials bandwagon, so I'm having to do a lot of research to get everything working again with the various containers that use influxdb as their repository.
-
Bridging: great. Any chance of finding out the chain of messages exchanged whilst bridging? Have you tried again with openLuup? My only thought is that is demands a QoS of greater than zero. A debug log would clarify.
InfluxDB: I’ve always used UDP to send data. Is that going away?
-
No, you can still configure UDP. You just need login credentials now.
If I have a few moments, I will try to set up one of my Pi machines this weekend with an instance of Mosquitto. My HA server that runs my docker Mosquitto is headless, and I run Ubuntu server, so command line captures of packets are just a drag. My Pi has an hdmi port so I should be able to load the gui version of wireshark, and then test/capture the traffic between the two instances. I will let you know.
-
@akbooer Below is the relevant output of a typical packet between mosquitto and a mosquitto bridged instance. In this case, mosquitto is sending update data to the bridge regarding a tasmota device/switch I use to remotely reboot my Vera. The format is definitely MQTT 3.1 and not 5.0, as 5.0 would not parse correctly in the wireshark viewer. The data payload is at the top of the window as Wireshark will truncate long messages. I can PM you the entire capture as it's not much, but may contain technical info that's best kept private. Let me know.
I'll try to capture some traffic between openLuup and mosquitto later.
{"Version":"9.1.0(tasmota)","BuildDateTime":"2020-11-07T11:57:45","Module or Template":"Gosund-WP5","RestartReason":"Software/System restart","Uptime":"6T05:50:22","Hostname":"power_MainVera-0278","IPAddress":"10.17.2.33","RSSI":"100","Signal (dBm)":"-17","WiFi LinkCount":5,"WiFi Downtime":"0T00:00:10","MqttCount":14,"LoadAvg":19} Frame 9: 433 bytes on wire (3464 bits), 433 bytes captured (3464 bits) on interface eth0, id 0 Ethernet II, Src: Advansus_0a:8c:3a (00:19:0f:0a:8c:3a), Dst: 96:62:08:fb:22:8a (96:62:08:fb:22:8a) Internet Protocol Version 4, Src: 10.17.2.41, Dst: 10.17.2.110 Transmission Control Protocol, Src Port: 40664, Dst Port: 1882, Seq: 3, Ack: 3, Len: 367 MQ Telemetry Transport Protocol, Publish Message Header Flags: 0x30, Message Type: Publish Message, QoS Level: At most once delivery (Fire and Forget) 0011 .... = Message Type: Publish Message (3) .... 0... = DUP Flag: Not set .... .00. = QoS Level: At most once delivery (Fire and Forget) (0) .... ...0 = Retain: Not set Msg Len: 364 Topic Length: 30 Topic: tele/power_MainVera/HASS_STATE Message [truncated--see above]: {"Version":"9.1.0(tasmota)","BuildDateTime":"2020-11-07T11:57:45","Module or Template":"Gosund-WP5","RestartReason":"Software/System restart","Uptime":"6T05:50:22","Hostname":"power_MainVera-0278","IPAddress":"10.17.2
-
@akbooer
And a ping response from bridge to main instance:Frame 33: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface eth0, id 0 Ethernet II, Src: 96:62:08:fb:22:8a (96:62:08:fb:22:8a), Dst: Advansus_0a:8c:3a (00:19:0f:0a:8c:3a) Internet Protocol Version 4, Src: 10.17.2.110, Dst: 10.17.2.41 Transmission Control Protocol, Src Port: 1882, Dst Port: 40664, Seq: 5, Ack: 2851, Len: 2 MQ Telemetry Transport Protocol, Ping Response Header Flags: 0xd0, Message Type: Ping Response 1101 .... = Message Type: Ping Response (13) .... 0000 = Reserved: 0 Msg Len: 0
-
The Connect packet:
MQ Telemetry Transport Protocol, Connect Command Header Flags: 0x10, Message Type: Connect Command Msg Len: 94 Protocol Name Length: 4 Protocol Name: MQTT Version: Unknown (132) Connect Flags: 0xec, User Name Flag, Password Flag, Will Retain, QoS Level: At least once delivery (Acknowledged deliver), Will Flag 1... .... = User Name Flag: Set .1.. .... = Password Flag: Set ..1. .... = Will Retain: Set ...0 1... = QoS Level: At least once delivery (Acknowledged deliver) (1) .... .1.. = Will Flag: Set .... ..0. = Clean Session Flag: Not set .... ...0 = (Reserved): Not set Keep Alive: 60 Client ID Length: 14 Client ID: Thing.MosquittoBridge Will Topic Length: 43 Will Topic: $SYS/broker/connection/Thing.MosquittoBridge/state Will Message Length: 1 Will Message: 0 User Name Length: 6 User Name: YYYYYY Password Length: 10 Password: XXXXXXXXXX
-
The connect ACK:
MQ Telemetry Transport Protocol, Connect Ack Header Flags: 0x20, Message Type: Connect Ack 0010 .... = Message Type: Connect Ack (2) .... 0000 = Reserved: 0 Msg Len: 2 Acknowledge Flags: 0x00 0000 000. = Reserved: Not set .... ...0 = Session Present: Not set Reason Code: Success (0)
-
@akbooer
The subscribe packet:Frame 156: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) on interface eth0, id 0 Ethernet II, Src: Advansus_0a:8c:3a (00:19:0f:0a:8c:3a), Dst: 96:62:08:fb:22:8a (96:62:08:fb:22:8a) Internet Protocol Version 4, Src: 10.17.2.41, Dst: 10.17.2.110 Transmission Control Protocol, Src Port: 36446, Dst Port: 1882, Seq: 147, Ack: 9, Len: 15 MQ Telemetry Transport Protocol, Unsubscribe Request Header Flags: 0xa2, Message Type: Unsubscribe Request 1010 .... = Message Type: Unsubscribe Request (10) .... 0010 = Reserved: 2 Msg Len: 5 Message Identifier: 2 Topic Length: 1 Topic: # MQ Telemetry Transport Protocol, Subscribe Request Header Flags: 0x82, Message Type: Subscribe Request 1000 .... = Message Type: Subscribe Request (8) .... 0010 = Reserved: 2 Msg Len: 6 Message Identifier: 3 Topic Length: 1 Topic: # Requested QoS: At most once delivery (Fire and Forget) (0)
-
Finally, the subscribe ACK:
MQ Telemetry Transport Protocol, Subscribe Ack Header Flags: 0x90, Message Type: Subscribe Ack 1001 .... = Message Type: Subscribe Ack (9) .... 0000 = Reserved: 0 Msg Len: 3 Message Identifier: 3 Reason Code: Granted QoS 0 (0)
44/179