openLuup: MQTT server
-
I just tested the broker and... the cpu utilization went from 1.5% to 90%... only getting home assistant connected to it without even subscribing a topic...
-
Interesting. I've tried it on three different systems and not seen this. Anything available from the log?
I should say, though, that the only MQTT clients I have been able to test with so far are the Shellies themselves.
-
The odd thing is that it seems to work fine. I am manually testing by sending messages from a mosquitto client command line tool. I reverted back to the mosquitto broker which uses <0.1% CPU. Could it be because I am using luajit?
-
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.
-
I updated to dev branch and added
luup.attr_set ("openLuup.MQTT.Port", 1883)to LUA startup on my docker project machine now.
Stays at about .2 CPU here.. I'll try to get some data in later. -
Any plans on a GUI for MQTT server control? i would love a status window with topics and activity.
-
rafale77replied to PerH on Feb 12, 2021, 3:41 PM last edited by rafale77 Feb 12, 2021, 10:47 AM
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.
-
I'll test it over the week-end, since snow is expected. I'll just relay all the traffic from my broker. I'll report back soon.
-
@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: 0x55694b952080When 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?
-
@rafale77 said in openLuup: MQTT server:
could the broker force users to use credentials like mosquitto does?
Absolutely not a problem. How would you like to be able to specify the credentials.
On your other problem... I’m working on it.
-
Credentials: Could be attributes of openLuup? somehow encoded?
-
Question: does the broker have to have the topics ready, or will it create them when some unit connects with topics?
-
I believe topics are created by subscribers/publishers. They are a "header" to the "message".
-
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.
-
Sounds good, Will get on it in the next few hours. I just finished refactoring a bunch of my scene lua code moving a couple of global state variables into virtual switch devices. I am trying to not convolute too many changes.
-
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!
11/179
