Closed Ra72xx closed 10 months ago
If I disable this feature, I will have many issues like this : https://github.com/jmcollin78/versatile_thermostat/issues/334 , https://github.com/jmcollin78/versatile_thermostat/issues/121, https://github.com/jmcollin78/versatile_thermostat/issues/95. These are major bugs which lead to a complete HA unavaibility. I'm sure you don't want this.
This feature avoid the infinite loop by having a mecanism that avoid to change too frequently the target temperature set directly from the hardware device. The other possibility is too refuse all modifications coming from the underlying hardware device. Having two way to control the same device is a mess: when there are not equal, which device is right ?
So for the moment, I really don't wish to remove this safety mecanism.
I understand your thoughts, especially as I was hit by the bug this workaround fixed, too. However, the direct result is that the thermostats are only controllable in a reliable way if you have access to the HA ui and not by the intuitive way of simply using the thermostat directly, which is inconvenient in everyday situations. Maybe the "lazy thermostat" workaround could be redesigned a bit: If the VT setting has been changed, it can be changed again without any time limit (cooldown-time) by the same means (i.e. UI or one of the controlled thermostats). Only if there is a change by some other means (e.g. another hardware thermostat, which in reality maybe just has not yet gotten updated), this is ignored for lets say 10 secs. cooldown time.
Can't you set directly the right target temperature instead of doing +/- 1 at each click ?
Here is the main loop reason :
At step 4, I'm not able to detect that the update is following an change from HA or directly from the underlying. I don't have any source of update. So I throttle all message at step 4 to ignore it, if just before (10 sec) the target was change.
I know this is not perfect but this is more a safety feature. When a event storms occurs this can be very bad for HA, the SD Card or the physical device which receive many update at each seconds.
So I will consider touching the feature with fears (see #334 ).
I don't say, I will not do anything to allow setting target temp from a thermostat device which is more user friendly than doing this from HA. Can I can do easily is to allow the change (in "expert mode") ot the 10 sec which is hard coded to something else so that you will be able to 0 or 1 to deactivated the feature. At your own risk.
Whatever I will do, this will be at a low priority (so you have to be patient)
Thanks. Maybe another way would be to wait a few seconds after (not more then 2 secs) a temperature change has been initiated by the user and only after this time take the current setting and apply that. I.e. not to react at once and then put in a 10 secs cooldown time, but give the user time for a typical setting of the temperature and only after that time begin to stear the actual thermostat?!
I will not touch this feature sorry.
I just realised that after updating from 5.2.2 to latest 5.3.3, setting the temperature manually on my zigbee2mqtt connected Tuya TRV no longer changes the temperature of.the VTherm. For example.i have VTherm now at 16.0, the underlying mqtt climate at 14.5 and the device display at 14.5.
I understand that the issue here is synchronization related and distinguishing user input from VTherm actuated changes, as it causes storms of events.
I'm not familiar with inner workings of HA but perhaps there's MQTT/ZHA events that could be listened to?
Given that being able to set the temperature on the device would be super useful, perhaps it would be worthwhile to keep this issue open for consideration of solutions?
Hello @mwitkow ,
Please open a new issue and follow the template of the issue. You should be able to change target temp on your TRV and VTherm should follow this temp.
You should be able to change target temp on your TRV and VTherm should follow this temp.
How? For me it's not really possible to set target temp on the TRV in a useful way, as it seems only to be synced partially. E.g. if I turn up the TRV from 20 to 22°, it may happen that after a second it might get set back to e.g. 21.5°, probably depending on how fast the knob is turned and how fast the information about it is transmitted back to the integration. This is especially valid for a room in which I combine four hardware thermostats, here it may indeed happen, as @mwitkow descrbes, that the target temperatures get somehow out of sync.
Posted the bug in https://github.com/jmcollin78/versatile_thermostat/issues/359
When trying to set temperature directly from my Aqara Zigbee thermostats, this is not really possible, because after few temperature steps the temperature will be reverted. So e.g. I turn down the thermostat from 30° to 22°, it at once resets to e.g. 28°. I assume this is related to fix https://github.com/jmcollin78/versatile_thermostat/issues/121#issuecomment-1763440389:.
Is there any possibility to configure/disable this "lazy thermostat fix"?