Weird issues since 2.2.5 update (Zigbee)

No for commands, but I use the "respond immediately" option.

However, Alexa TTS is noticeably slower to send notifications for some things - that said, it's only those that are sent by the HE "Notifications" app that have a significant delay. Manual tests of Alexa TTS are just as fast as they used to be.

I mentioned this before but I have a smartthings button in my office that I use to control some Sengled Bulbs in a few desk lamps. Lately after the latest firmware updates? it has been very slow to respond in the morning. Battery seems okay at 81%. Not sure if it is the bulbs or the button. Not using the advanced drivers. Just re-paired the button this morning to see if that helps. Things seem fine throughout the day just in the morning I seem to have these issues.

I have a "good night" routine in Alexa that shuts the lights down but this happens via the Maker API and not directly so don't think that is the cause.

My Zigbee devices are running on a C-5.

I hate to say it, but everything is back to normal on 2.2.4.158. The whole house has magically come back to life. I have had no issues whatsoever since reverting. Just so weird.

3 Likes

Glad it’s working again for you. I hate to say it, but I may end up reverting to the Generic rgbw driver. I like the Advanced driver, but I use mostly groups with zgm and scenes. This driver is causing unpredictable results with both due to it not updating the bulbs state when set by a group or scene. Plus, I don’t get the benefit of the settings the driver offers when using groups/scenes. The settings are completely ignored unless I use single lights.

1 Like

I see. It’s worth noting, I did not change to the advanced driver on a handful of bulbs until I was having issues for a while and couldn’t figure out what was going on so I tried the advanced driver.

2 Likes

I have about the same number of devices, and no child devices. I was surprised to see the routing table above with 20-something child devices.

1 Like

It would be interesting to look at the getChildandRoute info page now that things are working well and compare the Neighbor Table to the snapshot you took when things were flaky; the ones that show cost figures that are both non-zero and <7 are the ones that are actively participating in routing messages. Changes in those neighbor table devices (or their cost indexes) should correlate with signficant routing changes in your network, at least for the first-hop to/from the hub.

3 Likes

Here is a fresh one while things seem to be working great...

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

Child Data
child:[Kitchen Light 3, B84F, type:EMBER_END_DEVICE]
child:[Dining Room Hutch Light Left, 59EF, type:EMBER_END_DEVICE]
child:[Backyard Light, 2777, type:EMBER_END_DEVICE]
child:[Master Bathroom Sink Light Jacob 2, 0A5B, type:EMBER_END_DEVICE]
child:[Upper Hallway Light 1, 6617, type:EMBER_END_DEVICE]
child:[Master Bathroom Button, 82DD, type:EMBER_SLEEPY_END_DEVICE]
No information for Child 6
child:[Dining Room Table Light 3, 3EDC, type:EMBER_END_DEVICE]
child:[Dining Room Table Light 1, 3C8E, type:EMBER_END_DEVICE]
child:[Dining Room Table Light 4, BA0D, type:EMBER_END_DEVICE]
child:[Master Bathroom Sink Light Lisa 2, 5CC2, type:EMBER_END_DEVICE]
child:[Kitchen Button, 6628, type:EMBER_SLEEPY_END_DEVICE]
child:[Dining Room Table Light 5, 5BF3, type:EMBER_END_DEVICE]
child:[Dining Room Table Light 2, 69E2, type:EMBER_END_DEVICE]
child:[Dining Room Hallway Light 2, 07E6, type:EMBER_END_DEVICE]
child:[Dining Room Hallway Light 1, EC2A, type:EMBER_END_DEVICE]
child:[Dining Room Hutch Light Right, 2579, type:EMBER_END_DEVICE]
child:[Master Bathroom Sink Light Lisa 1, 96ED, type:EMBER_END_DEVICE]

Neighbor Table Entry
[Basement Hallway Routing Outlet, 0184], LQI:254, age:3, inCost:1, outCost:0
[Brennan’s Room Light Strip, 0720], LQI:210, age:7, inCost:5, outCost:0
[Fireplace Fan, 19BD], LQI:254, age:3, inCost:1, outCost:1
[Connor’s Room Christmas Lights, 1CA0], LQI:253, age:3, inCost:3, outCost:1
[Upper Hallway Routing Outlet, 235B], LQI:249, age:3, inCost:3, outCost:1
[Garage Front Routing Outlet, 635C], LQI:223, age:7, inCost:5, outCost:0
[Jacob’s Desk Routing Outlet, 7AB7], LQI:255, age:3, inCost:1, outCost:1
[Kitchen Routing Outlet, 968B], LQI:254, age:4, inCost:1, outCost:0
[Living Room Routing Outlet, 9869], LQI:250, age:3, inCost:3, outCost:0
[Garage Side Routing Outlet, CAAC], LQI:210, age:4, inCost:5, outCost:1
[Master Bedroom Heated Lotion, D13B], LQI:253, age:4, inCost:3, outCost:0
[Brennan’s Room Routing Outlet, D416], LQI:253, age:3, inCost:3, outCost:0
[Master Bedroom Routing Outlet, E1E0], LQI:232, age:5, inCost:5, outCost:1
[Ella’s Room Routing Outlet, ED24], LQI:238, age:5, inCost:5, outCost:1
[Basement Unfinished Workbench Light, F957], LQI:254, age:3, inCost:1, outCost:1

