Upgrade advice - upgrade from aarch64 to ARM64 image

[tunnus]

@cw-kid as you’ve already realized, there’s really not much that can be done (programatically). I use this for notification purposes only

[Buxton]

@toggledbits Is it the case that CommFailure is only an attribute of the HaDevice1 type. Per the below, I pre-filtered on "x_vera_svc_micasaverde_com_HaDevice1". I had some interesting results from the expression, though I'm still trying to get my head around expression syntax, so the below may be wrong:

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

Three of my zwave devices did not have a CommFailure attribute and I suspect, they were incorrectly migrated to my UI7 veraplus from a ui5 veralite. A reconfigure command established the CommFailure attribute for all three.

There is one plugin on my vera (it's the only plugin on the vera) that does not have the CommFailure attribute. Does the attribute get added automatically when one installs a plugin? I'm asking in the sense that a re-install might correct the problem but I don't want to mess with anything that isn't obviously broken.

[toggledbits]

The attributes is strictly tied to its existence on the Vera device. Use the guard code I added to my earlier getEntity() to prevent its absence from breaking the test.

[wmarcolin]

@buxton as @toggledbits mentioned, in another conversation (https://smarthome.community/topic/739/logic-loop-throttling/11) we discussed a similar situation, I recommend reading it.

And if I can do a suggestion, do not use CommFailure for this evaluation. I did several simulations in the exercise we mentioned, and this attribute fails more than x_vera_device.failed, this one responds faster (true / false).

Below is the screen of the test I am using, with the Global variable.

[Buxton]

@wmarcolin Yes, thanks. I have the data point "x_vera_device.failed" covered with the following expression:

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 was using CommFailure to detect devices that have not been configured properly, and sure enough, I found three on my network.

[Buxton]

@toggledbits said in How to? Rule for Vera "Can't Detect Device" errors and reset:

The attributes is strictly tied to its existence on the Vera device

Yes, I was asking more in general terms about what happens when a plugin gets initialized. And whether CommFailure is a specific attribute of Vera's HaDevice1 type.

[tunnus]

@toggledbits These devices that for some reason do not have CommFailure variable set, do you think it is safe to just manually add it? Don't want to do anything too "extensive", like exclusion/inclusion process

[toggledbits]

Guarding for it in your expressions is the "right" way (example shown in linked post).

[tunnus]

@toggledbits yep, I'm using that also, but wondering if I could add those missing variables

[toggledbits]

You can, but I wouldn't. But I've spent 40 years as a software engineer, and have learned many times over that you don't bend the input to conform to your algorithm, you get the algorithm right, so I'm (probably very predictably) stubborn about that kind of thing. Proper guarding for null (missing data) ensures that the result works always works (e.g. after including new devices or replacing existing, or broken devices/driver/plugin implementations, etc.), and is thus applicable to all users (so the code they see posted here actually works for them to the greatest degree possible without assembling other information or steps that may not be obvious).

If you're guarding properly, there's no need for the extra work and ongoing maintenance.

[toggledbits]

It was noted in another thread covering a specific case of this topic that it's possible, on some hubs (ahem), for a device to flap its *failed" state quickly, and perhaps is even likely due to temporary network/mesh/device issues, or a simple choice that during restart of the hub devices are marked down until known up. All of this may cause quick, although likely uninteresting, transitions between failed and not-failed.

It may therefore be advisable to use the "sustained for" option on any rule that reacts to a change in identified failed devices, to dampen the response to such potentially spurious state changes.