You may be getting an error in your browser console. Check here and let me know what you find. Not seeing any issues but maybe an unknown scenario causing a problem.
Hi Mark,
I get the following error in the browser console:
Since it reports as ‘Unknown error’ not sure if it’s of any use?
Are you running v3.2.3beta or v3.2.3beta2? There was an error in v3.2.3beta which maybe the cause of this which is fixed in v3.2.3beta2.
A climate entity , with heating actuators , provides :
heating_type: ElectricRadiator
number_of_heating_actuators: 1
demand_type: Modulating
heating_rate: 2984
percentage_demand: 0
comfort_mode_score: 21339
…
My understanding of the heating_rate and comfort_mode_score are representing quality or performance of the system, how are they built? what interpretation can we make?
Demand_type : modulating is there other demand type? The output signal work like a PWM, then what is the period.
I’m running beta2.
Do wiser TRVs ever open the valve fully? I’ve run some experiments using a wiser TRV, a normal manual TRV and a few valves (including Drayton valves). These experiments were run with the valves not connected to any pipes, just on a table.
In all cases I’ve reset and recalibrated the iTRV before each test.
The result was that when the iTRV is at 100% demand (by setting the setpoint to 30C while the temp is 19) what happens is that the valve pin is only retracted 1-2mm instead of more than 4mm.
A normal manual TRV, when set to the highest setting causes the valve pin to retract 4mm (fully open).
It is interesting that during calibration after reset the iTRV motor does get fully up (pin fully retracted ) but at normal operation and 100% demand the pin opens much less.
Why would this happen, seems to be by design. I’m wondering if this is intentional or a bug. It surely must affect how fast the rad heats up at full demand.
Here’s some pictures of a Drayton valve with iTRV and manual TRV when ‘fully retracted’
On calibration: my understanding is that during calibration the motor extends as far as possible until it finds resistance (fulkyc closed) so it learns that eg 7mm extension are needed for fully closed.
What I am figuring out now is that it doesn’t really know where the fully open position is.
So what it does instead of retracting full when it needs to open fully is to retract just by 2mm from the fully closed position at most.
2 Likes
Hi,
That’s really interesting.
After calibration or battery replacement, some of my iTRV’s on a different valve body to the majority of my rads, I have found that when the demand is high the rad never heats up ( the valve doesn’t open properly).
To solve this I have had to back off the iTRV a few mms by unscrewing it a turn or two from the valve body.
This obviously makes the valve open. The other interesting thing is when the demand for that room is zero the rad is cool even though other rooms are still calling for heat and getting it, so the valve is closed.
So my experience backs up your claim, the iTRV is not moving the pin back far enough.
1 Like
@Duke_box I don’t think unscrewing a turn or two fixes this unfortunately. By doing that after calibration you’ll end up with the valve opening a bit more when fully open but the valve won’t close fully when fully off, as it’d still remember that it needs to extend e.g. 7mm for full close but now it’d need a bit more. So you’ll end up with a valve that let’s some heat in when wiser thinks it’s fully closed.
Now if you recalibrate after unscrewing two turns you’ll end up at the same odd place: the valve will fully close (by extending a bit more say 8mm) but again won’t open more than originally.
This is because it seems that the iTRV is configured to be fully open when 2mm retracted from the calibrated fully closed position and no more. It’s really weird it works like this.
I’ve also seen that the iTRV actually modulates the pin: it’s not always fully on or fully off, it tries to behave as a modulating TRV as well depending on the demand percentage of the room.
1 Like
A TRV doesn’t necessarily have to open by much.
For the water distribution to work correctly, the radiators need to be in a balanced system.
The lockshield valve is really the flow regulating component in each radiator. (Balancing).
So a TRV changing from fully closed to fully open doesn’t have the effect you may think.
The TRV opens partially to allow flow and and then will finally almost close again, to regulate the temperature.
(Hence the modulating you describe).
If a particular rad doesn’t get warm under a high demand, it is likely some other rads are not balanced correctly and are allowing too high flow rate.
That will mean, insufficient pressure available across the system to provide flow to others in that situation.
I experienced a similar symptom with a hot water tank feed. (Mid position valve system).
Rads were balanced ok. But occasionally, the temperatures dropped significantly and some more than others.
I eventually realised it was when the HW demand came on and that circuit took virtually all the boiler flow.
I found a balancing ‘gate valve’ for this and have now adjusted it accordingly.
It obviously had never been set correctly before.
It’s possible you need to check the balancing?
3 Likes
@johnBoy that’s a fair point, but I still have some doubts. In this case there’s no specific problem with my radiators (i’m doing bench testing of the valves) but my assumption is that there could be a problem in some cases.
Say that the system is balanced and you have a radiator at the far end of the system which has its lockshield open fully to let max flow in, while others are restricted. The iTRV on this far end radiator, by not opening up fully like a normal TRV would, artificially restricts the maximum flow - it’ll behave just like having the lockshield closed down halfway, while you really want max flow instead. So indeed it may never get as warm as you’d like and it wont behave like a fully open manual TRV.
1 Like
I agree with your thoughts but…
Something I found surprising, was how little the lockshield valves are open.
Please bear in mind, I am not a plumber and can only relate to our home CH system which recently had a new boiler fitted.
The system also had a comprehensive clean & flush after all lockshield and TRV valves being replaced.
The installation plumber did a really good job.
Balancing was another story.
I won’t go into all the details but can summarise as follows:-
The lockshield on the two furthest rads are now 1.5 turns open.
The nearest rads are 0.5 turns open.
(The pipe length to our furthest rads I’d guestimate to be around 12m from the Mid Position Valve).
If you haven’t already checked,( or have set it yourself), it may be worthwhile checking the setting on your furthest rad.
I’d be surprised if any lockshield valve is fully open. (Just over 3.5 turns on those fitted here).
So the furthest here are around 40% open.
(I fitted the Drayton Wiser system to reduce boiler cycling.
But that again, is another story).
The above is just relating my experience to date.
I’m interested in other folks experiences as it could all be useful information.
(Three months on and still tinkering).
Apologies for the delay, I’ve been away (and have used 2/3 times my normal winter usage in that time).
Thanks for the reply, the firmware is 0000ea64 on the thermostats and 3.10.8 on the hub
Just a query regarding reported battery voltage. In ha, this is reported to one decimal place. Does the heat hub provide any greater level of precision (ie two decimal places)?
For context, I use rechargeable AA batteries despite them not being recommended as I find them to have no issues and as such they cut down on waste significantly. The only drawback is that due to lower voltages the batteries will report at low (approx 2.5v) for most of the time until they run out completely at 2.4v. If it were possible to get two decimal places, it would be possible for me to use rechargeable batteries and replace them before they fully run out.
Unfortunately not, the Wiser hub reports the value as an integer in 10’ths of a volt.
Roomstat
“BatteryVoltage”: 26,
“BatteryLevel”: “Normal”,
Smart TRV
“BatteryVoltage”: 26,
“BatteryLevel”: “Low”,
in both cases that is 2.6V
1 Like
Is there an easy way to logbook all boosts and cancel boosts? Or will I need to template some state attribute sensors to monitor hvac_action / is_boosted entries?
(Wanting to have different room unoccupied actions based on schedule vs boost called for. I.e. if scheduled and room unoccupied for 5 mins then turn off heat, if boost was called for that room then has to be 30 minutes unoccupied before turning off)
Just found the events output (not sure how i missed that) so can create an automation for logbooking boosts and temp changes (altho maybe easier to map the boosts to boolean template anyway for the occupied automations i want)
Hi Jamie,
When is the new firmware rolling out and what it the release number please?
My hub is on 3.10.8 and currently dropping off the network most days.
Opentherm Question…
When downloading diagnostic data you get the openTherm properties (below), is there anyway to get some of the attributes into home assistant sensors etc.
i know some where added as state attributes but not all.
Also does any one have any documentation on “SlaveStatus” from the diagnostic output in terms of possible values? i’m trying to debug an issue with an OpenTherm Gateway I’ve put in-between the Drayton and the boiler.
If anyone is interested in OpenTherm in general or clarification of the what some of the attributes could mean i did find this documentation:
“OpenTherm”: {
“chFlowActiveUpperSetpoint”: 800,
“chFlowActiveLowerSetpoint”: 350,
“dhwFlowSetpoint”: 550,
“dhwEnable”: true,
“featureActions”: {
“ModulationOnboarding”: true
},
“Enabled”: true,
“transmitter”: {
“messagesSentCount”: 100430
},
“receiver”: {
“decodingErrorsCount”: 4080
},
“operatingMode”: “OTplusCommunicationFailure”,
“preDefinedRemoteBoilerParameters”: {
“dhwSetpointTransferEnable”: true,
“maxChSetpointTransferEnable”: true,
“dhwSetpointReadWrite”: true,
“maxChSetpointReadWrite”: true
},
“ch1FlowSetpoint”: 350,
“ch1FlowEnable”: false,
“ch2FlowSetpoint”: 350,
“ch2FlowEnable”: false,
“operationalData”: {
“SlaveStatus”: 10
},
“roomTemperature”: 151,
“roomSetpoint”: 160,
“TrackedRoomId”: 1
}
This is due to be added to the 3.2.3beta2 before final release. Probably in a few days/a week.
1 Like
You can also use the attributes is_boosted and is_heating on the room climate device if they are more conditions than triggers.
Hi PJ,
Unfortunately I cannot give any release dates. All I can say is we are working super hard to get it out to all our customers. Look out for an email communication from our marketing team when it is ready.
4 Likes