Add window support (?)

[gdyr]

Added support for the "Window" accessory type - so that the Shelly 2.5 can present window actuators such as these to HomeKit as windows (but essentially just run in roller shutter mode).

No worries if you'd prefer not to implement it (or would prefer to do it a different way) but feel free to merge if it's of use!

I've pretty much taken the path of least resistance:

• Add a 5th system mode "Window"
• Add a 12th component type "kWindow"
• Add "w_avail" indication in the GetInfoExt JSON, though this is just fed by the same MGOS_SYS_CONFIG_HAVE_WC1
• Add shelly_hap_window.cpp and shelly_hap_window.hpp (copies of the window_covering files, but referencing kHAPServiceType_Window)
• Add new IID's and AID in shelly_common (still not sure what these are for, exactly)

Seems to work for me in HomeKit, though I don't have the actuator yet!

[timoschilling]

Please run make format and commit the result

[gdyr]

Done! Sorry about that

[rojer]

hi @gdyr , thank you for taking the time to do it.
i would like to first understand what is the practical difference, from the homekit standpoint, in having a Window vs Window Covering? just aesthetics, different tile?

second, if we are going to do it, we are definitely not going to do it by wholesale copy/paste of WindowCovering. we'll need to pull out common base and share bulk of the code.

[gdyr]

It is just the presentation of the tile, yep! Though this affects other things, e.g. if we ask Siri to “open the blinds” then that wouldn’t apply to a window but would apply to a window covering.

In our house we have both, so don’t want to open the window when we just want to open the blinds!

Happy to revise to deduplicate code.
What would your suggested approach be for doing so, in broad terms?

[rojer]

if it's just about the service type, then it may not even be necessary to create a separate mode. keep the roller-shutter mode, make HAP type a config parameter of shelly::hap::WindowCovering, and just use different constants at construction time.