openLuup: MQTT server
-
...and when you say "enabled mqtt on an I3 shelly device", that means that you have also set the Server IP parameter of the Shelly device to point to the openLuup IP and the 1884 port:
(for me it's 1883)
and you are just keeping all the other defaults on Shelly?
I'd like to see the main log after a system reload, preferably for a few minutes to give the Shelly time to update its status over MQTT.
@akbooer
the device is configured as
and log shows
openLuup.historian:: using memory cache size (per-variable): 1024 2021-04-13 21:09:55.722 luup.register_handler:: global_function_name=Shelly_MQTT_Handler, request=mqtt:shellies/# 2021-04-13 21:09:55.737 luup.register_handler:: global_function_name=Tasmota_MQTT_Handler, request=mqtt:tele/# 2021-04-13 21:09:55.738 luup.register_handler:: global_function_name=Tasmota_MQTT_Handler, request=mqtt:cmnd/# 2021-04-13 21:09:55.738 luup.register_handler:: global_function_name=Tasmota_MQTT_Handler, request=mqtt:stat/# 2021-04-13 21:09:55.739 openLuup.io.server:: starting MQTT:1884 server on port: 1884 tcp{server}: 0xf3f88c8 2021-04-13 21:09:55.744 openLuup.scheduler:: starting 2021-04-13 21:09:55.747 openLuup.scheduler:: [2] openLuup device startup 2021-04-13 21:09:55.748 luup_log:2: v21.4.8 2021-04-13 21:09:55.749 luup_log:2: sync in 4.3 s 2021-04-13 21:09:55.751 luup.variable_watch:: callback=housemode_watcher, watching=2.openLuup.HouseMode 2021-04-13 21:09:55.751 luup.register_handler:: global_function_name=openLuup_email, request=openLuup@openLuup.local 2021-04-13 21:09:55.752 luup.register_handler:: global_function_name=openLuup_images, request=images@openLuup.local 2021-04-13 21:09:55.753 luup.register_handler:: global_function_name=openLuup_events, request=events@openLuup.local 2021-04-13 21:09:55.754 luup.register_handler:: global_function_name=openLuup_mailbox, request=mail@openLuup.local 2021-04-13 21:09:55.754 luup.chdev.append:: [AltAppStore] Alternate App Store 2021-04-13 21:09:55.755 luup.chdev.sync:: [2] openLuup, syncing children 2021-04-13 21:09:55.756 luup_log:2: starting MQTT $SYS/broker statistics 2021-04-13 21:09:55.760 luup_log:2: 7Mb, 1.2%cpu, 0.0days
no other mention of mqtt.
this is from reload of luup and waiting 5 mins.
-
OK after a couple more reloads, I have success in getting shelly bridge to load in altui. All I changed was the the name to a custom name. tried giving an extra path e.g. "shellix3/name". That half worked and openluup installed the bridge, but half the variables were missing. I then tried shellyix3-name and all fired up.
Cheers for replies. -
I'm just thinking that generally, the functionality will probably reach out to more people without editing code to make it work.
Say you have a Plugin device called MQTT server, with a control panel with an "Enable server" button. (This could offcourse just happen when you add the plugin in "plugins" tab, like with Vera Bridge?)
Below could have a table list of registered topics and subscriptions (and attached child device, if existing), with the possibility to add/remove/ignore?
A button for "Create Device" with entrys for "Device type", "topic", ... <-whatever you need to assign the recieved/sent value to a sensor/button.Again, i'm not fully versed in how this works yet, "just spitballing".
@perh said in openLuup: MQTT server:
A button for "Create Device" with entrys for "Device type", "topic", ... <-whatever you need to assign the recieved/sent value to a sensor/button.
Would you be more interested into the UI part (I've never really coded anything in particular, but it's probably time to start...) or the raw features (ie: changing some very simple parameters?).
The latter is pretty easy and I'll probably have a working build for sensors and switches/dimmers pretty soon.
-
@perh said in openLuup: MQTT server:
A button for "Create Device" with entrys for "Device type", "topic", ... <-whatever you need to assign the recieved/sent value to a sensor/button.
Would you be more interested into the UI part (I've never really coded anything in particular, but it's probably time to start...) or the raw features (ie: changing some very simple parameters?).
The latter is pretty easy and I'll probably have a working build for sensors and switches/dimmers pretty soon.
Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done
You can mix and match different kind of commands (lua, mqtt, http, curl, etc).
I'll try to do some refactoring in order to use a common lib for all this virtual devices, then backport this to all of them, then start adding watches, so we could subscribe to mqtt messages and update variables. @PerH @akbooer
-
@perh said in openLuup: MQTT server:
A button for "Create Device" with entrys for "Device type", "topic", ... <-whatever you need to assign the recieved/sent value to a sensor/button.
Would you be more interested into the UI part (I've never really coded anything in particular, but it's probably time to start...) or the raw features (ie: changing some very simple parameters?).
The latter is pretty easy and I'll probably have a working build for sensors and switches/dimmers pretty soon.
@therealdb
I'm just thinking that the UI would enable people not familiar with MQTT or its nomenclature to use it.. Not having to go to lua code would definately be a step in the right direction.Mabye with some "proof reading" on the input too? as pop-ups if theres illegal characters and so on.
-
@therealdb
I'm just thinking that the UI would enable people not familiar with MQTT or its nomenclature to use it.. Not having to go to lua code would definately be a step in the right direction.Mabye with some "proof reading" on the input too? as pop-ups if theres illegal characters and so on.
@perh I could definitely develop a configuration page. It's on my TODO list since the first alpha was out. I'll try to write the code to support this feature first, then try to implement a configuration page and finally close the gap, since these devices have a lot of capabilities, but you'll need to configure them manually - and that's the same problem with yaml and Home Assistant, for example.
-
Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done
You can mix and match different kind of commands (lua, mqtt, http, curl, etc).
I'll try to do some refactoring in order to use a common lib for all this virtual devices, then backport this to all of them, then start adding watches, so we could subscribe to mqtt messages and update variables. @PerH @akbooer
@therealdb said in openLuup: MQTT server:
Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done
That's great. Glad we asked! ... saved me a lot of work
-
Hey AK, per the above about configuration options, it seems to me that a console page displaying every single topic that arrives at openLuup is the way to start the configuration process. Perhaps with a clickable sort option based on topic or prefix. I'm thinking of a checkbox to the left of a list of topics that allows one to subscribe, with the most current message displayed just underneath the topic syntax. So a two line notation for every topic. Then a second checkbox called purge for old obsolete topics that are no longer used (which would vanish on a luup reload).
A subscription table should eliminate hard coded prefixes in the Tasmota bridge as the bridge would create generic MQTT "devices" based on what topic name you subscribe to. From there, you can create sensors, switches etc based on what you want to pull from the MQTT device.
-
@therealdb said in openLuup: MQTT server:
Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done
That's great. Glad we asked! ... saved me a lot of work
I downloaded the latest development version 21.4.25 and am now seeing the following behavior where the AltUi tags/category etc disappear from the device page:
Here is the same screen shot using the master branch 20.5.22. This was captured only minutes later when I downgraded to the master branch:
As well, I'm seeing receive errors again in the log for the MQTT connection to mosquitto. These errors were not present in 21.4.18 but an update to 21.4.25 shows them back with my Mosquitto connection flopping with each error..... is there any way I can revert to 21.4.18. I tried a couple of different syntax changes in the plugin update field, but I can't pull any development version except for the current one.
-
@therealdb said in openLuup: MQTT server:
Ok, I've just prototyped a way to send a message on actions and I'm happy to report it's done
That's great. Glad we asked! ... saved me a lot of work
@akbooer As best as I can tell, the mqtt.incoming function is being sent nil values, so you go straight to the error handler because "client" is nil and therefore "message" is nil. Debug code below:
local message, errmsg = MQTT_packet.receive (client) local sClient, sMessage, sCredentials, sSubscriptions = unpack(client), unpack(message), unpack(credentials), unpack(subscriptions) if sClient == nil then sClient = "nil" end if sMessage == nil then sMessage = "nil" end if sCredentials == nil then sCredentials = "nil" end if sSubscriptions == nil then sSubscriptions = "nil" end _log ( "client " .. sClient .. " message " .. sMessage .. " creds " .. sCredentials .. " subs ".. sSubscriptions)
Creates the following sample log message:
2021-04-25 18:51:22.332 luup.tasmota:262: Topic ignored : tele/power_BedroomTV/INFO2 : {"WebServerMode":"Admin","Hostname":"power_BedroomTV-4552","IPAddress":"10.17.2.28"} 2021-04-25 18:51:22.333 openLuup.mqtt:: client nil message nil creds nil subs nil
2021-04-25 19:00:44.833 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55fd83233948
-
I downloaded the latest development version 21.4.25 and am now seeing the following behavior where the AltUi tags/category etc disappear from the device page:
Here is the same screen shot using the master branch 20.5.22. This was captured only minutes later when I downgraded to the master branch:
As well, I'm seeing receive errors again in the log for the MQTT connection to mosquitto. These errors were not present in 21.4.18 but an update to 21.4.25 shows them back with my Mosquitto connection flopping with each error..... is there any way I can revert to 21.4.18. I tried a couple of different syntax changes in the plugin update field, but I can't pull any development version except for the current one.
@buxton I can confirm the same problem. Om my test Pi running v21.4.25 (and AltUi 2.53c) the AltUi tags are missing and on my main server still running v21.4.18 the tags are there.
I do not however have any new Mqtt errors on the v21.4.25 server, but then I am not connecting to mosquitto either.
-
OK, apologies to all. I obviously need to improve my pre-release testing in this area. I don’t use AltUI much these days, and it’s hard to automate tests. I’m not seeing any MQTT errors, either.
I will tag the earlier release so that you can revert. Will let you know when that’s done.
Sorry, again.
-
FWIW, I've now updated, and hopefully corrected, the code – v21.4.26 is the latest development version. So, I'd be very grateful if anyone is brave enough to test this.
I'm really glad of this error being highlighted, beause it's caused me to re-think somewhat the openLuup object API, and I'm rather happier with the outcome now. No guarantees, of course, that this fixes all the problems, but I hope that it is a step in the right direction.
PS: One of my systems exhibited the AltUI missing buttons, but, curiously, one did not. However, they both appear to work OK after this update.
-
FWIW, I've now updated, and hopefully corrected, the code – v21.4.26 is the latest development version. So, I'd be very grateful if anyone is brave enough to test this.
I'm really glad of this error being highlighted, beause it's caused me to re-think somewhat the openLuup object API, and I'm rather happier with the outcome now. No guarantees, of course, that this fixes all the problems, but I hope that it is a step in the right direction.
PS: One of my systems exhibited the AltUI missing buttons, but, curiously, one did not. However, they both appear to work OK after this update.
-
Yes, that's correct. It effectively rips out some recent changes which now don't fit with the roadmap forward.
I had previously been adding, partially hidden, features to the usual luup API. My plan now is to freeze the functionality of that API (which is what third-party plugins use, including AltUI) but to extend the underlying openLuup object-oriented API. In doing so, I hope to minimize the chance of breaking working plugins.
In this particular case, the changes have been to 'virtualize' device variables so that they can now be addressed directly as program variables, rather than having to resort to get/set functions. The Shelly and Tasmota bridges use this approach.