openweather plugin ?

[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

[Buxton]

@akbooer The table level decode issue is a byproduct of the type of relay I'm using in the above examples.

This tasmota relay controls two separate outputs (switches), as well as an unlimited number of bluetooth sensors that see/connect to the relay. So for example, I placed the above mentioned relay behind a standard wall power outlet that has its two plug ports separated into two different circuits. One outlet of the relay controls the top plug and the other relay outlet controls the bottom.

This is not uncommon with the tasmota devices as I also have a four relay tasmota device that controls four different circuits of my landscape lights, though there is only a single device with a single IP address.

[therealdb]

My devices seem to have been discovered OK, albeit as generic. I'm eager to help to map them to child devices. Even with different sensors, the variable name seems to be consistent.

Here's what I have:

• Temperature
• Humidity
• Distance
• DewPoint
• IR
• Illuminance
• Pressure
• Broadband (for light)

I think that if multiple are present, multiple child devices could be created. I could also help with code @akbooer if you need help.

[akbooer]

@therealdb said in openLuup: Tasmota MQTT Bridge:

I'm eager to help to map them to child devices.

Oh, I didn't think that was necessary since you made it so easy to create virtual devices? You want ALL the child devices to be separate? This could become messy.

[ArcherS]

@akbooer I think it is quite good without the plugin creating a lot of child devices for Tasmota sensor devices.

Instead I create child devices myself with the excellent Virtual Sensor plugin for the ones I want (I typically do not want child devices for all the data from a Tasmota sensor). I then simply map each virtual sensor to the device and variable in the Virtual Sensor plugin:

Super easy and clean without any coding.

For Tasmota switches or similar where you typically want to send Mqtt data to the device it may be a bit different of course. I have not tested any of these yet. Perhaps the Mqtt addition to the Virtual Http plugin from @therealdb is the right path here? I have still to test this.
I have a Tasmota IR tranceiver that I will test for controlling my HVAC, but I have not come that far yet!