Do a better job at handling Comms Failure (esp in Home Assistant) #147
Comments
|
Issue part 1 - Vera not sending subscription updates - I like the idea of forcing a state refresh. When the device comes out of comm failure, it looks like we always get a subscription update indicating that CommFailure has changed to 0 but not necessarily the state change back to -1 (sometimes we do and sometimes we don't). This transition of CommFailure from 1 to 0 is what I would be inclined to use to trigger a state refresh. Issue part 2 - Forcing Vera to poll the device - I agree with adding the method, and probably calling it on a HA poll is the right time to do it. For reference, the URL I have been using to force Vera to poll the device is: |
|
BTW I should perhaps add that, if you can, it would be best to get your zwave network to be more reliable. Perhaps add a couple of extra mains power zwave switches to fill the network holes on the way to your unreliable devices. I've just done this - and it has helped a lot with the one device I find is unreliable. Doesn't take away from the goal of making |
|
You can see what I did in HA here home-assistant/core#46064 How often were you triggering zwave polls? |
|
Thanks - I'm looking forward to trying it out, but won't be able to for another week or so due to work. I was just triggering zwave polls manually during my testing. I don't think it's something we need to do too frequently with a device in comm failure. Vera retries several times before it flags a comm failure. Maybe start with attempting to poll a device in comm failure every 60s, with a backoff strategy to eventually only retry every 5 minutes? My Zwave network is actually quite reliable - the only comm failures I'm having are induced by myself for testing. Coming from an industrial automation background I'm paranoid about unhandled / unreported failures (e.g. flood sensors that you don't realize aren't working until it's too late - had that happen twice with a cheap D-Link flood sensor). |
|
Do the flood sensors also report temperature? Might give you a way of alerting if they stop reporting. |
|
The one I'm using does. Just using comm failure on the binary sensor indicating water works just fine. The flood sensor actually recovers from a comm failure on its own eventually (probably because it publishes updates without polling). My dimmers, switches and plug modules don't recover without a manual poll. |
|
I had the chance to do some testing today with the latest updates. Setting 'should_poll' to True on a comm failure in order to trigger polling all parameters from Vera doesn't appear to be helping issue #1. When I have a comm failure and should_poll becomes True, I don't see the update method being called for that device. I added logging to the should_poll property to indicate every time it is called, and it looks like it is only being checked at startup or when a entity service is called (e.g. turn_on or turn_off). For now I've just set should_poll to True so that my devices are updated both by polling and subscription, and that has temporarily resolved issue #1. |
|
How are you testing? |
|
I'm running the Vera component as a custom component for testing. I grabbed the current files with your merged PR from the repo (here) and replaced my custom component with them (and then added some more logging). I'm running Home Assistant 2021.2.3. Attached is my log file. Below are the relevant times: I added logging to the VeraDevice update and should_poll methods, so you will see events like this in the log when they are called: |
|
Do you know if you have the latest version of the pyvera library installed? |
|
Just to check I wasn't dreaming, I added some logging to my dev setup. Apart from the logs this is running the current HA dev branch. Here are the changes to VeraDevice :- def update(self):
"""Force a refresh from the device if the device is unavailable."""
+ _LOGGER.info("%s: update called (refresh=%s)", self._name, not self.available)
if not self.available:
self.vera_device.refresh()
@@ -245,6 +246,8 @@ class VeraDevice(Generic[DeviceType], Entity):
@property
def should_poll(self) -> bool:
"""Get polling requirement from vera device."""
+ _LOGGER.info("%s: should_poll called (should_poll=%s)", self._name, self.vera_device.should_poll)
+
return self.vera_device.should_poll
@property
(END)And here are the logs You can see all the calls to You can also see the pyvera poll / event handling - and the updates that are called via that process. Sensors look to refresh more frequently than switches - but I see both doing as expected in my setup So not sure what's happening in your setup. It could be an installation issue (it can be hard in a customised HA to make sure you have exactly what you want running) - or it could be your vera setup / devices are behaving differently. Probably easiest to wait for the next HA release - and then happy to take a look if yours is not behaving as expected. |
|
I'm definitely seeing different behaviour with the calling of Is there any chance that you had one or more Vera devices already in a comm failure state when you are starting HA? I've added a stack trace to the
If I start HA with any Vera device already in a comm failure state, I see results similar to yours. The entity platform regularly calls I hope that makes sense. It's been interesting digging into |
|
I found a closed architecture issue that relates. It confirms that should_poll should not change during the lifetime of an entity. |
|
I have a long term failed device - so that’s quite possible. Thanks for the link... |
|
@tgrusendorf Thanks for doing the research. I'll refactor slightly to try and make this work. BTW I've been experimenting with moving a few of my devices across to So far the results are really good - much easier to configure devices - and much easier entity setup. Some of my devices that never worked properly in Vera are also working better. I will test performance next. |
|
I still need to test this works as I expect. But if you are able to try it in your setup - please do! |
|
I will give it a try. I also tried a slightly different approach this week that has been working well. I modified |
|
Thanks for the tip on |
|
I've been waiting for the HA zwave technologies to settle for a while, and finally looks like they have, so thought I'd try it. Using an unsupported infrastructure always worries me - and it's getting hard to get new devices to work in Vera. Having a controller that understands the devices is really great (all the device params are already there in the controller). So yes - I suspect Currently you can use either I tried a few ways of moving things before I decided just running both vera and zwave-js and re pairing devices as I go was the best and safest. There are a couple of my devices that |
|
I checked out the dev branch of HA today, and I'm confused by the commit that ended up being merged into the dev branch. It still contains: But the comments indicated the property should be removed as it defaults to |
|
Thanks for the heads up. Looks like I messed up the rebase. Will fix! |
To continue the discussion started here: #146 (comment)
It would be good to make Vera devices handle comm failure updates in HA.
@tgrusendorf comments on some of the issues here:
#146 (comment)
If this is an issue with vera not sending subscription updates - then we could force state refreshes when devices are asked for their state and they are in comms failure.
I'm pretty sure @vangorra modified the HA integration so that the HA devices poll as well as responding to subscription updates (HA objects poll by default unless you tell them not to - and he just removed my code that turned this off).
The catch is when HA polls the pyvera device - it returns cached values (unless you pass
refresh=trueto get the status from the real device). But this shouldn't be hard,I think HA has the infrastructure to do this pretty easily.
Again I think the easiest thing would be to add a
force_vera_to_poll_devicemethod toVeraDevicethat could be called on a HA pollI think @vangorra is busy with other things - but he might have a few moments to comment.
The text was updated successfully, but these errors were encountered: