* Ensure camera stream can be restarted after failure
* If ffmpeg failed to start, was killed, or the iOS device
closed the stream right away, the stream could never
be started until the HomeKit bridge was restarted.
* watch ffmpeg instead of checking only once
* handle forceful shutdowns gracefully
* Increase coverage
* Homekit cameras - Add codecs support
* Add valid_codecs + move audio application parameter
* Increase video bufsize
* Increase audio bufsize
* Update config flow to be aware of the copy option
* Add tests for copy video and audio codec
* remove unused from test
* remove unused from test
Co-authored-by: J. Nick Koston <nick@koston.org>
* Add homekit camera support
* Cleanup pyhapcamera inheritance
* Add camera to homekit manifest
* Use upstream pyhap server handler in homekit
* Remove unused homekit constants
* Fix lint errors in homekit camera
* Update homekit camera log messages
* Black after conflict fixes
* More conflict fixes
* missing srtp
* Allow streaming retry when ffmpeg fails to connect
* Fix inherit of camera config, force kill ffmpeg on failure
* Fix audio (Home Assistant only comes with OPUS)
* Fix audio (Home Assistant only comes with OPUS)
* Add camera to the list of supported domains.
* add a test for camera creation
* Add a basic test (still needs more as its only at 44% cover)
* let super handle reconfigure_stream
* Remove scaling as it does not appear to be needed and causes artifacts
* Some more basic tests
* make sure no exceptions when finding the source from the entity
* make sure the bridge forwards get_snapshot
* restore full coverage to accessories.py
* revert usage of super for start/stop stream
* one more test
* more mocking
* Remove -tune zerolatency, disable reconfigure_stream
* Restore -tune zerolatency
Co-authored-by: John Carr <john.carr@unrouted.co.uk>
Co-authored-by: J. Nick Koston <nick@koston.org>
* Config flow for homekit
Allows multiple homekit bridges to run
HAP-python state is now stored at .storage/homekit.{entry_id}.state
aids is now stored at .storage/homekit.{entry_id}.aids
Overcomes 150 device limit by supporting
multiple bridges.
Name and port are now automatically allocated
to avoid conflicts which was one of the main
reasons pairing failed.
YAML configuration remains available in order to offer entity
specific configuration.
Entries created by config flow can add and remove
included domains and entities without having to restart
* Fix services as there are multiple now
* migrate in executor
* drop title from strings
* Update homeassistant/components/homekit/strings.json
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* Make auto_start advanced mode only, add coverage
* put back title
* more references
* delete port since manual config is no longer needed
Co-authored-by: Paulus Schoutsen <paulus@home-assistant.io>
* 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"
HomeAssistant Azure
Paulus Schoutsen
J. Nick Koston
stickpin
Greg Thornton
Jc2k
Knapoc
Ville Skyttä
springstan