hi Peter. none of the 10 TRVZBs I am using here ever go ‘off’ by accident.
check when it happened in HA… then check HA for logbook. maybe that will give you a clue. someone toucing it? use the childlock-on. etc.
I’m using the latest Blueprint with Sonoff TVRs also installed with ZHA and having the same issue.
I managed it by selecting a different temp sensor, and then updating automation in YAML putting the correct entity in.
I’ve done this now for all of the TVRs I can and it’s working perfectly, it’s just the filtering that isn’t right for some reason.
that sound like a different issue: You have the sensor not showing up?
(mrchips says it was the trvzb not showing up in the filter… although the pic is not clear on that.))
filtering for sensor is:
filter:
- domain:
- sensor
device_class:
- temperature
So your external sensor is probably not classified as proper temperature sensor or not even as sensor… pls check.
you can always remove the device class filter, but that might give you a very large list of sensors.
I was trying to use blueprint v1.0.1
I’ve moved on though and have it all working ok via Better Thermostat
funny: I just moved away from better thermostat as it is an additional layer around and always yield issues when restarting HA.
Interesting.
What did you move to?
I might end up swapping to Versatile Thermostat in the future (due to the more extensive documentation)
Highly recommended if you use a Sonoff TRVZB. I’ve been using Versatile with my TRVZBs for a while now and am very satisfied.
Direct valve control with Versatile Thermostat (VT) is the major technical advantage over many other solutions because it actually regulates the opening degree of the TRVZB – rather than just setting the heating to “on/off” or a target temperature.
There are a few other things about Versatile that are very convincing, but the possibility of direct valve control was and is the main argument for me.
Thanks, think I’ll start trialling VT instead ![]()
Agreed. I use VT for the same reasons. Dev seems to be adding new features regularly too. ![]()
I’m using this blueprint but whilst it finds the temperature sensor’s Entity ID it will not list or recognise the “External temperature sensor value” Entity IDs of my Sonoff TRVs. I have the External Temp Sensor switched on for the TRVs in question. Any thoughts on why the blueprint cannot find/recognise the TRV’s “External temperature sensor value” Entity IDs? Thanks.
It asks for the external temperature sensor. Which device do you use for this?
From my experience, using VTherm in PID mode with Sonoff TRVs can cause a loss of calibration. See, for example, this thread: SONOFF TRVZB - losing valve calibration quickly when using precise control · jmcollin78/versatile_thermostat · Discussion #831 · GitHub. (There are other threads as well).
Sonoff is about to release a native Adaptive mode, so maybe things will change in the near future, but as of now, it is no longer my first choice
interessting, and when is it updated when i dont have this automation?
hi!
are you using only opening degree for valve change or also closing degree?#
thanks
i think i have the same problem. even calibrating every day (100% to 0% for. a minute). what is your solution for now?
pls try to stick to the subject topic. This is not about VTherm.
the blueprint is to update the TRVZB with external temperature sensor value. the themrostat function is done by the SONOFF TRVZB itself.
(and that is for now an open/close function: see other comments here)
see blueprint triggers:
triggers:
- trigger: state
entity_id: !input sensor_entity
- trigger: time_pattern # added to keep trvzb from falling back to internal sensor
minutes: /30
so it updates on state change of the external sensor and as backup every 30 minutes (you can change that number if you like… but don’t make it more then 2h because the TRVZB will drop back to internal after 2h no update.
if you don’t have this automation (which IS created by this blueprint) … there is NO update of external sensor value. so the TRVZB will always fall back to internal mode
This seems to work well. Great job
I was hoping by using this and setting the trv’s external temperature sensor value, it would then show that value on the trv it self instead of the internal one. Mine is off by 5 degrees so the value on the trv when manually adjusting is just nonsense.
It seems kind of wierd really that you have this option. To use an external temp instead of the internal one, but the internal one is still the one being showed while manually adjusting the trv.
Or is it just me ?

