Recovering from devices that didn't respond

[ts1234]

This is mainly about issues with my Schlage zwave locks since they jeopardize security...but could be anything...and is often LED color changes sent my Homeseer light switches (which in general are awesome).

Two things happen fairly often with my locks...by no means everyday or probably even weekly... They either fail when sent a command and there is an error in the log or they are in an "unknown" state after a change. The same kind of thing happens regularly with switch LED's and I get a message such as...

Oct-07 10:18:33 AM

Z-Wave Warning

A Z-Wave action in the event Homeseer Switch Led Functions For Motion Detection OUTSIDE Set LED 1 to Blue If NO Motion Outside returned an incomplete (failed) result.

Oct-07 10:18:33 AM

Z-Wave Error

Event Action Set Configuration Parameter failed in Event Homeseer Switch Led Functions For Motion Detection OUTSIDE Set LED 1 to Blue If NO Motion Outside

Is it possible with an event to spot this and resend the command? I'm guess there is probably someway to script and spot this in the log, but that's a little more hassel than I'm willing to deal with the learning curve right now.

THANKS!

Tom

Current Date/Time: 10/10/2019 4:40:01 PM

HomeSeer Version: HS3 Standard Edition 3.0.0.548

Operating System: Microsoft Windows 10 Pro - Work Station

System Uptime: 0 Days 0 Hours 34 Minutes 21 Seconds

Number of Devices: 474

Number of Events: 197

Available Threads: 800

HSTouch Enabled: True

Event Threads: 0

Event Trigger Eval Queue: 0

Event Trigger Priority Eval Queue: 0

Device Exec Queue: 0

HSTouch Event Queue: 0

Email Send Queue: 0

In Virtual Machine: No MFG: gigabyte technology co., ltd.

Enabled Plug-Ins

2.0.61.0: BLBackup

3.0.30.0: BLLock

2.0.6.0: BLMarantz

3.0.0.70: EasyTrigger

3.9.610.5: HSBuddy

3.1.0.17: MeiHarmonyHub

3.0.0.34: Nest

3.0.0.63: PHLocation2

3.0.11.13: weatherXML

3.0.1.262: Z-Wave

[Wadenut]

What I've done is create an event with the trigger "has been in an INVALID/ERROR state for at least 5m, 0s" (choose whatever time you want). The event is set to not re-trigger for 1 minute, again whatever interval you want. The event will continue to re-trigger once per minute until the lock status becomes valid. Action is to send a "Lock" command to the lock. This makes the assumption of course that the desired condition in case of a failure is to Lock the lock. So far this has worked for me.
I've been thinking of an alternative to resend the actual last command but I'm afraid that might require a virtual shadow device, and likely a small script.

[ts1234]

Thanks...I’ll give that a try and start thinking about how to resend failed commands. It’d be nice if zwave was a little more TCP/IP like

[Wadenut]

It's quick and dirty, but it works until I can come up with something better.

[Wadenut]

I've been looking at the idea of using a shadow device to reflect the last command sent to Z-Wave Devices. The plan was, for instance, when a lock is commanded to lock, also set the shadow device to the same value. Then, when the Z-Wave device status becomes "Invalid", resend the last command based on the current value of the shadow device.

There are problems with this idea (it gets complicated):
- An event, and probably a script would be required for each device involved. I have over 80 Z-Wave devices to track. Is this going to add excessive load to the HS event engine?
- Control of the shadow devices would need to be added as an action to every event, script and HSTouch element currently controlling the Z-Wave devices.
- If a Z-Wave device is controlled from the GUI, the shadow device won't reflect the status unless, again, an additional event/script is created.

Plan B
I've noticed that when a Z-Wave device status becomes Invalid, the Advanced tab for that device still reflects the last known status and value for that device. This might be useful in that the device properties could be used in a script to "reset" the device to either that last known status, or to some desirable alternate. The problem there however is we wouldn't know what the last commanded status actually was meant to be. So for instance, we'd have to decide what would be the most desirable outcome; should a lock be set to Lock or Unlock; a light to On, Off or some Dim level; an Appliance to On or Off.

Plan C
Simply assume the possibility of failure and resend Z-Wave actions several times (2 or 3 perhaps). Unfortunately this also would require modification to every event, script and HSTouch screen involved and would unnecessarily load the Z-Wave network, possibly exacerbating the problem.

Other than that, I'm open to suggestions.

[Wadenut]

Like an ear worm, this is still rattling around in my head.

More thoughts (or early morning rambling):

Rather than using shadow devices (to clutter the system), create global variables for each device which we want to track/correct. These could be created/stored on Startup. Again, an event would be required to trigger on Invalid Status, but the tracked value wouldn't need to be stored in a device, instead just in memory. Perhaps something like the UltraLog plugin could trigger a single event, then a script to determine which device faulted and correct it's status with a re-send.

Just looking at the HS3 Help, there are several scripting functions which return log entries. Might be able to use these. Unfortunately, HS3 doesn't natively provide any Log triggers, so again probably use UltraLog or something similar to generate the trigger, otherwise it would probably have to be a reoccurring event, maybe 1 minute intervals, depending on the load it creates.

