Device Automations not consistently turning on or off all zwave devices

I’m fairly new to habitat (previously Vera) so excuse my ignorance on some of this. Most of my automations consist of turning on outdoor lights before sunset and indoor lights at sunset and turning things off at bedtime. Same routine for the mornings.
I’ve had repeated problems with getting these automations to consistently work. For instance, I have about 20 dimmers and smart plugs come on at varying dimmer levels 20 minutes before sunset. It mostly works but always misses a few lights and different lights each time with some next to the actual hub. And sometimes it doesn’t work at all even though the logs show the app as working. Another example is that I have an “All lights off” routine every morning around 8:30. Just a simple turn all the lights off. It never turns off all the lights.
This is what I’ve tried through researching this forum
• Upgrade all Leviton dimmers to latest release
• Removed all ghosts using a PC Controller on zwave USB
• On the “turn indoor lights on at sunset” Rule I separated the dimmers actions with 5 second delays between groups of dimmers(helped some)
• On the “all lights off” Rule, I used a users “All Off” app. This worked great but I don’t see why I had to do this
• Got range extenders spread around the house.
• Tried metering….sorta helped.
• Created a rule to refresh devices every 2 days since sometimes the devices showed on when they were actually off….sorta helped
• Any help or thoughts would be greatly appreciated!!!

• C8Pro latest release
• 2200 sq ft 2 story house (detached garage) with 1100 sq ft on each level
• 73 Zwave Devices total including dimmers, wall plugs, remotes, range extenders, switches, fan controllers
• 40 Leviton dimmers DZ6HD
• 6 Zooz dimmers 800 series
• 1 Inovelli Red 800 series
• Ministon and Leviton smart plug dimmers

Would be good to see the full Z-wave details page, after the hub has been running for at least 12 hours (during an active time period) since the last reboot.

Thanks so much for responding. It's been about 27 hours since last hub reboot. Here are the screen shots.

I think some people do, like, 5 devices at a time, wait a second or two, and then move to the next. I'm sure of the details, as in, what you can get away with

For max reliability, where you don't want to miss any device so check its state, blah blah blah, I don't think there's an app. It's probably been talked about, but searching is tough. Maybe someone with real world experience will chime in.

I turn off all the lights from a bedside button by sending the command twice, with a little delay, as I remember. Seems to work.

There is an "All Off" app that some people swear by.

Nothing for "All On", far as I know, lol.

1 Like

The mesh looks very solid, repeaters / extended are probably totally unnecessary actually.

5 seconds between groups is way more than enough, I stagger groups 1s or less and do not have issues.

What app did you try metering with and what did you set it to?

For turning devices on, you might want to follow up in your rules with a second delayed on command with the options to only command devices that are off. This would send a second on command to anything that did not turn on the first time.

Can you show screenshots of one of the problematic rules?

1 Like

Here is the one I have constant issues with. It usually works to some extent but seems to always miss a few lights. Lately the 1st 3 lights in the list don't come on.

On the metering, I created a group of all my lights so I could turn them all on or off if I wanted to from either a remote button or from an app (when I didn't care what dimmer level they come on at). I added 600 mms metering because so many lights were missed when turning on or off. The group is in the second image.

Thanks again for the help!

You are doing a wait for event, with no event. I suspect this may not even be doing a wait at all.
Have you run it with logging to see if the wait is working?

Here is what mine looks like, I add the delay to each action instead of adding separate waits actions.

Example of one with a 200ms delay (0.2 seconds)

The OP's rule has wait for event -> elapsed time. Isn't this the same thing as your delayed action?

Yes I think it might be, I am looking at how it was created right now. Very unorthodox way to add a wait.

Ahhhh....I can see where that would be easier to do. I didn't even notice the delay selection. Here's what my partial logs look like from last evening.


You could try adding a repeat loop around the entire thing and have it go through it all a second time? Seems excessive since a lot will probably be on already but might work.

Only other thing I could think of would be if someone takes that All Off app and makes an All On version that will keep trying the on/level commands until device changes.

Thanks @jtp10181 I might change the wait for event to delays and see if that makes a difference or not and then try the repeat loop idea (once I figure out how to do Yeah, the all off app really helped my issues with turning devices off. It works perfectly now. Wish someone could do the same with an All On one!

@jtp10181 There are subtle differences in doing a "Delay 2 sec" vs "wait for event - elapsed time 2 sec" vs. adding a "delay 2 sec" to each command.

From this link: [] Rule Machine Using Delay vs Delaying an action - #4 by bertabcd1234

@bertabcd1234 said:

All "Waits," including "Wait for events: elapsed time," are cancelled if the rule re-triggers. I've started to use these in most cases over delays because it's almost always what I want, whereas delays must be explicitly cancelled (with the most common method being to mark them as "cancelable" and use a "Cancel Delayed Actions" somewhere else in the rule). Otherwise, they are quite similar to a standalone "Delay" action--which, as discovered above, is different from the delay option you can use on an action. A delay on an action schedules that particular action for the specified time in the future, then continues on with the next action instead of waiting there.

It seems the "wait for event/elapsed time" is most likely the best way for most situations (it will automatically cancel itself if the rule gets triggered again).

If you have a "Delay xx secs" and the rule gets triggered again, you can end up with the rule sorta running two places at the same time (in a very simple rule with no conditions/loops/etc), that might work--but it can really gum things up and create "unpredictable results" in a lot of cases. You need to make sure those delays have "Cancelable" selected & you need to do a manual cancel of the delayed actions to force things to stop.

If you put a "delay" on a command, that simply schedules that one command to run at some later time--but the rest of the rule keeps running without any delay. And, unless the other delays are cancelled manually, they will still run even if the rule is re-triggered.

Hope that makes some sense (and that I got it right lol)


Good to know, I might have to take a look at some of mine and see which way might be best.

1 Like