4390fed168
* Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added requirement that RESTful JSON results used as attributes must be objects, not lists. * Expanded test coverage to test REFTful JSON attributes with and without a value template. * Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added requirement that RESTful JSON results used as attributes must be objects, not lists. * Expanded test coverage to test REFTful JSON attributes with and without a value template. * sensor.envirophat: add missing requirement (#7451) Adding requirements that is not explicitly pulled in by the library that manages the Enviro pHAT. * PyPI Openzwave (#7415) * Remove default zwave config path PYOZW now has much more comprehensive default handling for the config path (in src-lib/libopenzwave/libopenzwave.pyx:getConfig()). It looks in the same place we were looking, plus _many_ more. It will certainly do a much better job of finding the config files than we will (and will be updated as the library is changed, so we don't end up chasing it). The getConfig() method has been there for a while, but was subsntially improved recently. This change simply leaves the config_path as None if it is not specified, which will trigger the default handling in PYOZW. * Install python-openzwave from PyPI As of version 0.4, python-openzwave supports installation from PyPI, which means we can use our 'normal' dependency management tooling to install it. Yay. This uses the default 'embed' build (which goes and downloads statically sources to avoid having to compile anything locally). Check out the python-openzwave readme for more details. * Add python-openzwave deps to .travis.yml Python OpenZwave require the libudev headers to build. This adds the libudev-dev package to Travis runs via the 'apt' addon for Travis. Thanks to @MartinHjelmare for this fix. * Update docker build for PyPI openzwave Now that PYOZW can be install from PyPI, the docker image build process can be simplified to remove the explicit compilation of PYOZW. * Add datadog component (#7158) * Add datadog component * Improve test_invalid_config datadog test * Use assert_setup_component for test setup * Fix object type for default KNX port #7429 describes a TypeError that is raised if the port is omitted in the config for the KNX component (integer is required (got type str)). This commit changes the default port from a string to an integer. I expect this will resolve that issue... * Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added requirement that RESTful JSON results used as attributes must be objects, not lists. * Expanded test coverage to test REFTful JSON attributes with and without a value template. * Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added requirement that RESTful JSON results used as attributes must be objects, not lists. * Expanded test coverage to test REFTful JSON attributes with and without a value template. * Added support for extracting JSON attributes from RESTful values Setting the json_attributes configuration option to true on the RESTful sensor will cause the result of the REST request to be parsed as a JSON string and if successful the resulting dictionary will be used for the attributes of the sensor. * Added requirement that RESTful JSON results used as attributes must be objects, not lists. * Expanded test coverage to test REFTful JSON attributes with and without a value template. * Fixed breaks cause by manual upstream merge. * Added one extra blank line to make PyLint happy. * Switched json_attributes to be a list of keys rather than a boolean. The value of json_attributes can now be either a comma sepaated list of key names or a YAML list of key names. Only matching keys in a retuned JSON dictionary will be mapped to sensor attributes. Updated test cases to handle json_attributes being a list. Also fixed two minor issues arrising from manual merge with 0.58 master. * Added an explicit default value to the json_attributes config entry. * Removed self.update() from __init__() body. * Expended unit tests for error cases of json_attributes processing. * Align quotes |
||
|---|---|---|
| .github | ||
| docs | ||
| homeassistant | ||
| script | ||
| tests | ||
| virtualization | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .hound.yml | ||
| .ignore | ||
| .travis.yml | ||
| CLA.md | ||
| CODEOWNERS | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE.md | ||
| MANIFEST.in | ||
| README.rst | ||
| pylintrc | ||
| requirements_all.txt | ||
| requirements_docs.txt | ||
| requirements_test.txt | ||
| requirements_test_all.txt | ||
| setup.cfg | ||
| setup.py | ||
| tox.ini | ||
README.rst
Home Assistant |Build Status| |Coverage Status| |Chat Status|
=============================================================
Home Assistant is a home automation platform running on Python 3. It is able to track and control all devices at home and offer a platform for automating control.
To get started:
.. code:: bash
python3 -m pip install homeassistant
hass --open-ui
Check out `home-assistant.io <https://home-assistant.io>`__ for `a
demo <https://home-assistant.io/demo/>`__, `installation instructions <https://home-assistant.io/getting-started/>`__,
`tutorials <https://home-assistant.io/getting-started/automation-2/>`__ and `documentation <https://home-assistant.io/docs/>`__.
|screenshot-states|
Featured integrations
---------------------
|screenshot-components|
The system is built using a modular approach so support for other devices or actions can be implemented easily. See also the `section on architecture <https://home-assistant.io/developers/architecture/>`__ and the `section on creating your own
components <https://home-assistant.io/developers/creating_components/>`__.
If you run into issues while using Home Assistant or during development
of a component, check the `Home Assistant help section <https://home-assistant.io/help/>`__ of our website for further help and information.
.. |Build Status| image:: https://travis-ci.org/home-assistant/home-assistant.svg?branch=master
:target: https://travis-ci.org/home-assistant/home-assistant
.. |Coverage Status| image:: https://img.shields.io/coveralls/home-assistant/home-assistant.svg
:target: https://coveralls.io/r/home-assistant/home-assistant?branch=master
.. |Chat Status| image:: https://img.shields.io/discord/330944238910963714.svg
:target: https://discord.gg/c5DvZ4e
.. |screenshot-states| image:: https://raw.github.com/home-assistant/home-assistant/master/docs/screenshots.png
:target: https://home-assistant.io/demo/
.. |screenshot-components| image:: https://raw.github.com/home-assistant/home-assistant/dev/docs/screenshot-components.png
:target: https://home-assistant.io/components/