How to monitor sensors that stop working?
-
Besides the Variable x_vera_svc_micasaverde_com_HaDevice1.CommFailure I am also checking now the x_vera_device.failed, but the problem is the same, it's not updating, I keep searching how to send some command that forces this update.
I looked at the other post that @Buxton suggested and it has the information about the @rafale77 but I also didn't find anything about how to do something to force the re-evaluation of the variables.
@wmarcolin said in How to monitor sensors that stop working?:
I also didn't find anything about how to do something to force the re-evaluation of the variables
I'm not sure if you're talking about the state variables on the Vera here, or the attributes on the entity in MSR, or the expression variables in MSR, but a few important things:
-
Vera's state variables are driven by Luup and the ZWave engine. You have to rely on Luup to set them properly. You can change their value yourself, but that's meaningless, of course: setting CommFailure=1 doesn't mean device communications will fail thereafter, and setting CommFailure=0 when device communication failures are occurring will not cure them. They are state variables, not action variables. If you want a state variable to change related to device behavior, you have to think action:
Refresh,Poll,Reconfigure, etc. If those actions result in a change of state, that will update the variables. -
Entities are updated when Vera posts a change for the device. MSR uses Luup's method of sending changes for devices, and that's a pretty old and reliable mechanism, not without problems, but they are well known and would not apply here. The way to update an MSR entity related to a Vera controller is by causing its states to change.
-
MSR variables, be they global or rule-based, should update immediately upon a change of the entity, but since 21267, I've been chasing one particular problem that pops up in expressions that use
each,first, anddo...done. I think I finally found that yesterday. There is an unannounced build 21280 currently posted that contains that fix (I published it for just one person that I'm helping via Mantis). The expression shown in @Buxton 's post is exactly the type of expression affected. I would upgrade to 21280 and retry this experiment.
Also, the
x_vera_device.failedattribute on Vera device entities is driven entirely fromurn:micasaverde-com:serviceId:HaDevice1/CommFailureand there is no other magic there. I just converts the data type (0 if false, anything else is true).Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
-
@wmarcolin said in How to monitor sensors that stop working?:
I also didn't find anything about how to do something to force the re-evaluation of the variables
I'm not sure if you're talking about the state variables on the Vera here, or the attributes on the entity in MSR, or the expression variables in MSR, but a few important things:
-
Vera's state variables are driven by Luup and the ZWave engine. You have to rely on Luup to set them properly. You can change their value yourself, but that's meaningless, of course: setting CommFailure=1 doesn't mean device communications will fail thereafter, and setting CommFailure=0 when device communication failures are occurring will not cure them. They are state variables, not action variables. If you want a state variable to change related to device behavior, you have to think action:
Refresh,Poll,Reconfigure, etc. If those actions result in a change of state, that will update the variables. -
Entities are updated when Vera posts a change for the device. MSR uses Luup's method of sending changes for devices, and that's a pretty old and reliable mechanism, not without problems, but they are well known and would not apply here. The way to update an MSR entity related to a Vera controller is by causing its states to change.
-
MSR variables, be they global or rule-based, should update immediately upon a change of the entity, but since 21267, I've been chasing one particular problem that pops up in expressions that use
each,first, anddo...done. I think I finally found that yesterday. There is an unannounced build 21280 currently posted that contains that fix (I published it for just one person that I'm helping via Mantis). The expression shown in @Buxton 's post is exactly the type of expression affected. I would upgrade to 21280 and retry this experiment.
Also, the
x_vera_device.failedattribute on Vera device entities is driven entirely fromurn:micasaverde-com:serviceId:HaDevice1/CommFailureand there is no other magic there. I just converts the data type (0 if false, anything else is true).@toggledbits thank you for your comments, and let's be clear, the MSR is perfect, it reflects exactly the information from Vera's many variables. So it is possible to query x_vera_device.failed or urn:micasaverde-com:serviceId:HaDevice1/CommFailure without any problem, it can be a Global variable that updates immediately, or a routine that I execute every period and it also updates, the problem is definitely not with the MSR.
The question is how to force Vera to fetch the updated status of the device, and then update the variables in the hub (which MSR will then automatically see).
In an old and excellent suggestion from @rafale77 , the wakeup times and the poll (https://community.ezlo.com/t/zwave-network-on-vera-explained/210661/3) have been increased, which has improved the performance of the hub and battery savings, but causes a huge update delay.
So your comment about running a Refresh or Poll is exactly what I am looking for, I understand it should be commanded to not wait for the hub loop, and as you comment, the action should result in the update of the state and variables.
Now what is this command? Where do I find instructions on how to execute this command? Can I have a loop in the MSR to execute based on a device list (example above) of messages?
Thanks
-
-
The
zwave_device.reconfigureandzwave_device.refreshactions 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).Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
The
zwave_device.reconfigureandzwave_device.refreshactions 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).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.
-
Where are you looking to see if the variables are updated?
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
Where are you looking to see if the variables are updated?
@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
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
@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 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.
@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…
-
So what I'm confused about here... isn't it already showing failed=true?
-
@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...
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
@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...
@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.
-
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)
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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)
@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.
-
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.
Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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.
@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
-
T toggledbits locked this topic on
