* Add basic typing to emulated_hue
* type a few more places
* fixes
* numbers are always stringified
* numbers are always stringified
* coverage
* drop assert
* Enable setting XY color and transition time by client
* New test for setting XY color value
* Correct block outdent
* New test for setting transition time value
* Fixed commented out code
Prior 0.113 all lights and switches were reported as dimmable devices and this was fixed by #37978.
However, under some circumstances Alexa will not smoothly transition from those broken devices to the new ones as it cache the list of entities.
It is imperative to have Alexa rediscover all devices and then remove the now non-responding duplicates using the Alexa phone App. This can take quite a while if you have lots of devices.
An alternative would be to log to the Alexa web site and remove all the lights instead and then re-discover them all.
If you have multiple echo devices on your network, it is possible that the entries would continue to show as duplicates. This is due to an individual echo devices caching the old list and re-using it.
The only known solution for this is to remove your echo devices from your Amazon account and re-add them.
After that, have Alexa rediscover all your devices.
This is a one-off requirement.
Fixes#39503
* Wait for the state of the entity to actually change before resolving PUT request
Additionally, we cache the entity's properties for up to two seconds for the successive GET state request
When Alexa issues a command to a Hue hub; it immediately queries the hub for the entity's state to confirm if the command was successful.
It expects the state to be effective immediately after the PUT request has been completed.
There may be a delay for the new state to actually be active, this is particularly obvious when using group lights.
This leads Alexa to report that the light had an error.
So we wait for the state of the entity to actually change before responding to the PUT request.
Due to rounding issue when converting the HA range (0..255) to Hue range (1..254) we now cache the state sets by Alexa and return those cached values for up to two seconds so that Alexa gets the same value as it originally set.
Fixes#38446
* Add new tests verifying emulated_hue behaviour.
* Increase code test coverage.
The remaining uncovered lines can't be tested as they mostly check that the hass framework or the http server properly work.
This commit doesn't attempt to fix exposed issues as it would be out of scope ; it merely create the tests to exercise the whole code.
* Update homeassistant/components/emulated_hue/hue_api.py
* Add test for state change wait timeout
* Preserve the cache long enough for groups to change
* Update tests/components/emulated_hue/test_hue_api.py
Co-authored-by: J. Nick Koston <nick@koston.org>
This issue has been corrected and then reverted multiple times.
It seems that the core issue was a casing one (On/off vs On/Off) ; for better
matching with a real Hue hub, also add the productname.
Tested to work with echo 2 and echo 5.
Since we now base all of exposure checks on data that
will not change, we can cache the result instead
of calculating it every loop.
This change complements the work done in #32718
* Make emulated hue detectable by Busch-Jaeger free@home SysAP
* Emulated hue: Remove unnecessary host line from UPnP response
* Test that external IPs are blocked for config route
* Add another test for unauthorized users
* Change hue username to nouser
nouser seems to be used by the official Hue Bridge v1 Android app and is
used by other projects as well
Co-authored-by: J. Nick Koston <nick@koston.org>
* Return emulated hue id for update requests
* Emulated Hue: Rename function argument to match its content
* Use HTTP status consts throughout the test
* Use HTTP status consts in UPnP test
* Fix emulated_hue brightness off by one
Hue uses a max brightness of 254, Home Assistant
uses a max brightness of 255. Values > 127 were
off by one.
* use constant
* fix test
* add debug
* Revert "add debug"
This reverts commit 242220a02e.