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.
@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.
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.
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.
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)
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:
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.
Think I’ve got my automations sort now; so that someone briefly walking through a room won’t turn off the heating boost rather than my old global rule of turn off after 5 minutes of room becoming unoccupied.
On a side note though, does anyone know how to cleanly write to logbook? did create an automation for wiser_event triggering (mainly out of interesting, as the graph is easy to read) but you end with with a mess like
" Boosted By 4°C for 60 mins triggered by automation Wiser Log (my automation name) triggered by event ‘wiser_event’
"
with none of the ‘triggered by…’ being of any use in passively logging changes, would just want the message (bold text) i declared/templated.
If it’s any help, if I need to log something, I use the File integration, which allows you to create a standard notify service and then you can send whatever you want (using standard templating) in any format you want to a file. I just format my output as CSV. Easy to import into Excel for further analysis and good for long term storage outside the database, especially if you’re only keeping a week or two of history in order to keep your database size to a minimum.
Even if it’s a bit messy, I’d be interested to know how to write to the Logbook if could point me in the right direction. I didn’t know you could do that and although I can’t think of a use for it at the moment (over outputting to file), it would be useful to know how to do.
@darcey@robertwigley@crankshaft Sorry to bring up a previous mini-discussion from within this thread, but I wondered if any of you were still seeing any oddities between states of is_heating and percentage_demand, or sensor.wiser_heating etc?
To indicate whether or not my boiler is actually running, I am currently still using the following:
however I am noticing that the state attribute ‘is_heating’ of my climate.wiser entity can have a value of ‘true’ but my sensor.wiser_heating entity state is ‘off’’ as is my sensor.wiser_hot_water. In this state, the green LED on the wiser hub is NOT lit up for the heating channel. So I don’t understand why the state attribute ‘is_heating’ of my climate.wiser entity shows ‘true’ when no heating is taking place and the boiler is not firing?
On the other hand, the state attribute ‘is_heating’ of my climate.wiser entity can be ‘false’, while the sensor.wiser_heating entity has a state of ‘On’. The green heating channel LED on the hub is ON in this case.
Using the history stats based on my Wiser Boiler template is obviously being affected by this.
I can’t say I have noticed a discrepancy between the sensor.wiser_hub_heating and the is_heating attributes for individual rooms. In my case I believe if one is on, the other is on and vice versa. I’ll keep a closer eye on this though.
I use percentage_demand to tell whether the heating is actually on (i.e. calling for heat), even if it’s not actively firing the boiler, which I use is_heating for. I’ve created so many template entities and renamed all my devices so they make more sense to me, so it’s quite difficult to compare to someone else’s or a default setup.
Do you just have a single Room Thermostat, which is climate.wiser that you are referring to?
FWIW and for anyone considering purchasing additional Room Thermostats, I decided to bite the bullet and put them in my main living spaces, rather than relying on the iTRVs, which we know ‘guestimate’ the actual temperature.
I only put them in yesterday, but it’s made a noticeable difference to the accuracy of heating that I can actually feel without even looking at the data, reducing overshoots in the main heat up cycle in the morning, tracking the actual temperature (measured by another temperature sensor) properly within about 0.5 degrees of variance (Wiser measures lower than the real calibrated temperature from my other sensor) and is giving a noticeably more even temperature distribution between rooms.
Heat up cycle for my Living Room from this morning, after the Room Thermostat was added yesterday (the top blue lines in all the graphs are the real calibrated temperature from my other sensor):
And the same for yesterday, before the Room Thermostat was added (showing the big overshoot and additional unnecessary heating that went on well beyond reaching temperature):
Zooming out, you can clearly see when the Room Thermostat was added yesterday:
My conclusion is that although they are ludicrously expensive for what they are, they are worth buying, at least for the main living spaces. Unfortunately, I can’t really justify buying them for every room at the price they are. Although there is an argument that having them in every room would reduce unneeded heating and wasted energy, as can be seen when comparing the first and second graphs. I’d have to weigh up the cost benefits of this carefully though.
What we really need @jamiebennett is a small screenless temperature sensor (a bit like the Aqara temperature and humidity sensors) that can be easily hidden in each room and most importantly at a much lower price. I don’t need any of the controls or display of the current Room Thermostat, I just need the accurate temperature that a remote (from the radiator and iTRVs) temperature sensor gives.
Yes that’s correct, I still haven’t managed to fit my iTRV’s yet, so just using the Roomstat in our main living area currently.
I’ve bought a set of the small Aqara Temp/Humidity sensors which use BLE and have hooked these up to my HA using BTHome. I can now see the temperature of every room around the house, as far as I can tell, and comparing them to the Wiser Roomstat, they seem to agree on temperature so hopefully they are accurate. I will probably use these as the temperature source for each room even when i do fit my iTRV’s, but will compare with the temps reported by the iTRV’s out of interest first.
Good to see the improvement in accuracy that you have obtained via using additional Roomstats.
I agree though, a screenless, much cheaper version of the Wiser Roomstat would be nice to see, as I also never interact with the current one, probably as the screen is off, so I always reach for my phone for any adjustments.
You can certainly have rooms that is_heating is false but the sensor.wiser_heating is on as that means that that room is not heating but heat is being called by another room causing the boiler to fire.
What is more unusual is is_heating is true but sensor.wiser_heating is false. We read this from a parameter from the hub called “ControlOutputState” on each room. It is possible however, that something in the hub algorithm is not firing the boiler when a room demands heating due to cycle times or it being overridden by eco mode and this parameter does not reflect that.
I’d have to weigh up the cost benefits of this carefully though.