[MSR] Feature request: For Each action on arrays/groups

[wmarcolin]

@andr I will try to collaborate with two suggestions for you to validate your device.

The first one with the screen below is to validate your sensors with battery information:
sensor = prepares the list of which devices have the battery power variable
low_battery = checks who has less than 50% charge
names: make a list with names to send alerts

The second option is very similar, but I am using the CommFailure variable which depends on an invocation of the device for it to appear as failed, i.e., the same one as in the Vera device list.

But I open a question here for our master @toggledbits.

If the Vera hub has the Poll parameter on all devices, I understand that a call is made from time to time. In this case, using the two examples above, couldn't there be something that the validation would then be if a Polling fails to trigger the error? What would this variable or test time be? How would we express a current time equation - 6 hours to test?

Thanks

[toggledbits]

Vera keeps track of its own polling failures, which you can see most usefully for this kind of application in the entity attribute x_vera_svc_micasaverde_com_ZWaveNetwork1.ConsecutivePollFails.

[wmarcolin]

@toggledbits this variable I can't understand how it works to return to zero, because I have a case here that is different from zero but the device is working normally. It may be a historical accumulation.

[Andr]

@wmarcolin
Ok, Expressions isn't anything I have used before. But I noticed the thread about low battery notifications and added this to my list of needed knowledge in the future.
Either way, I copied your Expressions and devices got listed as expected.
But how do I get that list in a notification??

I think that many kind of sensors can need at least two rules/values for checking for failure.
For example I have a Fibaro Smokesensor that just stop reporting. But either Hass or Vera notice that the device doesn't communicate.
This device has a temp.sensor, which of course will (should) change value a lot more than battery level.
I think battery level is the least wanted value to monitor for the sake of device failure. Since some devices can have a battery life of several years the value moves to slow.

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