-
-
Notifications
You must be signed in to change notification settings - Fork 138
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
Target temperature in GUI changes by itself randomly #1097
Comments
Same Problem here. |
same as in #1079 |
Same issue occurring very frequently w/ BT 1.3.0. - using Aqara TRVs. Have experienced similar behavior with BT 1.2.2 (though the latter with a bit lesser frequency, before turning off TRVs). |
It almost feels like it's getting the target temperature mixed up with the actual TRV temperature somehow - i have not tried to set it for 20 degrees again (i see i had 19.5 before). And i'll monitor all day without changing anything myself to see if it stays. I would expect this to change on it's own :( |
I'm also facing this problem
|
Same as #1079 |
I switched to v 1.2.2 and I'm having the same. |
Is there any older version without that issue? Does anyone know? |
Yes, I believe it's 1.2.1 - I have been running it couple of days now without mentioned issues. |
Same here. Randomly heated up my livingroom to 26°C in the middle of the night. Eco mode was set to 18°C and it changed itself to 26 eco. |
Same problem here. It looks as if it works a bit better if the calibration mode is to Normal instead of AI |
Same here. |
Same here, too.... |
Can confirm, BT behaves completely randomly, especially after trying to adjust temperature from the BT card. Also TRV will freeze at some point, means temps in the GUI will jump back to as specific temperature. If you disable the BT climates and use the standard TRV cards, it will work flawless. Aqara E1 |
Same here with Temperatures are randomly set to a higher value than scheduled. |
Same with the eurotronic spirit zigbee trv. The temperature setpoint keeps jumping to 30°. |
Same for me, but only since I assigned 2 door/window sensors to two thermostats today. Since then, the same symptoms occur with these two. With the others without door/window sensor interestingly not. But maybe it is also a coincidence. I had the settings dialog open for the two affected ones; otherwise I did not change anything. |
Same with Z-Wave JS and Eurotronik TRV's never seen this before. |
Same Here |
The same problem occurs to me too. |
I haven't had the issue since using the 'old' default Cards in the HA Interface - i removed the new BT Cards and i'm suspecting the issue is only when adjusting temp through them? |
Same problem here with different TRV. Sometime set to 30°, sometime to 15°. |
I am giving up now on this ... will come back once it might be resolved |
@zzois thank you for the Tipp! Rolled back to 1.2.1 and it does no more Halloween things 👻 |
Got the same problem with two tado homekit trv groups, each with 2 trvs, the single valve BetterThermostats seem fine. Looks like this problem is not new |
Yesterday evening after fresh configuration, i set the temp to 20.5. Today morning it was on full throttle with 30° and the card was greyed out. Now i'm searching for a way, to prevent HACS from updating to keep 1.2.1. |
1.2.1 have several other bugs, 1.4.0 shoud work fine, can you provide your HA system log, with BT debug mode enabled? |
I tried all the above and nothing worked. However! I removed my Dell 5010 thin client and replaced it with a spare RPi4. I was always bothered by how long it was taking for restarts and it more often than not would not make backups, despite adequate memory. The thin client had dual core processor, 4GB ram and 32GB SSD. Enough you would think and should out perform a RPi4.! I gave up with ZHA since I was unable to cure the erratic TRV behaviour. However I had previously given up with Z2M since there was some kind of issue with RAM usage that used to trickle upwards by the minute until eventually the whole system would crash around me. This problem did not exist with ZHA. But with a RPi4 I re-installed HA, mosquitto and Z2M and all is well. The ram stays constant at around 20.5% usage and NO TRV's change whats so ever, in-fact they are far more stable than ever, each TRV within just a fraction of a degree from the setpoint at all times. Fianally I get my life back!. Why any changes that I made should make a difference I do not know! The only major change is from an X86 based cpu to an ARM cpu. Simon |
This also fixed it for me. Only encounter the problem in a group of thermostats (1 BT for 2 thermostats) |
I can confirm, at the moment it seems that this workaround is working. I have BT Lovelace Card installed. |
I have Danfoss Ally TRV's. Happened to discover BT just yesterday which I quickly installed. So I installed the latest and IT SEEMED TO BE WORKING FINE. Only after I "touched" the thermostat with tweaks the same problem (target temp changed irrationally) was generated. So I am thinking that maybe the issue is the "new" installation. Installing an older version just resets some flags and then upgrading to latest should work. Maybe just uninstalling does not clears everything. degrage and upgrade does the job. If this is the case any version should work? For degrade? I have not tried the child lock by the way Also using the latest BT UI without any issues |
Update on mine, all TRVs behave normally, that is according to the scheduler, during the day. |
I wonder if its worked on this issue? the project feels abandoned. |
After at least a month, I have had no further issues of either:
a: gradual hour by hour increase in RAM usage
b: Inconsistent and erratic behaviour of the BT integration
after switching from x86 based pc to RPI4 which is of course Arm based.
Maybe there is something wrong with the core.
regards
SImon
…________________________________
From: maglat ***@***.***>
Sent: 15 December 2023 13:42
To: KartoffelToby/better_thermostat ***@***.***>
Cc: g0mga ***@***.***>; Comment ***@***.***>
Subject: Re: [KartoffelToby/better_thermostat] Target temperature in GUI changes by itself randomly (Issue #1097)
I wonder if its worked on this issue? the project feels abandoned.
—
Reply to this email directly, view it on GitHub<#1097 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANO7EGN5P5PHEOVUKFI67WTYJRHULAVCNFSM6AAAAAA6FUNTUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXHEYDCOJQGM>.
You are receiving this because you commented.Message ID: ***@***.***>
|
I have exactly the same problem with one of my TRVs. I tested BT on one radiator for two weeks without any problems. Today I switched the other radiators to BT and one of the thermostats is constantly set to fantasy values. |
I also had similar issues with randomly changing temperatures with "AI Time Based" mode. I deleted my BT and created a new one with "Normal" mode as @baskham suggested earlier and now the temperature value stays stable. I've noticed that just changing the configuration of the existing BT doesn't help. |
@matschbirne I'll try this! |
For me, the target temperature changed whenever the temp sensor became unavailable. I use zigbee temp sensors and when restarting the Z2M integration, they go unavailable briefly. During this period, the BTT cards also show unavailable. When everything is back, that's usually when the changes in target temperature are happening |
Mine were set like that all the time, also while it is happening. |
I have some observations that might help solve this. I noticed that I got this problem with randomly changing target temperatures after updating some aspect of a Better Thermostat Instance. E.g. adding a window sensor. I happened until I restarted HA some time later. I enabled debug logging and deliberately deleted an instance of Better Thermostat, then recreated it with a different name. After that I could see that the old instance was still active and reacting to target temperature changes. So my suspicion is this:
# Check if the update is coming from the code
if self.context == event.context:
return => When updating the config or deleting an instance, make sure that the controlling loop actually shuts down. |
I have a single BT controlling four POPP TRVs. The BT is set on "Target Temperature Based", calibration mode "Normal". The BT setpoint changes at random moments to a probably random value, I observed changes to values between 17C and 24.5C. I am certain that I made no BT parameter changes immediately before the random change. Changing the BT setpoint back to the original value doesn't help, restarting HA does restore the original setpoint. Additional information: the BT temperature setpoint is set by a single scheduler device. The scheduler device sets the same setpoint to two BT devices. Not both BT devices go haywire at the same time: one of them remains at the same setpoint, the other tries to cook me by raising its setpoint. I have seen both BT devices getting confused, not at the same time though. I just found out that by changing the temperature setpoint in the scheduler both BT devices get back in line and follow the scheduler provided (changed) setpoint. Restarting HA is not really required. Because only one BT devices gets confused, not both, I assume that the BT device changes its setpoint, and that the scheduler maintains its original setpoint. |
I have this problem on 1.4.0 using Tado TRVs via HomeKit integration. Temperatures changes randomly, sometimes it's -1,5℃ sometimes +3,5℃. With 5 TRVs it happens on the daily basis. |
@bartoszkaminski is your tado only controlled by ha or is it connected to the tado Cloud or some homekit actions? Keep in mind with target Temperatur calibration the offset is done by adjust the target Temperatur on the real device. You can also Checkout the beta 1.5.0 |
1.5 Beta seems to resolve it for me. EDIT: Nope, it didn't. Only for a few days |
My z-wave devices (3 of 7) are still changing the temperatures from 19C to 21C, even with the 1.5 Beta :-( |
@KartoffelToby it is connected to the cloud but I never adjust them in the Tado app. There's no schedule also. I understand that with target temperature calibration Tado's temperature changes. This is intended. The problem is that it's the better-thermostat thermostat set value that randomly changes. |
@bartoszkaminski are the thermostats misbehaving grouped into rooms in the tado app? I noticed when one changes the other one(s) follow and betterthermostat gets confused as the values change. |
@1Tomber I'm not sure if I understand. I have rooms setup in Tado app (can it work any other way?), each room has one thermostat. Temperature changes randomly and I didn't notice that any particular thermostat fails more often than others. |
I apologise for my late reaction. Version 1.5 seems to have solved my problems: in 1.5 months no unexpected or unexplained setpoint changes. Good job, thank you! |
Hello there |
Prerequisites
Fritz Dect 301
Description
Target temperature is randomly set to a higher value. E.g. 26 or even 30°. My guess is, that the temperature meant for the thermostat is set as a target temperature of better thermostat, as it also changes in the gui. It happens randomly and regardless of the room temperature. I use the AVM Fritz Dect 301 Valve Thermostats.
Steps to Reproduce
Expected behavior:
The target temperature set in the gui should not change by itself.
Actual behavior:
The target temperature in the gui changes by itself.
Versions
HA: Home Assistant OS 11.0
BT: 1.3.0
BT UI: 2.1.3
Additional Information
The text was updated successfully, but these errors were encountered: