Thanks @jamiebennett. As I said, it’s a huge improvement. Do you want to take my hub details for monitoring?
Hi Rob. If you can send me your MAC address via a message that would be great and I’ll have the team keep an eye on it’s connectivity.
1 Like
I have done some more research on OpenTherm. So it turns out, I get this via the debug diagnostics
preDefinedRemoteBoilerParameters:
"maxChSetpointTransferEnable": false,
"maxChSetpointReadWrite": false,
"maxChSetpointUpperBound": 800,
"maxChSetpointLowerBound": 200
What do these mean?
maxChSetpointTransferEnable: False means that the hub cannot read the current value of the “Maximum allowable CH water setpoint temperature” that you may have configured on the boiler side using knob/buttons. This is because the boiler does not support sending this value through opentherm.
maxChSetpointReadWrite: False means that the hub cannot configure the “Maximum allowable CH water setpoint temperature” on the boiler side.
maxChSetpointUpperBound: 800 and maxChSetpointLowerBound: 200: These are the limits for the “Maximum allowable CH water setpoint temperature” supported by the boiler, but not what you may have actively configured on the boiler as the max flow temp.
So what does Wiser do?
"chFlowActiveUpperSetpoint": 800,
The wiser hub uses 80C as the active upper bound for the CH flow temerature (and 35C as the lower bound), by default.
This means that in Opentherm mode, when the boiler does not send its active max setpoint temp setting, Wiser will always use 80C and modulate within the 35-80C range depending on demand.
The bad news? Users cannot configure this. They could though, if Wiser allowed it.
Tado allows installers and engineers to configure this ‘default’ active max temp limit. @jamiebennett perhaps something you want to check (which may or may not be sent to the boiler, depending on whether sending this is supported by the boiler or not).
In my case, because I want to lower this upper bound from 80 to 65 or less, my only option right now is to get an OpenTherm GateWay device, which I will be able to connect between wiser and my boiler. This will allow me to ‘lie’ for some messages going back and forth and make it appear so that the boiler supports reading the active max CH temp, and also send to the hub that the active max temp is 65. I then hope that Wiser can read this and set this as its own upper bound, and thus start to modulate between 35 and 65 instead of 35 and 80.
FWIW, to all those discussing OpenTherm maybe not working as they expect or would like, Drayton have publicly stated that they are working on improving the OpenTherm implementation this year. Without explicitly saying it’s not quite up to scratch, they have sort of acknowledged that it isn’t as good an implementation as they would like it to be.
2 Likes
There’s certainly lots to do. I can think of at least the following:
- Make it work with DHW (so kit2 hubs): This would allow Wiser to control DHW temp or at least on/off through opentherm.
- Make it work with the second CH relay (so that kit3 works). Right now any demand from devices assigned to the second relay does not get translated into opentherm demand, so the second relay is unusable. Demand 100% for a device in relay2 and no demand from anything else will result in 35C flow temperature.
- Make it more configurable, as I describe above, so that max CH setpoint can be configured.
These are all things that I believe are supported by the protocol, its just a matter of implementation on the wiser side.
Thanks @georgek for the info - your explanation of your research is fantastic.
Because of this (and @robertwigley post) I now know the Wiser implementation is severely lacking when it comes to OpenTherm.
I am wondering if I should revert the boiler back to the normal way of working. It certainly hasn’t reduced my gas consumption but I perceive the setpoints are more accurately adhered to.
With regard to the firmware update, I haven’t had any dropouts that have lasted more than 30seconds for a few days now. So a big improvement so far.
30seconds - that’s the scan time of the integration - ??
1 Like
I have had no dropouts since firmware update.
1 Like
I have definitely seen fewer outages since the new firmware - in fact only one since 2nd March. I’ve never had a great signal where my hub is, and that hasn’t improved. I was seeing multiple disconnections per week, so I would have expected to see them recur by now.
1 Like
@msp1974 Mark, I’ve just noticed that if I try to change the set point manually (slider or up/down arrows) I’m getting the following error:
Failed to call service climate/set_temperature. “WiserRoom” object has no attribute ‘_is_passive_mode’
I’m on version 3.3.1 and I did re-enable Passive mode and delete the old passive mode entities. Currently I have none of the iTRVs with Passive mode enabled.
Any thoughts? Let me know if you’d like the diagnostics or log file output.
Thanks for the feedback.
Can you redownload v3.3.1beta as this was an issue but republished it with this fixed. Think you may have installed quite quickly after release and therefore dont have this corrected version.
Yep, that was it. Thanks very much.
Hi guys. Recently I’ve been having an issue which I hope someone could assist me with. I noticed that every now and then, my system resets back to whatever the schedule is set to. For example, if the room is scheduled to be 18C and I turn the heating up to 19C, randomly it will just back to 18C. This is quite annoying as my wife thinks it is me turning down the heating all the time haha!
Anyway, I checked the home assistant logbook to see what was going on. When this happens, it appears that all Wiser entities briefly go unavailable, then come back again. My first thought was the hub going offline due to this ongoing WiFi issue, but this is not the case. I checked my Unifi controller and the hub did not experience a disconnect.
I disabled the HA Wiser integration and the issue seems to have gone away. Presumably this means some weirdness is going on and the system keeps resetting overrides.
Anyone come across this before?
Maybe a silly question, but it’s not just the schedule resetting the target temperature is it? If you’ve set an override and the next scheduled start time is reached it will automatically set it to the scheduled target tempertature and cancel the override.
No, this crossed my mind too, but it happened at a time when no schedule event was due for hours.
Also, the fact that all the entities go offline briefly appears to have something to do with it, which wouldn’t occur during a simple schedule change.
Hmm indead a strange one. I can’t think of anything in the integration that would do this as it has to send a command to the hub to cause it to cancel any overrides. Especially strange that the entities go unavailable first. This would maybe indicate that the hub is rebooting for some reason. And maybe this hub reboot is being caused by HA getting updates which is why disabling it prevent issue you are seeing. Have you tried dropping the hub update interval and see if this stops it happening too?
As a side note to maybe see what is going on, there is a status available form the hub (it is not yet built into the api as I only recently discovered) which will give you uptime and last reason for reset. If you know how to use postman to get data from the hub, then go to:
http://[hub_ip]/data/v2/status/
last forward slash is important - don’t miss it.
{
"uptime": 183779,
"freeHeap": 62768,
"lowestFreeHeap": 20912,
"lastResetReason": "SOFT_RST",
"taskUsageEnabled": false
}
uptime is in seconds but only updates every 10/11 secs.
Thanks for this. After a bit more digging, I found that the entity “Wiser Cloud” disconnecting and reconnecting every 6 minutes precisely. If I look in my pfsense logs, DHCP shows corresponding Discover, Offer, Request and Ack entries every 6 minutes.
So I reckon what’s happening is that eventually the gives up after so many attempts and restarts, causing the set point to reset.
Question is, what could have changed that would cause this 6 minute loop?
Hi This may or may not be useful, but I had issues with the wiser hub showing a solid red light occasionally and I kept powering down the wiser hub and turning it on again and the issue was 3/5 resolved. Then I had a feeling my eero mesh wifi network may be the culprit, every time the light went red, I would restart the eero network and it would 4/5 work, however if I was to completely remove the power from the eero router (I have 5 around the house, this particular one is just an extender if you like) and this would resolve the issue every time and I felt my wiser app work relay information much quicker.
I therefore did a software update on the whole system and swapped out the eero unit with another one from a part of the house I don’t really much great wifi for and to-date no issues with the box.
I had not update this integration or anything like that so there is no way a wiser HA update resolved this issue.
it is possible the red light may have been on more often prior to getting the wiser integration and it is just luck that I was paying more attention to the unit and noticed the red.
hope that makes sense,again may or maybe be useful but I thought I would share my experience as it could be a coincidence issue with the wifi.