I have a motion and mode lighting app that is triggering according to the logs. However, the lights are sometimes not turning on even though the logs say that the app sent a dimmer level command. I have noticed this in two different rooms. How do I troubleshoot if the z wave message is getting to the lights or if I have a problem. It turns out that the motion sensor is also the light switch I am trying to turn on. So in fact it is sending the motion trigger event. The lights are just not turning on all of the time.
Also, I have a z wave switch (a bathroom fan) that has several automations assigned to it. I cannot determine what is causing it to turn on randomly. Is there any way to see what is turning on the light besides that it is a digital event? SmartThings would tell you in the logs which automation was causing the on/off to be triggered.
On your first question... if you go to the devices tab and look at the actual device events does the device driver say it sent the command to the device? I know you checked it from the app side already. If the device shows it IS sending the message then I would try using the device tab to do it manually a few times and see if it works. If not I'd suspect some sort of zwave mesh issue.
On your second question... you can look at the device tab and see what applications are using the device, then just turn on logging on each of those applications.
Next question - should I be seeing ~3 second delay from motion to switch on? Both devices are essentially in the same room as the hub. I am seeing some motion lighting automation triggering fast every single time and some that are either a) slow or b) inconsistent. Mostly z-wave plus devices I am automating although I do have some non-plus devices in the mesh. I have tried repairs of the individual offending devices. I have read that I should not need to do this for plus devices, right?
Example of slowness:
2021-11-09 09:28:10.610 pm debugdevice event: {"name":"switch","value":"on","displayName":"Mudroom Hallway","deviceId":"179","descriptionText":null,"unit":null,"type":"physical","data":null}
app:1472021-11-09 09:28:10.596 pm debugdevice event: {"name":"lastActivity","value":"2021 Nov 09 Tue 9:28:10 PM","displayName":"Mudroom Hallway","deviceId":"179","descriptionText":null,"unit":null,"type":null,"data":null}
dev:1792021-11-09 09:28:10.556 pm debugMudroom Hallway: BasicReport(value:50)
app:1472021-11-09 09:28:08.328 pm debugdevice event: {"name":"motion","value":"active","displayName":"Living Room Motion","deviceId":"93","descriptionText":"Living Room Motion is active","unit":null,"type":null,"data":null}
dev:932021-11-09 09:28:08.288 pm infoLiving Room Motion is active
app:5032021-11-09 09:28:07.286 pm infoTurning on switch [Mudroom Hallway]
app:5032021-11-09 09:28:07.272 pm infoMotion active Mudroom Hallway Motion
dev:4312021-11-09 09:28:07.225 pm infoMudroom Hallway Motion : motion is active
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
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.
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?
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.
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.
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.
