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