Hello. I have had periodic and persistent issues with various events not firing on the hub. It is not consistent, doesn't always impact the same lights or events, and doesn't have any apparent pattern to it. A reboot of the hub typically resolves the issue for some length of time. I've attached the logs that I could gather of the latest. For example, when dev:82, Hallway Motion Sensor detects motion, it should turn on dev:505 Hallway Lights. As you can see from the logs, it doesn't seem to even attempt to turn on the light.
|2022-09-19 08:58:28.872 pm info Fireplace Mantel is on [physical]
|2022-09-19 08:58:27.727 pm info Garage Freezer temperature is -6.16°F
|2022-09-19 08:58:13.886 pm info Hallway Motion Sensor is inactive
|2022-09-19 08:58:02.508 pm info Laundry Room Lights was turned on [digital]
|2022-09-19 08:58:02.266 pm info Laundry Room Motion Sensor is active
|2022-09-19 08:57:52.323 pm info Hallway Motion Sensor is active
|2022-09-19 08:55:38.974 pm info Master Bathroom Shower: switch was turned off
|2022-09-19 08:55:16.928 pm info Outdoor Pool Extender is off [physical]
|2022-09-19 08:53:49.469 pm info Hallway Motion Sensor is inactive
|2022-09-19 08:53:31.310 pm info Hallway Motion Sensor is active
|2022-09-19 08:53:28.881 pm info Fireplace Mantel is on [physical]
|2022-09-19 08:53:16.663 pm info Hallway Motion Sensor is inactive
|2022-09-19 08:53:11.102 pm info Cabin Northwest Sliding Door Sensor temperature is 71.87°F
|2022-09-19 08:53:00.839 pm info Person has arrived
|2022-09-19 08:52:59.197 pm info Hallway Motion Sensor is active
|2022-09-19 08:52:56.710 pm info Kids Bathroom Multi Sensor: motion is inactive
|2022-09-19 08:52:56.666 pm info Kids Bathroom Multi Sensor: motion is inactive
This has been going on for months so any help would be greatly appreciated.
Please provide some details to help the community in its ability to troubleshoot the issue.
- what model hub
- what version of the Hubitat platform is your hub running
- what are the make and model of the motion sensor
- what are the make me model of the light
- enable logging for both devices as well as the automation
- please share a screenshot of the automation that is supposed to turn on the light based on motion
Try disabling the “On/Off Optimization” feature in the automation.
No problem. I've turned it off and will monitor to see if it happens again.
Is this something that should be off in general? I don't understand that what setting does and when to have it on vs off.
The idea with optimization is that it won't command a state change if the device is already in that state. So, if the device state is on, and the command is on, the hub won't send the command. This can be handy if, say, you're trying to turn 30 lights on at the same time. It helps to cut down on the amount of traffic needed to accomplish the end result of having all the lights on. If half of them are already on, then only the other half would need the command (in an ideal scenario).
Turning optimization off will result in the hub always sending the command regardless of the device's state.
Disabling the optimization did not resolve the issue. I have been waiting for an opportunity for me to capture another failure in the log before they rolled over and finally got it today.
There should be an event to turn on the Hallway Lights but it didn't go. It is very sporatic on when it fails but it does happen fairly regularly. It is not just this app/set of lights either, it happens throughout the system.
I enabled debug logging on the light switch and it worked the next time the app fired.
Can you post a screenshot of your Z-Wave details page?
No problem. Is this the detail you needed or something? Not sure what exactly on that page you were needing.
You have a few ghost nodes, those ones with "Discover" and the last column blank need to be removed. Try hitting the Refresh button in those rows (a couple times if needed) and see if a Remove button appears.
Oh, and before you try to remove those devices, hit the Firmware Update button at the top of that Z-wave details page. That updates the Z-wave chipset. There were many improvements in the last couple firmware regarding ghost removals.
Also, your RSSI on many of these devices are quite bad. -1 is the worst you can get I think. Here is the recommendation from Silabs, who makes the Z-wave chipset. You might need some repeaters or move some stuff around to get a better signal. Maybe even relocate the hub to a better place?
I appreciate the help! The ghost devices won't remove so I am waiting for a USB stick to arrive to use that method. Stay tuned.
Note that "events" don't cause something to turn on; they would (normally) report that it has been turned on. A command is what would normally cause the actual state change, then (then that would normally create an event). So what you're really looking for is to verify that the app sent a command to the device.
I suspect this is what you'll find and that you might have an underyling Z-Wave network problem that is causing the actual issue. But it may still be worth looking into. Some app or device logging may indicate when a command is sent, but the platform now has a built-in way to see without any of that: go to the device detail page, hit "Events" at the top, and then look for entries with "command" as the type or names with things like "command-on" or "command-setLevel." They'll also tell you which apps did it. (This is still under "Events" despite the fact that they aren't really events--now kind of a historical name for this page, which once only showed actual events.) If the command worked, you should see an actual event (if the device wasn't already in that state) shortly before or after the command entry (the timing isn't always the order you'd expect...). If you don't even see the command, something else is wrong.
Again, not saying this is the actual problem, but it may be worth looking at to ensure you're chasing the right thing.
I would unplug whatever "garage door" is and try again for the barrier devices showing the discover button.
Typically the ghosts are failed pairings. When you attempt to forcefully remove a device, the radio will try to ping it first. If it gets a response, you will not be able to force remove. So, the hub will send the ping, and the device will respond because it was successfully paired later on, this preventing the removal. If you power down the device, then it can't respond to the ping and the removal should work.
You can typically deduce which device it is by looking at the type. Since the garage door is the only "barrier_addon" type, probably a good bet. The other devices with discover look like they can be any number of your actually devices.
The USB stick and PC Controller software basically allow you to bypass the ping check.
Sadly, this continues to happen. The logs show that the motion sensor went active, the app looks to have told the lights to turn off but it took almost a minute for the light to actually turn on. I can confirm that as I was standing in the hallway at the time. I don't see any ghost devices and that switch appears to be 'directly' connecting to the controller so I'm not sure where a delay could be introduced outside of the controller. It happened with two motion sensor/light combos(Laundry Room did the same thing).