openweather plugin ?

[Elcid]

@akbooer
There is a tele topic. Sorry about the image as the App would not let me copy the text.
and there is also a -
tasmota/tele/name/LWT with message "Online"

[akbooer]

OK, well that will work if I add configuration for your optional ‘Tasmota’ prefix.

[Elcid]

I added the prefix for future use so i could group devices by type (sensor/switch/dimmer/etc) as i will filter topics by type of device i want to subscribe to. So it would be nice to have a list of prefixes, if it is possible.

[Buxton]

@akbooer Good start on my end. Here's a pic of one device that shows three Bluetooth temp/humidity sensors (LYWSD...) that connect to a Tasmota relay:

You may need to decode a layer deeper for the "table" entries....

I do have a bunch of error messages in the log, but I will have to get into that on the weekend as I'm currently buried with work work....

Here's a snippet though:

2021-04-14 20:11:13.634   openLuup.context_switch::  ERROR: [dev #262] openLuup/L_TasmotaBridge.lua:188: table index is nil
2021-04-14 20:11:13.634   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/BLE : openLuup/L_TasmotaBridge.lua:188: table index is nil
2021-04-14 20:11:14.044   openLuup.server:: request completed (1490 bytes, 1 chunks, 1280 ms) tcp{client}: 0x5619338130b8
2021-04-14 20:11:14.642   openLuup.context_switch::  ERROR: [dev #262] openLuup/L_TasmotaBridge.lua:188: table index is nil
2021-04-14 20:11:14.642   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/STATE : openLuup/L_TasmotaBridge.lua:188: table index is nil
2021-04-14 20:11:14.662   openLuup.context_switch::  ERROR: [dev #0] attempt to call a string value
2021-04-14 20:11:14.663   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/SENSOR : attempt to call a string value
2021-04-14 20:11:14.701   openLuup.context_switch::  ERROR: [dev #262] openLuup/L_TasmotaBridge.lua:188: table index is nil

[therealdb]

Ok, I've added support for command based on MQTT in version 3.0-beta1.

Variable updated on messages coming soon. Feedback much appreciated!

GitHub - dbochicchio/vera-VirtualDevices: Virtual HTTP Devices plug-in for Vera and openLuup

Virtual HTTP Devices plug-in for Vera and openLuup - dbochicchio/vera-VirtualDevices

[Buxton]

@akbooer I did some debug on the error messages above and came up with the following. I placed some debug entries in the "L_TasmotaBridge.lua" to try to see what was causing the errors. First the code: under function _G.Tasmota_MQTT_Handler (topic, message)

  local myMessage = ""
  
  if message == nil then 
     myMessage = "Message is null" 
  else
	if message == "" then
	 myMessage = "Message is empty" 
	else
	 myMessage = message 
	end
  end
  
  _log ("JSON error info " .. myMessage)

Which produced the following log errors and their context:

2021-04-16 20:48:01.335   openLuup.io.server:: MQTT:1882 connection from 10.17.2.28 tcp{client}: 0x55fac42317b8
2021-04-16 20:48:01.355   luup.tasmota:262: JSON error info Online
2021-04-16 20:48:01.356   luup.tasmota:262: JSON error: ?
2021-04-16 20:48:01.366   luup.tasmota:262: JSON error info Message is empty
2021-04-16 20:48:01.367   luup.tasmota:262: JSON error: ?
2021-04-16 20:48:01.423   openLuup.mqtt:: BedroomTV SUBSCRIBE to cmnd/power_BedroomTV/# tcp{client}: 0x55fac42317b8
2021-04-16 20:48:01.432   openLuup.mqtt:: BedroomTV SUBSCRIBE to cmnd/tasmotas/# tcp{client}: 0x55fac42317b8
2021-04-16 20:48:01.433   openLuup.mqtt:: BedroomTV SUBSCRIBE to cmnd/BedroomTV_fb/# tcp{client}: 0x55fac42317b8

[Buxton]

@akbooer Then further down the log file I was getting errors in the "function init_device (altid, info)" function. Error code is:

	local myaltid = ""
	local myinfo = ""
	
	if altid == nil then
		myaltid = "altid is null"
		else
		myaltid = altid
	end
	
	if info == nil then
		myinfo = "info is null"
		else
		if info == " " then
			myinfo = "info is empty"
		else
			myinfo = unpack(info)
		end
	end


	_log ("Find info " ..  myinfo )
	_log ("Find altid " .. myaltid )

  local dno = luup.openLuup.find_device {altid = altid} 
                or 
                  create_device (altid, info)
 
	_log ("Find DNO " .. dno)

Which yields:

2021-04-16 21:37:06.773   openLuup.io.server:: MQTT:1882 connection closed  tcp{client}: 0x556c246bb0f8
2021-04-16 21:37:06.773   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x556c246bb0f8
2021-04-16 21:37:06.815   luup.io.incoming:: bytes received: 51, status: OK tcp{client}: 0x556c24620fb8
2021-04-16 21:37:09.516   luup.tasmota:262: JSON error info {"Time":"2021-04-17T05:37:09","Uptime":"0T02:24:57","UptimeSec":8697,"Heap":125,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":13,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"CD","BSSId":"FE:9F:DB:F5:A0:11","Channel":1,"RSSI":94,"Signal":-53,"LinkCount":1,"Downtime":"0T00:00:06"}}
2021-04-16 21:37:09.517   luup.tasmota:262: Find info info is null
2021-04-16 21:37:09.517   luup.tasmota:262: Find altid altid is null
2021-04-16 21:37:09.517   luup.tasmota:262: Find DNO 1
2021-04-16 21:37:09.518   openLuup.context_switch::  ERROR: [dev #262] openLuup/L_TasmotaBridge.lua:215: table index is nil
2021-04-16 21:37:09.518   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/STATE : openLuup/L_TasmotaBridge.lua:215: table index is nil
2021-04-16 21:37:09.605   openLuup.context_switch::  ERROR: [dev #0] attempt to call a string value
2021-04-16 21:37:09.605   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/SENSOR : attempt to call a string value
2021-04-16 21:37:09.605   luup.tasmota:262: JSON error info {"Time":"2021-04-17T05:37:09","Switch1":"ON","Switch2":"ON","ENERGY":{"TotalStartTime":"2021-04-04T05:29:11","Total":0.000,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":[0,0],"ApparentPower":[0,0],"ReactivePower":[0,0],"Factor":[0.00,0.00],"Frequency":60,"Voltage":121,"Current":[0.000,0.000]}}
2021-04-16 21:37:09.606   luup.tasmota:262: Find info info is null
2021-04-16 21:37:09.606   luup.tasmota:262: Find altid power_BedroomTV
2021-04-16 21:37:09.606   luup.tasmota:262: Find DNO 30001
2021-04-16 21:37:09.618   luup.tasmota:262: JSON error info {"Time":"2021-04-17T05:37:09","BLEDevices":{"total":3,"A4C138EB4F4F":{"i":0,"r":-73},"A4C13838EB2E":{"i":1,"r":-87},"A4C138A59E0C":{"i":2,"r":-92}}}
2021-04-16 21:37:09.619   luup.tasmota:262: Find info info is null
2021-04-16 21:37:09.619   luup.tasmota:262: Find altid altid is null
2021-04-16 21:37:09.619   luup.tasmota:262: Find DNO 1
2021-04-16 21:37:09.619   openLuup.context_switch::  ERROR: [dev #262] openLuup/L_TasmotaBridge.lua:215: table index is nil
2021-04-16 21:37:09.619   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/BLE : openLuup/L_TasmotaBridge.lua:215: table index is nil
2021-04-16 21:37:09.620   luup.tasmota:262: JSON error info {"Time":"2021-04-17T05:37:09","BLE":{"scans":483,"adverts":23232,"devices":3,"resets":0}}
2021-04-16 21:37:09.620   luup.tasmota:262: Find info info is null
2021-04-16 21:37:09.620   luup.tasmota:262: Find altid altid is null
2021-04-16 21:37:09.620   luup.tasmota:262: Find DNO 1

Hope that's of some use.

[Buxton]

@buxton In the above, I'm seeing an extra closing right hand bracket in the JSON string.

[therealdb]

And I've also added handlers to get status from a generic MQTT message. It's done on lights, dimmers, roller shutters and rgb/rgbw.

Just use the format topic/=/payload, where * for payload means "pass the value to the variable".

Color and white temp are supported, but I'll need to write a converter (or link to the existing one). If anyone is still interested, I could port it to alarm, heaters, door locks and sensors.

[akbooer]

@Elcid

The latest development version v21.4.17 has added and additional subscription to the tasmota/tele/# topic. I will make it configurable later.

@Buxton

I've refactored the bridge a bit, but haven't yet addressed the nested table issue... don't know if this has fixed any of the other errors you've seen, but I didn't do anything explicitly to address those. Still very much work in progress.

[Elcid]

Has installed tasmota bridge and the child devices have been added with the following varaiables

LastUpdate	
17/04/2021, 12:43:57
Switch1	
OFF
Time	
2021-04-17T12:43:57
tasmota/tele	
{"Time":"2021-04-17T12:43:57","Switch1":"OFF"}

[ArcherS]

I have now updated to v21.4.17 and also installed cjson.

The cpu load on my test Pi went down from 10.5% to 4-4.5%, so that is a good step better.

The server has been running with my Zway bridge with 64 zNodes and 165 vDevs and five Tasmota devices.
Data this morning after 2.5 days run time:

I have added one more Tasmota device, in total 6 are now pushing data over Mqtt to OpenLuup.

@akbooer what is changed in v21.4.17, I could not see any changes to be honest.

What I did notice however was that the old error messages I posted above have disappeared. I will see if I get any new, so far I have not seen any.

[akbooer]

@archers said in openLuup: Tasmota MQTT Bridge:

what is changed in v21.4.17

Well, I think you answered your own question...

@archers said in openLuup: Tasmota MQTT Bridge:

the old error messages I posted above have disappeared

[akbooer]

@buxton said in openLuup: Tasmota MQTT Bridge:

You may need to decode a layer deeper for the "table" entries....

Version 21.4.17c does just that (I hope.)

Would be interesting in seeing the variables which result...

[Elcid]

Just reporting that the variables in the tasmota devices are not updating correctly

tasmota/tele	
{"Time":"2021-04-17T19:28:59","Switch1":"ON"}

The time stamp updates, but not the value of Switch1.
[edit] after deleteing the 4 devices and reloading luup I found these errors in log

2021-04-17 19:59:39.142   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=685929357&Timeout=60&MinimumDelay=1500&_=1618685858944 HTTP/1.1 tcp{client}: 0xff56978
2021-04-17 19:59:39.145   openLuup.mqtt:: localhost.bridge-01 SUBSCRIBE to # tcp{client}: 0xff593e0
2021-04-17 19:59:39.147   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 19:59:39.148   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 19:59:39.153   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1
2021-04-17 19:59:39.154   luup.tasmota:47: JSON error: Expected value but found invalid token at character 1

[ArcherS]

@akbooer I have now discovered a few new error messages:

2021-04-17 19:52:02.446   openLuup.io.server:: MQTT:1883 connection from 192.168.1.56 tcp{client}: 0x2654a78

2021-04-17 19:52:02.464   luup.tasmota:14: JSON error: Expected value but found invalid token at character 1

2021-04-17 19:52:02.477   openLuup.io.server:: MQTT:1883 connection closed  tcp{client}: 0x20aeec0

2021-04-17 19:52:02.477   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x20aeec0

2021-04-17 19:52:02.477   openLuup.mqtt:: TasmotaBLE UNSUBSCRIBE from cmnd/tasmotas/# tcp{client}: 0x20aeec0
2021-04-17 19:52:02.478   openLuup.mqtt:: TasmotaBLE UNSUBSCRIBE from cmnd/TasmotaBLE/# tcp{client}: 0x20aeec0
2021-04-17 19:52:02.478   openLuup.mqtt:: TasmotaBLE UNSUBSCRIBE from cmnd/TasmotaBLE_fb/# tcp{client}: 0x20aeec0
2021-04-17 19:52:02.482   openLuup.mqtt:: TasmotaBLE SUBSCRIBE to cmnd/TasmotaBLE/# tcp{client}: 0x2654a78
2021-04-17 19:52:02.561   openLuup.mqtt:: TasmotaBLE SUBSCRIBE to cmnd/tasmotas/# tcp{client}: 0x2654a78
2021-04-17 19:52:02.859   openLuup.mqtt:: TasmotaBLE SUBSCRIBE to cmnd/TasmotaBLE_fb/# tcp{client}: 0x2654a78

I seem to get it on an irregular basis now and then in the log.

It is coming from my ESP32 Tasmota that has three BLE devices connected to it (device #20005). It typically sends the following every 5 minutes:

tele/TasmotaBLE/SENSOR = {"Time":"2021-04-17T19:12:04","ATC-f159bf":{"Temperature":24.0,"Humidity":44.0,"DewPoint":11.0,"Battery":63,"RSSI":-84},"ATC-9446bf":{"Temperature":23.1,"Humidity":62.0,"DewPoint":15.4,"Battery":80,"RSSI":-82},"ATC-6d5d44":{"Temperature":14.8,"Humidity":43.0,"DewPoint":2.3,"Battery":54,"RSSI":-89},"TempUnit":"C"}

I have seen in the log that the device works, i.e. the data for the three devices get updated between the errors.

I tried to capture what is going on and I think it is the device restarting or something when the errors occur. I will check some more on that, perhaps to try and update to a newer firmware.

At the time for the error I got the following in the Tasmota Console:

19:50:09.833 MQT: tele/TasmotaBLE/INFO1 = {"Module":"ESP32-DevKit","Version":"9.2.0.3(tasmota)","FallbackTopic":"cmnd/TasmotaBLE_fb/","GroupTopic":"cmnd/tasmotas/"}
19:50:09.841 MQT: tele/TasmotaBLE/INFO2 = {"WebServerMode":"Admin","Hostname":"TasmotaBLE-0476","IPAddress":"192.168.1.56"}
19:50:09.852 MQT: tele/TasmotaBLE/INFO3 = {"RestartReason":"Software reset CPU"}
19:50:10.911 QPC: Reset
19:50:13.901 MQT: tele/TasmotaBLE/STATE = {"Time":"2021-04-17T19:50:13","Uptime":"0T00:00:10","UptimeSec":10,"Heap":110,"SleepMode":"Normal","Sleep":50,"LoadAvg":37,"MqttCount":1,"Wifi":{"AP":1,"SSId":"BeachAC","BSSId":"FC:EC:DA:D1:7A:64","Channel":11,"RSSI":86,"Signal":-57,"LinkCount":1,"Downtime":"0T00:00:04"}}
19:50:13.924 MQT: tele/TasmotaBLE/SENSOR = {"Time":"2021-04-17T19:50:13","ATC-f159bf":{"Temperature":24.0,"Humidity":43.0,"DewPoint":10.6,"Battery":63,"RSSI":-81},"TempUnit":"C"}

Maybee it is the OpenLuup Mqtt server reacting to the startup messages?

Edit: Yes it is an error from when a Tasmota device starts, I restarted one of my other devices and got the same error in the log. It also recovered as it should after rebooted.

2021-04-17 22:01:05.433   openLuup.io.server:: MQTT:1883 connection from 192.168.1.50 tcp{client}: 0x25fcc50

2021-04-17 22:01:05.440   luup.tasmota:14: JSON error: Expected value but found invalid token at character 1

2021-04-17 22:01:05.447   openLuup.mqtt:: TasmotaUterum SUBSCRIBE to cmnd/TasmotaUterum/# tcp{client}: 0x25fcc50
2021-04-17 22:01:05.452   openLuup.mqtt:: TasmotaUterum SUBSCRIBE to cmnd/tasmotas/# tcp{client}: 0x25fcc50
2021-04-17 22:01:05.454   openLuup.mqtt:: TasmotaUterum SUBSCRIBE to cmnd/TasmotaUterum_fb/# tcp{client}: 0x25fcc50
2021-04-17 22:01:05.455   openLuup.io.server:: MQTT:1883 connection closed  tcp{client}: 0x24ae758

2021-04-17 22:01:05.455   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x24ae758

2021-04-17 22:01:05.456   openLuup.mqtt:: TasmotaUterum UNSUBSCRIBE from cmnd/TasmotaUterum/# tcp{client}: 0x24ae758
2021-04-17 22:01:05.456   openLuup.mqtt:: TasmotaUterum UNSUBSCRIBE from cmnd/tasmotas/# tcp{client}: 0x24ae758
2021-04-17 22:01:05.456   openLuup.mqtt:: TasmotaUterum UNSUBSCRIBE from cmnd/TasmotaUterum_fb/# tcp{client}: 0x24ae758

[akbooer]

@ArcherS

Version 21.4.17d adds an additional error message to see what is causing the JSON error. However, this should be totally recoverable, the message is simply ignored.

[Buxton]

@akbooer My log is much calmer with the oL update. Thanks for that. I still have the following error though:

2021-04-17 13:41:37.079   luup.tasmota:262: JSON error: ?
2021-04-17 13:41:37.080   luup.tasmota:262: Received message causing error was: Online

This happens only on a LUUP reload. If I were to guess, the JSON decoder is seeing a single text string, so it doesn't/can't really decode, but throws an error instead. Maybe trap for strings before being sent to the decoder.... They are valid messages and should not throw receive errors or decode errors.

[ArcherS]

@akbooer good to know it is recoverable, it seemed so also. I updated and will check the log and see what shows up.

[Buxton]

@akbooer And the below error is probably related to the string error:

2021-04-17 13:48:51.407   openLuup.context_switch::  ERROR: [dev #0] attempt to call a string value
2021-04-17 13:48:51.407   openLuup.mqtt:: ERROR publishing application message for mqtt:tele/power_BedroomTV/SENSOR : attempt to call a string value