* 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>
* Added some extra options to Weather Underground component
* Added Location and Elevation options
* Fixed if statement
* Fixed lint
* Updated tests including elevation and location
* Update wunderground.py
* Synology SSL fix & Error handling
* change handling for cookies/ssl
* fix use not deprecated functions
* fix lint
* change verify
* fix connector close to coro
* fix force close
* not needed since websession close connector too
* fix params
* fix lint
* Fix "argument of type 'NoneType' is not iterable" during discovery
When yamaha receivers are dynamically discovered, there config is
empty, which means that we need to set zone_ignore to [] otherwise the
iteration over receivers fails.
* Bump rxv library version to fix play_status bug
rxv version 0.3 will issue the play_status command even for sources
that don't support it, causing stack traces during updates when
receivers are on HDMI inputs.
This was fixed in rxv 0.3.1. Bump to fix bug #4226.
* Don't discovery receivers that we've already configured
The discovery component doesn't know anything about already configured
receivers. This means that specifying a receiver manually will make it
show up twice if you have the discovery component enabled.
This puts a platform specific work around here that ensures that if
the media_player is found, we ignore the discovery system.
* Change pilight systemcode validation to integer
According to the pilight code the systemcode should be an integer and
not a string (it is an int in the pilight code). Passing this as a
string caused errors from pilight:
"ERROR: elro_800_switch: insufficient number of arguments"
This fixes#4282
* Change pilight unit-id to positive integer
According to the pilight code the unit of an entity is also evrywhere
handled as an integer. So converting and passing this as string causes
pilight not to work.
This fixes#4282
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
* Add timeout to platform/component
* Revert "Add timeout to platform/component"
This reverts commit 280a311e48.
* Add logging data
* Change log message with paulus comments
* Set executor to 15 and help to reduce flooting async core with udpates
* fix typing
* if it a executor, wait
* address comments from paulus
* add space for style :)
* fix spell
* Update entity_component.py
* Update entity_component.py
