[SOLVED] StellaZ TRV Direct Control - has anyone managed it?

Hi All

I’ve tried, on and off, for about 4 years to get my StellaZ TRVs to work in ‘Manual Mode’, where the valve position is controlled directly by sending a dimmer type percentage value to it. So far, I’ve failed every time.

The TRVs are supposed to have 4 operating modes and most control the valve position based on internal algorithms using the device’s inbuilt temperature sensor. There’s an ‘Off’ mode, where the valve only opens at temperatures nearing freezing to prevent pipes bursting. There’s an "Economy’ mode, which keeps the room a bit cold. There’s a ‘Comfort’ mode, which keeps the room a bit too hot and there’s a ‘Manual’ Mode, where it should be possible to bypass the internal algorithms and control the valve between fully shut and fully open under program control.

I’ve found that the built-in temperature sensor isn’t that useful. It’s placed too low in the room to give an accurate indication of room temperature and it’s hugely influenced by hot water going through the pipes. As a result, I use separate temperature sensors mounted at mid-height in each room, which works well. I also use a crude bodge to set the target temperature very high when I want the valve to open fully (35c) and very low when I want it to close (10c). This bodge works well in ‘Comfort’ mode but I’d like to improve the solution by being able to (say) set valves at 50% and use some intelligence to avoid the binary ‘On/Off’ solution I have now.

Unfortunately, I can’t seem to put the TRV into Manual Mode and set the valve position directly. It reverts to ‘Comfort’ mode on wake-up. I’ve trawled the forum but haven’t yet found a successful implementation of ‘Manual’ mode.

Has anyone out there actually done it? If so, I would love to see your Items/Rules so I can replicate here on my OH2.4 system.

In hope…

Hi Andrew,

I am running openHab 2.5.0.M1 build on RPI 3B with Aeon S2 stick.

// Items
Dimmer stella_rad_dimmer "Stella Rad Dimmer [%d %%]" <radiator>					(All, gEveryChange, gEveryFive) 				{channel="zwave:device:zwave-stick:node22:switch_dimmer", autoupdate="false"}
Number stella_rad_battery "Stella Rad Battery [%d %%]" <batterylevel> 			(All, gNU, gBatt, gEveryChange) 				{channel="zwave:device:zwave-stick:node22:battery-level"}
Number stella_rad_mode "Stella Rad Mode [%d]" <radiator> 						(All, gNU) 										{channel="zwave:device:zwave-stick:node22:thermostat_mode", autoupdate="false"}
Number stella_rad_setpoint "Stella Rad Setpoint [%.1f °C]" <radiator> 			(All, gNU, gEveryChange) 						{channel="zwave:device:zwave-stick:node22:thermostat_setpoint_heating", autoupdate="false"}
Number stella_rad_setpoint_eco "Stella Rad Setpoint Eco [%.1f °C]" <radiator> 	(All, gNU) 										{channel="zwave:device:zwave-stick:node22:thermostat_setpoint_heating_econ", autoupdate="false"}
Number stella_rad_temp "Stella Rad Temp [%.1f °C]" <temperature> 				(All, gNU, gTemp, gEveryChange, gEveryFive)		{channel="zwave:device:zwave-stick:node22:sensor_temperature"}
// Set Rad Valve

if (stella_rad_mode.state != 31) { stella_rad_mode.sendCommand(31) }

var Number newDimmer = 50

// Logic
// Rad valve is normally half open (50) but when temperature is reached (bedroom_heater=OFF) valve will close.
if (bedroom_heater.state == OFF) 	{ newDimmer = 0 }

// DoIt
if ((stella_rad_dimmer.state > newDimmer + 2) || (stella_rad_dimmer.state < newDimmer - 2)) { // Dimmer has a mind of its own!!! Ignore small changes.
	logInfo("HeatingRules","Requesting Rad2 Dimmer to change from " + stella_rad_dimmer.state + " to " + newDimmer)

I originally had your problem but can’t remember what exactly got it working. I have to say this valve is very temperamental and needs the blue button poked repeatedly to get it to initialise. Also I found if I set it to say 50% it would decide 48% was good enough and the rule was constantly fighting it causing the valve to make small adjustments draining the battery! It also does this when in the other comfort/eco modes which must be why it seems so battery hungry.

Hope this helps.

1 Like

Good point.
It may be that the device has granular positioning i.e. it does not have a continuous smooth 0-100% range, but discrete steps instead. Say it had twenty-five steps - 0% , 4%, 8%, etc. You could command 5% and get an eventual response of 4%.

A clean way to deal with that might be to take the calculated “desired position”, compare to current “actual position”, and only issue a command if it’s more than 2% different (in our example)

1 Like

Hi Kevin

Many thanks for this. If one person can do it, then at least it’s possible! I agree that they are temperamental and battery hungry and I’ve almost worn the push-buttons out through frequent manual wake-ups… But your post gives me hope!

Your Items differ slightly in that I didn’t use the autoupdate=“false” config and I used Number instead of Dimmer and decimal values instead of %ages - but somewhere in there may be the answer.

I understand the motor shifting - mine would do that too, hence the very high and low target temps, which mostly overcame the problem. Every now and then it cycles on it’s own too, which I think keeps the valve from jamming.

I’ll give your code a spin and see how I get on.

Incidentally, I have a broken one that I took apart. There’s a pair of motor wires and what looks like a surface mount LED/Photodiode right next to an exposed bit of cog on the gears. The PCB is minimalist to say the least! It must use an initial calibration (fully open to fully closed) to work out what position the valve is in and it makes sense that it wouldn’t have 100 discrete positions.

Many thanks!!!

Thanks Rosko

I’ll do some testing if I get it to accept Direct Mode. I can find a workaround if it’s a bit random on positions… My guess is it counts cog teeth from fully open to fully closed during initial calibration and divides by 100 to get a rough position thereafter. This would vary from calibration to calibration as it depends how strong the battery is as to how tightly it can close the valve.

At least I know it can be done! Wayhey! :smile:


I’m so happy! 4 years of mucking about…

You are now on my Christmas card list!

Thank you

Comment only; sometimes this kind of mechanism will have a single ended calibration routine. Knowing that the expected full travel is say twenty steps (or 5 seconds or whatever), the firmware has only to gently run to closed for twenty-five steps (or six seconds) to establish its “zero point”.
Makes no difference here!