Even though Wiser have improved the WiFi stability, it still has issues dropping off wifi, especially on mesh networks.
This message is related to the connection being closed while doing an update from the hub.
I have moved mine off my mesh to a wifi extender (which itself is connected to my mesh wifi) and this has massively reduced the drop outs but not eliminated. I assume many get these messages. These drop outs now seem to be only a max of 5 mins and therefore do not impact you unless you have automations that may fail.
I have on the list to maybe put more retry logic in the code knowing that it will likely succeed within a few mins if initially fails.
Yes Iâm getting these errors, and also yes Iâm getting far fewer since moving it off my mesh (deco m5) back on to the main router, even though the signal quality it gets from that is abysmal.
Unfortunately you may be waiting a very long time for a feature to be added to Wiser. Even bug fixes seem to take forever to be implemented, in fact the wiser app has a couple of bugs that should be easy to fix but many months later are still present in the latest app version, v6.2.1.
I do not have a mesh, and itâs pretty close to the router, so connection shouldnât be too bad. Agree itâs not too bad and doesnât seem to cause issues.
I just like a log error free. Isnât there a way to ignore/hide this specific errors since there really is no way to fix them?
Mentioned way back up the thread, but thought it might be worth a reminder. For anyone that is still experiencing short WiFi dropouts who wants to prevent automations failing, create a template binary sensor for hub status:
- template:
- binary_sensor:
# 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 -%}
Then use it in your Wiser automations to check the hub is connected and wait for it to reconnect if it is not:
- 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'
This should prevent automations failing unless youâre really unlucky and the hub has disconnected and the sensor hasnât updated to reflect it yet. Under default polling settings, this is only a 30 second window max.
@RobinA - just released a v3.3.4 version with the fix for respecting heating channels for passive mode. Would you be able to test and confirm all working. Thx
Hi, Iâm starting with Wiser ecosystem (Schneider). Iâve successfully connected a smartplug and added it to my HA thanks to your amazing work. My aim is to track the power consumption on that plug and I found for that 2 power metering entities: âWiser powerâ (current power) and âWiser total powerâ.
Unfortunately, the entity âWiser total powerâ does not seem to work properly, the value does not correspond to anything real. According to the current power, the total power consumption should be now about several kWh but the total power entity is stuck at 0.02 kWh.
Any idea of whatâs going on? Iâve no clue if itâs a hardware problem (total power not supported by this plug but I assume in that case the entity should not return any value) or something wrong with the integration.
Thanks for your help
@msp1974. To follow up on my question from February, it turned out that behaviour with hass.services.call to invoke the Wiser integration from my code was still erratic. I switched back to bouncing an event via a separate automation - not beautiful but i works.
I am using an integration dependency to ensure that Wiser starts before my integration, so I can identify the climate sensors for the rooms, but recently all my derived sensors become unavailable on most restarts. Repeated restarts will eventually get everything working. I am using âwiserâ as the dependency name - is this correct? (The documentation on integration manifests does not specify which integration descriptor to use.) The sensors all appear in the Wiser integration and as far as I can see they are only created by init .
Well all is now installed and working. I have used the Electrical Heat Switch to control my (water based) underfloor heating. Have just hooked it up in place of the remote timer/stat and it works a dream. Controlled by its own stat. Found the device for ÂŁ35 as an Amazon Warehouse deal so well pleased with that. I now have three zones plus hot water.
As an aside, the Electrical Heat Switch is rated at 16 amps, is that enough to drive your immersion heater?
I dont know if the dependancies for custom components follow the same âdomainâ pattern. If you want to share a link to your latest code, i can have a look and try and get this more stable.
@NickyP - I havenât checked recently, but the Wiser system tied the electric heat switch very closely to (underfloor) heating applications - it had to be associated with a UFH room and thermostat as in your current use case. You may struggle to get it to control an immersion heater.
@msp1974. Thanks. The latest version of the code is in the repository at GitHub - TimClement/heating_automation. It should still be public. The Wiser integration rooms are picked up in init.py when initialising the coordinator at l83. The function called is in helpers.py.
Sent you back some updated code for your update coordinator (as an issue on your github) that ensures these sensors are created at load and an explanaition of why its not working.
Iâll have a look at your service call issue sometime soon.
@msp1974: wow, thanks so much for all the work you have put in on this. I have found the code on github, including a solution for the service call issue. I had forgotten that the direct call was hanging HA, and your approach is much more elegant than bouncing via an HA automation (which I guess has essentially the same effect of starting a separate job for the call).
Iâll follow up the issue in github (some more useful learning).
This seems to be working fine now. Demand on channel 2 no longer triggers rooms in passive mode on channel 1 to demand heat.
Thanks very much for addressing this.
(Off topic but) Does anyone know if you can disable the low battery LED alert on the TRVs? Not only is it a waste of the battery power thatâs left, theyâre pretty bright so annoying in bedrooms (especially as wiser seems to have adjusted âcriticalâ level to 2.4v so the LED light show starts much quicker on my rechargeable batteries)
So, the zigbee network card was the first card we did and frankly, that was a bit obvious. It has been on the plan to rework this card and make better looking and more functional. An issue raised on our github prompted to push this up the list.
So, here is v2 of the card which will be released in an integration update in the coming days. For any of you who are very keen, it is available in the dev branch of our repo.
Look and feel is much improved with defined colours for each device type
You can now modify and save the layout of the nodes to better fit the card for your specific setup
You can now have a manual refresh as well as auto (default). This will stop it redrawing when the integration updates and you are zooming/panning/moving nodes around
Minor Changes
You can now modify the card title
See a brief overview video. As always, love to hear feedback and further improvement ideas.
. In all seriousness, no you canât.
(and/or complain to wiser to change critical LED warning back to below 2.4)
