Refactor hub and move most of the functionality to the specific entity types

[tomer-w]

Right now, the only benefit (in my mind) of the single hub implementation and the 2-phase setup (create the config when entity is created and apply it to gpiod library when we start) is that it will create only one fd which we need to monitor for changes.
This also has the problem that we can lose state change for sensors from between the time we initialize the entity and till it is sent to gpiod and we start tracking changes.

Better design would be to interact with gpiod as the entity is created and then get fd per entity. Later in startup we would start monitoring all the fds but by then if there was any state change it will be just get queued on the fd and will process when startup finishes.

The down side of this approach would be that we might have few fds to monitor. I assume no more than 20 but I guess this depends on the HW and user setup.

@thecode, @jdeneef, I will be happy to get feedback if this change is considered a better approach.

[thecode]

Better design would be to interact with gpiod as the entity is created and then get fd per entity. Later in startup we would start monitoring all the fds but by then if there was any state change it will be just get queued on the fd and will process when startup finishes.

I agree this is a better approach, but note that IO setup should happen before creating the entity since you can't fail within an entity.

The down side of this approach would be that we might have few fds to monitor. I assume no more than 20 but I guess this depends on the HW and user setup.

I think this is acceptable

I would also consider checking if we can use Data update coordinator the benefits of using a coordinator is that you don't loose state changes, the coordinator holds the current data for all the entities and is responsible for calling the entity update method upon changes. In addition it makes sure you are not left with an orphan event in case the entity is disabled.