Different issue im starting to investigate. Has anyone seen an issue when editing a room on the native client?
ie Select Bedroom in the list of rooms, edit schedule and for some strange reason my install then says “Dining Room”… Very weird…
Is bedroom running the dining room schedule?
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
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.
5 Likes
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?
5 Likes
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
5 Likes
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.
2 Likes
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.