I wasn't sure what the /tablet/tablet section of the state_topic part meant so had to google a bit to figure it out. With this change, users will immediately understand what they should set as the topic.
* Dim (and brighten) lights via a remote
Hopefully this one won't break everything ;)
* Changes as requested
* Updates
Other than the last point, done.
The last part I've left, as these aren't strictly independent parts - the section after the comma is the explanation for how the "lever" works.
* Updates
You snuck those in while I was editing ;)
* Update dim_and_brighten_lights.markdown
* Dim (and brighten) lights via a remote
As per chat in the Discord, these are the scripts, automations, and input_sliders to allow a light to be dimmed and brightened by holding down the down or up button on an appropriate remote.
This has been extended to use input_sliders for the dim/brighten step, and for the minimum and maximum brightness levels.
* Updates
Replacing pointless data_templates with just data, complying with preferred formatting standards ;)
* Further updates
More fixes ;)
* Updating development environment setup guide
Added more complete instructions for setting up a development environment for Home Assistant. Including details of dependencies, setting up venv. This is based on notes captured from setting up a dedicated hass dev environment on Debian 8.6.0
* Update development_environment.markdown
Updated as a result of feedback on pull request: https://github.com/home-assistant/home-assistant.github.io/pull/1804
Adding reminder to activate virtual environment before running setup along with adding reference to indicate apt-get may not be applicable to distro in use.
* Revert change to instruction to run hass
Remove statement about running hass with --open-ui and what it does (wrongly stated). Based on feedback from @balloob.
* Updated setting up venv as pyvenv is being deprecated
As of Python 3.6 pyvenv has been deprecated in favour of python3 -m venv.
Further changes may be required following resolution of discussion around setting up venv in a sub directory vs at the top level of the project.
* Remove details of Frontend requirements for NVM and Node
Given change [#5507](https://github.com/home-assistant/home-assistant/pull/5507) only attempts to setup the frontend if nvm is present. It makes sense to remove the details from here, since that was mainly around avoiding errors in the first time setup scenario. Instead I've adjusted the text to point to the FrontEnd Dev section.
* Updated centos instructions
yum install commands needs to be split so that EPEL repo is added first ahead of attempting to install other dependencies.
* Create configuration_yaml_by_shortbloke.markdown
The "state" used to be an alias for "to" but this was deprecated to make the
meaning more clear.
This commit updates the examples to no longer use the deprecated name.
* Kodi specific services to call Kodi API methods
- Doc for new service: `kodi_execute_addon` to run a Kodi Addon with optional parameters. Results of the Kodi API call, if any, are redirected in a Home Assistant event: `kodi_execute_addon_result`.
- Doc for new service: `kodi_run_method` to run a Kodi JSONRPC API method with optional parameters. Results of the Kodi API call are redirected in a Home Assistant event: `kodi_run_method_result`.
- Add `timeout` parameter to yaml config (needed to make slow queries to the JSONRPC API, default timeout is set to 5s).
- Examples for using the new services: one simple yaml example to call `kodi_execute_addon`and turn on the TV attached to Kodi; and other, more complex, to query the Kodi library and make a dynamic input select.
* remove `kodi_execute_addon` service; change example to work with `kodi_run_method`
* naming changes
* complex example to cookbook
* Update media_player.kodi.markdown
The example in the current documentation does not appear to work in hass 0.43.2. A trigger containing 'to' without a 'from' doesn't fire, however one that uses 'state' does.
