openLuup email server

[akbooer]

Hi there,

Oh, they’re there already...

@akbooer said in openLuup: Version Log:

Development Branch: 2021 Release 2.18

MQTT server now supports login credentials.

To set Username and Password for MQTT connections use the following commands in Lua Startup:

luup.attr_set ("openLuup.MQTT.Username", "---username---")
luup.attr_set ("openLuup.MQTT.Password", "---password---")

Note, though, that this implementation in openLuup is an MQTT server (broker) and not a client.

[Buxton]

@akbooer ok thx. Mosquito allows bridging so I need to play around with things to see what works best. The goal will be virtual switches in openLuup that will map completely to my tasmota devices. That way I can integrate things like reactor with MQTT traffic.

[akbooer]

That should work, although I’ve not tried it. The handling of Shelly virtual devices with MQTT is very slick, so hopefully you’ll have a similar experience.

[Buxton]

I get a partial connection:

2021-03-01 23:01:15.829 openLuup.io.server:: MQTT:1882 connection closed tcp{client}: 0x559e58efeff8
2021-03-01 23:01:15.829 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x559e58efeff8
2021-03-01 23:01:21.819 openLuup.io.server:: MQTT:1882 connection from 10.17.2.40 tcp{client}: 0x559e583ea0b8

It took a while to get that far as networking with docker can be difficult, and mosquitto was passing its container network address to openLuup--an address that is on a completely different subnet to the host machine running docker. Anyway, this is about as far as I can go with out some sort of packet analysis.

[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.