Ramp tracking HUE is damn near impossible

[autoSteve]

Ramp tracking frequently gets lost. It does this because messages from the HUE event stream often do not arrive in a timely manner, hitting timeouts in the script for ignore HUE, and the final level messages. This will be because bulbs are sometimes lazy in reporting their current status to the bridge, and often VERY lazy.

If timeouts are increased, then doing one thing involving a CBus ramp, and then another that doesn't will likely result in unexpected behaviour.

For now I have no alternative but to disable ramping/transition of all my Hue devices, and turn my back on some quite complex tracking code.

For the future I hope to get my head around how I can solve this problem.

Do I treat CBus as authoratative, and update it for expected Hue events with a big timeout? If so, how do I know that a difference of opinion when a message fails to come in as and when expected isn't generated by something done in the Hue app or HomeAssistant?

Or implement a MQTT-style read/write semanic? Events received from Hue update the CBus GA without the script trying to publish that again to Hue? Yeah, that's what I'm doing already with the script, but in a different way.

Possibly do not use the HomeAssistant Hue integration, and avoid the app. That could work, using MQTT and discovery to publish, but would prohibit things that the app and HomeAssistant do well and CBus doesn't do, like colour temperature. (Or only do colour temperature in the app?) That and folks will obviously use the HA integration, because it's just better at things, has a massive ecosystem of diverse device support, and is usually the main game, unlike me where CBus/visualisation/DLTs are the main game, and HA is a nice-to-have-interface-to-haaaay-goooogle and to see how much fuel the car has on board...

There be dragons with Hue/CBus transition sync.

[autoSteve]

I've tried setting a pending end ramp timeout to 60 seconds. This goes okay so far, but is sub-optimal. The event stream really should be way more 'snappy' regading status updates, so I can only hope a future firmware update of devices or the bridge fixes this...

As a side note, Home Assistant will record a last level on as very low, or zero for Hue bulbs that are transitioned to off. This is sloppy programming by whomever wrote their Hue plugin, because they are remembering the last level of the last event stream message received, which may be varying to off over time. Turning a Hue light on in HA after a transition to off will not return it to its previous level... Does nobody else ramp/transition Hue lights??? I guess I am the only one, preferring my bedside lights to sigh off, not click off... So I NEVER use HA to turn these things on. I use CBus scenes to set the room to 'bed time' or 'sexy time' levels over time, and an 'all off', 'inside off' or 'room off' scene to turn off much stuff with ramps, including Hue devices.

[autoSteve]

I am done with many days looking at tracking Hue transitions.

Done.

Status updates appear on the event stream seemingly randomly. Sometimes so quick that the transition is not over and the bridge is reporting that it is, so I must end tracking, which is usually for short transitions. Or an update might drag itself across the line eight seconds after job done.

0555c73 limits the collateral damage. I've not observed ramp orphans yet, but have seen status updates often come through after the CBus ramp is done, leading to GAs that ramp to the target level by CBus, then after jump to a level in between, only to finally be updated to the target level some seconds later. It'll do. It'll never be perfect. Closing with a shrug.