What's the objective/roadmap for this library?

[Rjevski]

Hello,

I've recently been working on improving the CoolMasterNet integration in Home Assistant and long story short ended up rewriting this entire library pretty much entirely.

The new version supports more features (serial comms in addition to TCP, and REST is planned too), better error/exception handling and support for a device hierarchy (CoolPlugs act as intermediary CoolMasterNet devices and can be sent commands via the main CoolLinkHub or CoolMasterNet) is planned too once I figure out a good data model for it.

It does however complicate the library significantly and is definitely a breaking change, so I was wondering whether you have any guidelines or plan for this library in mind - maybe you want to keep it as-is and keep changes to a minimum, and in which case I'm better off keeping it as a separate fork?

I have committed my current work to my fork - here's the diff as of now: master...Rjevski:master

[OnFreund]

Thanks @Rjevski. That's quite a diff and I don't see myself reviewing it in the foreseeable future. If it provides major benefits, and is relatively easy to adapt the HA integration to I'm happy to review the HA integration PR.

[Rjevski]

I will make more changes to this in the coming weeks. I think my initial approach of putting too much stuff in the Gateway class is flawed and introduces unnecessary complexity for users who just want to send raw commands to the Coolmasternet device. Instead, the plan would be as follows: * A Gateway class (initialized with a Transport) will just have methods to send commands to the gateway. That's more or less how the current library works. It will be stateless, and if all you need is to send commands to a device by UID you can use that, simplifying development. * A new Topology (or Network) class taking a gateway that will have more logic to infer the topology of the Coolmasternet network including support for multiple devices such as CoolPlugs (which have their own command-line interface and can be sent commands by proxying them through the main CoolLinkHub gateway). That one will be stateful and will cache certain stuff like device settings/properties for improved response times. The new Topology class will have most of the logic to infer the topology and discover devices as well as their metadata, such as being able to tell the device manufacturer - this is useful for populating the Home Assistant UI with the manufacturer name and set proper limits such as temperature range (Mitsubishi Electric only allows 18-28C on heating mode for example). Regarding the Home Assistant integration specifically, I don't see any major difficulty there - I already have an updated version of the HA integration locally that works with the current state of this library in my repo. It adds some new features such as displaying/clearing air filter state (for units that support it), providing current ambient temperature to the units (useful if your HVAC thermostat is in the wrong place and you have a better-placed one controlled by Home Assistant) as well as discovering unit capabilities based on Coolmasternet "properties" (CM is unable to discover unit capabilities by itself, however you can manually tell it which unit supports what - I think it's better to do this once at the source rather than having it configured at the Home Assistant level, and it means initially configuring the integration in HA is a matter of providing a hostname/port and all units and their capabilities will be autodiscovered).

…

On 15 Dec 2021, at 09:37, On Freund ***@***.***> wrote: Thanks @Rjevski. That's quite a diff and I don't see myself reviewing it in the foreseeable future. If it provides major benefits, and is relatively easy to adapt the HA integration to I'm happy to review the HA integration PR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.