[v3] Strongly Typed State Object for Devices [WIP]

[webdjoe]

Discussion on creating a state object to normalize state attributes across all devices. Device attribute will be frozen - ie cid, uuid, mac_address, model, device_type, config_module, pid, subdevice_no, etc.

I mapped my initial thoughts below, looking for feedback.

The state object should be strongly typed and consistent across all devices:

Base State Class

BaseState:
power_state -> bool (on True, off False)
connected_state -> bool (disconnected False, connected True)

Bulb State Class

brightness -> int (0-100)
color -> Color dataclass 

Outlet State Class

current_power -> int
current_volts -> int
history -> Historical Power Data class

[cdnninja]

Agreed on strong typing. I also would like to see a single list of dict of all devices vs split up by types. If interested in viewing one approach I have used in the past take a look at this: https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/blob/master/hyundai_kia_connect_api/Vehicle.py Someone else came up with the design. Each region has different cars etc. Vehicle only populates the data that car offers otherwise stays as none. It allows for easier HA data access since you just check if it exists.

From the command side we have this: https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/blob/master/hyundai_kia_connect_api/ApiImpl.py
with each region under it.

I wonder if easiest to turn this into 2.0 gradually or not? I am game to help support this effort. I am not sure how much we can keep this all from being a breaking change or not. Potentially could avoid it but don't know the code crazy well.

[cdnninja]

I am thinking on this have all devices in a single device list. Then define a class for each type not as vesync views it but from a functionality standpoint. An example would be humidifier, air purifier, etc. Under those classes we add specific classes for unique aspects to implement each. With the intent of the humidifier class defining how it should response for properties and methods. Even if not implemented. This would ensure integrations just confirm to say the humidifier class and all base features would work for all of this family.

Thoughts?