Version 4.0 - Move to DataUpdateCoordinator and @property getters.

[scottyphillips]

The DataUpdateCoordinator model centralizes polling, for our application the preexisting ECHONETConnector class is ideal.

I have started a new branch and I have refactored all entities to use the new DataUpdateCoordinator design pattern.
The big benefit is that it reduces contention, a single Echonetlite Instance is polled at a predictable 30 second interval by the coordinator, which then automatically updates all the entities that rely on data. The same goes for push notifications - as soon as they arrive any sensors that ingest that data will be updated automatically.

I have also updated all entities to use @Property values for returning data; this means as soon as there is new data, whether by polling or by push notifications, Home Assistant should update them in real time. No more stale copies of data being stored here and there, the coordinators job is to look after all that data.

https://developers.home-assistant.io/docs/integration_fetching_data#coordinated-single-api-poll-for-data-for-all-entities

• All polling per Echonet entity is now centralized to the connector. Thanks to @nao-pon it was easy to maintain the push notification framework, so sensors continue to update in near real time if they are supported by notifications.
• Update Cover, Fan, Light, Select, Switch, Time, Binary Sensor -> remove async_update() and callbacks from all entities
• Provide proper @Property methods as necessary.
• Complex transformations (eg JSON derived sensors that use "dict_key" or "lambda") use _handle_coordinator_update(self)
• improved error handling for availability tracking of instances.
• Test Light Entity (NOTE: Partially tested with Moekaden Room emulator)
• Test Number Entity
• Test Cover Entity (NOTE: Partially tested with Moekaden Room emulator)
• Test Time Entity
• Stretch goal - create a base entity structure to standardize device attributes such as name etc.

If you would like to help out with testing that would be much appreciated!
My goal is to merge and release within the next 2-3 weeks as a beta release.

[nao-pon]

@scottyphillips One case where immediate polling is necessary is when a request is sent and the state that needs updating on the HA UI is not available via push.

I haven't looked at this source code recently, so I can't answer immediately, but I recall something like that happening.

[scottyphillips]

@nao-pon I dont get a lot of notifications with my HVAC, but what has worked well is that ECHONETConnector was always coordinating that push role with the entities to begin with (thanks to you!!! 🥇 ) When I refactored, I updated the logic so that now ANY relevant notification will automatically update the state of All entities that belong to a particular Echonet instance, we don't need the chain of callbacks, or the complex _is_polled() / _is_push() logic anymore! So, I have managed to cut a lot of unneeded code out of the custom component as a result.

[scottyphillips]

I have partially tested Light and Cover entities for basic operation with Moekaden Room emulator.