Closed bsafh closed 1 year ago
(beta-45 installed at 11:20 am 21.11.2022 ...)
real TRV:
temperature near the door to the outside:
temperature in the middle of the room (yes, it's really different due to the geometry of that room)
same problem here
i can confirm ,some of my TRV have this problem too
Happens to me too and I still don't understand the logic behind it as the temperature I set as desired is the only value that should never be changed.
I agree with you . I have the same issue that I have fixed as described her under . There is something in the code that makes the better thermostat slave or the TRV that should not be possible. There is surely a reason behind …..
my solution: My main master is a Nest thermostat. I have automation for each BT that copy the reference temperature of the Nest inside the better thermostat and copy again this temperature if it changes alone after 5 seconds . This works perfectly but this is really a work around that I am not satisfied for Phil
alias: Transfert consigne Nest vers vanne salon gauche description: "" trigger:
Activate Child Lock or comment out the following lines in the code, fixes the problem. https://github.com/KartoffelToby/better_thermostat/blob/master/custom_components/better_thermostat/events/trv.py#L148:L152
Can someone try, if this fixes the problem? I'm currently not at home and can't test myself. https://github.com/wtom/better_thermostat/commit/9c0d8b12b1cb83f712802bb258165748dcd4e7b2
I have the same Problem. This needs to be fixed asap, since it pretty much renders the whole thing unusable.
For me it took more than an hour before the temparature was set behind my back.
red dot is my manual change. next spike is the automatic change.
I had the same problem with my Nedis Thermostats (generic via ZHA). First "workaround" was to set up an automation wich sets the BT Adapter back to my originally set temperature in case it automatically changes. Somehow like pbranly did in a post above ... But: Activating "Child lock" did fix the problem finally. (no need for the automation anymore)
Happy that you tried my pseudo solution ! Child lock is really a way to prevent that issue . Nevertheless I still can't understand why BT is changed by native TRV. TRV should always be a slave from the BT Child lock is a short term work around .... I hope Phil
Yes, directly in the UI. Theres an option called "Ignoriere alle manuellen einstellungen am realen Thermostat (Kindersicherung)" (German) should be something like "ignore all settings on the real TRV (child lock)" in english versions.
Yes, directly in the UI. Theres an option called "Ignoriere alle manuellen einstellungen am realen Thermostat (Kindersicherung)" (German) should be something like "ignore all settings on the real TRV (child lock)" in english versions.
yeah i found it since i wrote my comment, thats why i deleted it ^^°
Happy that you tried my pseudo solution ! Child lock is really a way to prevent that issue . Nevertheless I still can't understand why BT is changed by native TRV. TRV should always be a slave from the BT Child lock is a short term work around .... I hope Phil
On the other hand: Theres absolutely no need to set the temp at the real TRV when using BT in my opinion. But you are right.
The feature behind that is actually, that you can set the BT target temperature via the real TRV. That's why the child lock prevents this bug to happen.
Somewhere on the if condition is a mistake and that's why the BT target temperature is changed after the TRV target temp is changed by BT. And then the loop begins.
I will try to find the bug tonight.
The feature behind that is actually, that you can set the BT target temperature via the real TRV. That's why the child lock prevents this bug to happen.
Somewhere on the if condition is a mistake and that's why the BT target temperature is changed after the TRV target temp is changed by BT. And then the loop begins.
I will try to find the bug tonight.
Didn't know that.. cool feature! will this also work with BT Groups? Using this for my living room with 3 TRV's in one BT
The feature behind that is actually, that you can set the BT target temperature via the real TRV. That's why the child lock prevents this bug to happen.
Somewhere on the if condition is a mistake and that's why the BT target temperature is changed after the TRV target temp is changed by BT. And then the loop begins.
I will try to find the bug tonight.
Didn't know that.. cool feature! will this also work with BT Groups? Using this for my living room with 3 TRV's in one BT
Yes it should also work with groups.
So yes, this seems to fix it for me. Maybe someone else could test it.
The problem was, the new setpoint sometimes as a weird float value something like 20.00000023939 but the TRV just reports back then 20.00 and then there is a difference and BT thought, that the TRV was manually changed.
Did someone else test the fix?
Prerequisites
[climate.trv_ai_schlafzimmer_1] hvac_modes:
Description
Whatever target temperature I set on the BT UI card, the BT climate entity goes up to Maximum (35°C) within seconds.
Same happens when I set the target temp on the real TRV UI card
Steps to Reproduce
Expected behavior:
target temperature stays on e.g. 19°C
Actual behavior:
TRV are opened to maximum heating and stay there forever
Versions
BT: Beat-45
HA: 2022.11.4
Additional Information