Set reaction triggering wrong z-wave device

[Buxton]

@toggledbits One of the last things keeping me from localizing my vera is that the cloud will notify me when a zwave device goes offline. It's important for me to know as some of my devices are connected to security functions.

Do you know if the offline notice is tied to "x_vera_svc_micasaverde_com_ZWaveNetwork1.ConsecutivePollFails" and if so, the count/number of fails that vera uses to send a device offline notice? My distant zwave devices tend to rack up a lot of fails, but I never get an offline notice sent to me.

I'd much rather prefer to handle that error condition locally, and if it can be done, I can then run your Vera Decouple script.

[toggledbits]

I do not know how their notification works or what their thresholds are.

[Buxton]

@wmarcolin I'll get a device offline notice approximately 24 hours after a device is disconnected. Perhaps vera is using a combination of the two metrics to trigger an offline email ie once 24 hours passes without a poll response, the CommFailure for the device goes true and an Email is sent.

[Buxton]

@wmarcolin Here's a do loop that uses the device.failed attribute:

join( 
  each id in matchEntities( { controller: 'vera', capability: 'x_vera_device' } ): do
    e=getEntity( id ), 
    e.attributes.x_vera_device.failed ? e.name :  null
  done, ", " )

I have one device offline that shows up in the array and the device is offline as I physically removed it a couple of days ago. As well, I'm seeing one plugin that has this attribute set to true, although it is working. Perhaps something in the plugin code needs to reset the device from true to false if the plugin regains communication....

Edit: the plugin that was showing failure used "luup.set_failure false" instead of 0 or 1. This is probably an openLuup bug as using false in this case is a holdover from UI5. I changed false to 0, and the plugin no longer shows as failed. http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_set_failure

[Buxton]

@rafale77 does a deep dive into failed vera zwave devices in this thread: https://smarthome.community/topic/392/vera-device-extended-attributes

[wmarcolin]

@andr I'm using Telegram, but I think this work for all

<b>BATTERY LOWER THAN 30%</b>
Check the devices listed that have the battery below the desired charge: ${{BatteryMSG}}.

<b>DEVICE WITH ERROR</b>
Check the listed devices that have a communication failure: ${{FaultMSG}}.

I am trying to better understand how the CommFailure variable is updated. Devices plugged into power as soon as it is cut off, update on the fly, now on battery power it doesn't. I am looking to see how to force this update, this would solve a validation of all devices that do not respond to the hub.

[wmarcolin]

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.

[toggledbits]

@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:

1. 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.

2. 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.

3. 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, and do...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.failed attribute on Vera device entities is driven entirely from urn:micasaverde-com:serviceId:HaDevice1/CommFailure and there is no other magic there. I just converts the data type (0 if false, anything else is true).

[wmarcolin]

@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

[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.