Automation firing but no response from lights

Yet another issue is plaguing my automations. The turn on at sunset, off at sunrise automation is only turning on the lights. It shows in the logs that it is triggering the anti-turn on. There is, however, no command sent to the lights. I feel like I just recently started seeing these anomalies.

app:1372021-11-10 06:42:00.155 am infoTurn On  Outdoor Lights at sunset anti-Turn On

note the front door lights were turned off manually by me but not by the automation:

4302021-11-10 07:41:52.579 am infoFront Door Lights and Controller  was turned off
4302021-11-10 07:41:52.091 am infoFront Door Lights and Controller  was turned off

Running C-7 at version

I have tested this first question and the automation says it is turning the lights on. The lights do not turn on. Using the devices control in hubitat I am able to turn the particular light on and off quite quickly. I am also seeing cases where the motion automations are NOT turning on the lights because it believes they are already on when in fact they are not. I'll try automating with another method than the motion lighting app to see if I have better results.

Have you checked the health of your zwave mesh and do you have any ghosts that might make the mesh less reliable? And what kind of zwave switches are you using? Are they zwave plus switches?

Mostly zen77/76 with some Inovelli Red Dimmers. There are a few GE/Jasco non-plus devices but I have worked out from the location of the hub with many mains powered Z Wave plus devices. This really does not explain why the automation says it is turning on the light and it does not if I am able to do so in hubitat manually, right? What else should I be looking for to determine the health of my mesh besides ghost devices?

Right... however if some devices are not correctly reporting that they're on that could be a zwave issue. Ghost devices are the biggest ones... but you can also look at RSSI, response time, and # of reroutes. I don't know that any of these are absolutes but certainly if you see a device that falls outside the norm of your other devices on a couple of these it might indicate an issue. On the other hand I have devices that LOOK like they should fail but seem to work fine .

When you look at the time that the automations should have triggered an on or off is there a corresponding on or off event on the devices tab? It might also help if you posted a screen shot of the automation. Are you using a group or scene? Or controlling the lights directly? If the former sometimes I've enabled metering in the group and that has helped reliability.

I was having the same thing. Z-wave (all plus) not firing, but I could control manually without issues.

For any Z-Wave group, I enable metering with an 85 ms delay.

This has solved most of my automation firing issues.

Yeah same here... definitely helps. I suppose even if you are not using a group and simply turning them all on individually you could run into the same issue... not sure. Maybe part of the solution is to put them in a group if not yet and then turn on metering?

I was not using groups for most of these. I will try that. Some of the issues are with single lights being controlled.

I have found a few ghost devices which I tried to remove under z wave settings. Unfortunately, they seem to be stuck like some other users have mentioned. I cannot find any good suggestions to remove stuck ghost devices. Any pointers?

1 Like

ZWave ghosts are an issue and can definitely cause the sorts of issues you're seeing, though often they will also cause problems when trying to turn devices on and off from the devices page as well.

Removing them can be tricky. The first step is you have to identify what the corresponding "real" device is and make sure it cannot be reached, usually by disconnecting it from its power source. Often ghosts are created when an inclusion attempt fails, so it is possible that the next device on the list may be the real device. Once you've removed power from the real device (and sometimes this means air gapping or shutting off a breaker), clicking refresh repeatedly until you get a remove button, then clicking on it, should remove the device. Sometimes this takes a while and has to be done repeatedly.

If that fails, or you lose patience, you can try the method @672southmain references. It pretty much always works, but it's more complicated and requires a zwave stick. Those are cheap and readily available, and honestly not a bad thing to have on hand for situations like this.

In my experience there are a couple ways to prevent ghosts in the first place. The first is if you try to include a zwave device and it fails, assume you have a ghost. Immediately doing a exclusion on the device usually resolves the issue. If you wait, well, then you have bigger problems. I've also created them myself by using the "remove" button in the device details page and then waiting for it to time out. This removes the device from the HE database so it no longer shows up as a device, but it does not remove the device from the zwave radio... hence the ghost.


Thank you @672southmain and @brad5 for the advice. I have had ghost devices previously that could be removed with the z wave remove button. Not so lucky with these.

Some constructive feedback which has likely already been shared, if this can be done with a z wave stick, why is it not possible in hubitat? I have never had any issue forcefully removing a device in the SmartThings IDE. I fortunately already have a z wave stick that I previously used for firmware updating. Surely this is not the case for most others and it will turn them off with Hubitat.

Apparently, Silicon Labs (developer of the Z-Wave protocol and radio chips) doesn’t expose that capability in their API, but is able to have that control in their free Simplicity Studio software, a misnomer if there ever was one.


Definitely... the HE folks are painfully aware of this issue. They have made improvements over time, and I know if they can they will continue to do so.


As @672southmain and @brad5 noted, there are different "rules" for a consumer Z-Wave 700 series certified hub (e.g., HE C7), and the developer-centric PC Controller app (subset of Simplicity Studio) using a UZB stick. Those rules are determined by Silicon Labs.

1 Like

Well I have good news. It was the ghosts. The Ghostbusters z wave stick trick wiped them out and all automations are firing very quickly as I would expect. Thanks all for the help.


Tada! Keep that stick handy.

1 Like

Great news.

By the way, don't miss the new "Ghostbusters: Afterlife" movie in which several ghosts are dealt with using the new Ghostbusters custom UZB stick proton backpacks. :wink:


Is that the one with the Mr. Fusion power pack?

1 Like

Absolutely!! Fission is so 1980's. :wink:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.