v3.3.1b0: Template variable warning: 'dict object' has no attribute 'tempautotemp' #229
Comments
|
use MQTTExplorer and search for |
|
@proddy {
"id": 158,
"errorcode": "(0)",
"datetime": "21:19:30 01/12/2021",
"floordry": "off",
"dampedoutdoortemp": 1.7,
"floordrytemp": 0,
"building": "light",
"minexttemp": -10,
"wwsettemp": 60,
"wwmode": "own_prog",
"wwsettemplow": 45,
"wwcircmode": "own_prog",
"wwchargeduration": 60,
"wwcharge": "off",
"wwextra1": 0,
"wwdisinfect": "on",
"wwdisinfectday": "we",
"wwdisinfecttime": 180,
"hc1": {
"seltemp": 24,
"temp": 24,
"hatemp": 24,
"hamode": "auto",
"mode": "auto",
"modetype": "comfort",
"ecotemp": 15,
"manualtemp": 24,
"comforttemp": 25,
"summertemp": 17,
"designtemp": 45,
"offsettemp": 0,
"minflowtemp": 25,
"maxflowtemp": 60,
"roominfluence": 0,
"curroominfl": 0,
"nofrosttemp": 5,
"targetflowtemp": 38,
"heatingtype": "radiator",
"summersetmode": "auto",
"summermode": "off",
"controlmode": "optimized",
"program": "prog_1",
"fastheatup": 0
}
}
|
|
there must be one otherwise HA wouldn't be complaining. Is it not in homeassistant/sensor/ems-esp/..... ? |
|
@proddy
|
|
you still seeing the error in HA then? |
|
@proddy |
|
Strange, no i can see the warning again, w/o my changing anything.
|
|
There may be something not right then in the code. Those log messages "Lost device value for thermostat_hc1_tempautotemp. Removing HA config" should be removing that MQTT topic from the broker but it doesn't look like it's working. So either the name is wrong or something else is at hand. Is this easy for you to reproduce on command? Then I can provide more debug information that will help track down where the problem is. |
Testcase - is working: mosquitto_pub -h mbsbroker.home -p 1883 -u ******* -P ****** -t 'homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config' -n -rBut EMS-ESP32 do not remove the topic ??? |
|
All this sounds horribly like my issue in #196 ! @zibous - you will probably find this error occurs if you override the heating temperature. At the end of the override period, tempautotemp no longer has a value so isn't published, but the template remains. @proddy did some code changes (see #196) which fixed it for me. I just have the same problem now with 'lastcode' - I thought we'd cracked that and it's come back again... EMS-ESP is publishing the config topic but no data to go with it and the retained flag is set... If I clear the Retained flag in MQTT Explorer it goes and stays gone. Wonder why the code change implemented for #196 isn't working with 'lastcode'? |
|
this is frustrating. I thought we fixed it. @zibous are you able to reproduce it manually without sending MQTT payloads? Like switching the modes or timer on your thermostat and then monitoring in EMS-ESP if indeed the |
|
@proddy If I change the thermostat (Homeassistant) temperature value, this is transferred and also changed to the RC310.
After a certain time, usually overnight, the entry Could this have something to do with the day / night changeover? Because the message ems-heizung/thermostat_data {
"id": 158,
"errorcode": "(0)",
"datetime": "08:59:50 05/12/2021",
"floordry": "off",
"dampedoutdoortemp": 7,
"floordrytemp": 0,
"building": "light",
"minexttemp": -10,
"wwsettemp": 60,
"wwmode": "own_prog",
"wwsettemplow": 45,
"wwcircmode": "own_prog",
"wwchargeduration": 60,
"wwcharge": "off",
"wwextra1": 0,
"wwdisinfect": "on",
"wwdisinfectday": "we",
"wwdisinfecttime": 180,
"hc1": {
"seltemp": 24,
"temp": 24,
"hatemp": 24,
"hamode": "auto",
"mode": "auto",
"modetype": "comfort",
"ecotemp": 20,
"manualtemp": 24,
"comforttemp": 24,
"summertemp": 17,
"designtemp": 45,
"offsettemp": 0,
"minflowtemp": 25,
"maxflowtemp": 60,
"roominfluence": 0,
"curroominfl": 0,
"nofrosttemp": 5,
"targetflowtemp": 41,
"heatingtype": "radiator",
"summersetmode": "auto",
"summermode": "off",
"controlmode": "optimized",
"program": "prog_1",
"tempautotemp": 24,
"fastheatup": 0
}
}homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config {
"~": "ems-heizung",
"uniq_id": "thermostat_hc1_tempautotemp",
"stat_t": "~/thermostat_data",
"name": "Thermostat hc1 temporary room temperature automode",
"val_tpl": "{{value_json.hc1.tempautotemp}}",
"unit_of_meas": "°C",
"ic": "mdi:coolant-temperature",
"dev": { "ids": ["ems-esp-thermostat"] }
}Syslog Data: |
yes, also for me, when i restart the EMS-ESP.
|
The sequence looks fine. at 5am the |
|
Thanks.
Well, I can only receive the messages via syslog, but it should work. How can I install the special firmware update normally via OTA? |
|
just drag & drop into the WebUI |
|
@proddy |
|
I haven't made the special build for you yet. I'm away on business so it'll be a week or two until I can make the changes. |
|
@proddy
I have checked the EMS-ESP Log and the Mosquitto Log: Does this method cause deletion? If so, why do I not see the log message Testcase - is working:
It looks as if the "Remove" topic is logged, but does not arrive at the MQTT Brocker. |
Those debug messages are only shown when the project is built with the -DEMSESP_DEBUG flag set (in pio_local.ini). It's for additional logging messages. |
|
@proddy |
|
you have logging enabled on Mosquitto so it's basically capturing and reporting back on all traffic, which is handy now for debugging but later you should turn it off. The log messages look like the ones you sent from MQTTExplorer. Also I noticed the retain flag is on (r1). What we're looking for are MQTT publishes from EMS-ESP with an empty payload and no retain flag |
Yes, this message comes when I select the topic in MQTTExplorer to look at the payload. Testcase - no topics on the mqtt brocker. root@nuc2020:~# mosquitto_pub -h nuc2020.siebler.home -p 1883 -u emstester -P KQvMhzJBfK9sjTB6K3Jg26jH8F -t 'homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config' -n -d
Client mosq-fGV0OHLP16QnBY2gXJ sending CONNECT
Client mosq-fGV0OHLP16QnBY2gXJ received CONNACK (0)
Client mosq-fGV0OHLP16QnBY2gXJ sending PUBLISH (d0, q0, r0, m1, 'homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config', ... (0 bytes))
Client mosq-fGV0OHLP16QnBY2gXJ sending DISCONNECT
## Adds an empty topic, even if flag delete is specified
root@nuc2020:~# mosquitto_pub -h nuc2020.siebler.home -p 1883 -u emstester -P KQvMhzJBfK9sjTB6K3Jg26jH8F -t 'homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config' -n -d
Client mosq-BHKElKecyvOUHfBRqk sending CONNECT
Client mosq-BHKElKecyvOUHfBRqk received CONNACK (0)
Client mosq-BHKElKecyvOUHfBRqk sending PUBLISH (d0, q0, r0, m1, 'homeassistant/sensor/ems-heizung/thermostat_hc1_tempautotemp/config', ... (0 bytes))
Client mosq-BHKElKecyvOUHfBRqk sending DISCONNECT
## Removes the topicMosquitto LOG Simple Test for async-mqtt-client: For me it is working, but do not handle the retain flag. |
|
I'm still wondering if the retain flag is the clue. The two points I have problems with (tempautotemp and lastcode) are always sitting in MQTT Explorer with the retained flag set. When I clear the flag manually, they go away and stay gone! So, my money is one something stopping that retained flag getting cleared. Mysterious. Weird. But that's what I'm seeing. I'm using the embedded Mosquitto broker in HA - maybe there's some weird issue buried in that? |
|
it could be, but doubt it. But then again, I need to do some testing. In theory if you send a MQTT message to Mosquitto with topic homeassistant/...../config and an empty payload it should remove the entry from HA. It works in my tests regardless of the retain flag being set. When I'm back this weekend I'll work on a debug version so we can trace the MQTT removals and then with logging set on Mosquitto we should be able to see why it's not working. By design all EMS-ESP HA config topics are created with the retain flag set because if the MQTT broker is restarted it will remember the last state and Home Assistant will continue to work. |
That's right and it works. I tested it native, with python scripts and with an ESP32 - not just with an MQTT brocker. Can I simply download the source code, compile ( Test: |
|
Note: During my second installation on a different computer, the Homassistant runs and is not updated. I don't see the warning there. |
|
I'm also running both HA and Mosquitto as docker containers, with watch grabbing any updates. I think what you need to do is
|
o.k 💯 I will try it and wait for the end of your simulations. |
Could be: the set message has retain set, the remove publish not, after restart the broker uses the latest retain message, and set the config for tempautotemp. Try to send the remove message also with retain (replace mqtt.ccp, line 752 with:) btw: i think tempautotemp is a useless value, if set the information is also in seltemp and after next autoswitch it goes to |
|
ah, perhaps yes. It's worth checking if those topics reappear after the MQTT broker is bounced. one of things I was planning on building next into the webUI is the ability to choose which entities to show (api, mqtt, console, web dashboard). So users can just disable tempautotemp. |
|
Sorry to butt in... just catching up with all this. So, I have the ongoing issue of lots of logged errors: and an orphaned point in MQTT Explorer with the retained bit set: If I clear the retained flag, it'll be gone for good. Problem seems to re-occur if the gateway restarts. I'm running v3.3.0b11 - is there a later version to try that might sort this? Thanks. |
|
I also have these kind of errors in home assistance, not able to get rid off |
|
@elRadix I'm not seeing this. Did you follow the guidelines on https://emsesp.github.io/docs/#/Troubleshooting?id=ha-is-showing-errors-like-quottemplate-variable-warning-39dict-object39-has-no-attributequot |
|
@elRadix - what can you see in MQTT Explorer (or similar) about these points? |
|
this should hopefully be fixed now in 3.4 |
Bug description
Logger: homeassistant.helpers.template
Source: helpers/template.py:1766
First occurred: 13:53:24 (731 occurrences)
Last logged: 15:55:03
Template variable warning: 'dict object' has no attribute 'tempautotemp' when rendering '{{value_json.hc1.tempautotemp}}'
Steps to reproduce
Log Homeassistant
Expected behavior
I have already deleted all entries in the MQTT broker, restarted EMS-ESP.
Screenshots
If applicable, add screenshots to help explain your problem.
Device information
{
"System": {
"version": "3.3.1b0",
"uptime": "002+06:13:09.948",
"uptime (seconds)": 195189,
"freemem": 155,
"reset reason": "Software reset CPU / Software reset CPU",
"Dallas sensors": 0
},
"Network": {
"connection": "WiFi",
},
"Status": {
"bus status": "connected",
"bus protocol": "Buderus",
"telegrams received": 134376,
"read requests sent": 15084,
"write requests sent": 22,
"incomplete telegrams": 14,
"tx fails": 13,
"rx line quality": 100,
"tx line quality": 100,
"MQTT": "connected",
"MQTT publishes": 62142,
"MQTT publish fails": 0,
"Dallas reads": 0,
"Dallas fails": 0,
"syslog active": true
},
"Devices": [
{
"type": "Boiler",
"name": "Buderus GBx72/Trendline/Cerapur/Greenstar Si/27i (DeviceID:0x08 ProductID:123, Version:07.00)",
"handlers": "0x10 0x11 0xC2 0x14 0x15 0x1C 0x18 0x19 0x1A 0x35 0x16 0x33 0x34 0x26 0x2A 0xD1 0xE3 0xE4 0xE5 0xE6 0xE9 0xEA"
},
{
"type": "Thermostat",
"name": "RC300/RC310/Moduline 3000/1010H/CW400/Sense II (DeviceID:0x10, ProductID:158, Version:74.02)",
"handlers": "0xA3 0x06 0xA2 0x12 0x2A5 0x2B9 0x2AF 0x29B 0x471 0x2A6 0x2BA 0x2B0 0x29C 0x472 0x2A7 0x2BB 0x2B1 0x29D 0x473 0x2A8 0x2BC 0x2B2 0x29E 0x474 0x2F5 0x31B 0x31D 0x31E 0x23A 0x267 0x240"
},
{
"type": "Controller",
"name": "BC25 (DeviceID:0x09, ProductID:125, Version:03.05)"
}
]
Additional context
The text was updated successfully, but these errors were encountered: