zigbee2mqtt
zigbee2mqtt copied to clipboard
Heating is completely broken right now (At least for TV02 thermostats)
What happened?
After the most recent changes to the tuya converter (https://github.com/Koenkk/zigbee-herdsman-converters/pull/4750) the heating with TV02 radiator valves is completely broken.
When there are manual changes made (e.g with better thermostat doing local temperature updates or scheduler component doing the scheduled temperature changes) the thermostat switches back to auto mode and completely ignores the adjusted attributes.
This currently leads to radiator valves (with the model TV02 at least, I dont have any other valves installed in my home) being completely open 24/7 -> Even if I turn the knob on the thermostat itself the changes will be discard and the heating continues.
Especially in this winter I wish that this issue gets resolved fast. I see no other way than remove them from Z2M right now and controlling them manually by hand (which sucks).
What did you expect to happen?
I expected that the valve accepts the manual temperature changes and will stay at "manual" mode.
How to reproduce it (minimal and precise)
- Change the local_temperature_calibration or any other attribute of the valve in Z2M / HA / or by hand at the valve
- The system mode will then switch from manual to auto
Zigbee2MQTT version
1.28.2-dev commit: ca4badc
Adapter firmware version
20210708
Adapter
zStack3x0
Debug log
No response
When there are manual changes made (e.g with better thermostat doing local temperature updates or scheduler component doing the scheduled temperature changes) the thermostat switches back to auto mode and completely ignores the adjusted attributes.
If I understand correctly, when setting the temperature of this thermostat via MQTT, the thermostat kicks itself out of manual mode and switches back to auto mode? (and therefore ignore the set temperature)
When there are manual changes made (e.g with better thermostat doing local temperature updates or scheduler component doing the scheduled temperature changes) the thermostat switches back to auto mode and completely ignores the adjusted attributes.
If I understand correctly, when setting the temperature of this thermostat via MQTT, the thermostat kicks itself out of manual mode and switches back to auto mode? (and therefore ignore the set temperature)
Dear @Koenkk, that's exactly what happens. But I don't know if the change of the mode is triggered from Z2M or ifthe thermostat is doing it itself. It happens also when switching it from "off" to "on" it changes to "auto" mode.
I don't see a usecase where people using them with Z2M (HA or whatever in the background) will ever have any use of the auto mode, as automation is done in HA.
As always, thanks a lot for your work!
Meik
So when after setting the temperature you also set the mode again, it works correctly?
So when after setting the temperature you also set the mode again, it works correctly?
Yes and no. Because when switching between the modes it also changes the temperature that is assigned from the mode. So when switching just back to the manual mode, it stays in the temperature that came from auto mode.
@Koenkk yes. If you have automation for getting actual temperature(no automatic report, need to set online
attr to ON
in some time periods you want) it even ignores what you set directly on TVR by buttons.
@Hessenpower01 so what do you need to publish in order to keep it in manual and set the temperature?
@Hessenpower01 so what do you need to publish in order to keep it in manual and set the temperature?
@Koenkk ... I don't know ... sorry. Which info may I offer?
@Koenkk @vladi1234 said in prev topic that he working on patch for this. I think he knows what to do because he already did that once.
@vladi1234 can you answer this?
so what do you need to publish in order to keep it in manual and set the temperature?
Hello, got my TV02 since two weeks and wondered about this problem found here.
I tried to "betray" the scheduler. but that's that same.. so i went to Scenes. Default is 0. I changed it, without filling anything else, to manual and i think it solved my problem.
Maybe it's the way, to get it working, without switching back to auto after setting the temperature via "currentTemperature". Let me know if this helped you too. Cheers
Hello, got my TV02 since two weeks and wondered about this problem found here.
I tried to "betray" the scheduler. but that's that same.. so i went to Scenes. Default is 0. I changed it, without filling anything else, to manual and i think it solved my problem.
Maybe it's the way, to get it working, without switching back to auto after setting the temperature via "currentTemperature". Let me know if this helped you too. Cheers
@rendo0m the setting as you showed ist standard, already like this in my installation
sad. mine was "auto".
Hello everyone,
i tried to remove errors from the user code "vladyspavlov", but I also found that this does not make sense, since in total it has more than 10 errors embedded in the code, which makes our thermostat stupid.
I am planning to reanimate and integrate my extended code which is now bug free and includes new features.
Has a working system_mode
for Homeassistant
.
Similarly, it has a functional schedule
.
Some other small corrections.
Eliminated all known problems.
Hello everyone,
i tried to remove errors from the user code "vladyspavlov", but I also found that this does not make sense, since in total it has more than 10 errors embedded in the code, which makes our thermostat stupid.
I am planning to reanimate and integrate my extended code which is now bug free and includes new features.
Has a working
system_mode
forHomeassistant
. Similarly, it has a functionalschedule
. Some other small corrections.All known problems are eliminated.
Happy to read that :-)
Wouldn't mind if OTA would also work ... thank you so much for your efforts
Pull request https://github.com/Koenkk/zigbee-herdsman-converters/pull/5022
@vladi1234: Does your PR fix the set-window_open-issue (#14163 and #15181) as well? I already had the set window_open-error before and not only in the latest version based on vladyspavlov's recent commits...
@vladi1234: Does your PR fix the set-window_open-issue (#14163 and #15181) as well? I already had the set window_open-error before and not only in the latest version based on vladyspavlov's recent commits...
Can you perform TVR reset and then tell if it helped?
I set up a test environment with latest z2m-dev, applied your patch, resetted TRV and paired it. At first it seemed to work, but if I now set "open_window" to ON via Webfrontend, it switches back to "OFF" after a second, unless I set "system_mode" to "off" - then I am able to toggle "open_window" as expected and if I switch "open_window" "ON" it stays "ON".
Please let me know, if you need more information or data - I am happy to assist.
Has the same issue, can you help me out how to apply the patch please?
Our TV02 does not seem quite compatible with new Tuya format.
But it will be done
Bug fix for known bugs TV02 which were installed in 0.28.1. https://github.com/Koenkk/zigbee-herdsman-converters/pull/5096
Please revert the auto mode switch back to previous state. There's no reason for putting the mode in auto after heating or changing temp. This screws any logic and cannot be reverted using automations in HA.
Thanks in advance.
This may take some time until the pull request marged.
Workaround
To be able to use them as they behave currently I leave them all the time in manual mode. I don't turn them off but reduce temperature to 5°C instead. Also created a script named "heating off" which in fact just set's temperature to 5°C. So they remain in manual and temperature values coming from HA apply.
The problem with the auto
has already been fixed.
If you want control everything, you don't need the auto mode or off or anything else. In my opinion you need this only if you don't want control it from outside. All other settings result in that what you setup into z2m. If you control it via Homeassist or Openhab iobroker etc. Then leave it on manual. Everything else you control it via Setpoint temperature. Nothing else will happen with auto, window open or off. That is how it is working for me and very fine. 5° is the lowest and the valve is closed. 8° is frost protection. I didn't found any protection to prevent that the valve stuck on summer time. Are you know about this kind of protection? My old thermostat drove the valve fully each Thursday at 11 o'clock to prevent of stuck. If not, so I must develop a rule for it...
I set up a test environment with latest z2m-dev, applied your patch, resetted TRV and paired it. At first it seemed to work, but if I now set "open_window" to ON via Webfrontend, it switches back to "OFF" after a second, unless I set "system_mode" to "off" - then I am able to toggle "open_window" as expected and if I switch "open_window" "ON" it stays "ON".
Please let me know, if you need more information or data - I am happy to assist.
I have currently the same issue. @vladi1234, afaik you fixed a similar problem in your PR for frost_protection and replaced the converter with tuya.valueConverter.TV02FrostProtection
. Do you think a similar thing might fix the window_open problem? I have no idea of how all of this works yet, but might take a look into it if you think the cause is similar.
I don't just have frost_protection
tuya.valueConverter.TV02FrostProtection
replaced, but also heating_stop
and system_mode
tuya.valueConverter.TV02SystemMode
replaced. That should fix problem with switching into auto
mode.
Your problem with PR does not have the slightest to do.
My question is, for what purpose do you want to use open_window
?
I don't mean that my problem is a result of your PR :) As far as I understand it your PR solved a similar problem with frost_protection as I have with open_window. I am using it coupled with my window sensors to disable heating. That works for quite some time, but after a certain time it always resets itself from on to off immediately, as frost_protection did before your PR. My question is whether replacing open_windows method with your new method might solve that problem too?
My question is whether replacing open_windows method with your new method might solve that problem too?
Replacing 'open_windows' method can not fix these problems.
You must not connect a window sensor to open_windows
it works automatically. See an excerpt from Manual for Thermostat:
8.4 Open Window Detection
The device automatically stop heating when it detects a sudden temperature drop(5°C in 5 minutes as default). This is usually caused by an opened window or door and the open window icon will display(open) on the device. The device will operate according to the preset window. Press the pair button to cancel.
App operation: Click the open window icon in APP to cancel the window opening function.
The open window detection only operates in automatic mode and manual mode.
For window sensor you use heating_stop
then it works correctly.