Security is always the excuse, but it's a local device connected to Wifi. Add a setting to the existing menus that is opt in to turn on the new API.
Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.
For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.
Beyond that, there's what, like 4 or 5 parameters that are useful to set, and a few that can be read. It wouldn't be necessary to over engineer the API, even a few simple, fixed TCP packets to query state and set the basic parameters like mode, fan, room and set temp would be all that is needed. It can be ugly and basic, just release the info and other devs would run with it.
For example, the older TPLink Kasa line of smart devices have a simple TCP packet protocol for local control. The 'security' was easily reverse engineered (simple key autokey cipher), but there wasn't any outrage. Their simple scheme that wasn't meant to be widely known meant it was possible for others to build the integrations.
https://www.softscheck.com/en/blog/tp-link-reverse-engineeri...