Automations waiting for known connection is a very good idea.
If you just want to monitor success and get a history graph of update, just use an entity card with the last_update attribute.
Automations waiting for known connection is a very good idea.
If you just want to monitor success and get a history graph of update, just use an entity card with the last_update attribute.
Thanks. However, unless I’m doing something wrong that only produces a history graph of the heating operation mode:
type: entity
entity: sensor.wiser_hub_heating_operation_mode
attribute: last_updated
name: Wiser Hub Last Update
state_color: false
icon: mdi:router-wireless
I had a similar thought on Saturday and created a template sensor to record the signal strength as seen by the hub (an attribute of the Hub Signal entity).
Here you can see the last 24 hours, with my hub becoming unresponsive between 00:21:51 and 02:21:46. However, I just realised that the signal strength figure isn’t going to be reported by the hub when it is down
Looking back, I notice that the outages are often within a minute of 2 hours duration but occur at different times of day.
17 Sept 01:59:45 - 03:59:40
17 Sept 09:25:44 - 11:25:40
18 Sept 13:31:59 - 15:31:54
21 Sept 03:44:10 - 05:44:06
26 Sept 00:21:51 - 02:21:46
That is too much of a pattern…
I realise that I am not actively monitoring any other WiFi clients, so wouldn’t necessarily notice if it was my WiFi going down for short periods. I’ve now set up a ping binary sensor monitoring something relatively near the Hub, so should be able to tell if it is a global issue or limited to the hub.
I wouldn’t want to go as far as power cycling my hub automatically if it becomes unresponsive. Especially not before being certain it isn’t something else to do with my infrastructure - e.g. DHCP lease renewal, some issue causing WiFi access points to stop working.
I think there are too many of us experiencing this issue for it to be anything other than a problem with the hub. My current router setup has been in place for a number of years and I don’t have anything else dropping off the network randomly, other than a couple of (identical) Ecovacs Deebot robot vacuums, but that also seems to be a common issue, at least with the model I have. I did try to do something similar with them, but there’s no way to power cycle them as you physically have to move the slide-switch under the lid on the vacuum. Unfortunately, putting them on a smart plug isn’t a possbility due to the built-in battery (I already tried) preventing the power cycle, so it’s just something I have to live with (first world problems). Incidently, the hub disconnecting and the Deebots disconnecting has not coincided (yet) and the Deebots usually go weeks without an issue.
@dunxd that’s interesting about the two hour duration and that you seem to be seeing it every few days, or even twice a day on one occasion! I’ll keep an eye on my times when (I say when as I’m nearly certain it’s not if) it occurs again, if I can be patient enough to wait to see if it recovers itself.
I am going to keep monitoring/investigating and probably won’t automate the power cycle yet (I still have to wait on the Sonoff being delivered and then need to wire it in anyway), but regardless of whether it turns out to be something else, or Wiser fix the issue and it’s no longer needed, I’m still going to wire the Sonoff in. If anything, this has highlighted to me the importance of having a way to reboot the hub if something does go wrong. I’m looking at it as an insurance policy for the heating/hot water. I already have the same for Home Assistant itself. My RPi4 is connected to a Meross smartplug that can be operated independently of Home Assistant, so I can power cycle it if there’s a problem. I’ve never had to use it, but it’s there if I need to.
@dunxd do you mind sharing how you created the template sensor for signal strength? I am not getting a state over time graph, just a bar with the state changes.
My template sensors is as follows:
template:
- sensor:
# Wiser Heating and Hot Water sensors
# Wiser Hub Signal Strength sensor
- name: Wiser Hub Signal Stength
device_class: signal_strength
state_class: measurement
unit_of_measurement: dB
state: "{{ state_attr('sensor.wiser_hub_signal', 'wifi_strength') | int }}"
Update
I figured this out. I was missing:
state_class: measurement
unit_of_measurement: dB
Setting the device_class as signal_strength does not appear to add the unit of measurement. I have updated the yaml above to include this in case anyone else is trying to figure out how to do this.
FWIW, for anyone else that wants to use this, here’s the yaml snippet using the wait_for_trigger
and an if condition
for checking the hub is online (using my template binary sensor above), that you can place at the beginning of your actions
in an automation or sequence
in a script:
actions:
# If hub is offline wait for it to come online, otherwise start/continue
- if:
- condition: state
entity_id: binary_sensor.wiser_hub_status
state: 'on'
then:
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.wiser_hub_status
to: 'off'
# Start/continue
# e.g. Set Living Room to Auto
- service: climate.set_hvac_mode
target:
entity_id: climate.living_room_climate
data:
hvac_mode: auto
Update
Determined to get to the bottom of this, or at least rule out environmental factors, I’ve now put an old phone right next to the hub and setup a ping sensor for it. I just need to wait for the next disconnection and see if the phone is still responding to the ping.
I’ve also just thought of another improvement to ensure commands are delivered to the hub. It might be overkill, but in addition to using wait_for_trigger
I could create a loop to check the state of any entities have been updated and, if they haven’t, wait a few seconds (probably 30, as that’s the default polling interval of the integration) and keep trying until they have. I’m going to hold off on this for now and keep it in mind if wait_for_trigger
isn’t enough on it’s own.
I’ll post an update when I have anything more to share.
In the interests of transparency, I work for Schneider but NOT for the Drayton part of the business. However, I asked around internally about this, as it seems from the thread to be increasingly happening and I was curious if they had seen a rise in reports and/or something firmware related.
Seems not, but they did say if you log a ticket with support and provide your MAC address for the hub, they can poke about in the backend and see if there is anything obvious they can see from their end. I mentioned someone was doing a “group” report ticket, but knowing Schneider, the more individual ones they get, the more it will highlight a potential issue for them to investigate.
Hi Dunxd,
Again full transparency, I work for Schneider and I lead the team responsible for the Wiser offer. Happy to see a thriving community around our platform.
Usually, what you describe as the hub becoming ‘unresponsive’ can be for a number of reasons. It could be, as you say, a wifi router DHCP problem, it could be a transient drop in signal strength caused by interference from other devices in the home, connected and none connected like microwaves, it could be a normal reboot of the hub due to a software update (they happen in the background) or of course, something else. If you contact customer support they will get all your details and crucially the MAC address of your hub. From that the support team can look to see if there is anything obvious in the support package to indicate a problem.
Jamie, great to have you as part of our community. There are many people on here, myself included, who love your teams product - even more so at this time of year!
As one of the developers of this integration, it would be great to have a closer relationship with you or your team to aide in the development of this integration or to help drive features in your roadmap.
In terms of the wifi disconnect issue many (but not all) are experiencing, there seems to be common patterns that people see, in particular the duration of this disconnect that is not related to firmware updates. I myself have this issue and had some conversations with one of your support team over the weekend to try and raise this to someone like yourself. It would be good to try and isolate this as a group rather than individual support calls. Clearly, we feel this issue more than your customers who only use the app as we are calling the api ‘constantly’ and have logs of when the hub is unresponsive/off the wifi. Is there anyway we can do this and how can I help gather the required information?
All, just to update you on a new v3.1.6 version was released this afternoon with some fixes, improvements and new attributes. However, i have also spent some time tidying and improving our documentation, including a new section on services giving more detail about both our custom services and use of built in ones supported by this integration. Hope you find useful. List of changes below.
Welcome @jamiebennett and @davefi! Great to have people from Schneider/Wiser here! I’m a happy user of your product, and trying to push the value I get out of it. Something this integration and HA make very possible.
I will log a ticket with my hub’s details.
Thank you for these updates - much appreciated!
Hello all - I have the Merten Wiser Home Touch which allegedly is the same hardware as the Drayton. This is a zigbee hub which talks to my Schneider Shutters. Will this integration work? If so, how do I get the “secret”. There is no web login and I can’t really log onto the “cloud” but the hub does.
I can obviously just have the Schneider shutters talk directly to the HA but it seems a waste not to be able to use the hub.
Appreciate any feedback/suggestions.
Firstly thank you for such a great integration. I have been using it since it’s inception.
I’ve had a Wiser system for a number of years, initially on a thirty year old Vaillant combi but that was replaced last year with an Intergas Xtreme which now uses Opentherm.
All is working really well but I just wanted some clarification on a couple of things.
If I look at the attributes for my Wiser Heating senor I see a couple of thing I’m not sure about.
Some of them are obvious, such as percentage demand, ch flow temp (although this is always below the indicated temperature on the boiler?), ch pressure bar etc.
The ch return temperature never displays a value. Is this correct?
Also can someone explain Relative modulation level? I’ve seen it anywhere between 1000 and 0.
By looking at the figures is there anyway this integration can tell me whether my boiler is condensing or not?
Appreciate any answers.
Unfortunately I don’t have an opentherm boiler and this protocol is a bit of a closed shop, but I can say this.
We added opentherm via a github issue for one of our community. They provided the json output from their boiler and we just added some as attributes to this sensor.
If the CH return temp is showing -, then it is likely that your boiler does not provide this info in the data to the Wiser hub. If you want to see what is being provided from the hub by opentherm, you can download the diagnostics and (at the bottom of the file) is the opentherm data from the hub. I suspect that ChReturnTemperature property is not there.
Below is example of data visible in diagnostics download if opentherm is connected (this is the data we used to add to integration - not mine)
{
"chFlowActiveUpperSetpoint":800,
"chFlowActiveLowerSetpoint":350,
"dhwFlowSetpoint":550,
"dhwEnable":true,
"featureActions":{
"ModulationOnboarding":true
},
"Enabled":true,
"transmitter":{
"messagesSentCount":51728
},
"receiver":{
"decodingErrorsCount":615
},
"operatingMode":"OTplus",
"preDefinedRemoteBoilerParameters":{
"dhwSetpointTransferEnable":true,
"maxChSetpointTransferEnable":false,
"dhwSetpointReadWrite":true,
"maxChSetpointReadWrite":false,
"dhwSetpointUpperBound":650,
"dhwSetpointLowerBound":350,
"dhwSetpoint":2560,
"maxChSetpointUpperBound":750,
"maxChSetpointLowerBound":200
},
"ch1FlowSetpoint":350,
"ch1FlowEnable":false,
"ch2FlowSetpoint":350,
"ch2FlowEnable":false,
"operationalData":{
"RelativeModulationLevel":0,
"ChPressureBar":13,
"Ch1FlowTemperature":330,
"ChReturnTemperature":320,
"Dhw1Temperature":275,
"SlaveStatus":0
},
"roomTemperature":191,
"roomSetpoint":190,
"TrackedRoomId":7
}
I cannot tell you what Modulation Level means but maybe someone with more expertise on opentherm can. If you get anymore info and we can add or amend some of these parameters to help you, please let us know via our github issues.
Frank, in general, if you can’t get the secret by the method in the instructions, then I don’t think it is compatible.
Thank you @msp1974 for such a quick reply.
You are correct regarding the ch return temperature. I don’t have “ChReturnTemperature” entry in my diagnostic download, so the boiler isn’t providing it.
Real shame because I think if I could see that it would give me some indication that the boiler was in condensing mode. Not that I have any reason to doubt that it is.
In case it helps, although you would have to buy one if you don’t own one already, you can check boiler flow and return temperatures (as well as radiator flow and return temperatures) independently of the integration using either a digital k-type pipe clamp thermometer, an analogue pipe clamp thermometer, or an infrared thermometer. Obviously these are examples only and there are plenty of choices, especially of the infrared type ones. However, I do own that specific infrared thermometer and it works well considering the price.
Thats a nice idea… how much were the bits? and any recommendations? Id be tempted to use esp8266s/32s with esphome, but that entails powering them… (which should be ok given the boiler will have 240v nearby)