openLuup email server

[akbooer]

OK, thanks for that. You can turn on extra debug log messages with this Lua Startup line

luup.openLuup.mqtt.ABOUT.DEBUG = true

[akbooer]

@Buxton

Also been looking at the Mosquitto configuration documentation here (the section on Bridging Controllers):

mosquitto.conf man page

I note that there are username/password defaults which may not be appropriate.

It’s also possible that it relies on some $SYS topics, but debug logging should show this. I’d like to see the log of the original connection from your broker.

[Buxton]

The mosquitto log just shows the connection attempts. In the below, my mosquitto bridge is named openLuup and I'm running openLuup on the same machine as my docker host so the IP address is the same--10.17.2.40. Port 1882 is the openLuup MQTT port

1614713171: Connecting bridge openLuup (10.17.2.40:1882)
1614713237: Connecting bridge openLuup (10.17.2.40:1882)
1614713303: Connecting bridge openLuup (10.17.2.40:1882)
1614713369: Connecting bridge openLuup (10.17.2.40:1882)
1614713435: Connecting bridge openLuup (10.17.2.40:1882)

The docker compose file is below. I had to change to "network_mode: host" as that was the only way to forward the machine host IP address to openLuup. My other MQTT clients specify the broker IP in a device field, so there was no need to expose the entire container before.

mosquitto:
container_name: mosquitto
image: eclipse-mosquitto:latest
restart: always
depends_on:

• hass

expose:

- "1883"

- "9001"

ports:

- "1883:1883"

- "9001:9001"

network_mode: host
volumes:

• /home/kevinb/mosquitto/data:/mosquitto/data
• /home/kevinb/mosquitto/config/mosquitto.conf:/mosquitto/config/mosquitto.conf
• /home/kevinb/mosquitto/log:/mosquitto/log
  environment:
• TZ=US/Pacific

The mosquitto config is below:

allow_anonymous true
password_file /mosquitto/config/PW.txt
listener 1883
connection openLuup
address 10.17.2.40:1882
topic # out 0
topic # in 0
cleansession false
notifications true
username yyyyyyy
password xxxxxxx

I will check packets later with wireshark when I have some free time.
Thx

[Buxton]

LOL the large font above is from using a pound sign to comment out the line.

[akbooer]

Not sure it will make any difference, but I would try with clean session as true. Have you set the right username and password in the openLuup startup?

[Buxton]

yes pw and name are correct. Occasionally I'm seeing this in the logs:

2021-03-02 14:27:47.824 openLuup.mqtt:: CONNECT: Protocol level is not 3.1.1 '132' tcp{client}: 0x557f03015048

I tweaked the code in MQTT.lua to include the error code on the error return. If you're using Connack codes, 132 translates to: "Unsupported protocol version".

[akbooer]

Well, that error would explain it.

...although 132 doesn’t make any sense to me.

[Buxton]

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.

[Buxton]

This post is deleted!

[Buxton]

This post is deleted!

[rafale77]

@buxton

Seems to work for me. Are you using the button on the right highlighted below?

[Buxton]

@rafale77 Ah! The problem was I was not using reply. Will try again below:

[akbooer]

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.

[Buxton]

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.

[akbooer]

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.

[therealdb]

that's huge @akbooer! I'll trying to use it in production next week, hopefully. I've been very busy lately, unfortunately.

[Buxton]

Awesome AK. This will integrate all my MQTT devices. Have you tackled the Mosquitto bridge issue.

[akbooer]

@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?

[Buxton]

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.

[akbooer]

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?