My Blues are all working great - no drop-offs and no other type of adverse effect on my zigbee mesh.
Are your Blues the only (or bulk of) mains-powered devices in your zigbee mesh? I wonder if this is somehow a zigbee meshing issue…
My zigbee mesh was strong/robust before I added the Blues, so they aren’t carrying the water on mesh-maintenance too (but they should be capable of doing that AFAIK).
One of my Blues is bound to 2 Hue bulbs, but none of the others are bound (or were ever previously bound).
Interestingly, several of those other Blues show “4” for parameter 51 (# of bindings), but if that’s actually true, I have no idea what they are bound too… I’m sensitive to that issue since I’m the one who raised alarm bells about unsolicited bindings in the original firmware. I’ve considered factory-resetting them now that they are all on f/w 2.08, but since I’m not seeing any adverse effects, I’m just letting it ride for now.
Yes i have plenty that are just a load and not bound. Theybswitch works to turn light on and off but at times there will be no zigbee responce a d still have to reset the switch and then incan remote activate it again
Inhave plentybof other zigbee devices. And also plugs that are hardwired with repeters. All other zigbe stuff continues to work. Its literally just my blues that are acting wonky.
I had a similar issue, but I believe the switch in question was part of the recall batch so most likely that is the reason. Here is my experience anyway.
Switch paired fine, another switch would not, so this led me to believe I only had one recalled switch. Then after about two weeks it stopped working through hubitat. It acted like it was in a sleep mode because manually using the switch would seem to wake it and it would start working. I’d wake it every few days and then it stopped responding after a week or so. I had to remove the device, reset it, and add it back. Sometimes hubitat would find it and sometimes not. I could not add it back even though hubitat said it was added, the switch pulsed blue remaining in pairing mode. Nothing in logs, just sitting in my hubitat device list not working. Slapping a repeater on it “fixes” it, for now.
If it seems I am not very certain if it was a recalled switch that is because I just took pictures, submitted the form, and seems it probably was based on the email I received.
I think I have the same issue on my c5… no resolution. I even have a c7 new out of the box and I paired a single blue to it as the only device on the hub. Some random time later it no longer responds just like my c5.
4-way dimmer setup (No traveler wire on AUX, just power and neutral)
Dining Room Light Main (Controls Load) - 94DEB8FFFEF4BEF3
Dining Room Light AUX1 Binded to Dining Room Main - 040D84FFFE029862
Dining Room Light AUX2 Binded to Dining Room Main - 040D84FFFE02B397
3-way on/off setup (No traveler wire on AUX, just power and neutral)
Front Door Light Main (Controls Load) - 040D84FFFE06126F
Front Door Light AUX1 (Binded to Front Door Main) - 040D84FFFE02A5F4
Smart Mode - Power always on
Porch Door Light (Rule turns HUE Lights on and off, not Binded) - 94DEB8FFFEF4DCDD
These are the most recent ones that have giving me issues, but now been solid the last 2 days.
Quick update, I switch my zigbee channel from 20 to 19 two day ago and so far they have been solid, so the blues might just be a little more picky on interference than any of my other zigbee devices. Time will tell. I will report back should it happen again.
Update, Since changing the zigbee channel from 20 to 19 I have had 0 issues, not sure why the Blues just started droping after a few weeks on channel 20 but everything else stayed working. But now that its on 19 everything including the blues are working. So incase anyone else has issues, try changing the zigbee channel. it might help.
Lol yes I was – sorry, this thread got buried for me – just seeing it again. I would give @Almulder’s suggestion a shot. Quite possibly you’re seeing some interference.
@hydro311 – where were you seeing the, “low-ram concentrator” tag in Hubitat? That’s interesting.
Changed to channel 15 a couple days ago. It was not a fun experience. I had to manually re add the blues. They would not change the channel on their own. But I still see the units go un responsive after 12~ hours. I have my replacement units so I am going to install one today and see if I have the same issues.
I am not sure if I was just being impatient but all my blues started working yesterday on their own and are still functioning over 15 hours later. Still on channel 15. Ill keep an eye out.
when you change your ZigBee channel it can take over 24 hours to have everything switch, mine took about 10 hours for most, a few took overnight. .Glad its working for you, mine is still solid since i changed.
They’re considered Low Ram because they can’t hold a larger routing table.
At least, that is what Hubitat support says. It’s normal behavior if there’s not much memory available.
Low Ram = can hold 8 states in total.
High Ram = can hold more than 15+ states in total.
When speaking with Hubitat support, they have sent me the following:
"A low ram concentrator is just what it sounds like. The coordinator device does not have enough memory to fill a full routing table so it only stores a partial table. When the coordinator needs to send a message to a device but does not know the route, it first has to send out a discover frame and wait for a routing response before it can actually send the message.
A high-ram concentrator is the opposite. It maintains a full routing table to each end device. This also means that a high-ram concentrator has to frequently request route information from devices that act as routers so it keep its routing tables updated. Since the coordinator knows the routes to each device, whenever it needs to send a message it can do so without having to wait for route discovery. This method usually results in much quicker response times to devices.
Low ram concentrators have to frequently send route discovery requests prior to sending a message. That’s horrible for large networks because these are effectively broadcast messages which can start to degrade a network."