A simple plugin which would have the ability to track any device and automatically correct the status by re-sending its last command when Invalid Status is detected.
I've never tried writing a plugin for HS3 as yet, but this one could be a simple project to begin with. On that thought though, I'm wondering if something doesn't already exist.

Naturally, HS containing some mechanism to do the work rather than simply logging "Unknown Status" would be ideal. Maybe HS4 going forward?

[outbackrob]

Like an ear worm, this is still rattling around in my head.

LOL! The imagery.....

REALLY like your ideas. We have 7 locks and occasionally (rarely) they lose their mind and don't respond. Since ours have a keypad outside, always defaulting to LOCK is not an issue. I am going to incorporate your original idea and watch your efforts going forward. Great ideas!

[Wadenut]

Since ours have a keypad outside, always defaulting to LOCK is not an issue.

This was my logic with the locks as well.
Lights and other modules are a bit more difficult. Do we want a light left on potentially for an extended period, or should we turn it off and let someone stumble in the dark?

[outbackrob]

...or should we turn it off and let someone stumble in the dark?

Unless Grandma is visiting, let 'em stumble! Between all the multi-tap switches and Alexa everywhere, it is super easy to turn on a light here. If there is a fault in a light or a switch or module controlling a light (or decoration), it usually means something was unplugged (to plug in a phone charger....) or someone turned off a zwave light bulb at the switch. No way to automatically recover. BUT your ideas could help remind a certain 17yo someone (via text perhaps) that they need to plug the module back in the wall! We have guests here constantly who don't understand HA so we have had to live with lights turned off at the switch. (Conversely, the certain someone has never learned to turn off a light when leaving a room....) I can see a lot of benefits to having something keep track of non-nominal statuses.

[Wadenut]

Unless Grandma is visiting, let 'em stumble! Between all the multi-tap switches and Alexa everywhere, it is super easy to turn on a light here. If there is a fault in a light or a switch or module controlling a light (or decoration), it usually means something was unplugged (to plug in a phone charger....) or someone turned off a zwave light bulb at the switch. No way to automatically recover. BUT your ideas could help remind a certain 17yo someone (via text perhaps) that they need to plug the module back in the wall! We have guests here constantly who don't understand HA so we have had to live with lights turned off at the switch. (Conversely, the certain someone has never learned to turn off a light when leaving a room....) I can see a lot of benefits to having something keep track of non-nominal statuses.

You could always try making the switch hot so anyone turning it off would only do it once.

I have an experimental script which so far seems to do the trick. I've only tested it with a light so far, but other devices should work as well.
If you want to try it, sans warranty as it's a work in progress, msg me & I can send it to you. I'd rather not post it here just yet.

There is a second routine in the script I added as an afterthought. I haven't actually used it yet as we never have a need to touch our light switches; I actually think I may be the only person here who remembers how. It's meant to mirror the actual device status back to the shadow. Take care with that though as I've explained in the text of the script.

[Gadgetman!]

In the case of someone switching off a HA controlled light by using the switch, consider adding a Telldus switch behind it...

Or, as I'm thinking of doing, get some blister packs and fasten the blister over the switch with double-sided tape.
(I get a lot of these blisters because I collect and paint miniatures. Reaper Miniatures comes in just the right size packs.)

[outbackrob]

….msg me & I can send it to you. I'd rather not post it here just yet.

I look forward to trying it!

[outbackrob]

In the case of someone switching off a HA controlled light by using the switch, consider adding a Telldus switch behind it...

Hmmm. I've never heard of a Telldus switch. Assuming it is HA? All my switches in question are WS-100's or 200's so I could have them turned right back on if they are ever turned off. I need to figure out the best way to do that because if someone turns it right back off again and keeps on doing it, it will reset the LIFX bulbs that are connected to many of them. Been there...…. I will look up Telldus.

[Wadenut]

If one has access to a 3D printer, one can print a locking device or a cover for switches which makes them difficult, but not impossible to activate locally. Sort of a "Think twice" device. There are several on thingiverse dot com.

Someone turning off a table lamp, or tampering with it however is another matter. Recently I had a bit of a panic here. Two lamps on a lamp module seemed to have failed. Naturally I went directly to the plug in module. It seemed to be responding to HS On/Off and Polling but didn't activate from its push button at all. Thinking the triac circuit had somehow failed, I removed it from the Z-Wave network, replaced it, included and optimized a brand new one. Same problem. After about another hour of head scratching I found my partner had unscrewed both bulbs for some reason and forgot to tell me.

[Furious]

You could always try making the switch hot so anyone turning it off would only do it once.

I have an experimental script which so far seems to do the trick. I've only tested it with a light so far, but other devices should work as well.
If you want to try it, sans warranty as it's a work in progress, msg me & I can send it to you. I'd rather not post it here just yet.

There is a second routine in the script I added as an afterthought. I haven't actually used it yet as we never have a need to touch our light switches; I actually think I may be the only person here who remembers how. It's meant to mirror the actual device status back to the shadow. Take care with that though as I've explained in the text of the script.

Could I also have a copy please? I've been playing with something similar with MQTT, problem is its way too involved