* osram lightify removed duplicated set in case of brightness changes
* lightify component: anticipate brightness evaluation to handle unconsidered scenario described in the PR request comments (light turned on with color/temperature)
* Correction for travis ci error:
undefined name 'transition'
* Added effects to Yeelight bulbs
* Fix Typo and Use randint instead of randrange
* Added Effects
* updated requirements_all.txt
* fix empty line
* minor fixes
* fix passing effects as parameter
* starting light template component
* linting/flaking
* starting unit tests from copypasta
* working on unit testing
* forgot to commit the test
* wrapped up unit testing
* adding remote back
* updates post running tox
* Revert "adding remote back"
This reverts commit 852c87ff9694dfc48e92b74fd9dbafbc164a2393.
* adding submodule back from origin
* updating submodule
* removing a line to commit
* re-adding line
* trying to update line endings
* trying to fix line endings
* trying a different approach
* making requested changes, need to fix tests
* flaking
* union rather than intersect; makes a big difference
* more tests passing, not sure why this one's failing
* got it working
* most of the requested changes
* hopefully done now
* sets; the more you know
The product type is already established in order to decide the Kelvin range
so just reuse that information to disable color features for white-only lights.
Also change the breathe/pulse effects to be more useful for white-only
bulbs. For consistency, color bulbs set to a desaturated (i.e. white-ish)
color get the same default treatment as white-only bulbs.
* Refactor color profiles to a class
* Refactor into preprocess_turn_on_alternatives
* LIFX: use light.preprocess_turn_on_alternatives
This avoids the color_name duplication and gains support for profile.
* Add kelvin parameter to light.turn_on
* Add brightness_pct parameter to light.turn_on
* LIFX: accept brightness_pct in effects
* Add test of kelvin/brightness_pct conversions
* Move service helpers to LifxManager
* Add lifx_set_color
This is a synonym for light.turn_on except it does not actually turn on the
light unless asked to.
Thus, turn_on can be implemented just by asking.
* Rename set_color to set_state
* Support power=False with lifx_set_state
* ps - do not install all dependencies
* Comment out blinkt because it depends on GPIO
* Add pip upgrade check back
* Disable import error blinkt
* Update comment
* Fix comment
The hue is now a float but the hsbk conversion still believed it to be
an integer that could not be larger than 359. The float can in fact be,
for example, 359.9 and this would cause an out-of-bounds error in the
set_color call.
For completeness, the initial hue is also changed to a float.
Recent aiolifx allow sending messages to unregistered devices (as a
no-op). This is handy because bulbs can disappear anytime we yield and
constantly testing for availability is both error-prone and annoying.
So keep the aiolifx device around until a new one registers on the same
mac_addr.
* Added osramlighrify groups.
Allows you to make use of the build in osram lightify groups. Group states get
handeled similar as in the case of phillips hue. A lightify group shows up as
light in the homeassistant webinterface. If one light of the
group is on, the complete group is considered to be on.
To use this feature, first define some groups within your lighrify bridge, then
set add `allow_lightify_groups=true` to you osramlightify config.
It might look like:
````yaml
- platform: osramlightify
host: IP-ADDRES
allow_lightify_groups: true
```
* Fixed Pylint errors.
* Included requests.
* Included more requests.
* Fixed setup bridge and removed _light attribute.
* Update osramlightify.py
Forcing a refresh will log a warning if the periodic async_update happens
to be running already.
So let's do the refresh locally and remove the force_refresh.
State restoration takes up to a second because bulbs can be slow to react.
During this time an effect could keep running, overwriting the state that we
were trying to restore.
Now the effect forgets the light immediately and it thus avoids further
changes while the restored state settles.
This clears the internal cache in case polling picked up the state as set by
an effect.
For example, aborting an effect by selecting a new brightness could keep a
color set by the effect.
This allows for more of a disco mode where lights change so fast that you
actually notice it.
Also change the valid period to the maximum 20 msgs/sec that LIFX bulbs
can handle.
First, move the default away from turn_on so we do not have to test for
the current service.
Next, change the default color away from random. The new default is that
saturated colors will flash white and desatured colors will flash to their
fully satured color. Always with full brightness.
After many experiments, this was the method that best produced results that
are both visually pleasing and always noticeable as a flash.
* light.sensehat: adding plugin to control the 8x8 LED matrix on a Sense Hat
* add new .coveragerc entry
* light.sensehat: formatting and removing unused import
* light.sensehat: add to requirements list
* light.sensehat: update docstrings to the linter's specs
* light.sensehat: add a bit more docstring
* Remove global limit on white light temperature
Here are the supported temperatures of some popular bulbs:
Philips Hue: 2000K-6500K (the current 500-154 mired range)
LIFX Color 1000: 2500K-9000K
IKEA TRÅDFRI: 2200K, 2700K, 4000K
Obviously, Home Assistant cannot enforce a global limit and work properly
with all of these bulbs. So just remove the limit and leave it up to each
platform to work it out.
This commit updates the existing users and adds a clamp to Hue (where the
limit appears to have originated). It does not attempt to update other
platforms that might need extra handling of the larger range that is now
possible.
* Add min_mireds/max_mireds state attributes to lights
* Support min_mireds/max_mireds with LIFX lights
