More settings needed for TRVZB

I purchased several TRVZB devices to replace some simple “smart” thermostatic radiator valves which were programmable but were missing the option to controle using app/api and a connection to monitor the temp remotely (so i had to go to the room and check the temp manually).

The main reason for replacing with TRVZB was to monitor and log the temp and to turn the valves on from downstairs. But when I compare the way the temperature in the room is maintained, the old valves where far better at maintaining a constant temperature in the rooms.

Example of the temperature fluctuation within a 5 °C band, this should off course be an almost constant temperature

1. The TRVZB is currently on or off this should be possible to do in incremental steps. This in combination with a fixed hysteresis causes the room to heat up… TRVZB shuts off above the desired temperature and then cools down several degrees below desired to turn on again. This causes a huge fluctuation in the temperature causing discomfort. The old valves would close the valves a certain amount (for instance 50%) to prevent huge spikes in temperature.

2. fixed hysteresis In combination with above option to incrementally close/open the valve a custom hysteresis is desirable to tune the device to the specific room.

Both options would be greatly beneficial to maximizing the comfort in the specific room and reduce overal usage. Coupling these settings to for instance scene allows us to tweak the settings using external sensors. But if the settings are made available using the API it allows developers to monitor and tweak this settings on the fly and make the device actual smart and tuned to the specific room.

params (read/write):
hysteresisOn: offset in degrees, open valve when temp [x] lower then set temp
hysteresisOff: offset in degrees, close valve when temp [x] lower then set temp
valvePosition: 0 to 100%

Linking the device to iHost would off course give these settings extra option by creating node-red flows to tune the settings dynamicly using other sensors.


Yes. I also found this problem when using it at home. I also prefer to be able to set the TRV to open the valve at a ratio, rather than setting the temperature and then constantly opening and closing the valve.

We will consider this issue in next year’s release update. It depends on whether the current hardware supports us to upgrade the software to achieve more stable temperature control.

Of course, TRV support for ihost and node-red is already in development - since we’re on holiday throughout February, we expect these updates to be released in March.

Next year as in 2025? I would like to think that this is more pressing then i-host or node-red due to the fact that keeping temperature is the basics of the device. Also “depends on whether the current hardware supports” suggests doubt if the hardware can manage this and reads (to me) that there is the possibility that this hardware version isn’t even suitable for this type of settings.

I hope i am interpreting your comment incorrect and that this option has some priority above all else.

That said if i can supply any help in this matter please don’t hesitate to tell me in what way.
I’m running everything on sonoff at my house and am willing to help in testing, perhaps developing and supplying detailed feedback on measurements etc. to see how to get the best results in temperature management.

I currently have 4 rooms running the TRBZB all with an additional SNZV-02 to monitor overall room temp/hum. All data is being logged every 5 minutes.


In the meantime I’ve made sure the devices are up-to-date with the latest version and added a full json logger every 5 minutes. This in combination with information about room temp using the SNZV-02 and outdoor temp can perhaps give a first insight on how settings should be best managed for the best result.

Until this fine-control is available, this TVR is nothing but a toy. I was going to use them throughout but now I’ll have to consider a more expensive route.

The shown temperature swing is larger then normal due to -6 outside (old house) and for me the ability to turn the radiators on and off outway this shortcoming for now since i’m using the trvzb in rooms that are not always occupied.

I do think it is strange this option is not added from the start since it is the basis principle of the thermostatic valve. The issue for me with other (more expensive) options is that in most cases an extra zigbee hub is needed making everthing more complex.

I’m in agreement - we can’t be waiting until 2025 for this support. IHost/NodeRed are not priorities!

iHost and Node Red are priorities. At present it is not possible to control valves attached to the iHost without logging in to the main iHost website using a computer. Node Red is needed for all advanced scene creation and connection to Google Assistant and Alexa. If they don’t then they would need to spend time making the scenes equivalent between the phone app and the iHost, which would take them even more time.

Most Zigbee smart valves work on all or nothing . It is standard for them to function this way not being controllable. It is not standard to be unable to control smart Zigbee TRV with your phone, which is the case for iHost owners.

@eerke - I too am an iHost user and have clients who currently have this ‘brick’ of a device. I do feel we should have a working solution with the app before iHost support is completed. IMHO, the iHost is way behind in its development schedule, effectively in beta, and the core capabilities need to robustly evolve. Currently, until the iHost platform is stable, my unit will stay turned off.

Although iHost and Node Red connections and control would be nice, if the set temperature is not maintained correctly using valve percentages then is that control even worth something at this moment?

That being said, Alexie mentioned possible update in March:

So because you have personally decided not to use your iHost it shouldn’t be improved for all the other users?

@eerke - My point was about priorities … get the basic app right first, for the majority of users, and then, progress to more advanced platforms used by a fraction of users.

A working iHost is of course needed but if a device does not perform its basic functions correctly the point can be made to prioritize first on correct functionality and then on integration in iHost.

But i support your frustration that iHost is lagging on integrations, even the basic information from some devices is not shown, simply “not supported” instead of for instance showing the set temp and current temp from a TRVZB in the overview would provide some use in this case.

If all goes well, as mentioned by @Alexie, we can look forward to some update on iHost in March.
Fingers crossed.

@Alexie please let me/us know if any testing is possible/desirable in this case.

Your priorities and definition of basic. How is having any access using a phone to the TRV on the iHost not basic?

An iHost is a device from this company and has been out longer than the TRV.

Lets agree to disagree on what each of us think should be priority… I have an iHost here as well standing idle at the moment, but i personally would rather have a comfortable room temperature before an TRV control on the iHost :wink:

FYI: The conversation was started with sub zero temperatures over here and since i can control it using the app on my phone this was at that moment more usefull to me to mention.

“I personally”: you have both an iHost and a alternative bridge. You can see and adjust the TRV now. You want an extra feature that is not present on most smart TRV at anything like this price to be prioritised ahead of people without bridges even being able to see or adjust the device at all without turning a computer on or going to the radiator.

Hi Eerke,

Yes I have a z-bridge, z-bridge pro and paid subscription to use the API because I have been using many sonoff devices far before the iHost was even an idea. And don’t get me wrong I’m also frustrated by the fact that the promised software updates are behind for the iHost and would love to actually use it as intended.

But your reactions read a bit as if you feel attacked by my opinion and @njdt . It’s a forum so I should think (and hope) that we are free to define our preferences of what we would like to be considered as an update and can have a friendly discussion about it.

The main goal is to give the developers a clear an concise idea of what features are desirable in the community and let them decide on the actual execution and roadmap for this. And as @Alexie has stated iHost is first up, so i guess you “win”.

But lets try to keep discussions somewhat more friendly because at the end of the day we all would like to have all options available at some time.

I had a cheap (as in 20 euro’s) TRV with only a simple daily local schedule option to define starttime, endtime and desired temp. The valve would be adjusted in steps of 10% when the temperature would (almost) be reached to allow the room to stay within less then half a degree of the desired temp. Only thing missing was the option to control it remotely. And that device was 5 years old… so I guess the option is not that far fetched at all.

@eerke @njdt i was reading through What’s the plan for TRVZB? where @Alexie says the following:

But in this topic March was given as a possible date. So i thought I will give it a try and see if I could connect it to the iHost and it looks likes this works now.

TRV device is also found by node-red at this moment but have not been able to do more tests at this moment.

@Alexie I can select the category thermostat but am unable to select deviceid’s in node-red put-device-state

Running a PUT over the open-api seems to be working correctly:

    "state": {
        "thermostat-target-setpoint": {
            "manual-mode": {
                "targetSetpoint": 18