You could do this with an automation using the attributes on the operation mode sensor.
If the minutes since last update is say 5 mins, then power off the sonoff, delay 10s, power on the sonoff.
You could do this with an automation using the attributes on the operation mode sensor.
If the minutes since last update is say 5 mins, then power off the sonoff, delay 10s, power on the sonoff.
Before investing time and money in this, I would need to be very certain that the WiFi disconnect would be resolved by this power cycling, and wasn’t caused by some environmental factor.
But my first question - how are you establishing that the hub is disconnected?
I would suggest setting up a ping sensor in HA to record how often the Hub is offline at a network level. You might see patterns that suggest a cause, or find that it is always reachable by ping. I have ping sensors for all my critical infrastructure.
I’d also consider whether the hub being offline occasionally is a big problem - if the ZigBee network still stays up all your scheduling and temp control should still work fine - you just might not be able to action changes to config immediately or trigger automations via HA.
It probably isn’t that helpful for me to say my hub seems to be online all the time despite having walls in between hub and access point.
I agree with your assessment and suggestions DunXD. I too have HA pinging routers, APs and Wiser Hub and it was the latter which drew my attention to the amount of time the hub was off line. I’m certainly not going to rush into a hardware ( eg Sonos) reboot solution . I’ve now got a “Wiser Cloud” status indicator adjacent to my HA Wiser Hub Ping monitor so I can more easily check the status from wherever.
I also have the option to bring the nearest AP closer to the hub but again, I won’t rush into that before getting more data. I’m all too familiar with rushing to solve what may have been only a temporary issue only to create further unanticipated problems and unnecessary complexity.
My thinking is that if the ping always shows online then the issue most likely is software/memory related and would be solved by a restart.
If the device is low level off the network regularly (i.e. not responding to ping) then spend more time diagnosing if some environmental interference is the issue before spending any cash, and certainly before splicing a sonoff onto the power cable for your hub. What if the sonoff is less reliable than the hub?
Thank you, downloaded and connected to my IHD.
Is this the addon being used to get the data into HA?
I have also some communication issues between my HA host and my WiserHub.
I read all the conversations on the forum; I imagine another scenario.
For my point of view the WiserHub can manage a certain number of connections as server (often for Schneider: 32) or per client.
I have already seen such issue when the client opens a new connection after an error, without closing the previous. When the maximum number of connections is reached it’s impossible to open a new one…
In this case there is two ways to recover:
In HA I restart the system and I check the communication on Wireshark. In the following example I made it 6 times. For the 5 firsts the communication restart but the 6th I’ve got an issue
The Issue starts at 14:54:21.649 and ends at 13:31:16:.270, so time-out is about 36:54.
The led of the WiserHub is still green and the wiser entities are not refreshed in HA, they had been initialized.
I can share my results
I did not need an add on. I set up some rest sensors as described here which grab the data from the Geo API.
Boiler Demand Sensor?
Is there a sensor available in the integration that reflects the level of demand the heathub requires of the boiler? Maybe sensor.wiser_lts_heating_demand_channel_1 ? I cannot see sufficient history of this sensor in my system to work out what it does.
For various reasons my heathub is not directly connected to my boiler, and I’d like to work out the approximate demand the system expects from the boiler so that I can combine this with the demand from another system (FHEM/FHT) and drive the total demand to the boiler through a custom OpenTherm controller.
I’m fairly sure that the Wiser system is a simple on or off signal to the boiler based on a combination of time of day and detected temperature. So the hub is only really able to say when it has turned on the boiler for either heating or hot water.
That is what my LTS sensor histories show, and not particularly interesting at this time of year when the heating isn’t needed.
My boiler isn’t OpenTherm capable so there may be other data for people who have that - but if your boiler isn’t communicating directly with the hub I doubt you would see different.
What do you mean by level of demand?
The sensor.wiser_lts_heating_demand_channel_1 sensor does show the boiler demand (if you have a hot water and 2 channel hub, you will also have a channel 2 sensor). However, as @dunxd said, this is then translated into an on/off state of the relay for the boiler to fire. Not sure what % it has to hit to turn on the boiler and think this is some calculation of the individual TRV demand %s. If you have connected on opentherm, you would get other opentherm sensors that show the boiler demand more reflective of what is actually happening. You can also look at the wiser heating sensor to see a history of the boiler actually being fired or not.
In an OpenTherm system the hub (or equivalent) should change the boiler flow temperature setpoint in accordance with some calculation of how much heat the system requires - e.g. average iTRV actuator setting. This is what I mean by ‘demand’. In a relay switched system a similar demand effect is achieved by a PCM on/off control of the boiler, with the flow temp set manually or maybe by weather compensation in the boiler. This is why OpenTherm + well behaved modulating boiler should offer greater efficiencies as the boiler can operate for long periods at low power levels in the fully condensing state. Unfortunately my OpenTherm boiler is not so well behaved so I use a bespoke control algorithm to tame it a bit, and why a direct OT connection from the heathub wouldn’t work for me.
I’ll experiment with the system a bit without the boiler connected / running and I should at least see how the demand sensor varies and work out what to do from there. My control algorithm runs in Node-RED so will be relatively straightforward to amend.
Thanks for your assistance.
I would add that the hub does provide data for opentherm but we dont create a sensor for it unless we detect it is connected. If you look at the diagnostics download data, you will see the opentherm data. Im not sure if it does update if not connected but you could download it a few times with some testing and see if it does. We could then include a config option for you to create the opentherm sensors if not connected to use in your nodered script.
OpenTherm": {
"chFlowActiveUpperSetpoint": 800,
"chFlowActiveLowerSetpoint": 350,
"dhwFlowSetpoint": 550,
"dhwEnable": true,
"Enabled": true,
"transmitter": {
"messagesSentCount": 2567087
},
"operatingMode": "NegotiatingOTplus",
"ch1FlowSetpoint": 350,
"ch1FlowEnable": false,
"ch2FlowSetpoint": 350,
"ch2FlowEnable": false,
"roomTemperature": -400,
"roomSetpoint": 110,
"TrackedRoomId": 1
}
Thanks Mark, I’ll have a look at that over the coming week and get back to you.
I’ve had a quick look at it this afternoon. The 'sensor.wiser_heating.percentage_demand_Channel-1’ seems to be what I’m looking for, so no change to the integration required.
The ch1FlowSetpoint in the diagnostics just seems to switch from the lower value (e.g. 350) to the upper value (e.g. 800). It may well be more useful when OT is connected. If I have time I’ll try temporarily connecting the hub to the boiler and see what changes.
There is definitely some form of integration factor in the hub’s control algorithm as the demand value increased over time with a simple half degree temp +ve demand set on a couple of rooms which went unsatisfied.
I’ve set up some better logging to influx and have a play over the next week or so to see if I can determine the characteristics of the demand signal and the maybe the control algorithm used.
Thanks so much for the discussion on the way that the hub communicates with the boiler. I had assumed that it was a simple off/on, and hadn’t noticed that the Heating Demand Channel 1 LTS was a percentage - during the summer months there has been no demand at all recorded, but if I go back a few months I can see a couple of spikes around 40%.
My boiler is a system boiler with separate hot water tank and doesn’t support OpenTherm, so I am assuming for me the hub just uses the demand value to decide whether to turn the boiler on for heating channel (or if it just turns it on any time that any of my thermostats detect a room is below the setpoint.
For combi-boilers with OpenTherm it would be interesting to know if the hub sends the boiler more than off/on commands.
Yes for opentherm it tells the boiler what temp to heat the water to. See above post with the opentherm output from the hub and you will see the ch1FlowSetpoint value for heating channel 1. I have no idea how much cost saving this generates and how often it heats less than the max 80C in real life as mine is also non opentherm.
My understanding is that, in a modern condensing boiler, as far as efficiency goes it’s the return temperature that determines the marginal boiler efficiency. To ensure ‘full condensing’ the flue gas needs to cool down below ~ 55 deg C whilst still in the heat exchanger. Modulating burner controllers (i.e. the controller that’s part of the boiler) should reduce their heat output to maintain the set flow temperature. Given that most radiators (when practically sized) will only develop a temp drop of 20 deg C when room temps are much lower than desirable, its easy to see that an 80 deg setpoint is almost certain to a) push too much heat into the property and b) almost ensure the boiler isn’t operating at max efficiency.
If you don’t have a room or weather compensating controller of some form setting the boiler flow temp, you must ensure that you manually adjust the flow temp to match the season. Even in the coldest months of the year we’re unlikely to want 80 deg C flow in the steady state (all rooms at temp) as most boilers are well oversized for steady state demand. However, we also demand rapid heat up in the morning so end up with a compromise setting.
BTW - as a test I connected the HubR to the boiler using OT today. It works (the boiler responds to the HubR), but the HubR hasn’t activated OpenTherm modulation -its still working in On/Off mode Diagnostics say
“ModulationOnboarding”: true
so the Hub seems to know that it can use modulating control. Maybe it takes a little time to activate, anyway I’ve raised a support request with Schneider and we’ll see what they say.
Sorry if this has already been covered in the past but i tried searching, does the integration support the Wiser PowerTag and/or Energy meter Gateway from Schneider?
Looking at the documentation/github page it dousent but wanted to make sure as its part of the wiser branding.
Thanks in advance
Wiser is the name of a line of product for the smart home. Wiser energy is not supported by the integration.