Closed trvrnrth closed 11 months ago
listening to event-based updates from ramses_rf which the DataUpdateCoordinator framework is not suited to
FYI: this is a long way away - lots of refactoring required.
listening to event-based updates from ramses_rf which the DataUpdateCoordinator framework is not suited to
FYI: this is a long way away - lots of refactoring required.
Yup. I wasn't imagining it would be happening any time soon. Just didn't want to lock the component into a paradigm that didn't really suit long-term.
Just didn't want to lock the component into a paradigm that didn't really suit long-term
I just had an idea that a co-ordinator was a pre-requisite for config flow?
Just didn't want to lock the component into a paradigm that didn't really suit long-term
I just had an idea that a co-ordinator was a pre-requisite for config flow?
Not that I'm aware of.
Beautiful.
Tidies up broker start and polling.
Removes redundant DataUpdateCoordinator as the broker already handles updates on an interval. This is more suited to a single API call that returns data and is intended for use with entities that extend
CoordinatorEntity
. Without such entities in place there are no listeners registered with the coordinator and it never does any polling. It seems like a better idea to stick with the existing broker setup as ideally in future it would be possible to transition to listening to event-based updates from ramses_rf which the DataUpdateCoordinator framework is not suited to.