I have a need to schedule a task in the HomeKit add-on: specifically, I need to ignore changes to garage door states that occur shortly after a change. HomeKit has a default notification for garage door open and close. At least for the binding I’m using, MyQ, setting the state to CLOSED starts a fast polling loop on the door. Since the poll then identifies the door as open for the length of time it takes to close, the state is then reset to OPEN. And later again to CLOSED. This results in three push notifications (Garage door is closed. Garage door is open. Garage door is closed).
There’s an argument that the binding should handle this better, but I expect it’s going to be a problem across most bindings - ESH doesn’t really have a concept of a “Target State” so the state gets overloaded for this purpose.
So, back to the topic - there’s an existing pool for thingHandler and discovery, neither of which apply to the HomeKit add-on. Is it acceptable to register a pool just for HomeKit? Should we add a third type of generic pool? @Kai
Doesn’t this mean that there is an incorrect state update that should be avoided, instead of ignored?
Is the state update triggered through the auto-update functionality? If so, the solution would be https://github.com/eclipse/smarthome/issues/595.
Is it acceptable to register a pool just for HomeKit? Should we add a third type of generic pool?
If there is no suitable pool defined yet, it is acceptable to register your own, yes. But I agree that we might want to introduce a “fallback” pool that can be used if no other dedicated pool is applicable. Where should we best define the name as a constant for this pool directly within the ThreadPoolManager?
Oh, I didn’t realize the auto-update functionality was anything other than the expected behavior. That solution you linked would certainly be better than any workaround I did on the subscriber end. I’ll just hold off on submitting the GarageDoor accessory tags.
