@jeeftor I could use your help on this one... I THINK there's a double polling loop, and that that's leading to poor performance, but testing will require me to fork the HA component at least temporarily, and fixing it will involve a small intellifire4py API change, so I'm hoping to get your opinion first.
What I mean by a "double polling loop" is that I think HA is polling the cached data from intellifire4py (every X seconds), and that intellifire4py is polling the data from the cloud/local APIs and then caching it (every Y seconds). If that's true, then we could wait anywhere from almost 0seconds to X+Y seconds for updates. Plus of course we would have two coroutines when we only need one.
I think one polling loop is managed by https://github.com/home-assistant/core/blob/dev/homeassistant/components/intellifire/coordinator.py, according to https://developers.home-assistant.io/docs/integration_fetching_data/#coordinated-single-api-poll-for-data-for-all-entities. I think that means X=15 (https://github.com/home-assistant/core/blob/dev/homeassistant/components/intellifire/coordinator.py#L32).
I think the second pooling loop is managed by https://github.com/jeeftor/intellifire4py/blob/master/src/intellifire4py/local_api.py#L120 for example on the local API, so Y=15 as well (https://github.com/jeeftor/intellifire4py/blob/master/src/intellifire4py/local_api.py#L120).
This means updating the entities in HA after a command is sent could take anywhere from 0-ish seconds to 30-ish seconds.
If I'm correct, I would propose disabling the background polling in intellifire4py when used from HA. To do this I'd add a flag to the UnifiedFireplace constructor to optionally disable background polling, and I'd add a poll() method to UnifiedFireplace which then calls the appropriate poll() method on either local or cloud depending on the mode. This would allow the HA data update coordinator to disable intellifire4py's polling loop, and instead manually call UnifiedFireplace.poll() from within the IntellifireDataUpdateCoordinator which has its own loop. Basically following the example in https://developers.home-assistant.io/docs/integration_fetching_data#coordinated-single-api-poll-for-data-for-all-entities - where HA is responsible for polling the REST API, and the library doesn't have any background threads.
Overall, I think this will decrease the delay in fireplace entity updates in HA from 0-30seconds down to 0-15seconds. Does any of this make sense to you? If I don't hear from you, I'll probably try it out to see what happens, but considering the effort and the API change I'm hoping to get your opinion.
@jeeftor I could use your help on this one... I THINK there's a double polling loop, and that that's leading to poor performance, but testing will require me to fork the HA component at least temporarily, and fixing it will involve a small intellifire4py API change, so I'm hoping to get your opinion first.
What I mean by a "double polling loop" is that I think HA is polling the cached data from intellifire4py (every X seconds), and that intellifire4py is polling the data from the cloud/local APIs and then caching it (every Y seconds). If that's true, then we could wait anywhere from almost 0seconds to X+Y seconds for updates. Plus of course we would have two coroutines when we only need one.
I think one polling loop is managed by https://github.com/home-assistant/core/blob/dev/homeassistant/components/intellifire/coordinator.py, according to https://developers.home-assistant.io/docs/integration_fetching_data/#coordinated-single-api-poll-for-data-for-all-entities. I think that means X=15 (https://github.com/home-assistant/core/blob/dev/homeassistant/components/intellifire/coordinator.py#L32).
I think the second pooling loop is managed by https://github.com/jeeftor/intellifire4py/blob/master/src/intellifire4py/local_api.py#L120 for example on the local API, so Y=15 as well (https://github.com/jeeftor/intellifire4py/blob/master/src/intellifire4py/local_api.py#L120).
This means updating the entities in HA after a command is sent could take anywhere from 0-ish seconds to 30-ish seconds.
If I'm correct, I would propose disabling the background polling in intellifire4py when used from HA. To do this I'd add a flag to the UnifiedFireplace constructor to optionally disable background polling, and I'd add a poll() method to UnifiedFireplace which then calls the appropriate poll() method on either local or cloud depending on the mode. This would allow the HA data update coordinator to disable intellifire4py's polling loop, and instead manually call UnifiedFireplace.poll() from within the IntellifireDataUpdateCoordinator which has its own loop. Basically following the example in https://developers.home-assistant.io/docs/integration_fetching_data#coordinated-single-api-poll-for-data-for-all-entities - where HA is responsible for polling the REST API, and the library doesn't have any background threads.
Overall, I think this will decrease the delay in fireplace entity updates in HA from 0-30seconds down to 0-15seconds. Does any of this make sense to you? If I don't hear from you, I'll probably try it out to see what happens, but considering the effort and the API change I'm hoping to get your opinion.