Hi all,
I have a simple rule that turns off some lights 10 minutes after I go to bed but they are not running:
Seems to be pretty consistent, I can't figure out why they won't go. It doesn't seem like HE is even sending the command to them
I ran my sleep routine at 12:19 AM which dimmed a couple lights to 25% then the rule turns them off 10 minutes later, except that it doesn't. The event at 12:19 was the last.
How can I troubleshoot this?
thanks
Dan
It looks like it should work from my POV.
If you do not have descriptive logging enabled for those devices they may. It appear in the log but I assume they are not turning off either.
Does your vButton get set after 10 mins?
Iām sure there will be others that disagree with me but I donāt like setting delays to all trigger at the same time. Can you try to offset the delays by five seconds?
Do delays on individual actions mean that the next action won't run until the previous one runs? e.g. if action 1 has a delay of 10 mins, does action 2 not start until 10 minutes later as well? Suspect not, but just wanted to ask, in case that is the issue.... and am curious about how that works.
No. Not when the delay is written as he has it. All the delays get set up one right after the other and will all fire in 10 minutes.
If a separate Deleyās statement was used between the actions, then the actions would have a 10 minute delay between them.
To add to the ideas above, do these devices ("Guest Bathroom Table Lamp" and friends) work if you control them directly from the device page? What kind of bulbs (brand/model) are they, and are they paired directly to Hubitat (as opposed to, e..g, through a Hue Bridge)? Asking because some Zigbee bulbs can be problematic, and I agree that your rule looks like it should work, though you'll have at least three commands on your network being sent in quick succession, so making the second delay maybe 11 seconds or splitting all three out into separate actions might help tame that down a bit and help if that is the problem (quick commands/flooding network; if the bulbs themselves are acting poorly on your network, that's another issue).
Also, is there a reason you're using "Dim to 0" for the second set of lights instead of "Off"? These commands are more or less synonymous in most drivers, but "Off" is generally the better-tested choice.
Thanks all, Iām away from home right now but I appreciate the help and will jump in as soon as I get home in a couple days. These devices are direct zwave to the HE hub. They do generally respond quickly when I do on/off from the device page. I do have issues with HE not knowing that a deviceās status has changed. Iāve considered setting up a polling rule but in this case, the suspect devices are Honeywell zwave plus plug in modules so I didnāt think polling should be necessary (or possible, I donāt think the polling app shows them in the drop down)
That smells like a rule issue to me. Spreading them out is an interesting idea, I can try that.
Yeah, so Iām not crazy about the dim 0 either. I couldnāt figure out how to send them a simple OFF command. If I select ācontrol switchesā only proper switches are shown.
Weird, what kind of devices are these? RM should show you any device that supports the "On" and "Off" commands there, which includes most real-world bulbs and dimmers. Not saying it would solve your problem, but it seems odd regardless.
Dimmer should definitely show up under the Control Switches / Turn switches off
But I guess itās how the driver is set up.
That's just redundancy in case the alarm doesn't arm. That might happen if a garage door was open and the first time it tried to arm the alarm, it failed because I don't have any way of auto-bypassing zones with the Konnected alarm system. If the rule closes the garage door making all zones secure, the alarm will arm on the second pass.
One of them is a GE outlet and the other two are new Z-Wave plus dimmer plug-in modules. They are both showing as generic drivers.
thanks, all - i've separated them out so not everything is hitting at 10 minutes after. Will see what it does tonight.
Separating the delayed actions SEEMS to have worked last night. At least, my lights weren't still on this morning.
Smells like a bug 
Iām glad you got it working.
I donāt know if I would call it a big or not. I mean yes it should not happen but itās hard to define what is actually happening.
I mean we have a four core processor firing commands at a much slower zwave interface. The zwave interface should be queueing commands and sending them out. We have no reason to believe that is not occurring properly. My feeling is the zwave mesh just canāt guarantee rapid fire commands floating around reach all recipients.
I even had similar issues two years ago back on wink with only a handful of zwave devices. If I tried to turn a few lights off and lock my front door without any delays something would get missed.
I guess I would say, if an average user canāt purchase the hub, buy a door lock and some light switches and build a simple routine to lock the doors and turn off the lights without starting a community thread and doing a bunch of troubleshooting, then that is a failure of the hub or the software manufacturer. I never had this problem with SmartThings and thereās so many other posts out there alluding to the same type of issues that didnāt exist with SmartThings. Itās the hub manufacturers job to understand device platform and protocol limitations and build robustness into their software to work around those limitations.
Thatās just my opinion - I wonāt be giving Hubitat a pass here. They have not done a great job of implementing zwave. That is painfully apparent but if we keep our standards and expectations high, report issues and apply pressure, we can make home automation better for the masses when it becomes ubiquitous in 20-30 years. Until then, issues like these ensure Hubitat to be a hobbyistās toy ripe for being squeezed out by someone like Steve Jobs or Elon Musk who will solve these problems and bring automation to the masses.
Hubitat, are you listening? 
Well I guess they could limit the processor to just one core and slow it down so the processor becomes the bottleneck that is incapable of overrunning the the zwave network.
No but I get what you are saying.
For instance, Echo Speaks has now integrated a throttling queue in front of the Alexa calls that limits back to back commands. But if HE did this on the zwave, possibly it would slow down other operations.
I did notice on smartthings, sometimes my door locks would be a little late even though I never built in any latency to my routines. Maybe all it takes is a bit of cleanup in the code to check on things after events have fired.
it's interesting to think about the massive amount of data that can travel back and forth between a mobile device and a wifi access point, or a phone and a cell tower with little or no loss at incredible speeds and yet we can't get a few simple on/off commands to reliably reach multiple devices inside a single home. I mean, that's just wild... I could have 5 people in my house all streaming a movie from the same AP but Z-Wave falls on its face trying to send a few packets at the same time.
I have to think Z-Wave's days are numbered just like Insteon, X10 and probably Zigbee. Maybe it's just time to embrace IoT, invest more in the Wi-Fi mesh and move away from individual device mesh technologies.
Download the Hubitat app
