* Collection of changing entity properties to class attributes
* Apply suggestions from code review
Co-authored-by: Erik Montnemery <erik@montnemery.com>
Co-authored-by: Erik Montnemery <erik@montnemery.com>
* A platform is not a component
* Fix dynalite
* SUPPORTED_PLATFORMS --> PLATFORMS
* In tests
* In tests 2
* Fix SmartThings
* Fix ZHA test
* Fix Z-Wave
* Revert Z-Wave
* Use PLATFORMS const in ambient_station
* Fix ihc comment
Currently, covers return "Lutron Integration ID" as a state attribute. This is inconsistent with the light, switch, and binary_sensor which return "lutron_integration_id".
* Rename BinarySensorDevice to BinarySensorEntity
* Tweak
* Move deprecation warning to __new__, add test
* Move deprecation warning back to __init__
* Move deprecation warning to __init_subclass
* Add support for Lutron Keypad LEDs
* Removed unneeded attribute definitions
* Pull initial state from Lutron on startup
* Format updates per code review
* Altered caching code to only fetch state if needed
* Update homeassistant/components/lutron/switch.py
Co-Authored-By: Martin Hjelmare <marhje52@gmail.com>
* Cloud pylint is also offended by this ;)
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Use f-strings in integrations starting with "H"
* Use f-strings in integrations starting with "I"
* Use f-strings in integrations starting with "J"
* Use f-strings in integrations starting with "K"
* Use f-strings in integrations starting with "L"
* Fix lint error
* Use join instead of f-string in homekit_controller
* Use local variables with f-strings
* Fix lint error
* Escape the characters in f-string
* Sort imports with isort in homeworks light
* Fix pylint error
* Fix broken tests
* Fix broken tests v2
* removed a nesting level
* Lutron Pico fix
* Reverted logging change
Was unaware that f-strings aren't used in logging commands, reverted the usage
* Reverted logging change
Was unaware that f-strings aren't used in logging commands, reverted the usage
* fixed logic
We only want to force a query if we don't have any previous state.
Otherwise, we should be tracking the state via continuous status
updates.
For lights (not switches) the extra query was also superfluous since
it was already querying on startup.
We should probably have a timeout on that so at some point we'll
requery in case remote end disconnected/rebooted, etc. Leaving for
another PR.
* pylutron PyPI update
We've been working with the original maintainer of pylutron, and they've published an update to PyPI to support a couple different things: homeowner keypads, main repeater keypads
* added requirements