openLuup: Tasmota MQTT Bridge
-
Feedback / solutions for openLuup's built-in Tasmota MQTT bridge.
-
@akbooer I have now set up a clean install of OpenLuup on my Pi running Zway bridge and two Tasmota devices reporting over Mqtt. The Zway bridge links "165 vDevs, 64 zNodes". No Veras linked. No errors in the log file.
This is the traffic after approximately 6 hours:
We will see how it goes, so far it looks ok. At the moment I have not installed lua-cjson. CPU load is staying slightly above 10%, i.e. quite high.
Running OpenLuup v21.4.8d and Zway bridge v21.1.19.
-
Has the Tasmota bridge appeared as a device? At the moment it’s just an empty shell.
-
OK, which two devices are you using? I"ll try and implement them first.
-
@akbooer a suitable type of Tasmota device to test with would be an AM2301 device reporting temp and humidity:
tele/tasmota_7FA953/SENSOR = {"Time":"2021-04-13T21:18:28","AM2301":{"Temperature":15.6,"Humidity":44.7,"DewPoint":3.6},"TempUnit":"C"}
I have a few of these that I could use for testing the bridge.
The ones I have set up now are two devices each containing a BME280 sensor (temp, hum, air pressure) and a MHZ19B sensor (CO2):
tele/TasmotaCO2An/SENSOR = {"Time":"2021-04-13T21:17:20","BME280":{"Temperature":22.1,"Humidity":41.5,"DewPoint":8.4,"Pressure":1017.5},"MHZ19B":{"Model":"B","CarbonDioxide":806,"Temperature":46.0},"PressureUnit":"hPa","TempUnit":"C"}
I could test with these also.
(The temp value of the MHZ19B is rubbish, I think it is the internal temp in the sensor or something, so I do not use it.)
-
I've set this up as a new openLuup topic. The latest development version v21.4.14 has filled in some of the Tasmota infrastructure so that tele/# topics should force the creation of new devices and the variables will be extracted from the JSON message.
This needs further work to create standard serviceId/variables and possibly specific child devices, but I'd be interested in how it looks for a start (again, I currently have no Tasmotas, but MQTT makes it easy to pretend!)
-
@akbooer I've already sent a couple of announcements in the other post. IMHO discovery messages should be preferred.
tasmota/discovery/ABC/sensors {"sn":{"Time":"2021-04-05T11:49:16","DS18B20":{"Id":"3C01D6070BEA","Temperature":15.1},"SR04":{"Distance":58.456},"TempUnit":"C"},"ver":1}``
tasmota/discovery/ABC/config {"ip":"192.168.1.53","dn":"tasmota-watertank","fn":["tasmota-watertank",null,null,null,null,null,null,null],"hn":"tasmota-watertank","mac":"ABC","md":"Generic","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.3.1","t":"tasmota-watertank","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[0,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":1,"lt_st":0,"sho":[0,0,0,0],"ver":1}
As you could see, the config will send all the supported commands, topics, sw version, etc.
Moree info here: https://tasmota.github.io/docs/MQTT/#mqtt-topic-definition
-
Yes, thanks. I'm not precluding anything, but just started with the telemetry, since that's where the updates are.
-
ArcherSreplied to akbooer on Apr 14, 2021, 4:22 PM last edited by ArcherS Apr 14, 2021, 12:43 PM
@akbooer I installed v21.4.14 and it looks really nice, well done.
At first I did not find the two Tasmota devices, but then I found them in the room "Tasmota" that I already had made!
The devices seem to behave as they should, I will check over time.
Combined with the GUI in the Virtual Sensor plugin from @toggledbits it is now really easy to link the desired variables to a virtual sensor.
In total a really user friendly setup without any coding required.
The system load stayed the same as when I had the devices mapped via luup handlers, which I assume is expected. On my Pi that also has a Zway bridge on it the cpu load without cjson is approx 10.5%. I think the Zway bridge is costing a bit of cpu actually, it is quite active.
I will add some more Tasmota devices and see how it works.
-
@akbooer I have set up seven Tasmota devices reporting various data and it seems to work.
I do however get the following errors in the log:
2021-04-14 19:39:10.020 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 19:39:10.020 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaTest/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 19:39:10.071 luup.watch_callback:: 20004.AM2301.Humidity called [9]virtualSensorWatchCallback() function: 0xb1cf28 2021-04-14 19:39:10.072 luup.variable_set:: 28.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousRawValue was: 40.7 now: 40.5 #hooks:0 2021-04-14 19:39:10.072 luup.variable_set:: 28.urn:toggledbits-com:serviceId:VirtualSensor1.RawValue was: 40.5 now: 40.4 #hooks:0 2021-04-14 19:39:10.072 luup.variable_set:: 28.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 40.5 now: 40.4 #hooks:0 2021-04-14 19:39:10.073 luup.variable_set:: 28.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousValue was: 40.7 now: 40.5 #hooks:0 2021-04-14 19:39:10.073 luup.variable_set:: 28.urn:toggledbits-com:serviceId:VirtualSensor1.LastUpdate was: 1618421890 now: 1618421950 #hooks:0 2021-04-14 19:39:10.073 luup.watch_callback:: 20004.AM2301.Temperature called [9]virtualSensorWatchCallback() function: 0xb1cf28 2021-04-14 19:39:10.074 luup.watch_callback:: 20004.TasmotaTest.Time called [9]virtualSensorWatchCallback() function: 0xb1cf28 2021-04-14 19:39:10.465 openLuup.server:: request completed (3239 bytes, 1 chunks, 2133 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:10.477 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/humidity_sensor_default.png HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:10.477 openLuup.server:: request completed (0 bytes, 0 chunks, 0 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:10.592 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018566&Timeout=60&MinimumDelay=1500&_=1618416957720 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:12.814 openLuup.server:: request completed (1210 bytes, 1 chunks, 2221 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:12.933 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018568&Timeout=60&MinimumDelay=1500&_=1618416957721 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:15.631 openLuup.server:: request completed (1210 bytes, 1 chunks, 2697 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:15.757 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018570&Timeout=60&MinimumDelay=1500&_=1618416957722 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:18.080 openLuup.server:: request completed (1210 bytes, 1 chunks, 2322 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:18.202 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018572&Timeout=60&MinimumDelay=1500&_=1618416957723 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:20.463 openLuup.server:: request completed (1210 bytes, 1 chunks, 2261 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:20.576 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018574&Timeout=60&MinimumDelay=1500&_=1618416957724 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:23.362 openLuup.server:: request completed (1210 bytes, 1 chunks, 2785 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:23.490 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018576&Timeout=60&MinimumDelay=1500&_=1618416957725 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:25.785 openLuup.server:: request completed (1210 bytes, 1 chunks, 2295 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:25.903 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018578&Timeout=60&MinimumDelay=1500&_=1618416957726 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:28.206 openLuup.server:: request completed (1210 bytes, 1 chunks, 2303 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:28.327 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018580&Timeout=60&MinimumDelay=1500&_=1618416957727 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:30.474 openLuup.server:: request completed (1210 bytes, 1 chunks, 2146 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:30.597 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018582&Timeout=60&MinimumDelay=1500&_=1618416957728 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:32.848 openLuup.server:: request completed (1210 bytes, 1 chunks, 2250 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:32.977 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018584&Timeout=60&MinimumDelay=1500&_=1618416957729 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:34.831 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 19:39:34.831 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaUterum/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 19:39:34.841 luup.watch_callback:: 20003.AM2301.Humidity called [9]virtualSensorWatchCallback() function: 0xb1cf28 2021-04-14 19:39:34.842 luup.variable_set:: 26.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousRawValue was: 38 now: 38.1 #hooks:0 2021-04-14 19:39:34.843 luup.variable_set:: 26.urn:toggledbits-com:serviceId:VirtualSensor1.RawValue was: 38.1 now: 38 #hooks:0 2021-04-14 19:39:34.843 luup.variable_set:: 26.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 38.1 now: 38 #hooks:0 2021-04-14 19:39:34.844 luup.variable_set:: 26.urn:toggledbits-com:serviceId:VirtualSensor1.PreviousValue was: 38 now: 38.1 #hooks:0 2021-04-14 19:39:34.844 luup.variable_set:: 26.urn:toggledbits-com:serviceId:VirtualSensor1.LastUpdate was: 1618421706 now: 1618421974 #hooks:0 2021-04-14 19:39:34.844 luup.watch_callback:: 20003.AM2301.Temperature called [9]virtualSensorWatchCallback() function: 0xb1cf28 2021-04-14 19:39:35.152 openLuup.server:: request completed (2848 bytes, 1 chunks, 2175 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:35.168 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/humidity_sensor_default.png HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:35.169 openLuup.server:: request completed (0 bytes, 0 chunks, 0 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:35.387 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018598&Timeout=60&MinimumDelay=1500&_=1618416957730 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:35.493 openLuup.server:: request completed (1210 bytes, 1 chunks, 105 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:35.615 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018600&Timeout=60&MinimumDelay=1500&_=1618416957731 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:37.882 openLuup.server:: request completed (1210 bytes, 1 chunks, 2266 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:38.002 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018602&Timeout=60&MinimumDelay=1500&_=1618416957732 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:40.289 openLuup.server:: request completed (1210 bytes, 1 chunks, 2286 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:40.402 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018604&Timeout=60&MinimumDelay=1500&_=1618416957733 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:42.661 openLuup.server:: request completed (1210 bytes, 1 chunks, 2259 ms) tcp{client}: 0xe227b0 2021-04-14 19:39:42.770 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=420018606&Timeout=60&MinimumDelay=1500&_=1618416957734 HTTP/1.1 tcp{client}: 0xe227b0 2021-04-14 19:39:44.412 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 19:39:44.412 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaCO2An/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil
The errors come in pairs, two for each Tasmota device continuously with other entries in between.
-
Would love to test Tasmota, but my devices are in working state, and connected to a mosquitto server. I was wondering if MQTT openLuup can be bridged?
-
Well I tried a simple bridge in the mosquitto config file with no luck. What did i miss?
connection bridgemqtt1
address 192.158.0.40:1884
topic # both 0[edit] Nevermind i failed to restart using -c mosquitto.conf
-
@archers said in openLuup: Tasmota MQTT Bridge:
I think the Zway bridge is costing a bit of cpu actually, it is quite active.
Do you have it running in asynchronous mode? Do you have CJson installed yet?
@archers said in openLuup: Tasmota MQTT Bridge:
I do however get the following errors in the log:
OK, I'll take a look. Do you have an example of the message posted which causes the error?
Otherwise, things seem to be going fairly well...
@archers said in openLuup: Tasmota MQTT Bridge:
Combined with the GUI in the Virtual Sensor plugin from @toggledbits it is now really easy to link the desired variables to a virtual sensor.
In total a really user friendly setup without any coding required.This is really good news, and perhaps means that I don't need to refine the variables further or create any child devices?
-
@akbooer I have "AsyncPoll" true on the Zway Bridge, I assume that means that it is in asynchronuous mode? Or should I check something else?
No, I have yet to install cjson. This was actually intentional since I wanted to test it without this first and see if it works. On my main OpenLuup server that has experienced crashes I have cjson installed so I wanted to test without cjson first. But I should test this later on and see what happens to the cpu load.
Regarding cpu load it has not gone up that much when comparing running one Tasmota vs running seven which is promising.I am not sure what message that causes the error, do you have any ideas what I should look for in the log or elsewhere? It mentions "TasmotaBridge.Lua:188 table index is nil" in all errors for the devices.
The errors always says:
2021-04-14 21:19:10.214 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 21:19:10.214 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaTest/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil
and it seems to cycle through my Tasmota devices reporting the same two rows but for each device:
2021-04-14 21:35:10.064 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 21:35:10.065 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaTest/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil ... 2021-04-14 21:35:42.864 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 21:35:42.865 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaUterum/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil ... 2021-04-14 21:35:44.637 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 21:35:44.637 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaCO2An/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil ... 2021-04-14 21:35:44.844 openLuup.context_switch:: ERROR: [dev #14] openLuup/L_TasmotaBridge.lua:188: table index is nil 2021-04-14 21:35:44.844 openLuup.mqtt:: ERROR publishing application message for mqtt:tele/TasmotaCO2Ax/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil
Yes I agree, it seems to be going well.
No, I think it is quite good the way it is, creating Virtual Sensors and then linking them to the devices/variables is very easy. It only takes a few minutes to add a new Tasmota device from scratch without any coding at all.
In fact I think it is better this way since typically you do not want all of the reported values as a child device, e.g. you do not want "Dew point" or "Time", the useless MHZ19B temperature etc. This way you can select only what you want, not getting OpenLuup cluttered by a lot of "useless" child devices. -
@akbooer, I have bridged the 2 brokers but not seeing any Tasmota bridge I see the mosquitto bridge in the openluup log no errors. My topics are
tasmota/stat/devicename/POWER
The devices are sonoff mini's flashed with tasmota-lite.bin. Any ideas? -
@elcid said in openLuup: Tasmota MQTT Bridge:
My topics are tasmota/stat/devicename/POWER
So, at the moment, I have only subscribed to
tele/#
, so that's why you're not seeing anything.I can make this configurable, but what does a message look like with this topic?
-
@akbooer
Ask the device for statuscmnd/tasmota_switch/Power ← // an empty message/payload sends a status query ↳ stat/tasmota_switch/RESULT → {"POWER":"OFF"} ↳ stat/tasmota_switch/POWER → OFF We can see that the switch (devices relay) is turned off. Send a command to toggle the relay~ cmnd/tasmota_switch/Power ← "TOGGLE" ↳ // Power for relay 1 is toggled ↳ stat/tasmota_switch/RESULT → {"POWER":"ON"} ↳ stat/tasmota_switch/POWER → ON
I have appended th tasmota at the start of the topic in my tasmota device settings.
-
ATM the bridge doesn't solicit any response from the devices. Indeed, it would have to discover them first in order to do so. So at this time, if the device does not sent regular tele/ updates, then it won't be seen. This is early days for the bridge.
4/127