* Use standard entity_ids for zwave entities
* Include temporary opt-in for new entity ids
* Update link to blog post
* Update tests
* Add old entity_id as state attribute
* Expose ZWave value details
* Update tests
* Also show new_entity_id
* Just can't win with this one
* # This is a combination of 3 commits.
# The first commit's message is:
Add seperate zwave panel
# The 2nd commit message will be skipped:
# unused import
# The 3rd commit message will be skipped:
# Use get for config
* Add seperate zwave panel
* Modify set_config_parameter to accept setting string values
* descriptions
* Tweaks
* Tweaks
* Tweaks
* Tweaks
* lint
* Fallback if no config parameteres are available
* Update services.yaml
* review changes
* # This is a combination of 3 commits.
# The first commit's message is:
Add seperate zwave panel
# The 2nd commit message will be skipped:
# unused import
# The 3rd commit message will be skipped:
# Use get for config
* Add seperate zwave panel
* more info
* Add usercodeview
* Improve api
* Improve api
* Separate api into own file.
* disable missing import
* review changes
* Tests 1
* Verify that we fetch data from groups
* Tests groups
* config 1
* usercode 1
* Api mods
* Tweak API
* docstrings
* 100% api testing
* 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.
* wierd pylint complaint
* Workaround for Graber csz1 shades
* logging
* Try direct
* Try direct
* Use workaround
* Review changes and tests
* test
* reset test
* Use Bright and Dim also as open and close is
* Refactor zwave discovery to entity schema
* Address PR concerns
* Split DISCOVERY_SCHEMAS into separate file
* Only check cover reverse workaround once
* Add Zwave refresh services
* services file
* Use dispatcher
* Add zwave prefix to signal
* Delay zwave updates for 100ms to group them.
* Fixes
* lint
* Access _scheduled_update from loop thread only.
* More async
* Some optimizations
* Fix
