Dashboard bulbs turn On, but physically remain Off

🛎️ Get Help
1

First a brief intro:
After 2.5 years of Wink 2 "fun" I decided to pull the plug on that, and to migrate to Hubitat. By and large that went just ok (not well, but not too bad either). Hubitat does have its own "complexities" so to speak, and is definitely NOT the Panacea for all smarthome challenges.

My current issue:
I have about 27 or so Sengled Element Classic bulbs in various groups/dashboards, along with a few Zigbee outlets/repeaters. When they work they all seem to work well. At bedtime I turn everything off, and confirm that no tiles are l it in any dashboards. However, in the morning I will find a number of bulbs On in the dashboards that they appear in, but the bulbs are physically still Off. These bulbs cannot be turned on/off from the dashboards and/or Alexa, and can only be "reset" via the Devices page - that is to cycle them on/off - after which they are back to "normal", and can again be controlled via dashboard/Alexa.

This issue of bulbs turning on in dashboards but not physically is 1. ) not limited to nighttime, and does happen through the day as well; 2.) does appear in the Logs; 3.) seems to happen with only some bulbs from most but not all groups; and 4.) are not the same bulbs every time.

Having to perform a daily cleanup is rather irritating, and takes me back to the frustrations of Wink. I would hope to get this figured out soon. Any thoughts/suggestions?

1 Like
2

Which specific repeaters and how many? Also, do you have any other zigbee bulbs besides the Sengled ones?

P.S. Welcome to Hubitat! I'm sure you'll get this issue sorted out soon.

3

@aaiyar Thanks! 1 x Iris v2 3210-L, and 2 x Innr generic Zigbee smart outlets. All bulbs are Sengleds.

1 Like
4

@flotsam1

I suspect you don't have enough repeaters. While no one knows for certain, the general recommendation is one repeater for every 6-8 zigbee end-devices.

See this thread for details:

5

@aaiyar I will take a look at that, but if I did not have sufficient repeaters then how would that explain why the system works just fine for hours on end, and then at times tiles get lit up with no human/rules interaction while the device remains off? How can the root cause of the tiles getting lit be determined?

6

I was the poster of the repeaters thread. I had this happen. You have poor communication, which might have confirmed that the switch was flipped, but the command actually did not execute. The Zigbee mesh is always changing. Looking for the best path to the hub. Having weak connection can cause drop off's that may only last for a short time. Take a look at your routing tables. It might help you to determine the strength of your mesh.

1 Like
7

@flotsam1

This. 100%. Here's how you can look at the routing table:

~~http://hub-ip/hub/zigbee/GetChildAndRouteInfo~~

Edit: as corrected by @doug
http://hub-ip/hub/zigbee/getChildAndRouteInfo

1 Like
8

Might want to look at this thread as well. There is a concise explanation on how to read it. Also, there are document pages for zigbee mesh under documentation.

1 Like
9

FYI it's case sensitive apparently.
getChildAndRouteInfo

1 Like
10

I would also recommend de-coupling the dashboard from the issue. Just use the Device Edit page in the hub UI to turn on and off the devices, and check that the status there updates reliably and follows the actual state of the device. Sometimes hitting Refresh in the device can get its status updated, but with a decent zigbee mesh, this should not be necessary.

In theory the dashboard should follow the device state, but there have been reports of dashboards not refreshing, so you would want to be sure not to be battling that issue as well.

Lastly, its not just about the number of repeaters, its where they are positioned to be in range of the hub and edge devices around your property.

3 Likes
11

100%. Sorry about that. Apparently the older I get, the less I remember :confused:

12

@jon1 Yes, I do believe that I have a Device <> Dashboard issue, and not mesh (although that might need some work). The fact that I can turn the Device on/off from the Device page and NOT the Dashboard seems to support the possibility of a refresh issue. If it is a refresh issue, any thoughts?

@aaiyar I cannot reach that site (even with the correct case . . .)

@april.brandt I had previously looked at the "Greek" on the child/route tables. I will have to do some research to understand what that all means. Hopefully I can access the info Aaiyar is trying to share . . .

13

