Is bedroom running the dining room schedule?
Is the day for the Hot Water schedule exposed anywhere similar to next_day_change
in climate.wiser_your_room
?
Currently building a card for hot water controls with the status of when itās next turning on/off.
Problem is if the schedule is set for every other day (e.g) I cannot take that into account into my ācountdownā as only next_schedule_change
is exposed.
Yeah, thats it, Alas I tend to use the Mobile UI more than the HAā¦ Ive also noticed there are defunct rooms there tooā¦ we need to fix that
It appears not. However, log an issue on our github and we can add. Iāll double check that the attributes are consistent across hot water and heating.
Itās likely that there will be an update release in the next week or so and will add for that.
I had the hub go offline again last night. Interestingly the Signal strength was bouncing around all over the place, between Good and Medium before dropping to Poor just before it disconnected (it normally shows as VeryGood). Since I reconnected it, itās back to normal (for now) and showing as VeryGood almost constantly, with the odd dip down to Good, but never below that.
In order to try and gather more data, Iāve created a template sensor (in addition to the Ping sensor) to see how often the hub fails to respond (i.e. detect any failure to communicate). I thought the template sensor might be useful for anyone else wanting to monitor this as well.
template:
- binary_sensor:
# Wiser Heating and Hot Water binary sensors
# Wiser Hub Status binary sensor
- name: Wiser Hub Status
device_class: problem
icon: >-
{%- if is_state('binary_sensor.wiser_hub_status', 'on') -%}
mdi:router-wireless-off
{%- else -%}
mdi:router-wireless
{%- endif -%}
state: >-
{%- if is_state_attr('sensor.wiser_hub_heating_operation_mode', 'last_update_status', 'Success') -%}
off
{%- else -%}
on
{%- endif -%}
Although we shouldnāt have to (Wiser really need to sort the route cause), I think there is a way to work around these disconnections. I really like this integration and donāt really want to send the system back.
You can use this same template sensor (alternatively you could use a Ping sensor) in automations to check that the hub is responding and to wait for it to become responsive (you can check the state of this sensor and if itās on
, use wait_for_trigger
to wait for it to turn off
) before sending commands to it, to make sure that those commands are delivered.
Iām going to combine this with a Sonoff BASICZBR3 (I did not know Sonoff did Zigbee versions of their relays) and wire it to the power supply for the hub and then, when it stops responding/disconnects, power cycle the hub. The automations will then continue, and should send the commands successfully, as if nothing had happened, other than with a small delay while the hub is power cycled to bring it back online.
For me, itās essential that the automations in Home Assistant are delivered to the hub, as Iām already using it to activate/deactivate Away Mode, switch the heating off/on in a room if a window/door is opened/closed (using Aqara contact sensors) and plan on using presence detection to see if our daughter is staying to switch the heating on/off in her room. If the automations donāt work due to the hub disconnecting, Iām going to be left with things in the incorrect states and potenially a cold house and no hot water, which is definitely not good for the WAF, especially as I sold her on this to save us as much money on heating as possible.
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.
- BREAKING CHANGE: The boost hot water service parameters have changed and no longer require an entity id. See Boost Hot Water Service
- BREAKING CHANGE: Removed remove_orphaned_devices services as now replaced with UI delete option
- Bumped api to v0.0.40
- Added next schedule day attributes to hot water sensor. Issue #302
- Added next schedule datetime attribute to climate, hot water, light and shutter sensors
- Added ability to delete devices via UI (including associated entities)
- Updated deprecated constants. Issue #289
- Removed need to have HACs installed. Issue #292
- LTS target temp sensor now shows None value if room set to off. Issue #301
- Prevented creation of LTS sensors if room has no devices
- Moved services into own file to tidy up code for readability ahead of future rework of this code
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.