openLuup: MQTT server
-
Any plans on a GUI for MQTT server control? i would love a status window with topics and activity.
For inspiration, this is Home Assistant:
Edit: This is really weird, I am not seeing the cpu load problem anymore. Just retried it... and it seems to work just fine. The CPU load is a little higher but by a few decimals. Not sure what happened previously.
-
Any plans on a GUI for MQTT server control? i would love a status window with topics and activity.
@perh said in openLuup: MQTT server:
Any plans on a GUI for MQTT server control? i would love a status window with topics and activity.
Er, yes. It's already there in the openLuup console Server pages. I added a new one for MQTT, from which I notice that the same client IP is subscribed twice. I've not yet implemented UNSUBSCRIBE !! (but will do so now.)
-
Ok, think i found an issue?
All I did in openluup was to start MQTT in the lua_startup.
Then tried to connect something, and suddenly it started running wild with alot of these messages (and CPU at 95%):
2021-02-12 17:50:51.847 luup.incoming_callback:: function: 0x55694ad24e40 ERROR: table: 0x55694b5b18a0 2021-02-12 17:50:51.847 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b2257c0 2021-02-12 17:50:51.847 luup.incoming_callback:: function: 0x55694ac43980 ERROR: table: 0x55694b2257c0 2021-02-12 17:50:51.847 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b225ea0 2021-02-12 17:50:51.847 luup.incoming_callback:: function: 0x55694ad24e40 ERROR: table: 0x55694b225ea0 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b13bae0 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ac43980 ERROR: table: 0x55694b13bae0 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b13c200 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ad24e40 ERROR: table: 0x55694b13c200 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b139d60 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ac43980 ERROR: table: 0x55694b139d60 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b13a440 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ad24e40 ERROR: table: 0x55694b13a440 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b9519a0 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ac43980 ERROR: table: 0x55694b9519a0 2021-02-12 17:50:51.848 openLuup.context_switch:: ERROR: [dev #0] table: 0x55694b952080 2021-02-12 17:50:51.848 luup.incoming_callback:: function: 0x55694ad24e40 ERROR: table: 0x55694b952080
When I stopped the sender (stopped the container it was running in), the errors kept coming until I reloaded luup.
The sender was this, which is a program that parses data from Tibber Pulse into JSON. Tibber Pulse sends instant power data from my house power input.
It has two tobpics, do i have to establish these in the broker first? -
Already a feature request: could the broker force users to use credentials like mosquitto does?
-
The server/broker needs no configuration aside from the port number (except, soon, for defining login credentials.)
The joy of MQTT is that you don’t need to know who is listening, where they are (IP address), who is sending, or what they’re sending. It’s just that if you’re subscribed to a topic, and someone publishes an application message with that topic, then you receive it.
-
The latest development release of openLuup, v21.2.16 should have fixed the error condition that you were seeing. I was using the socket.try() function incorrectly in an attempt to catch errors in a better way!
I’ve also fixed the multiple subscriber issue that I was seeing. Still some more to do, including login credentials, but would appreciate any feedback at this stage.
The Shelly bridge also seems to be working well with it... very responsive.
-
The latest development release of openLuup, v21.2.16 should have fixed the error condition that you were seeing. I was using the socket.try() function incorrectly in an attempt to catch errors in a better way!
I’ve also fixed the multiple subscriber issue that I was seeing. Still some more to do, including login credentials, but would appreciate any feedback at this stage.
The Shelly bridge also seems to be working well with it... very responsive.
Looking good so far! Will run more tests today.
Now I am thinking how much you could do by making the console an mqtt client and channel the console as a UI to openluup....
It is a minor thing but ALTUI, relying on regular http API polling, is actually pretty taxing on the server. If only it could use websocket or MQTT...
And z-way bridge could use this too! -
Yes, I know, I know... MQTT is so simple, but it opens up so many possibilities (and a lot more rewriting work to go along with that!)
I should update my ZWay installation and see what the MQTT server offers. The Shelly bridge is by far the simplest bridge implementation I've ever done, just because it uses MQTT.
BTW, I've implemented login credentials for the server and that'll be in the next release.
-
Hey AK,
Good to see you back in the saddle! I use MQTT quite a bit in Home Assistant and though I wanted to do the same in openLuup, the MQTT plugin was not cutting it for me as the polling was slow to catch updates. I too need credentials built in to the MQTT openLuup client as the latest docker mosquito build now more or less mandates a user name and PW. I have all my devices working with the updated broker so I don't want to roll back to test in openLuup. Let me know when you finish credentials and I'll pull down your changes.
-
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.
-
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.
@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.