* Adjusted api for new library version.
* Added support for output monitoring. Added initial status check for the alarm.
* Added default values to the configuration as per review notes.
* added gtt sensor
* removed trailing space
* updated requirements_all
* fixed two errors in the code style
* fixed imperative in docstring
* disabled pylint false positive
* fixed description on top of the file
* added files to .coveragerc
* fixes
* linting
* fixed linting 👍
* left a trailing space, now it's gone.
* fix
* Provide charging indicator for mychevy
This expands the mychevy sensor for the battery level to also know if
the system is currently charging to get the correct icon.
* address review feedback
When editing an entity in the frontend dialog, pressing save causes a "save failed: Entity is already registered" error. This is because the frontend always sets `name` and `new_entity_id` in the websocket command even if they haven't been changed. This adds a check that the `new_entity_id` is actually different from `entity_id` before erroring that the `new_entity_id` is already registered.
* Fixed manual alarm control panel restore state
* Revert "Fixed manual alarm control panel restore state"
This reverts commit 61c9faf434a8bb276133578a0811100a796784ca.
* Fixed manual alarm control panel's state restore
* Set lock status correctly for Schlage BE469 Z-Wave locks
PR #17386 attempted to improve the state of z-wave lock tracking for
some problematic models. However, it operated under a flawed
assumptions. Namely, that we can always trust `self.values` to have
fresh data, and that the Schlage BE469 sends alarm reports after every
lock event. We can't trust `self.values`, and the Schlage is very
broken. :)
When we receive a notification from the driver about a state change,
we call `update_properties` - but we can (and do!) have _stale_
properties left over from previous updates. #17386 really works best
if you start from a clean slate each time. However, `update_properties`
is called on every value update, and we don't get a reason why.
Moreover, values that weren't just refreshed are not removed. So blindly
looking at something like `self.values.access_control` when deciding to
apply a workaround is not going to always be correct - it may or may not
be, depending on what happened in the past.
For the sad case of the BE469, here are the Z-Wave events that happen
under various circumstances:
RF Lock / Unlock:
- Send: door lock command set
- Receive: door lock report
- Send: door lock command get
- Receive: door lock report
Manual lock / Unlock:
- Receive: alarm
- Send: door lock command get
- Receive: door lock report
Keypad lock / Unlock:
- Receive: alarm
- Send: door lock command get
- Receive: door lock report
Thus, this PR introduces yet another work around - we track the current
and last z-wave command that the driver saw, and make assumptions based
on the sequence of events. This seems to be the most reliable way to go
- simply asking the driver to refresh various states doesn't clear out
alarms the way you would expect; this model doesn't support the access
control logging commands; and trying to manually clear out alarm state
when calling RF lock/unlock was tricky.
The lock state, when the z-wave network restarts, may look out of sync
for a few minutes. However, after the full network restart is complete,
everything looks good in my testing.
* Fix linter
* Added motion, speed and battery attributes.
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
* Use dict[key] when we know there is a value there.
Co-Authored-By: ludeeus <joasoe@gmail.com>
When editing an entity in the frontend dialog, pressing save causes a "save failed: Entity is already registered" error. This is because the frontend always sets `name` and `new_entity_id` in the websocket command even if they haven't been changed. This adds a check that the `new_entity_id` is actually different from `entity_id` before erroring that the `new_entity_id` is already registered.
* Added brottsplatskartan sensor
* Update brottsplatskartan sensor
* Remove redundant configuration checks.
* Set attributes during initialization.
* Setup brottsplatskartan module in setup_platform().
* Just do a simple return, no need for returning false.
* Remove file that was used during testing
* Better variable name and remove excessive newline.
* More updates to brottsplatskartan
* Import uuid at the top of the module.
* Use sensor as domain.
* Don't fire custom events.
* Remove period from logging message.
* Adding validation for area parameter
* Validate empty area configuration
* Fixing indentation.
* Fixing the config schema
* Adding ambient_station.py sensor and updating requirements file
* Cleaning up code and fixing flake8 warnings
* Fixing flake8 and pylint warnings
* Adding ambient_station.py sensor and updating requirements file
* Cleaning up code and fixing flake8 warnings
* Fixing flake8 and pylint warnings
* Fixing bug, things are working well now
* removing nosetests file
* Adding changes as requested in pull request #18551
* Updating with more change requests from PR code review
* Removing SCAN_INTERVAL from PLATFORM_SCHEMA
* Removing unused import
* Adding platform schema validation for monitored_conditions and conf_units
* Updating link to documentation in doc-string. File already named in doc repo
* Only setup platform if component can successfully communicate with API
* Inverting check for platform setup success
