I've found ton of useful information on this forum and am hoping to get some support on a bulb problem I'm having.
Backstory, I'm using a zigbee contact sensor to trigger my pantry do light based on the current mode the hub is in. This is done in rule machine 4.0 and was working really well until last weekend when I added 7 more color bulbs to my outside sofit lights. This seemed to cause all kinds of problems with my pantry bulb. I've let a week go buy to hopefully allow my mesh to settle down, but what I've noticed is that the pantry bulb turns on fine in my breakfast and day routintes (I think so at least) but when I get into my dinner, evening and bedtime modes it fails to fire. Or according to the zigbee logs its firing but not turning on.
I've attached the zigbee logs of a trial I just did. I opened the door to see if the "pantry door open" would turn to true in my rule. It did and looking at the logs HE is seeing the contact sensor, but then a bunch of commands fire off to the bulb in a matter of like one second. The bulb doesn't come on however. If though I go into the rule and click the "run action" button the bulb (if the door is still open) does come on.
I've read a ton on zigbee bulbs being bad repeaters and that they should be separated onto a different hub so I am close to going down that path. Before I sink even more money (lost count at this point) I'd like some other input that this will address to the route cause of the problem.
Does anyone recommend anything else I can try?
I have 8 additional repeaters spread all over my house and garage to build a reliable mesh. Prior to this I did have sensors that would drop due to poor zigbee coverage.
From what I can make from the logs, the LQI is good and the RSSI is also good... I'm not totally sure the -73 on the pantry light new is good, but I think I'm understanding this correctly.
What kids of bulbs are you using? I experimented with using a separate Hubitat hub dedicated to smart bulbs as an alternative to the Hue Bridge I was using--and eventually went back to due to some problems I noticed on this setup, mostly bulbs sometimes needing commands to get sent twice in order for everything to work (e.g., if off, a Set Color Temperature action might turn the bulb on but not to the right Color temperature, but sending it again will work).
One thing that may help is group messaging. If these are all Zigbee bulbs (just assuming...), using a group from the Groups and Scenes app and checking the "enable Zigbee group messaging" box will may help (assuming you can group some you want to all act in the same way). I went back to my Hue Bridge (another option for you if all your bulbs are compatible), but if you have things like Sengled or US Osrams that won't work there, I've also seen better reliability by modifying Hubitat's stock Zigbee bulb driver to slightly increase the delay between commands (according to a friend I tried this for--I no longer have this setup): Hubitat/Generic-Zigbee-RGBW-Light-Tamed.groovy at master · RMoRobert/Hubitat · GitHub
Another thing that might help: either sending things twice with a delay between (I basically just activated scenes twice in a row) or sending individual commands (e.g., an On and then a Set Color Temperature) with a small delay between might be one workaround if you're using something like RM where you can control this.
Others may have better ideas, but this is what has worked for me based on my experience with Zigbee bulbs. Another Hubitat hub may help with other problems but is unlikely to help with the specific one you mentioned. If you have Zigbee bulbs that are repeaters (all I'm aware of except Sengled), they usually caused problems for other devices by occasionally dropping messages from them and causing hard-to-troubleshoot Zigbee problems, so it's still not a good idea to mix bulb and non-bulb Zigbee on the same network.
I’m going to go out on a limb and say your using a Sengled bulb just for fun. What I like to do is enable color prestaging and disable level prestaging on the device page. I then create a rule that fires when the mode changes. I the create the action “set color temperature by mode” and fill in the color temperature you want for each mode but don’t fill in the level and give it a delay of 10 secs so it isn’t firing with other mode change rules. In the other rule just use set level per mode. If it still isn’t coming on (which it should), you can add an on command before or after the setlevel command. Btw, I also use this rule for groups of lights, but have it use the group device if the light is on and the individual bulbs, no more than 3 individual bulbs at a time with a 1 second delay between each 3 bulbs, if the lights are off.
They are Osrams. I have quit a few of these and the ones that seem unreliable are on the outside of the house and in our kitchen pantry. We have some in our master shower and they haven't missed turning on yet.
I have adjusted the rule to fire the scene twice in short order. This seems to have helped however tonight the outside lights didn't turn on and the pantry was again giving me trouble.
What I noticed tonight is that my phillips hue undercabinet lights were in their sunset transition (coming on 10 mins before sunset through Phillips hue app and fading on over 15 mins) and that's when the outside lights didn't come on nor would the pantry light.
I saw your delay and link to git hub however am a little intimidated by this as well as cautious as it seems like HE seems to think custom code installs is causing hub slowdowns. I do experience this even with trying to load the local dashboard from my pc, for this being local and having gigabit cat 6 everywhere, the speed is terrible at times! I'm reluctant to go down this path for this reason, but do appreciate the input.
I know the last hubitat live the guys put on they were taking feedback in the forum about future topics. Someone suggested a tutorial on troubleshooting things when stuff isn't working as expected. I hope they put some thought into this as I get the business from the wife every time something doesn't turn on the way its supposed to. Plus its frustrating to me when it doesn't work the way its supposed to.
That's not universally true; it's just that poorly written custom code (or poorly written native code, but staff know what they're doing ) can cause problems. The particular driver you saw was based on the native Hubitat driver that they released as an example of how to write good drivers for their platform, and the only modifications I made were slightly prolonging the delays between Zigbee commands, so the code is almost entirely theirs if all of this makes you feel better about this situation.
In related news, I saw a recent post from Bobby where I don't think he even mentioned custom code as a troubleshooting step for slowdowns, at least not directly (but he did mention searching the logs for errors, which custom code could certainly cause).
Regarding Dashboard loading times there have been several posts on the Forum where slow Dashboard loading has been related to the number of devices selected to be available on the dashboard.
E.g if you have a security Dashboard, select only the devices you want to monitor.
You might want to see if this helps speed them up for you.
I have a mixed bag of brands on the outside of my home, many of them Sylvania, a couple Lightify, Sengled, and a few bulbs on Leviton switches. I've grouped the Zigbee bulbs by region to reduce mesh traffic. I was still having trouble with some of my 15 outdoor lights not turning on or off on queue. My final solution was to use the repeat command and to make the rules modular. By that I mean, I have one rule called "Outdoor lights ON by mode". It has no triggers, just the one action to set dimmers by mode, plus a second rule to set color by mode for my one color light. I then have a second rule has the triggers on the mode changes and all it does is do a repeat 10 times, run "Outdoor lights ON by mode". This keeps the rules small and easy to edit and each of them executes quickly.
So I use three Groups, and two rules. Since I broke it up this way, my outdoor lights have been perfect. I'm going on 8+ months without coming home to a dark house or seeing a light on when I leave for work. The repeat 10 times might be overkill but "once" didn't always work so I figured I'd go all in.
I have not had any issues with @bertabcd1234 ‘s Hue app or driver. I have one Osram labeled under cabinet light that was hit or miss with turning on and off that has been perfect since using the tamed driver. You could also get the Lightify gateway and use @adamkempenich ‘s Lightify integration. If you have the newer Sylvania bulbs, they really need updated to the 00102428 firmware to work well.
That makes me feel better. I'm definitely more interested giving this a try now.
I wish I understood the zigbee logs better. This morning during my morning mode the light didn't turn on during three consecutive sensor trips despite it looking like the commands were sent (I wish I understood the logs a little better). Then the mode changed to day and the light starts turning on no problem; huh! So I look at RM4 again thinking maybe there is something in the rule and I see morning and bedtime CT are set to 1500. I wonder if for some reason this is out of range even though I think it has worked before. I manually change the mode to morning open the door and the light comes on to 1500 per RM4. Not sure what to think or do next.
Here is the log, time was 742 am when door opened but bulb did not turn on.
Thanks for the feedback. You willing to share some screenshots? I'm only repeating the command a second time after a short delay in RM4 after helpful feedback from @bertabcd1234.
Sure these are the two main rules. I do have another rule (no trigger) that simply turns everything off that is called by the one that triggers on mode changes. So I have three groups and three rules.
I do have lightify gateway I could use, however it's in the basement and its a pretty good distance to the outside lights. What about that?
There are sylvania.
Lightify version is 00102090 possibly. I have some on lightify but the ones we are discussing have been moved once I did the latest update about a month ago. So I assume they are on they are on the same version. I don't see an update option to get them to 00102428. Any recommendations?
The only problem with adding 2nd hubs or alternate gateways is you weaken your overall mesh. Some bulbs might be bad repeaters, but they do repeat. That's why I went with the 10 repeats and group messaging instead of further segmentation for my outside lights.
I am playing with the Lightify Gateway integration that's under development to fix bulb drop off, those lights need to be added back to hub on a monthly basis. Since I've taken those seven bulbs off my Zigbee mesh my Xioami Magic Cubes keep disappearing. So taking seven repeaters out of the middle of my house has weakened my mesh for sure.
We all have different environments, so we need to find what works best for us.
I don’t know why your lights don’t show an update available. I have those very lights and there have been several updates to the firmware since 00102090.
I haven’t had zigbee mesh issues with the Sylvania bulbs that I’ve updated the firmware on.
I plugged in my V2 smart things hub (brand new actually) and it updated them to the latest (102428). I then repaired to HE and it has been over a week and the light has been working very well! Thanks for all the input. I'll have to verify firmware version on my outside bulbs to as I'm guessing these are also the older version.
None of them come updated. Every bulb I have purchased has had the original firmware. My Lightify hub actually updated the Flex XL strips to that firmware (102428) as well, where my ST hub said it was up to date.
) can cause problems. The particular driver you saw was based on the native Hubitat driver that they released as an example of how to write good drivers for their platform, and the only modifications I made were slightly prolonging the delays between Zigbee commands, so the code is almost entirely theirs if all of this makes you feel better about this situation.
