Actually the bulbs are behaving just fine, but the dashboard does not reflect their state correctly.
I recently added four Zigbee bulbs. They are on my client Hubitat hub, connected to the server hub using HubConnect. I’m using the SharpTools Rule engine to turn them on and off according to time-of-day. The events show up correctly in the logs, and the bulbs do as they are told by the rules. But they almost never show the correct status on the dashboard, usually displaying the “!” symbol instead.
If I reboot the dashboard by “Goto Start URL” in Fully KIosk, they snap to attention, showing the correct status. An earlier post about Zigbee problems mentions “authorizing the switches directly” as a potential fix. I don’t know what this means or how to do it, but of course these are bulbs not switches.
These are the only devices that don’t display status correctly, and they are the only devices on a remote hub. Must be a clue there.
Stan-
Thanks for the message and sorry to hear that these HubConnect devices aren’t updating state as expected.
That’s quite odd as the ! symbol should only be shown when the devices are controlled directly from their respective ‘Thing’ tiles (and the tile state doesn’t match what’s reported by the hub). The reason I bring this up is if they are strictly being controlled by the Rule Engine then the ! shouldn’t be displayed.
Can you PM me one or more of the Doc IDs for the device IDs of the devices in question?
I’ve come up with a quasi solution by using Virtual Switches that turn on/off when the bulb is switched on/off.
The virtual switches are responsive. Wish they showed color in the icon glow. I tried tinkering with Virtual RGBW bulbs but couldn’t see how to make them mimic the color of the actual bulb.
Any resolution on this? I noticed I have a couple of Hue bulbs that are connected with HubConnect to my synced hub. I will get the ! symbol many times after a rule has run on Hubitat (on the non synced hub). Refreshing the dashboard always corrects the problem.
@Greg_Cole thanks for the additional details. We haven’t been able to reproduce this and at the time only had a single report of it. From what I understand @Stan_Silverman had worked around it using Virtual Switches.
I’m not sure if it’s related yet or not, but @Jon_Canniff mentioned a similar experience when using a Rule to control Lutron Caseta lights connected to a Lutron PRO Bridge connected to Hubitat.
Have any of you been able to reproduce this with any of the built-in virtual devices? We have a few hubs here in the office, so I can try setting up a HubConnect integration between two of them, but it would be helpful if we knew exactly how to reproduce the issue.
Josh - I have a spare bulb I could ship to you if it would help reproduce the problem. It’s a new, unused Sylvania RGBW BR30 just like the ones I’m using. Interesting to see that Hue bulbs are also involved. Must be Zigbee related rather than brand of bulb.
Josh - here is the setup I have that consistently produces the “!” error.
Display is a Fire 10" running licensed fully kiosk
All Hue lights on secondary hub. Use HubConnect V1.6 to connect only the Hue lights needed for dashboards to primary hub. I utilize the Hubitat groups and scenes to create Hue lighting based on the time of day. The groups and scenes are run on the secondary hub that the Hue lights are directly connected to (via Hue hub). I see the error when the scene ends and shuts off. Then the dashboard gets out of sync. Notice the lights on the upper right corner of the dashboard, Noticethe Go1 and Go2. They both are physically off but show on here. When I check the device status on Hubitat they show the correct state.
Thanks for the additional details guys. We have a number of Zigbee bulbs, so we can test with those. My suspicion is that it’s not related to Zigbee necessarily.
@Greg_Cole are your Hue bulbs connected directly to your secondary hub? Or connected to the Hue Hub which is then connected to the secondary hub.
Edit: I just noticed that Greg’s tiles that are out of sync all appear to be Color Control tiles and Stan mentioned that the issue occurs with his RGBW bulbs, but not the simple Virtual Switch equivalents of these.
I see a few tweaks I can make to the Color Control tile. I’ll work on making those changes and get a patch out to beta for you to test.
We’ve pushed an update to beta with some enhancements to the Color Control Tile which I believe will resolve this issue.
Both of you are part of the beta program, so if you wouldn’t mind trying things out on the beta site and letting us know if that resolves the issue, we would really appreciate it! Thanks again for reporting the issue!
Josh - thanks for the quick support. I do have all my Hue bulbs connected to the secondary Hubitat hub via the Hue bridge and Hubitat integration. Have the beta site up now next to the production dashboard to see if I can reproduce the error manually and if this fixed it.
The only unusual thing I’ve noticed is that the “!” sometimes appears, but then vanishes after a few seconds. This only occurs when turning a bulb on, and I would say less than half the time.
I’ve observed this on my Surface Book 2
,Win 10. Have not yet put a fire tablet on the beta software.
UPDATE: A little different on Fire 10. The “!” will show when turning the bulb off, as well as on. And - occasionally doesn’t vanish…
It sounds like the hotfix has resolved the originally reported issue of the states getting out of sync (on color control tiles) when controlled by a rule.
Regarding the ! showing for a moment after manually controlling things by tapping a tile… that typically indicates that the device is a tick slow to report it’s status back to SharpTools. With the introduction of Instant Switches, the tile will immediately reflect the expected state for switch type tiles.
After the light is toggled, it waits a few seconds and then verifies that the status shown on the tile matches what is reported by the hub. If the hub hasn’t reported back the state, then it will show the warning. It sounds like in your case, the state update is a tad slow, so it shows the warning icon briefly until it gets the proper event update.
