this helps to auto-configure if the binding is providing the necessary info
metadata config still overrides
Signed-off-by: Cody Cutrer <cody@cutrer.us>
this is a theme, and I've extracted a helper method and applied it to several
other locations as well
example, I have a double-sliding door, with two contact sensors
in the alarm system, defined as:
```
Group:Contact:AND(CLOSED,OPEN) DeckDoor_Contact "Deck Door [%s]" <door> (gExteriorDoors, gWarningVisibility_Contact, gDoor, lMainFloor, gInflux) { homekit="ContactSensor" [instance=2] }
Contact DeckNDoor_Contact "Deck Door North" <door> (gInflux, DeckDoor_Contact, gGreatContacts) { channel="dscalarm:zone:46c52f35:zone11:zone_status" }
Switch DeckNDoor_Tamper "Deck Door North Tamper [%s]" <warning> (gTamper, gWarningVisibility_Switch) { channel="dscalarm:zone:46c52f35:zone11:zone_tamper" }
Contact DeckSDoor_Contact "Deck Door South" <door> (gInflux, DeckDoor_Contact, gGreatContacts) { channel="dscalarm:zone:46c52f35:zone12:zone_status" }
Switch DeckSDoor_Tamper "Deck Door South Tamper [%s]" <warning> (gTamper, gWarningVisibility_Switch) { channel="dscalarm:zone:46c52f35:zone12:zone_tamper" }
```
This allows the Group:Contact to be used for the ContactSensor.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
given:
```
Group eThermostat { homekit="Thermostat" }
Number:Temperature Thermostat_AmbTemp (eThermostat) { homekit="CurrentTemperature" }
Number:Temperature Thermostat_SetTemp (eThermostat) { homekit="TargetTemperature" }
Group gThermostatZoneContacts
// in reality there are multiple thermostats and multiple of these groups,
// so that a rule on members of gThermostatZoneContacts can find the related
// thermostat to turn it off when a window is open
Group:Contact:OR(OPEN,CLOSED) gWindows (eThermostat, gThermostatZoneContacts)
Contact Window_Contact (gWindows) { homekit="ContactSensor" }
```
When constructing the Thermostat accessory for eThermostat, detects the
Window_Contact as a mandatory characteristic, because it's a base accessory
in a nested group. This leads to lots of warnings about the temperature
value of a contact item being out of range.
The fix is two-fold - first of all, there's no reason to search nested
groups for characteristics of a complex accessory. Second of all,
even if for some reason you were to nest an accessory in an accessory,
the nested accessory does not actually belong to the outer accessory,
so don't add it as a mandatory characteristic of the outer.
I suspect there's still one more bug, because AbstractHomekitAccessoryImpl.
getCharacteristic(HomekitCharacteristicType.CURRENT_TEMPERATURE) was
returning Window_Contact, which is only tagged as a ContactSensor. But
after fixing the above two bugs, it was no longer reproducible, and I
didn't continue digging.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
this is especially important if you use the same item for both
TargetTemperature and HeatingThresholdTemperature characteristics,
since the former was already doing unit conversion for min/max.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
if an Item associated with a temperature characteristic has a QuantityType
(of dimension Temperature) as its state, regardless of current unit,
use that to convert to celsius instead of any other configuration.
Note that this is only for supply values to HomeKit; commands coming from
HomeKit will still send a DecimalType with units according to the HomeKit-wide
useFahrenheit configuration.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* Add default translations for io add-ons
This makes the texts used by these add-ons translatable with Crowdin.
Signed-off-by: Wouter Born <github@maindrain.net>
Add support for setting TARGET_POSITION of Window Covering accessories from groups with a baseItem type
Closes#10812
Signed-off-by: Colin Keehan <github@colin.xyz>
