* Declare missing connection attribute
* change mactts, marytts, and picotts to none for consistency
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
* [homekit] unify all enum handling
regardless of if it's a required or optional characteristic,
or even "boolean" enums
then allow number or switch items to be linked with enums
then update the docs listing the numeric value for enums
as part of this, global configuration of thermostat enum values
is no longer supported; you must use metadata.
in particular, for GarageDoorOpener, the global settings didn't
even actually work, so they should work now.
Fixes#13595
* [homekit] default-invert boolean items for garage door states
this was previously handled explicitly by the switch statement.
so need to set the inverted flag now that we're building a
mapping instead
* [homekit] document that CurrentDoorState can be linked to a Contact item
* [homekit] improve docs on invert param to createMapping
also fix a new helper method not properly passing through the inverted
param
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* New translations iCloud.properties (German)
* New translations miele.properties (German)
* New translations jruby.properties (German)
* New translations mqtt.properties (German)
* New translations influxdb.properties (German)
* New translations homekit.properties (German)
* New translations amazonechocontrol.properties (German)
* New translations amazonechocontrol.properties (German)
* [homekit] Implement IrrigationSystem
Fairly trivial now, except that a ServiceLabelService has to be added
to the accessory.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] TV accessory
Now possible since we support multiple secondary services. Just need to explicitly
declare that InputSource is a linked service to a Television, not just a secondary
service.
Note also that since TV and related services have so many mandatary characteristics
that are often static, I introduced a new way to declare characteristics -
via metadata on the service's item. Honestly, I feel like it's a lot cleaner to
have a factory create the mandatory characteristics the same way as the optional
characteristics, and then construct the service ourselves instead of basing the
service on the specific accessory interface. But this commit is already big enough,
I didn't want to go refactoring _all_ of the accessories to do it that way just
yet. This is why I have "unused" metadata characteristic factory methods for
AirQuality, HeaterCooler, and Thermostat - I started to make those configurable
via metadata, then realized they were mandatory characteristics that couldn't
be found from metadata via the current infrastructure.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] improve instance management
* allow addressing individual instances for most console commands
* don't restart all instances if simply adding/removing instances on
config change
* clear stored info when removing instances
* [homekit] reset instance identity when clearing pairings
* [homekit] log the actual interface we looked up
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] support Rollershutter items for HoldPosition
just send STOP to them
* [homekit] log a warning for incompatible HoldPosition items
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] allow configuring secondary services as members of a group
Required introduction of AccessoryGroup to represent the base
AccessoryInformationService for ease of configuring multiple of the
same service.
This is also "breaking" in that someone who previously had HomeKit
accessories nested directly inside of a group that was itself a
HomeKit accessory will now have those items grouped within the Home
app.
* [homekit] combine multiple readme sections on complex accessories
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] delay starting until a particular StartLevel
instead of a blind "delay by seconds", the new default won't even
attempt to start until items are loaded (both file-based and UI-based),
with an additional config to let the user delay it any further (in
case they have items coming from JSR223 scripts that can't run until
at least SL20 anyway).
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] add BasicFan accessory
This is Fan v1. It's a subset of FanV2, except that Home allows you
to customize the icon to show a ceiling fan.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
just the sub-commands.
since the show command is already a "search", I didn't feel it's super
important to implement on that
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] persist all known accessories, to prevent loss of homekit information
See the readme for more details, but basically this keeps track of every
accessory we've ever created, and if it no longer exists, presents a dummy
accessory instead. If the accessory comes back, nothing is lost in the Home
app; if you meant to prune it permanently, you have to run a console command.
there are also several fixes to prevent presenting the device with missing data -
such as when the bundle stops, _don't_ explicitly remove the accessories until
the server has stopped.
we also don't increment the configuration version unless the configuration
has _actually_ changed (so removing and re-adding the exact same thing
won't trigger the device to reconnect). this even works across restarts
of the bundle, because we're persisting all the accessory information
for dummy information anyway.
* [homekit] Address review comments for accessory persistence
* update hap-java to 2.0.4
* remove unused local variable
* [homekit] ensure accessories are replaced in a batch
so that HAP-Java can maintain subscriptions with the new objects
* [homekit] log individual dummy accessories up to 5
* [homekit] Tweak readme for dummy accessories slightly.
* Be consistent with proper usage of useDummyAccessories.
* Make the sentence more clear about the effects of having dummy accessories.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
otherwise if your step is 1.0 in fahrenheit, then your
values will get rounded to 1.0 celsius, and you might not
even notice you've lost precision in the Home app.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] increase flexibility of ColorTemperature
allow Number or Dimmer items, and mired or Kelvin units.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] Improve output of console's `homekit show` command
* include the full JSON from all the characteristics, so you can confirm
everything is configured correctly.
* only use simple class names; the fully qualified package is just a
distraction.
* show linked services if they exist
* include the class name of services, not just the GUID
Signed-off-by: Cody Cutrer <cody@cutrer.us>
If you have many instances, it can take a while. So stop all the
instances in parallel. Also, fix a race condition where the update
debouncer might get called again after being stopped, because the
change listener was deregistered _after_ the debouncer was stopped.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] fix BooleanItemReader to work with DimmerItems
DimmerItems have a PercentType state, which is easily convertible
to OnOffType, but is not inherited from it. So take that into account.
i.e. a variable speed fan can use a single DimmerItem for both
ActiveStatus and RotationSpeed.
* [homekit] Document that Dimmer is a possible item type for several booleans
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* [homekit] allow configuring maxValue on VOCDensity
the default of 1000 is quite low in reality. tested and confirmed
working with iOS 16
* [homekit] allow step value to be configured for VOCDensity
Signed-off-by: Cody Cutrer <cody@cutrer.us>
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>
