Reactor-Editor / Reactor-ui-Status Errors

[toggledbits]

The zwave_device.reconfigure and zwave_device.refresh actions are available on multiple hubs (it takes a bit of extra config for Home Assistant and Hubitat because they don't "disclose" that a device is a ZWave device through their APIs, but still doable).

[wmarcolin]

@toggledbits

This work.

But after a few seconds the error message disappears, and the error is not displayed, i.e. the variables are not updated.

Incredible! Even after doing a Poll or Refresh, the variables are not updated.

[toggledbits]

Where are you looking to see if the variables are updated?

[wmarcolin]

@toggledbits here in this query

Or

Taking as an example the same type of device, but I don't know how and when Vera updated it, see how the same queries appear:

The problem is not the query, it is effectively why the hub is not updating the variables after a refresh or poll, and how come then the hub does an operation that does this updating is we can do the same when we want to.

Thanks

[toggledbits]

Doing a refresh or poll on a failed device is no guarantee it will be unfailed. Am I missing something here?

I would also not assume that the absence of the error from Vera's UI7 is any indication of what the device is actually doing. UI7 is horrible at maintaining sync with its own devices. Don't draw any conclusions about anything UI7 tells you unless you've done a hard refresh before you look. This is especially true of the state variable display on the Advanced tab.

[wmarcolin]

@toggledbits well in my little technical knowledge, I imagine that if you send a Poll or Refresh command to a device, it should try to perform the operation, as I see it is happening, until it has a time-out because it did not get a confirmation of the operation.

In this case in my small technical view, I understand that the variables that indicate a failure should be updated as x_vera_device.failed = true.

Well, it is unfortunate not to understand that in a magic trick these variables are updated.

[toggledbits]

So what I'm confused about here... isn't it already showing failed=true?

[tunnus]

@wmarcolin I have Aeotec nano dimmer that from time to time go to a state where it can only be awaken by flipping circuit breaker.

And yes, it shows comm failure on UI7, but no polling can heal it…

[wmarcolin]

@toggledbits no

[toggledbits]

@wmarcolin Well, I'm sorry, I guess I don't understand what you're asking/saying. From what I see, the two examples you gave above are completely consistent...

[wmarcolin]

@toggledbits I put two examples.

The first Plug Old Switch, I removed the power yesterday during the day, and somehow the hub updated the status overnight, and this morning it showed up as a failed device, as you indicate.

The second case, TEST Virtual Binary, I removed the device today from power, and applying Poll or Refresh, it does not update the status, it tells me the device has no error.

I am sure that sometime between now and tomorrow, Vera will update and then indicate failure of this device.

[toggledbits]

I see... I think I'm on the page now. OK. So "TEST Virtual Binary" is a ZWave device? That name...

Sounds to me like that hard failed status is related to the nightly heal. Do you have that turned on? (it normally would be; you have to work at it to get it turned off)

[wmarcolin]

@toggledbits Oops, I don't know what you are talking about, nightly heal? Where do I see this? On or off.

And trying to explain the test better.

Take a perfectly working door sensor and remove its battery. If you apply Poll or Refresh this sensor should change variables and report that it is failing, disconnected.

This test I am performing, and there is no change of variables.

[toggledbits]

Battery-operated devices don't poll immediately. If a battery-operated device was constantly on the ZWave network listening, it would pretty quickly kill its battery. Not as fast as if it was constantly transmitting, but even running with the receiver on is an issue. What most devices do is sleep the CPU and turn off the radio until either an event happens that they care about (like the door they are monitoring being opened or closed), or a timer expires. When an event happens, they do what you expect them to do, like any other device: send a message and wait for an acknowledgement. Then they go back to sleep. When the timer expires, they "wake up" and send a packet of information (or several), often including state and battery level information, maybe temperature, humidity, etc. if they have that, and then go back to sleep. It's a "just wanted to let you know I'm still here" message.

Because these devices are not on line constantly, you can't poll them. The chances of you (or Luup) hitting the device at the moment it is awake for whatever reason are about as good as getting hit by lightning on a sunny day. At some point, the device wakes up and tells Luup what's going on, so this serves the purpose of polling, it's just driven by the device rather than by Luup.

Configuration is actually no different. When Luup starts, the device is marked unconfigured/pending, and it's not until the device first wakes up and communicates with the hub that Luup can then see the device needs to be (re)configured and does that. Then the rest of the dialog happens. So unlike your mains-powered devices, your battery-operated devices may not even be configured for hours after a Luup startup. This is also why many devices have a "wake up" mode you can start, often by pushing a button briefly or several times, that keeps the device awakened and talking for a short period of time. This feature is particularly helpful right after inclusion when you are first configuring the device, and you should always look to see if the device has this feature and know how to access it.

The "wake-up" interval is settable in the UI for many devices. Sometimes, the device default wake-up is huge, like 86400 which is 24 hours. That means the device will only talk to the hub once every 24 hours unless another event forces it to. If you try to change the wake-up interval, you may have to wait for the current wake-up interval to expire so that the device will start talking and the hub can tell it to shorten the interval (another reason the forced wake-up mode is handy -- removes that delay).

I suspect what you are seeing is that Vera may wait for a couple of missed wake-up intervals before it decides the device is unavailable. Setting a shorter wake-up on the device may reduce that time, but keep in mind, more frequent wake-ups mean more battery use, means less battery life.

P.S. It should follow, then, that setting Vera's polling on a battery device is pretty much useless, and empirically we've proven this. You can usually turn polling off for battery-operated devices with no ill effect. There are, of course, some exceptions, so experimentation and observation are always advised. But just remember, polling is initiated by the hub, and wake-up is initiated by the device. They are not the same.

[wmarcolin]

@toggledbits as always a master explanation, a class!

You are absolutely right, the devices sleep, only communicate if they have an action or is time to communicate with the hub to update the status.

So there is no sense Poll or Refresh commands that will not work, perfect!!

In this case my devices are configured to communicate with the hub every 12 hours, I will decrease to 6 and have a more constant report.

Well, exercise of the day closed, thanks again.

The routine that I exposed at the beginning of testing CommFailure, I'll just change it to x_vera_device.failed that is more elegant