Logs say on, device says off, bulb is actually off

🛎️ Get Help
1

This is the result of simple motion lighting rules. I walked into the hallway, saw the motion detector (Fibaro) blink as it reported my motion, but the ceiling light did not come on.

So, I went to the logs, and what I see is this:

Screenshot_2021-03-03 Logs

Which shows exactly what I expect; the motion detector goes active, and the rule causes the bulb to be given a color temperature and level, and turned on.

Except the actual bulb in the actual ceiling isn't on. It's a Smart+ bulb, in a ceiling fixture with an old mechanical wall switch which is on.

And, when I check the device state, it shows the bulb as off, consistent with reality but not consistent with the log:

Screenshot_2021-03-03 HALL ceiling
Screenshot_2021-03-03 HALL ceiling832×458 32.6 KB

So, for a final test, I turn on the light via the hub, and it comes on (I was out of range of the motion detector, and it came on exactly when commanded through the hub web UI). (And this confirms that the physical wall switch hasn't somehow gotten turned off when I wasn't looking; well, this plus that I looked at it and it's definitely on.)

Sometimes when I walk through the hall the ceiling light does come on.

It never fails to turn on or off through the HE web UI.

This is crossing Zwave to Zigbee; my Zigbee setup is very simple, just 4 of those bulbs, no other Zigbee devices. They're connected directly to the HE. This is within the guidelines for stable Zigbee meshes in the document here, and the fact that it responds reliably on hub commands (and the other bulbs also, both manual hub commands and rules triggered by mode changes and the like) suggest that hub connectivity to the bulb is fine. If there were communications problems, I'd expect to see that in the log, too, wouldn't it?

So, I'd like to acquire a clue, if there are any available?

2

What kind (brand/model) of bulb is this, and what driver are you using for it on Hubitat? Related to that latter point, if these are the "Generic Zigbee Bulb" family of drivers, do you have any prestaging options enabled? Some of your behavior could be explained if so (though not the "says it's on when it's not" thing), and I'd turn that off (as it is by default) if you don't know what it does (allows you to use "standard" commands corresponding to the prestaged attribute to state/pre-stage those values for the next time the light turns on--but doesn't turn it on, as is standard behavior otherwise, if off).

For either the "Generic..." or "Advanced..." Zigbee bulb drivers, you might also consider hitting "Configure" on the device page (at the top with the commands) to see if that changes the behavior at all. Don't worry if you don't see anything happen when you hit this button; you won't in the UI (except maybe the logs).

3

I'll second that thought. I have seen this cause issues with the built in Motion Lighting, but only with level prestaging enabled.
You could try using @bertabcd1234 's excellent Lights on Motion Plus app. I really like that it dims the lights as a warning before turning them off.

1 Like
4

I have been having this same type of problem too with my Hub.
Several different contact sensors and motion sensors are triggers in several rules; all programed to turn on lights and turn off lights. I'm having failure rates of 40% or more! All lights are Hue or Lutron.
I've noticed that in my Rule machine section some of the rules say 4.0 and other rules say 4.1. Should they all be the same??
Do I have to start over from scratch? This is really frustrating.Preformatted text

5

This sounds like a zigbee mesh problem. I'm betting the Hue lights are connected to Hubitat. They are terrible repeaters and you really are paying way to much for a crappy bulb if you don't use them with the Hue bridge. Don't get me wrong, I have over 50 Hue bulbs myself and love them (obviously for what they cost). I tried them directly connected to Hubitat and put them back on Hue a couple days later because it really degraded the experience.

No. It was upgraded recently to 4.1, but all of the 4.0 rules will continue to work.

1 Like
6

No. There was a very slight update to Rule Machine, but old rules don't expire. Some are using rule 3.0 just fine. You simply cannot add a new RM 4.0, anything you added after that hub update will be a RM 4.1.

VERY unlikely you need to do that.

First, why Rule Machine instead of Motion Lighting? You went for the most complicated and hard to use app first. Use Simple Automations, and Motion Lighting whenever possible.

Lutron should be literally 100% reliable. I am not as familiar with Hue, but I understand it to be pretty darn good too.

I think you need to post some of your rules in a new thread and see what is going on!

1 Like
7

This is the way. You can also use contact sensors with ML, although I prefer to add them as motion sensors using the "contact-motion" app in Hubitat's github.

1 Like
8

Thanks for the advice.
I had never used anything but rule machine to create rules. I just recreated all of my motion/contact sensor automations with "simple lighting." I never even knew that existed. They are really quick to create. I deleted all of the old ones.
Been testing for the past hour and everything seems to be working flawlessly.
Now the only things left in my rule machine, is my blinds control, my dozens of Lutron Picos, and a couple of
bathroom exhaust fan timers.

Thanks again. :+1:t4:

9

Try Advanced Button Controller. Very easy to setup and use for many common button tasks.

Advanced Button Controller (ABC)

Timers, or humidity? There are bath fan apps that do a terrific job of handling the humidity side of things. Much easier than RM. Timer apps also can be found.

If you haven't already, install Hubitat Package Manager, and dig around in some of the very cool apps that are available in this community.

1 Like
10

As I said about, it's a Smart+ bulb. Driver is Generic Zigbee RGBW (which is what came up by default), and the other three bulbs seem to work fine with that driver, so I hadn't considered that might be wrong. I'm sure I've hit "configure" multiple times at various points (I've never seen anything happen when I hit configure anywhere; what's it supposed to accomplish, anybody know?) No pre-staging options are available (color pre-staging is the only one I remember seeing, but I left it in the default off state).

11

" * Configure: Pressing this button causes the driver to execute its configure() function. This function usually sends configuration commands to the Zigbee or Z-Wave device, instructing those devices on how to report status updates back to the Hubitat hub. This normally happens automatically whenever a device is initially paired with the hub."
I think configure is also called when saving preferences.
I'm not sure which Smart+ bulbs you have. I have had as many as 65 Smart+ RGBW bulbs and the A-19 bulbs are rubbish. Sometimes the zigbee radio goes out, but usually the bulb just starts flickering, or only comes on very dim at 100% (my guess is from overheating), but after Sylvania replaced about 50 of mine under warranty, I started replacing them with Hue. I've never had an issue with the recessed Smart+ lights. They have never failed and run much cooler. I don't know what is causing your issue, as I have never had problems with motion lighting where it said it turned on a bulb and then reported (from the bulb response I believe) that it was on but it wasn't. You could try creating the rule in a different program. I'm not sure which one you are using (guessing ML and you added "switches to turn on" because it wasn't working)

if it's Simple Automation, try Motion Lighting and vice versa. Sometimes just deleting and recreating a rule fixes the issue, especially if you have had power failures or other issues where the hub experiences a hard shut down.

1 Like
12

I'll try some random poking, but no hard or unplanned shutdowns (hub is on a UPS).

This probably is the one you've had trouble with:

Screenshot_2021-03-04 HALL ceiling
Screenshot_2021-03-04 HALL ceiling851×617 42.9 KB

13

Replacing the rule with a simple automation rule (sacrificing the color-temp setting) doesn't change anything. It works sometimes, while direct switch on and off commands continue to work every time.

14

Yes, it is. It's a complete crapshoot how long it will last. Overheats and then stops responding to commands, or it could be another bulb overheating (and no longer routing messages) and I am wondering why I have to re-pair the bulb to the hub. It's best to have a couple good repeaters so when this happens, other bulbs don't lose connection.

15

They're all within 25 feet of the hub, but they do repeat for each other. I have no other Zigbee devices, just these bulbs (and some sources seem to be pretty sure mixed zigbee repeater setups are trouble with an HE; but bulbs only seems to be okay).

And they're wide-open fixtures, not closed (the bulbs are even marked not rated for use in closed fixtures). But I've noticed the base gets remarkably hot for what they're doing, yeah.

16

So are mine. 25 feet is a long way for zigbee to be reliable. I do have a few GE zigbee dimmers on the hub with my lights (still technically lights, right?), which made a big difference in reliability. If you add a couple of those about 10 feet from the hub, or in-wall outlets, it would likely make a big difference.

17

Okay, so I deleted nearly all apps (everything referencing the light and the motion sensor in the hall got deleted). And repaired the zwave network. And shut down the hub. And restarted the hub.

And started re-creating the hall lighting motion settings.

Based on not hugely much time yet, the following seems to be working reliably:

Screenshot_2021-03-04 HALL motion
Screenshot_2021-03-04 HALL motion634×669 31.8 KB

Note the duplication of brightness settings in "dimmers per mode" and "color temperatures per mode". Annoying. But...I took out the "dimmers per mode" section, and found the light failing to come on fairly often. (Takes a minute to time out, so testing is a bit boring and slow.) Up to 5 trials in a row with 100% success, though, which we never got close to before.

And in some sense the "switches per mode" is redundant yet again. Haven't tried leaving that out, I got the impression it was magically required in the past?

I don't think this differs significantly from the version that didn't work, before. However, if the problem was interaction from some other rules elsewhere (which I couldn't find, but), this clean slate would have fixed that. And the shutdown / restart may have cleaned up some things, too.

Anyway, that one rule seems to be working.

I think I'm going to build this and the one other thing I used regularly back up carefully and slowly and watch for long enough to see if they're really stable before I add additional complexities. (I did save the config just before I started cleanup, so I should be able to get it back if I really need to.)

18

Nope. I think only if level prestaging is enabled.
This is one of my ML rules. Zigbee light strips in the kitchen that I have a separate ML rule from the big kitchen lights. This never fails:

image
image1565×712 37.4 KB