Gradually turn on lights.

[cw-kid]

I have a problem device right now an Everspring appliance plug that says "Can't Detect Device".

If I run this LUA code on the Vera controller it does clear the red banner from the web GUI but then it comes back again about 20 seconds later, so maybe there is more to it than I thought.

luup.set_failure(0, 50)

Normally to fix this issue with this particular smart plug, I have to removed it from the wall outlet and then plug it back in again and then the problem goes away for a good period of time.

[toggledbits]

This has recently been covered in other threads, but it would be good to roll up everything so far into one place.

Create a global expression to find all of the Vera devices with CommFailure <> "0":

Failed = each id in matchEntities( { capability: 'x_vera_device' } ):
             ( getEntity(id)?.attributes.x_vera_svc_micasaverde_com_HaDevice1.CommFailure ?# 0 ) !=0 ? id : null

Now you can do whatever you want with that array. To a create a comma-separated list of names:

FailedNames = join( each id in Failed: getEntity(id)?.name ?? id, ", " )

You can then have a rule that just checks to see if FailedNames is not an empty string. Of course, you could combine the two expressions into one for a bit of efficiency (assuming the array Failed has no value other than to drive FailedNames), but separating them may be more clear.

Through the other conversations we learned that this is best done in global variables because the large potential number of devices involved can cause excessive evaluations of the rule and rule throttling. That is simply a result of getEntity() being used on a large number of entities, and each use of getEntity() adds the target entity to a watch list, so the rule's watch list can become quite large. The global variables will evaluate faster than a rule, and are not subject to throttling (but be aware, a lot of work is still being done).

Also note that other examples check CommFailure=1 rather than CommFailure<>0. Not recommended. There are defined values of CommFailure other than 0 and 1 that are significant (errors).

Edit: Amended the expression to handle devices that don't have the CommFailure variable at all (ignore/treat as 0/not failed).

[cw-kid]

@toggledbits

Thanks for your help !

I tried creating the Global Expressions but one is yellow:

[tunnus]

@cw-kid should be "!=" not "<>"

[tunnus]

noticed also that using CommFailure != "0" leads to false positives as not all my z-wave devices have CommFailure variable (but should be safe to add?)

[cw-kid]

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

should be "!=" not "<>"

That then lists some plugin devices and scene controller devices.

"Fan" device is also listed however and that is the device I am actually have issues with.

[cw-kid]

This works and does list two actual Z-Wave devices that currently have "Can't Detect Device" issues:

Batteries on my Thermostat device are currently dead, charging them up at the moment.

[cw-kid]

@tunnus

So what are you then doing in your rules actions ? To reset the devices? Or are you just sending yourself notifications about the problem devices?

[toggledbits]

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

noticed also that using CommFailure != "0" leads to false positives as not all my z-wave devices have CommFailure variable

I've amended my version of the expression to ignore devices that don't have CommFailure at all and still honor all possible non-zero values when present.

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