* create light.hue_activate_scene service
This creates a light.hue_activate_scene service that takes group_name
and scene_name, and calls phue's bridge.run_scene with those
parameters. This allows calling hue bridge stored scene names by name
during automation.
This only currently works reliably in 1 hue hub configurations (which
is most of them). Phue will be further enhanced to display warnings
when it can't figure out what to do with the parameters passed in to HA.
* Update hue.py
* Add keypress & output control services to Envisalink component
Add services to allow sending custom keypresses and activating
programmable outputs on an alarm control panel.
Implemented for the Envisalink alarm, and moving to new version of
pyenvisalink to support this.
Replicated the service handler mapping code from Cover component into
Alarm Control Panel to allow handling alternative schemas if required
by new services.
* Update requirements_all.txt
* Updated services.yaml
* Removed requirement to enter code in HA UI
Incorporated changes suggested by @sriram
https://github.com/srirams/home-assistant/commit/2f8deb70cb5f3621a69b6b9
acb72f8e29123650c
Including pending state for exit/entry delay
Clarified services to use the code passed to them as a first priority,
otherwise use the code from configuration
Swapped back to using NotImplementedError for the service definitions
* - Add support for alarm_keypress to manual alarm (functions like a standard alarm keypad where entering the code disarms or arms the alarm)
- Add tests for alarm_keypress to manual alarm
- Style corrections (too many returns, comment & whitespace issues)
* Removed alarm_output_control service as unable to incorporate in the demo/test in a meaningful way
* Add keypress & output control services to Envisalink component
Add services to allow sending custom keypresses and activating
programmable outputs on an alarm control panel.
Implemented for the Envisalink alarm, and moving to new version of
pyenvisalink to support this.
Replicated the service handler mapping code from Cover component into
Alarm Control Panel to allow handling alternative schemas if required
by new services.
* Update requirements_all.txt
* Updated services.yaml
* Removed requirement to enter code in HA UI
Incorporated changes suggested by @sriram
https://github.com/srirams/home-assistant/commit/2f8deb70cb5f3621a69b6b9
acb72f8e29123650c
Including pending state for exit/entry delay
Clarified services to use the code passed to them as a first priority,
otherwise use the code from configuration
Swapped back to using NotImplementedError for the service definitions
* - Add support for alarm_keypress to manual alarm (functions like a standard alarm keypad where entering the code disarms or arms the alarm)
- Add tests for alarm_keypress to manual alarm
- Style corrections (too many returns, comment & whitespace issues)
* Removed alarm_output_control service as unable to incorporate in the demo/test in a meaningful way
* Moved the Alarm_Keypress service into Envisalink component out of the generic
* Update envisalink.py
* Update services.yaml
* Migrate callbacks to use schedule_update_ha_state
* Migrate MQTT sensor callback to async
* Migrate wemo to not update inside schedule_update_ha_state
* Make MQTT switch async
* Fix nx584 test
* Migrate tellstick callback
* Migrate vera callback
* Alarm control panel - manual: use async callbacks
* Run the switch rest tests that work
This makes it so that media playback support for inputs is dynamically
fetched from the receiver, instead of assuming that all playback
commands work for all inputs.
Tests are added for this, using a FakeYamaha class, which has some
sample data stubbed in for key methods that need to be called. We also
include an example of the desc.xml needed to dynamically parse these
features for these tests (as this is done in platform init).
* Convert switch to AsnycIO
* Move update entity to service
* use time better for faster handling
* Change to suggestion from paulus
* Use new shedule_update_ha_state
* fix lint
* minimize executor calls
Occassionally the values of `keys` and `p256h` are bytes objects instead of
strings. As JSON by default does not serialize bytes objects let's decode
bytes objects to unicode strings.
Resolves the registration issue mentioned in #4012.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>
The linters really need to specify an exact version, because when
either flake8 or pylint release a new version, a whole lot of new
issues are caught, causing failures on the code unrelated to the
patches being pushed.
Pinning is a best practice for linters. This allows patches which move
forward the linter version to happen with any code fixes required for
it to pass.
Occassionally the values of `keys` and `p256h` are bytes objects instead of
strings. As JSON by default does not serialize bytes objects let's decode
bytes objects to unicode strings.
Resolves the registration issue mentioned in #4012.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>
* Use entity_id for backend, friendly name for frontend
Closes https://github.com/home-assistant/home-assistant/issues/3434
Command line switches had the option to set a `friendly_name` reportedly
for use in the front end. However, if set, it was also being used as the
`entity_id`.
This did not seem like obvious behavior to me. This PR changes the
behavior so the entity_id is the object_id, which must already be
unique, and is an obvious place to have a very predictable slug (even if
long or unsightly), and the friendly name (if set) is used for the
display.
Example:
```yaml
switch:
platform: command_line
switches:
rf_kitchen_light_one:
command_on: switch_command on kitchen
command_off: switch_command off kitchen
command_state: query_command kitchen
value_template: '{{ value == "online" }}'
friendly_name: "Beautiful bright kitchen light!"
```
If you were using in an automation or from dev tools, would use:
`switch.rf_kitchen_light_one`, but your front end would still show `Beautiful
bright kitchen light!`
* Add new arg to test_assumed_state_should_be_true_if_command_state_is_false
* Import ENTITY_ID _FORMAT from existing, rename device_name to object_id
* Rename `device_name` to `object_id`
* Test that `entity_id` and `name` are set as expected
This feature needs to be enabled through the `http.use_x_forwarded_for` option,
satisfying security concerns of spoofed remote addresses in untrusted network
environments.
The testsuite was enhanced to explicitly test the functionality of the
header.
Fixes#4265.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>