Did you replace hub-ip with the IP address of your hub?

14

@aaiyar My bad, yes I had looked at the tables, but was trying to reach an external site called "hub-ip" . . .:slight_smile: Here is what I get shown below.

An interesting observation is that two of the devices (Bed1 & Bed2) that go into dashboard/device disconnect are Child devices, and therefore connected directly to the Hub and not the Zigbee mesh (routers). So if it was a mesh issue, why would these Children go weird? . . . .

Parent child parameters
EzspGetParentChildParametersResponse [childCount=3, parentEui64=0000000000000000, parentNodeId=65535]

Child Data
child:[Ext Garage L, A350, type:EMBER_END_DEVICE]
child:[Bed2, 687E, type:EMBER_END_DEVICE]
child:[Bed1, EFCF, type:EMBER_END_DEVICE]

Neighbor Table Entry
[Jaguar, 0DEE], LQI:253, age:3, inCost:3, outCost:1
[Zigbee SW Lounge, 4B44], LQI:231, age:3, inCost:5, outCost:3
[Zigbee SW Diner, DB91], LQI:240, age:3, inCost:5, outCost:7

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [Sink, 3C35] via [Jaguar, 0DEE]
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Ext Deck, F966] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Hall1, 5ED4] via [Zigbee SW Lounge, 4B44]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Base1, 2FDD] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [B1, CF0D] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [B3, DCAB] via [Zigbee SW Lounge, 4B44]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Base2, 92BF] via [Zigbee SW Lounge, 4B44]
status:Active, age:64, routeRecordState:0, concentratorType:None, [C2, 2B90] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [A1, B900] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [A3, E318] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Coffee1, F804] via [Jaguar, 0DEE]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Ext Garage R, 0F61] via [Zigbee SW Lounge, 4B44]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Ext Front Door, 12CC] via [Zigbee SW Lounge, 4B44]
status:Active, age:64, routeRecordState:0, concentratorType:None, [B2, AD9C] via [Jaguar, 0DEE]
status:Unused

15

The mesh can change dynamically. Although your snapshot probably a decent reflection of its current state. Still, I'd recommend you monitor that for a bit - and especially when there's are discrepancies.

16

Thanks you all for the input.

However, I want to come back to the problem that I described in my 1st post:
Dashboard tiles for some bulbs get lit (with a corresponding entry in the Logs) without any human interaction / Alexa Routine / HRM / Simple Lighting rule / whatsoever. The fact that these devices remain off is secondary to the root cause I suspect.

My understanding is that Zigbee bulbs will turn On after a power failure, but this is not the case here. Only some bulbs exhibit this behavior. A mesh problem might affect functionality when I try and turn a light on/off, or a rule/routine makes that attempt, but a mesh problem should not automatically light up tiles, correct?

Which brings me back to the question:
What could cause bulb tiles to get lit in all their respective dashboards with relevant log entry, without any human/rule action?

17

So the tiles just randomly light up? the device doesnt go on? what does the log say?

18

@jon1 Exactly - tiles light up but the bulbs physically remain off. Here is the log extract at 12:48 am for one of the devices that I found to be On in the Dashboard this morning. Coincidentally, at this moment in time, the route tables shows this device to be a Child . . .

dev:662019-11-06 12:48:16.991 am infoBed1 was turned on

19

That is spooky. Does the status in the device edit page also show it going on? Are there any other log messages before or after the turned on message? Is it possible these bulbs still have some kind of association with another controller or hub? Is the wink still powered on, for example? I don't know if zigbee would allow more than one controller. Might be worth resetting and re-discovering the bulb next time it happens, see if that fixes it?

Could it be being turned on but at a very low level so it doesn't appear to be on, but actually is?

20

Yeah, very weird - so hence my post.

Once the devices are in this state, I cannot turn them on/off via the dashboard/Alexa, and can only do so on the Device page - cycle them through on/off (like a reset). The Events button does show a similar entry to the Logs.

The devices were all properly removed from Wink, and then Reset prior to Discovery. You have given me an idea though. While the Wink now has zero devices included, it is still powered on. I will take it down and then see what happens.