-
-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unmatched entities in MQTT payload #196
Comments
I know it's annoying, it happens when there is a if you fire up MQTTExplorer and in the Search bar at the top type in |
and if you're worried about the size of the log file (not a solution I know but a temporary workaround) disable the logging in HA with logger:
default: critical
logs:
homeassistant.components.mqtt: error |
I get a little flurry at start-up as things sort themselves out and templates get populated with all the necessary variables. But, this one just keeps on coming! I only get the one topic... There's something weird/different about this one point. Loads of disk space, so log file not a catastrophic issue, but I'd rather HA wasn't wasting time writing out 20k+ errors every day *8) |
that's odd. EMS-ESP wouldn't create that homeassistant topic if there wasn't a value. Are you sure it sneaks back in after you delete it in MQTTExplorer and restart EMS-ESP? |
Now the fun. I deleted the 'tempautotemp' topic above, so no entries in MQTT Explorer. I then went to my thermostat and changes the temperature by spinning the wheel - nothing else. So now we have a TEMPorary AUTO TEMPerature set. MQTT Explorer now shows... So now I have matched data and no HA errors. I suspect things get interesting when the temporary temperature period ends. At that point, tempautotemp probably has no definition but the template is still being sent... |
I realised I turned the temperature down last night when I was the last to bed, relatively early! The errors started started at 23:00:05 when the thermostat would have gone from my temporary temperature back to the time programme. At that point, there was no temporary info to send any more. I've just tried resetting the temp and reverting to AUTO but this hasn't replicated the problem, so it may depend on reaching the next programme time/temperature change. |
So... the logic is there to define the point when the stat begins to publish it, but when it stops publishing it (and the point disappears from the payload), the definition payload remains. Weird. Nasty. |
yes, that's it! If there is no value for tempautotemp then it will not be included in the I think the solution is either
|
Great - glad we at least understood what's going on pretty quick. I think there might be other points doing other weird stuff like this. I'll try and collect evidence this week. One was something to do with ww but I'll wait and check. I guess the first option above is technically better, but I don't know about the coding practicalities. |
Shame the thermostat doesn't handle it better but I suppose there's no point in it sending data that doesn't exist any more! |
Yep, the errors are back and only the definition payload is being sent. The data payload disappears when...
|
Going back in the logs, one of the changes I made also caused a bigger burp, albeit short-lived. Thermostat is obviously having a good cough then...
|
I've implemented my option 1 (delete the HA config when the value is bogus). I'll test it for a bit and see how well it stands up |
@glitter-ball looks like its working, I haven't seen any errors in the HA logs yet. Do you want to give it a go? It's called 3.3.0b7 and you can find the binary here. if it works I'll do a PR against the EMS-ESP dev branch. |
fixes #196 (HA missing entities), add row click to devices, change max limit on integer types to avoid NaN, refactored generation of device value JSON objects
Will try and check it tonight... |
the logic I wrote does
it's not bulletproof by all means and I'm sure there will be some edge cases I haven't thought about. please keep an eye on it! |
I wonder whether the handling of the Retained flag is implicated somehow? I had this...
... clear the Retained flag on 'lastcode' and, of course, the errors stop. So, when an entity disappears, is it as simple as clearing its Retained flag too? If it re-appears, the addition code will set the flag again, so I don't think we lose anything. If the broker restarts, the previous retained one it still there. I wonder if this guy... https://discord.com/channels/816637840644505620/816958041345884180/910424597663453234 ... is having the same issue? |
when the entity disappears, it deletes the whole config topic along with the retained flag, so that can't be it. And in the log you should see a warning like "Device value lastcode gone silent. Removing HA config topic..."? |
That's weird because I was seeing the topic still in the broker with the retained flag set. As soon as I cleared it manually, the topic disappeared and errors cleared. Helpfully, of course, it's not doing it now. I'll keep an eye on it and try to work out what's happening. |
oh, bugger. so maybe the code I wrote to remove the topic isn't working. I never really tested it in a live situation. I'll do so now! |
my bad, I made a typo. the homeassistant/sensor/ems-esp/... config topics should be removed now. I should test more thoroughly. Build is 3.3.0b9. |
Phew! Thinking I was missing something... I've loaded b9 and will see what happens. Thanks. |
Oh dear. This one's back now...
MQTT Explorer shows the usual stuff... |
that's odd. the |
should be fixed in the latest 3.3.0b10. I haven't seen any issues since, but please check and re-open if necessary |
This issue seems to work counter-productive for my setup. Issue observed:
|
Think you’re on an older build?
…On Mon, 14 Feb 2022 at 09:54, Stef Boerrigter ***@***.***> wrote:
This issue seems to work counter-productive for my setup.
I do use an IRT <-> EMS converter in between, so might be that that causes
an issue here.
*Issue observed:*
After a little while (less than a day) the EMS-ESP32 seems to throw away
most of my sensors in HA. snippet from the log:
002+04:43:17.415 W 529: [mqtt] Lost device value for boiler_wwsetpumppower. Removing HA config
002+04:43:17.415 W 530: [mqtt] Lost device value for boiler_wwmixertemp. Removing HA config
002+04:43:17.415 W 531: [mqtt] Lost device value for boiler_wwtankmiddletemp. Removing HA config
002+04:43:17.415 W 532: [mqtt] Lost device value for boiler_wwstarts. Removing HA config
002+04:43:17.415 W 533: [mqtt] Lost device value for boiler_wwworkm. Removing HA config
002+04:43:17.415 W 534: [mqtt] Lost device value for thermostat_errorcode. Removing HA config
002+04:43:17.415 W 535: [mqtt] Lost device value for thermostat_lastcode. Removing HA config
002+04:43:17.415 W 536: [mqtt] Lost device value for thermostat_datetime. Removing HA config
002+04:43:17.415 W 537: [mqtt] Lost device value for thermostat_hc1_seltemp. Removing HA config
002+04:43:17.415 W 538: [mqtt] Lost device value for thermostat_hc1_currtemp. Removing HA config
002+04:43:17.415 W 539: [mqtt] Lost device value for thermostat_hc1_mode. Removing HA config```
—
Reply to this email directly, view it on GitHub
<#196 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMO6E3DMDBEM4O6PHBRZDU3C7LXANCNFSM5IAE6NGQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
I'm on 3.3.1 which is latest official version. this was merged back to 3.3.0 it seems? System Status
|
Ah ok. This is fixed in 3.4
On Mon, 14 Feb 2022 at 10:39, Stef Boerrigter ***@***.***>
wrote:
… I'm on 3.3.1 which is latest official version. this was merged back to
3.3.0 it seems?
System Status
EMS-ESP Version
v3.3.1
Think you’re on an older build?
… <#m_3445462048818379591_>
On Mon, 14 Feb 2022 at 09:54, Stef Boerrigter *@*.*> wrote: This issue
seems to work counter-productive for my setup. I do use an IRT <-> EMS
converter in between, so might be that that causes an issue here. Issue
observed: After a little while (less than a day) the EMS-ESP32 seems to
throw away most of my sensors in HA. snippet from the log: 002+04:43:17.415
W 529: [mqtt] Lost device value for boiler_wwsetpumppower. Removing HA
config 002+04:43:17.415 W 530: [mqtt] Lost device value for
boiler_wwmixertemp. Removing HA config 002+04:43:17.415 W 531: [mqtt] Lost
device value for boiler_wwtankmiddletemp. Removing HA config
002+04:43:17.415 W 532: [mqtt] Lost device value for boiler_wwstarts.
Removing HA config 002+04:43:17.415 W 533: [mqtt] Lost device value for
boiler_wwworkm. Removing HA config 002+04:43:17.415 W 534: [mqtt] Lost
device value for thermostat_errorcode. Removing HA config 002+04:43:17.415
W 535: [mqtt] Lost device value for thermostat_lastcode. Removing HA config
002+04:43:17.415 W 536: [mqtt] Lost device value for thermostat_datetime.
Removing HA config 002+04:43:17.415 W 537: [mqtt] Lost device value for
thermostat_hc1_seltemp. Removing HA config 002+04:43:17.415 W 538: [mqtt]
Lost device value for thermostat_hc1_currtemp. Removing HA config
002+04:43:17.415 W 539: [mqtt] Lost device value for thermostat_hc1_mode.
Removing HA config``` — Reply to this email directly, view it on GitHub
<#196 (comment)
<#196 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJMO6E3DMDBEM4O6PHBRZDU3C7LXANCNFSM5IAE6NGQ
<https://github.com/notifications/unsubscribe-auth/AAJMO6E3DMDBEM4O6PHBRZDU3C7LXANCNFSM5IAE6NGQ>
. You are receiving this because you modified the open/close state.Message
ID: @.*>
—
Reply to this email directly, view it on GitHub
<#196 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJMO6BJJGTF4UUU4NYD6R3U3DETNANCNFSM5IAE6NGQ>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
I'll have a test later today. will update accordingly. |
tested with latest 3.4 branch 2 days ago. EMS-ESP Version - v3.4.0a18 I do see these messages every 10 seconds: (Filtered with Node-Red) `
I have digged a bit deeper, seems like they are notified in HASS, but not as the climate but as sensor (number) entity. This snippet is only seen once after starting the service (or reconnecting) which is most likely only used for auto discovery of the sensor. Then the ems-esp topic should update the sensor value?
Is there a mismatch in naming between discovery and update(s)? |
if EMS-ESP can't find a device entity (e.g. a thermostat setpoint value) it will mark it as inactive and also remove the config discovery topic from MQTT. I'm not sure what the problem is with your setup but worth using MQTTExplorer to see what topics and payloads are available |
Please use the dev build, which is the latest v3.4, The v3.4 branch is alpha and outdated. |
Thanks @MichaelDvP, |
the command_topic is the name of the topic that MQTT discovery uses when changing a value using the component. It's unrelated to the other topics and only picked up by EMS-ESP which subscribes to it. Back to the issue, is it working or not working? I'm not sure what you mean by a Climate node? |
Thanks for explaining; |
ok. Still strange. The MQTT topics should all come in within the first 60 seconds |
They appear directly(<30 sec), which is ok. the problem is that HASS mentions them as "inactive" after a few (>12) hours. for some reason. seems like (wrong/no) update? |
not sure. Haven't seen this behaviour before. Please open a specific GH issue if you think this is a new defect. |
Bug description
EMS-ESP32 regularly sending the same few points with no matching data.
2021-11-13 23:00:05 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'dict object' has no attribute 'tempautotemp' when rendering '{{value_json.hc1.tempautotemp}}'
At one level, this is trivial! But...
I can delete the point with MQTT Explorer, but it will be back - presumably when I restart EMS-ESP32? If the point has no associated data, can it be stopped from sending the template? 'tempautotemp' is far and away the biggest culprit! Is there something special about the definition of this point?
Steps to reproduce
Run EMS-ESP32 and HA : HA log file fills up with this error.
Expected behavior
No HA errors!
Screenshots
Device information```
EMS-ESP version 3.3.0b2
Boiler: Worcester Logamax Plus/GB192/Condens GC9000 (DeviceID:0x08 ProductID:208, Version:01.01)
heating active: off
warm water active: off
selected flow temperature: 28 °C
burner selected max power: 100 %
heating pump modulation: 96 %
outside temperature: 11.3 °C
current flow temperature: 26.5 °C
gas: off
flame current: 0.0 uA
heating pump: on
fan: off
ignition: off
heating activated: on
heating temperature: 75 °C
burner pump max power: 100 %
burner pump min power: 60 %
pump delay: 3
burner min period: 5
burner min power: 0 %
burner max power: 100 %
hysteresis on temperature: -10 °C
hysteresis off temperature: 6 °C
burner current power: 0 %
burner starts: 19281 times
total burner operating time: 173 days 6 hours 51 minutes
total heat operating time: 132 days 16 hours 41 minutes
total UBA operating time: 1200 days 18 hours 11 minutes
last error code: EA(227) 09.10.2021 10:27
service code number: 204
maintenance message:
maintenance scheduled: off
maintenance set time: 6000 hours
maintenance set date: 01.01.2014
ww selected temperature: 60
ww set temperature: 60
ww type: buffer
ww comfort: hot
ww flow temperature offset: 40
ww max power: 100
ww circulation pump available: off
ww charging type: 3-way valve
ww hysteresis on temperature: -5
ww hysteresis off temperature: 0
ww disinfection temperature: 70
ww circulation pump frequency: off
ww circulation active: off
ww current intern temperature: 55.2
ww current extern temperature: 55.2
ww current tap water flow: 0.0
ww storage extern temperature: 55.2
ww activated: on
ww one time charging: off
ww disinfection: off
ww charging: off
ww recharging: off
ww temperature ok: on
ww active: off
ww heating: off
ww starts: 5233
ww active time: 40 days 14 hours 10 minutes
Thermostat: RC300/RC310/Moduline 3000/1010H/CW400/Sense II (DeviceID:0x10, ProductID:158, Version:33.03)
error code: (0)
date/time: 18:52:15 14/11/2021
floor drying: off
damped outdoor temperature: 11.8 °C
floor drying temperature: 0 °C
building: medium
minimal external temperature: -5 °C
ww set temperature: 60
ww mode: own_prog
ww set low temperature: 45
ww circulation pump frequency: own_prog
ww charge duration: 60
ww charge: off
ww circuit 1 extra: 0
ww disinfection: off
ww disinfection day: tu
ww disinfection time: 120
hc1 selected room temperature: 18.5
hc1 current room temperature: 18.7
hc1 mode: auto
hc1 mode type: comfort
hc1 eco temperature: 15.0
hc1 manual temperature: 18.0
hc1 comfort temperature: 21.0
hc1 summer temperature: 17
hc1 design temperature: 45
hc1 offset temperature: 0
hc1 min flow temperature: 25
hc1 max flow temperature: 82
hc1 room influence: 9
hc1 current room influence: -1.7
hc1 nofrost temperature: 5
hc1 target flow temperature: 28
hc1 heating type: radiator
hc1 set summer mode: auto
hc1 summer mode: off
hc1 control mode: optimized
hc1 program: prog_1
hc1 fast heatup: 0
Controller: ErP (DeviceID:0x09, ProductID:209, Version:01.03)
Dallas temperature sensors:
Sensor 1, ID: 28-BE2A-7791-0402, Temperature: 26.2 °C (offset 0.0)
The text was updated successfully, but these errors were encountered: