* Refactor zwave discovery to entity schema
* Address PR concerns
* Split DISCOVERY_SCHEMAS into separate file
* Only check cover reverse workaround once
* Fix colortemp conversion for osramlightify
Copied from the LIFX fix in 75df4be733.
* Fix style
* Updates from review
@armills:
While we're doing cleanup here, can you just change self._brightness,
self._rgb, self._name, self._temperature, and self._state assignments in
__init__ to None? These will get overwritten when self.update() is called, so
it's safer/cleaner to initialize them to None since it shouldn't matter if
everything is working.
This increases the global limit to 6535 seconds (1h48m55s) because that is
supported by all light platforms.
Some platforms support even longer transition times so the limit should
actually be platform specific.
* Add effect support to MQTT Light
* Use effect state topic for supported_features
* Dont use rainbow as default color
* Add color_temp support to MQTT JSON Light
* Add effect to MQTT JSON light
* Support lights in MQTT discovery
* Allow discovered devices to set their platform
* Add white value support to MQTT Light
* Add white value support to MQTT JSON Light
* Remove blank line
* Add color_temp support to MQTT Template light
* Add white value support to MQTT Template Light
* Remove unused SUPPORT_MQTT_TEMPLATE and stale unused flash and transition code from MQTT Template
* Add XY Color to MQTT Light Platform
* Fix syntax
* Fix more syntax errors
* Revert "Remove unused SUPPORT_MQTT_TEMPLATE and stale unused flash and transition code from MQTT Template"
This reverts commit c03798cb63.
* MQTT Template supports flash and transition but doesnt allow templating of the values
* Add XY color support to MQTT JSON
* Proper variable names
* Only allow whitelisted MQTT platforms to be loaded via MQTT Discovery
* Minor tweaks.
A LIFX bulb maintains its previous color even when the light is off.
For example, if the previous color is blue and the bulb is turned on
and then set to a red color, it will transition through purple colors.
After this commit, the target color is set while the bulb is still
turned off. This overrides the previous color and brightness that the
bulb remembered. The light is then turned on with the requested
transition duration.
For the example, this gives the expected result of only going through
red colors.
* Make zwave devices listen on less network changes.
* Convert more platforms
* Remove printouts.
* Fix copy-paste
* Change default dependent list to empty list
* Fix for OSRAM lights connected to hue bridge
Do not send command "effect = none" to OSRAM lights
Osram lights connected to a hue bridge do not seem to handle "effect =
none" very well. Most of the times they jump to the selected color and
then change to red within a second.
Osram lights connected to a hue bridge do not handle xy values outside
of their gamut. Since they just stay at their old color value, handling
the UI is very unpredictable. Sending HSV values to the lights fixes this.
* Add tests for new util methods
* Create zwave devices on OZW thread and only add them during discovery.
* Read and write devices dict from loop thread.
* More async
* replace callback with coroutine
* import common function instead of callin git
* Connect to PLM and process simple protocol callbacks
* Baseline commit
* Connect to PLM and process simple protocol callbacks
* Baseline commit
* Connection working again
* Async add devices is working via callback now
* Beginning to interface with PLM library for control and state
* Deal with brightness in 255 levels with library
* Change sub names to match API changes
* Remove PLM-level update callback
* Support dimmable based on underlying PLM device attributes
* Expand to non-light platforms
* Stubs for turn on and off
* Current version of Python library
* Amend to use switch device attributes
* Use asyncio endpoints for control
* Add logging line
* Bump module version to 0.7.1
* Auto-load platforms, display device info/attributes
* Unify method name for getting a device attribute
* Require Current version of insteonplm module
* Import the component function in each platform in the balloob-recommend manner
* For consistency, handle switch state as onlevel just like lights
* Use level 0xff for on state, even with binary switches
Observing the behavior of a 2477S switch, it looks like even the non-dimmable
devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on
previously, but that yields unnecessary state change callbacks when message
traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff.
* Use sensorstate attribute for sensor onoff
* Move new device callback to devices attribute
* Add support for platform override on a device
* Bump version of insteonplm module
* Default overrides is an empty list
* Avoid calling private methods when doing common attributes
* Remove unused CONF_DEBUG for now
* flake8 and pylint code cleanup
* Move get_component to local function where it is needed
* Update to include insteonplm module.
* New files for insteon_plm component
* Legitimate class doctring instead of stub
* Docstring changes.
* Style changes as requested by @SEJeff
* Changes requested by @pvizeli
* Add @callback decorator to callback functions
* Opportunistic platform loading triggered by qualifying device detection
Instead of loading all the constituent platforms that comprise the insteon_plm
component, instead we defer and wait until we receive a callback for a device
that requires the platform.
* Restore states
* feedback
* Remove component move into recorder
* space
* helper
* Address my own comments
* Improve test coverage
* Add test for light restore state
* First round of not using values directly
* Round two
* lint
* Round four
* Conflict
* Round five
* Update zwave.py
* round six
* Docstring
* flakywakie
* Fetch values in constructor
* Blank line removal
* Set attributes in callback
* Docstring
* Round seven
* Ughgit add homeassistant/components/lock/zwave.py!
* Sloppy code
