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.
In Hubitat, this endpoint will give some basic zigbee mesh info:
your-hub-IP-here/hub/zigbee/getChildAndRouteInfo
A few of my blues highlighted below in that listing…
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.
I made the change about 7 days ago so it was well past the 24 hours. I also re-paired the switches to force the channel change after waiting 48 hours.
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."
I have this similar issue and wondering where to start debugging. Some points:
Any pointers on how to figure out what is going on would be very helpful…
Update: After updating to the most recent 2.17 version of the firmware, my switches are staying connected to the c8.
