TRV controller not updating temperature

[siclark]

Hi Jon, its october, we are all home all day and the heating is on and queue the start of the, my heating isnt working messages!

I have an issue with one of mine where the TRV controller is set to use a remote sensor, an Aqara one using MQTT connector. I have that on other ones and all seems ok. But on the study one, where I sit all day, the temperatures on the TRV controller dont seem to update at all.

Screenshot 2020-10-13 at 11.23.54.png (45.09 KiB) Viewed 4886 times

You can see there its showing 23.3 and 23.4 when it should be 23.0 and 19.3

And plotting the remote and trv temperature readings from the trv controller, the remote temperature doesnt track the sensor at all.

Screenshot 2020-10-13 at 11.28.37.png (50.45 KiB) Viewed 4886 times

Any ideas? The jumps when the TRV and Remote temperatures came more in line was when I restarted the plugin. I have 9 TRV controllers running now (which is killing my zwave network when they updated )

[siclark]

Screenshot 2020-10-13 at 11.57.30.png (69.33 KiB) Viewed 4877 times

Actually this is happening on all rooms where I use a temperature sensor.

Here the schedule turns on at 9 and set points increase. The TRV one 5 deg higher than the "thermostat" / TRV controller. Thats fine, but you can see the sensor temperature cross the set point at 9:15 ish but no change to the Stat TRV. The TRV itself clearly sees the increasing temperature and starts to close the valve.

The TRV SP is only set to 8 deg, ie turned off, at 9:40ish when the TRV controller temperature suddenly jumps to match that of the sensor. Its set to poll every 5 minutes when schedules are active, but I would think it could be checking the remote temperature constantly, as there is no battery issue like polling the TRV.

I Am thinking I need to stop using all the external sensors.

[siclark]

This is what happens when I restart the plugin, suddenly the trv controller temperatures come in line, but havent been for an hour (actually more)

[autolog]

I have the TRV Controller code loaded up in PyCharm as I write this.

It is my next priority task to look at this as we have just turned our heating on.

Are all your remote sensors the Aqaras? I have a few of those and so will check it out. It seems like this is a bug.

[siclark]

Ha perfect! Yes the ones I use are Aqara, but was planning to use a couple of other ones as well from another plugin. I can test with those if that helps narrow bug down.

[autolog]

What would be interesting is whether you see that the custom state temperatureRemote on the TRV Controller device actually agrees with the temperature on the Aqara?

I have just checked mine and they do. You need to check once you see the temperature not being updated as you would expect.

[siclark]

The green line in chart above is the remote reported temperature from the TRV controller. As you see its different.

this is it currently. reporting remote at 22.11 and TRV at 20.3 when the devices are showing 23.9 and 21.5 respectively.

[autolog]

Can you show me the similar image for the Aqara?

[siclark]

Here you go

[autolog]

OK - Thanks.

I think this is a similar issue (if not the same) that @Busta999 reported.

I will continue my investigations!

[siclark]

Great. I get the same when using a heatmiser thermostat as a remote device as well, so not restricted to Aqara.

[siclark]

And strangely seeing this on the devices not using a remote sensor.

[autolog]

The script I PM'd you should pick that up?

It should handle not having an associated Remote.

I think the issue we are seeing is that the device updates of the Spirit and Remote (where used) are not always being picked up by the plugin.
Yesterday, I noticed one of my Aqaras was having updates that weren't picked up but is behaving itself today.

I am running the script every 15 minutes and (famous last words), haven't detected an anomaly yet.

[autolog]

Seems like the issue is related to the last TRV plugin update which introduced the plugin configuration feature: Delay Queue.

For the moment (pending a fix), the workaround is to set the option to No Delay.

Thanks to Simon (@siclark) for testing and the heads-up on this - much appreciated.

[siclark]

In the meantime, I am setting the polling periods to be different frequencies, ie 4/5/6 for while active, 8/9/10/11 inactive etc, so hopefully they all end up polling at different times and not 5 at the same time.