openLuup: MQTT server
-
I’m using LuaJIT in development, so that’s one of the systems I am testing under. That typically runs at 0.2% CPU, as does the system on my Synology NAS, although I seem to be having a few issues there with IP address mapping. Are you running this under a VM?
-
I’m using LuaJIT in development, so that’s one of the systems I am testing under. That typically runs at 0.2% CPU, as does the system on my Synology NAS, although I seem to be having a few issues there with IP address mapping. Are you running this under a VM?
Yes I am running in inside a VM. I am not having any IP address mapping issues though... puzzling.
See my openLuup cpu load. I am also checking it with "top" and the openLuup process goes nuts hovering between 87% and 92% when I uncomment the server launch code from the lua startup. Commenting it brings the CPU load back to normal.
-
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.