openLuup: MQTT server
-
Sounds like we need just a small extension to the Virtual HTTP device plugin? Let's ask @therealdb
-
Hi @akbooer , I installed the latest developement version of openLuup and have enabled mqtt on an I3 shelly device, I have not set any user or password. The issue I have is that openluup has not discovered the device. In the mqqt server page I have 1 internal mqtt connection and the publised/messages/ received is currently at 24000. I have set port in startup lua to 1884 and shelly is configured to 1884. Any Idea of my error may be?
-
Sounds like we need just a small extension to the Virtual HTTP device plugin? Let's ask @therealdb
@akbooer said in openLuup: MQTT server:
Sounds like we need just a small extension to the Virtual HTTP device plugin? Let's ask @therealdb
I was thinking of adding special support for mqtt under openluup, with protocol handler mqtt:// under virtual device for actions. This will work for you?
-
What settings have you used in your Lua Startup to enable the MQTT server? Specifically, have you set openLuup.MQTT.Port?
-
...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.
-
...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.