How to? Rule for Vera "Can't Detect Device" errors and reset
-
Hi
I have some devices on my Vera Plus controller that sometimes change to say "Can't detect device".
I can clear those red banners that show up in the Vera UI7 web GUI, for a device by running some LUA code like this:
luup.set_failure(0, 331)
Maybe I can use the new MSR matchEntities to find and detect any devices on Vera that have developed the "Can't detect device" error and then reset them. ?
I can currently manually specify a particular problem device in a ruleset trigger like this:
But if I could have a rule that automatically detects any device that develops this problem that would be better.
Thanks
-
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.
-
toggledbitswrote on Oct 15, 2021, 12:34 PM last edited by toggledbits Oct 15, 2021, 12:07 PM
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 arrayFailed
has no value other than to driveFailedNames
), 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 ofgetEntity()
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 thanCommFailure<>0
. Not recommended. There are defined values ofCommFailure
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-kidreplied to toggledbits on Oct 15, 2021, 1:35 PM last edited by cw-kid Oct 15, 2021, 9:38 AM
-
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-kidreplied to tunnus on Oct 15, 2021, 2:21 PM last edited by cw-kid Oct 15, 2021, 10:22 AM
@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.
-
-
@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. -
@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.
-
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. -
@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.
-
@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.
-
@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.
-
tunnusreplied to toggledbits on Oct 20, 2021, 8:53 AM last edited by tunnus Oct 20, 2021, 5:12 AM
@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
-
Guarding for it in your expressions is the "right" way (example shown in linked post).
-
@toggledbits yep, I'm using that also, but wondering if I could add those missing variables
-
toggledbitswrote on Oct 20, 2021, 12:32 PM last edited by toggledbits Oct 20, 2021, 10:57 AM
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.
9/21