Route Table Entry
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Garage Door Lisa, 65D1] via [Jacob’s Desk Routing Outlet, 7AB7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Addison’s Room Motion Sensor, 16E5] via [Jacob’s Desk Routing Outlet, 7AB7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Ella's Closet Motion Sensor, DB41] via [Fireplace Fan, 19BD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Basement Kitchen Stairs Motion Sensor, BD32] via [Connor’s Room Christmas Lights, 1CA0]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Laundry Room Motion Sensor, 7951] via [Fireplace Fan, 19BD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Upper Hallway Thermostat, 421E] via [Fireplace Fan, 19BD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Office Desk Motion Sensor, 5DE8] via [Basement Unfinished Workbench Light, F957]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Garage Refrigerator, 8204] via [Jacob’s Desk Routing Outlet, 7AB7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Master Bedroom Closet Motion Sensor, FC27] via [Jacob’s Desk Routing Outlet, 7AB7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Garage Light 5, A5AE] via [Fireplace Fan, 19BD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Ella's Bathroom Motion Sensor, 1B01] via [Upper Hallway Routing Outlet, 235B]
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Master Bedroom Dimmer Switch, D786] via [Basement Unfinished Workbench Light, F957]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Back Hallway Light 3, DB29] via [Jacob’s Desk Routing Outlet, 7AB7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Kitchen Sink Light, EE87] via [Ella’s Room Routing Outlet, ED24]

The neighbor lists don't look much different (a couple more routers were being used in the 'before' configuration than the more recent one; a couple less devices are now showing as child devices of the hub meaning they found better parents elsewhere, assuming they aren't MIA). It's probably not possible to get much insight from just single 'before' and 'after' snapshots (a stable neighbor table implies a stable network, so keeping an eye on it periodically is a better way to judge).

Having said that, one thing that seems notable is that according to the previous route table entries, most of the route record requests (which indicate devices that are reachable 'via' a specific router) were handled by a single router (the 235B device) whereas in the later snapshot, three of the routers (19BD, 7AB7, and F957) were 'via's for more than one route entry.

But again, not having any feel for how stable the neighbor tables were before (or are now), there probably isn't too much that can concluded from this.

Thanks, Ken -- I was afraid it might be a polling thing.

I used to have additional devices set up (especially from when I was initially on Smartthings, and then when I was running a bridged system between Smartthings and HE), but I recently removed them as I'd become tired of constantly re-encountering "duplicate" devices that would confuse Alexa. Seems like I solved that problem at the expense of this one.

I wonder if it might just be worth upping the polling frequency. Do you know where I'd find that?

Thanks for this, dJOS. Where is this "respond immediately" option?

(Never mind -- found it here)

1 Like

Under Apps, "Amazon Echo Skill" and it's the second option under the list of devices exposed to Alexa.

Thanks -- checked, and it was already set (and it shouldn't really apply to Alexa-initiated actions anyway, I don't think?)

Can't seem to find "polling interval", though, per @Ken_Fraleigh (here) and @christiansandp (here)...

In the Hubitat "Apps", open the "Hue Bridge Integeration" app, then click OPTIONS.

Ah, thanks Dan -- had been looking at the device instead of the app.

Just installed CoCoHue, though, and I have to say it seems to be working brilliantly, updating the dashboards, device pages, and VRCZ4 LEDs instantly (even with default 1-minute polling).

1 Like

Both CoCoHue and the built-in Hue Bridge integration should update device states immediately if the change was made from Hubitat, as long as Hubitat hears back from the Bridge without an HTTP error; it's outside changes, like those made from the Hue app (or other integrations that use it, like Alexa), that may take up to the polling interval to be reflected in Hubitat. Of course, if the built-in app isn't doing one or both of those (I've seen some people mention that the latter doesn't work for them, even when configured appropriately), I can't help with that but could if it's CoCoHue. :slight_smile:

Right -- it was always the Alexa-driven changes that I was trying to address. CoCoHue seems to be updating those immediately on the HE side...although I just noticed that operating the Hue bulbs via the Hue app does not update HE through CoCoHue.

Will have to investigate further, and let you know what I find.

I’ve been using CoCoHue since Robert’s first version and it’s been great, especially importing scenes into Hubitat. Instead of increasing the polling frequency and thus the load on the hub, I just share the lights from HE to Alexa.

Again this won’t update until polled.

Understood...although it didn't even seem to update with polling? (Not sure why that would be, but there it is...)