How to? Rule for Vera "Can't Detect Device" errors and reset
-
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). -
-
@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.
-
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?)
@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. -
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?
-
@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. -
@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.
@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 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.
-
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.@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.
-
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.@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).
-
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
-
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.
-
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.
-
T toggledbits locked this topic on
-
C cw-kid referenced this topic on
-
C cw-kid referenced this topic on