* Display a QR code for homekit pairing
This will reduce the failure rate with HomeKit
pairing because there is less chance of entry
error.
* Add coverage
* Test that the qr code is created
* I cannot spell
* Update homeassistant/components/homekit/__init__.py
Co-Authored-By: Paulus Schoutsen <paulus@home-assistant.io>
* Update homeassistant/components/homekit/__init__.py
Co-Authored-By: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* HomeKit: Store generated aid against unique_id where possible
* Fix conflict
* Fix max accessories check
* homekit counts the bridge as an accessory
* Add coverage for aidmanager
* prepare for merge
Co-authored-by: J. Nick Koston <nick@koston.org>
* Prevent a single accessory setup failure from breaking all HomeKit accessories
Raise the max devices to 150 as the spec allows for this
many. Previously 100 made sense because of the event
storms when homekit started would sometimes break pairing,
as these have largely been fixed in 0.109 (still a few
to cleanup) using the HAP spec limit of 150 is now possible.
* Handle both failure states
* Convert homekit fans to use service callbacks
* Convert homekit fans to use service callbacks
Service callbacks allow us ensure that we call
fan services in the correct order.
* Avoid calling turn_on if a speed is sent and the device is on
* Fix test to not leave files behind
* Fix test
* Update homeassistant/components/homekit/type_fans.py
Co-Authored-By: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Set homekit alarm/sensor/switch state as soon as possible
This change is part of a multi-part effort to fix the
HomeKit event storms on startup.
Previously we would set the states after HomeKit
had started up which meant that when the controller
client connected it would request the states and get
a list of default states so all the initial states
would always be wrong. The defaults states generally went
unnoticed because we set the state of each HomeKit device
soon after which would result in an event storm in the log
that looked like the following for every client and every
device:
Sending event to client: ('192.168.x.x', 58410)
Sending event to client: ('192.168.x.x', 53399)
Sending event to client: ('192.168.x.x', 53399)
To solve this, we now set the state right away when we
create the entity in HomeKit, so it is correct on
initial sync, which avoids the event storm. Additionally,
we now check all states values before sending an update
to HomeKit to ensure we do not send events when nothing
has changed.
* pylint
* Fix event storm in covers as well
* fix refactoring error in security system
* cover positions, now with constants
* Convert homekit thermostats to use service callbacks
Service callbacks allow us to get all the temperature
changes in one request so we can avoid all the
need to store state and debounce.
* remove excess debug
* Fix lock and light tests
* Ensure all code for Thermostats has coverage
* I am answering all the homekit cases anyways so might as well be aware of regressions
* Make lock notifications reliable
* Update homeassistant/components/homekit/type_lights.py
Co-Authored-By: Paulus Schoutsen <paulus@home-assistant.io>
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Fix reversed door closing/opening states in HomeKit
When we closed the door we would set state 2 which
is "Opening" it should have been 3 which is
"Closing"
When we opened the door we would set state 3 which
is "Closing" it should have been 2 which is
"Opening"
Add constants to make this easier to catch
in the future.
* Remove debug
* Add note about target door state
* Add homekit configuration option to bind to default interface
Homekit can fail to be discoverable because the
zeroconf default is to bind to all interfaces
(InterfaceChoice.All). This does not work
on some systems and (InterfaceChoice.Default) which
binds to 0.0.0.0 is needed for homekit to zeroconf
to function.
A new option is available for homekit
zeroconf_default_interface: true
* Update tests
* Update homeassistant/components/homekit/__init__.py
Co-Authored-By: springstan <46536646+springstan@users.noreply.github.com>
* Update homeassistant/components/homekit/__init__.py
Co-Authored-By: springstan <46536646+springstan@users.noreply.github.com>
* Review items
* has a default
* Revert "has a default"
This reverts commit 24ecf0920f.
Breaks the tests
Co-authored-by: springstan <46536646+springstan@users.noreply.github.com>
Home Assistant auto mode is described as
"The device is set to a schedule, learned behavior, AI."
HomeKit Accessory Protocol expects "heating or cooling to maintain
temperature within the heating and cooling threshold of the
target temperature"
Since HomeKit is expecting to set temperatures in this mode,
mapping homekit state 3 ("Auto") to Home Assistant HVAC_MODE_HEAT_COOL
is more inline with how Home Assistant defines HVAC_MODE_HEAT_COOL
as "The device supports heating/cooling to a range"
Homekit only has Off/Heat/Cool/Auto at this time, but
at least we can prevent the device from erroring
by mapping dry and fan to cool so it continues
to function.
* Switch homekit lights to use service callbacks
Service callbacks allow us to get the on/off, brightness, etc
all in one call so we remove all the complexity that was
previously needed to handle the out of sync states
We now get the on event and brightness event at the same time
which allows us to prevent lights from flashing up to 100%
before the requested brightness.
* Fix STATE_OFF -> STATE_ON,brightness:0
* Add HomeKit support for slat tilting
* Reset tilt-specific attribute, not position attribute
Co-Authored-By: J. Nick Koston <nick@koston.org>
* Add explanation why we fix HomeKit's targets
We have to assume that the device has worse precision than HomeKit. If it
reports back a state that is only _close_ to HK's requested state, we'll
"fix" what HomeKit requested so that it won't appear out of sync.
Co-authored-by: J. Nick Koston <nick@koston.org>
In PR#24804 the step size was changed to match the step size
of the device that HomeKit is controlling. Since HomeKit
is always working in TEMP_CELSIUS and the step size is based on
the Home Assistant units setting, we were mixing data with different
units of measure when Home Assistant was using imperial units.
This regression presented the symptom that setting the
temperature to 73F would result in 74F. Other values are affected
where the math doesn't happen to work out.
HomeKit currently has a default of 0.1 in the spec and the override
of this value has been removed.
* HomeKit: update position state characteristic for covers
position state is a mandatory characteristic for HK window coverings
* Test position state characteristic
* Move imports to top for homekit
* Moved back a couple imports, added annotation to disable import-outside-toplevel
* Fix all tests in test_homekit.py
* Limit available heat/cool modes for HomeKit thermostats.
The Home app only shows appropriate modes (heat/cool/auto) for the device. Depending on the climate integration, disabling the auto start might be needed.
* Include improved mapping for HVAC modes in tests
* Add options to specify advertised IP and MAC for HomeKit Bridge
This makes use of HAP-python's new feature in version 2.6.0
that allows to specify the mDNS advertised IP and MAC address.
This is a requirement for the following use cases:
- Running Home Assistant behind a NAT, e.g. inside Docker.
- Running it on a system with multiple interfaces there
the default IP address, DNS entry and hostname diverge.
The forwarding of the required mDNS packets can be done with
an avahi-daemon based gateway, e.g. by using enable-reflector=yes.
Specifying the MAC address makes it possible to identify an
accessory in case HA is run inside a ephemeral docker container.
Whitespace changes were performed due to black and flake8.
* Update tests for HomeKit Bridge due to IP and MAC advertising
Whitespace changes were performed due to black and flake8.
* Remove the possibility to set the MAC address of the HomeKit Bridge
Since the MAC address is a random device ID, there is no need
for the user to be able to set a custom MAC address value for it.
Whitespace changes were performed due to black and flake8.
* Fix homekit temperature sensor for round with one decimal
* Removing unnecesary operations
* Adapting tests for new temperature_to_homekit() result precision
