[Pull Request] Added capabilities to set myZone, use all constant zones and to handle a system with mix zones

[uswong]

---

name: Added capabilities to set myZone, use all constant zones and to handle a system with mix zones about: Add improvements to homebridge-cmd4-AdvantageAir. title: "[Pull Request]" labels: new features assignees: mitch7391

---

Added improvements to current cmd4-advantage plugin:

1. added capability to set myZone.
2. used all defined constant zones instead of using only the first constant zone.
3. added capability to handle correctly a system with a mixture of zones with and without temperature sensors.

Is your pull request related to a problem or a new feature? Please describe:

This pull request is to add improvements to the plugin.

Describe the solution you'd have implemented:

1. Modified AdvAir.sh to:

   • add a set of codes to read myZone from $myAirData and another set of codes to set myZone.

   • add a few line of codes to make myZone as priority, if it is defined, as temperature control for the Aircon system.

   • add a set of codes to scan through all constant zones and modified the logic such that at least the noOfConstants zones are opened at any one time to protect the Aircon system.

   • add logic such that if the zone to close is assigned as myZone, myZone will be re-assigned to another opened zone with temperature sensor before closing it. If the number of open zone is not more than noOfConstants or the opened zones are of noSensors zones, then a closed zone with temperature sensor will be opened (with priority to constant zones) and assigned it as myZone before closing the zone.

   • determine on-the-fly whether a zone is with or without temperature sensor so that a system with mixed zones can be handled correctly. Since the zone with or without sensor is determined on-the-fly directly from $myAirData, the myAirConstants.txt cache file is no longer required, hence the codes and the function related to the creation of myAirConstants.txt is removed from AdvAir.sh.

2. Modified ConfigCreator.sh to allow the generation of config for myZone "Switch" accessories.

3. Modified CheckConfig.js to allow the checking of myZone.

4. Modified server.js to allow the checking of myZone.

5. Modified AirConServer.js to allow the update to myZone.

6. All unit tests were modified to reflect the removal of the use myAirConstants.txt file and added a few unit tests to test for myZone and the use of all constant zones.

Do your changes pass local testing:

• [x] Yes

Additional context:

ConfigCreator.sh:

This new version of ConfigCreator.sh will generate additional config for myZone "Switch" accessories if myZone is defined.

myZone is defined if its value in $myAirData is not 0.

If myZone is defined, only those zones with temperature sensors will have a myZone "Switch" accessory. An example below shows all the 10 zones in this Aircon system has temperature sensors, hence there are 10 myZone "Switch" accessories.

You can set a zone to be myZone by pressing a myZone tile on Homekit. Note that you cannot unset a myZone but you can do so by setting a new myZone. There will be only one myZone allowed at any one time.

If the zone you set as myZone is a closed zone, it will be opened before assigning it as myZone.

Please note that myZone may not be avaliable to all system which has temperature sensors. myZone is an optional feature which AdvanatageAir system installer can set it up during installation.

New version of AdvAir.sh is 100% compatible with the existing cmd4 configuration file:

Despite the removal of myAirConstants.txt cache file, this new version of AdvAir.sh is still 100% compatible with the existing cmd4 configuration created manually or generated with the previous version of ConfigCreator.

However, if your system has temperature sensors and has myZone defined, then you need to re-run ConfigCreator in order to make the myZone "Switch" accessories availiable in Homekit.

[uswong]

Hey Mitch, you are right, I have the 'myZone' switches grouped together initially, but the homekit in IOS16 has all the switches assigned the same name as the first one. I guess that is a bug within Homekit with IOS16.

As such, in order to have each 'myZone' switch to have their own unique name, I have to make each 'myZone' a separate switch.

It works well for users who prefer the switches in a separate Homekit room called "myZone" as in my example. For users who would prefer to have all the 'myZone' switches in one homekit tile, they can easily group all those switches together within Homekit.

[mitch7391]

I think it might do that do to it acting like a 'linkedType', I am pretty sure if we were to force it from a config point of view we would make one of them the main switch (and hence why the name assigns across all of them) and the rest would be 'linkedType'. Just a guess but happy to leave it as is and let users decide how they would to use it :)

[uswong]

we were to force it from a config point of view we would make one of them the main switch (and hence why the name assigns across all of them) and the rest would be 'linkedType'.

That is exactly what happened in IOS16. All the accessories within the 'linkedType' adopt the name of the main one. It did not do that before I update to IOS16.

Many other accessories in my homekit which has mulitple swtches in one homekit tile has all the switches in it having the same name after the I updated to IOS16. So I have to rename each one painstakingly otherwise I won't know what function for each switch.

Please have a detail look into your "xiaomi roborock" homekit tile, you will find that all the switches in it are having the same name as the main one.