Sonos Playbar and Playbase devices support Night Sound and Speech Enhancement
effects when playing from sources such as a TV. Adds a new service "sonos_set_option"
whichs accepts boolean options to control these audio features.
* Fix X10 commands for mochad light turn on
This commit attempts to address issues that a lot of people are having
with the x10 light component. Originally this was written to use the
xdim (extended dim) X10 command. However, not every X10 dimmer device
supports the xdim command. Additionally, it turns out the number of
dim/brighness levels the X10 device supports is device specific and
there is no way to detect this (given the mostly 1 way nature of X10)
To address these issues, this commit removes the usage of xdim and
instead relies on using the 'on' command and the 'dim' command. This
should work on all x10 light devices. In an attempt to address the
different dim/brightness levels supported by different devices this
commit also adds a new optional config value, 'brightness_levels', to
specify if it's either 32, 64, or 256. By default 32 levels are used
as this is the normal case and what is documented by mochad.
Fixes#8943
* make code more readable
* fix style
* fix lint
* fix tests
* Fix X10 commands for mochad light turn on
This commit attempts to address issues that a lot of people are having
with the x10 light component. Originally this was written to use the
xdim (extended dim) X10 command. However, not every X10 dimmer device
supports the xdim command. Additionally, it turns out the number of
dim/brighness levels the X10 device supports is device specific and
there is no way to detect this (given the mostly 1 way nature of X10)
To address these issues, this commit removes the usage of xdim and
instead relies on using the 'on' command and the 'dim' command. This
should work on all x10 light devices. In an attempt to address the
different dim/brightness levels supported by different devices this
commit also adds a new optional config value, 'brightness_levels', to
specify if it's either 32, 64, or 256. By default 32 levels are used
as this is the normal case and what is documented by mochad.
Fixes#8943
* make code more readable
* fix style
* fix lint
* fix tests
* Fire events for ISY994 control events
This allows hass to react directly to Insteon button presses (on switches and remotes), including presses, double-presses, and long holds
* Move change event subscription to after entity is added to hass
The event handler method requires `self.hass` to exist, which doesn't have a value until the async_added_to_hass method is called. Should eliminate a race condition.
* Overhaul binary sensors in ISY994 to be functional "out of the box"
We now smash all of the subnodes from the ISY994 in to one Hass binary_sensor, and automatically support both paradigms of state reporting that Insteon sensors can do. Sometimes a single node's state represents the sensor's state, other times two nodes are used and only "ON" events are sent from each. The logic between the two forunately do not conflict so we can support both without knowing which mode the device is in.
This also allows us to handle the heartbeat functionality that certain sensors have - we simply store the timestamp of the heartbeat as an attribute on the sensor device. It defaults to Unknown on bootup if and only if the device supports heartbeats, due to the presence of subnode 4.
* Parse the binary sensor device class from the ISY's device "type"
Now we automatically know which sensors are moisture, motion, and openings! (We also reverse the moisture sensor state, because Insteon reports ON for dry on the primary node.)
* Code review tweaks
The one material change here is that the event subscribers were moved to the `async_added_to_hass` method, as the handlers depend on things that only exist after the entity has been added.
* Handle cases where a sensor's state is unknown
When the ISY first boots up, if a battery-powered sensor has not reported in yet (due to heartbeat or a change in state), the state is unknown until it does.
* Clean up from code review
Fix coroutine await, remove unnecessary exception check, and return None when state is unknown
* Unknown value from PyISY is now -inf rather than -1
* Move heartbeat handling to a separate sensor
Now all heartbeat-compatible sensors will have a separate `binary_sensor` device that represents the battery state (on = dead)
* Add support for Unknown state, which is being added in next PyISY
PyISY will report unknown states as the number "-inf". This is implemented in the base ISY994 component, but subcomponents that override the `state` method needed some extra logic to handle it as well.
* Change a couple try blocks to explicit None checks
* Bump PyISY to 1.1.0, now that it has been published!
* Remove -inf checking from base component
The implementation of the -inf checking was improved in another branch which has been merged in to this branch already.
* Restrict negative-node and heartbeat support to known compatible types
Not all Insteon sensors use the same subnode IDs for the same things, so we need to use different logic depending on device type. Negative node and heartbeat support is now only used for leak sensors and open/close sensors.
* Use new style string formatting
* Add binary sensor detection for pre-5.x firmware
Meant to do this originally; writing documentation revealed that this requirement was missed!
* Allow using more than one keyboard remote
This sets up one thread per keyboard remote, listening for events.
* Remove enclosing block in keyboard_remote
* Remove unnecessary semantic check for keyboard_remote
The current code relies on the assumption that the first invocation will never specify no_throttle=True.
However that puts us in a pickle when writing unit tests: if we had a fictitious:
def setup_platform():
update()
@Throttle(MIN_TIME_BETWEEN_SCANS)
def update():
pass
Then given multiple tests, the second and some of subsequent tests would be throttled (depending on timing).
But we also can't change that code to call `update(no_throttle=True)' because that's not currently accepted.
This diff shouldn't change the visibile behavior of any component, but allows this extra flexibility.
* Add media progress information
* Remove unnecessary comments
* Remove datetime import
* Remove pysonyavr dependency
* Fix doc syntax (D205)
* Lint fix: no-else-return
* Don't attempt to set media progress info if program is None
* Fix Python 3.4 compatibility
* Explicitely depend on pyteleloisirs
* Only update remaining play time when it changed
* Fix floot state table
* Introduce a new Hue component that knows how to talk to a Hue bridge, but doesn't actually set up lights.
* Refactor the hue lights platform to use the HueBridge class from the hue component.
* Reimplement support for multiple bridges
* Auto discover bridges.
* Provide some migration support by showing a persistent notification.
* Address most feedback from code review.
* Call load_platform from inside HueBridge.setup passing the bridge id.
Not only this looks nicer, but it also nicely solves additional bridges being added after initial setup (e.g. pairing a second bridge should work now, I believe it required a restart before).
* Add a unit test for hue_activate_scene
* Address feedback from code review.
* After feedback from @andrey-git I was able to find a way to not import phue in tests, yay!
* Inject a mock phue in a couple of places
* Add support for Logitech UE Smart Radios.
* Removed full stops to please Hound's line limit.
* Updated with requested changes.
* Fix Pylint Flake8 problem.
* Updated with requested changes.
All mochad devices are sharing a single socket interface. When multiple
threads are issuing requests to the mochad daemon at the same time the
write read cycle might get crossed between the threads. This is normally
not an issue for 1-way X10 devices because as long as the request issued
successfully and data is read over the socket then we know as much as
mochad will tell us (since there is no ACK from the request for most
X10 devices). However, where it does matter is on the device __init__()
because we're relying on the mochad daemon's internal state to take an
educated guess at the device's state to intialize things with. When
there are multiple devices being initialized at the same time the wires
can get crossed between and the wrong device state may be read.
To address this potential issue this commit adds locking using a
semaphore around all pairs of send_cmd() and read_data() (which is what
pymochad.device.Device.get_status() does internally) calls to the mochad
controller to ensure we're only ever dealing with a single request at a
time.
Fixesmtreinish/pymochad#4
* Updated snips to listen on new mqtt topic and use rawValue if value not present in slot
* Too late at night
* Trying to make minor changes via web
* Update test_snips.py
* Update __init__.py
* Updated wrong branch cause I'm a monkey
* Add Canary component
* Made some change to how canary data is updated and stored
* Updated to use py-canary:0.1.2
* Addressed flake8 warnings
* Import canary API locally
* Import canary API locally again
* Addressed pylint errors
* Updated requirements_all.txt
* Fixed incorrect unit of measurement for air quality sensor
* Added tests for Canary component and sensors
* Updated canary component to handle exception better when initializing
* Fixed tests
* Fixed tests again
* Addressed review comments
* Fixed houndci error
* Addressed comment about camera force update
* Addressed comment regarding timeout when fetching camera image
* Updated to use py-canary==0.2.2
* Increased update frequency to 30 seconds
* Added support for Canary alarm control panel
* Address review comments
* Fixed houndci error
* Fixed lint errors
* Updated test to only test setup component / platform
* Fixed flake error
* Fixed failing test
* Uptake py-canary:0.2.3
* canary.alarm_control_panel DISARM is now mapped to canary PRIVACY mode
* Fixed failing tests
* Removed unnecessary methods
* Removed polling in canary camera component and update camera info when getting camera image
* Added more tests to cover Canary sensors
* Address review comments
* Addressed review comment in tests
* Fixed pylint errors
* Excluded canary alarm_control_panel and camera from coverage calculation
* initial commit of shuffle option for sonos
* added test
* Small adjustments to adhere to review requests
* Removed unnessesary setting of variable. Use shuffle state from soco instead
In a case where either (a) an incorrect source name is used, or (b) the
TV isn't currently queryable (e.g. it's off), we get tracebacks because
we assume the source that we are being asked to select exists in
self._source_list.
This makes the lookup code a little more rugged, and adds in a warning
message (in place of the current exception).
* Device tracker for meraki AP
* styles fix
* fix again
* again
* and again :)
* fix hide if away
* docs and optimization
* tests and fixes
* styles
* styles
* styles
* styles
* styles fix. Hope last
* clear track new
* changes
* fix accuracy error and requested changes
* remove meraki from .coveragerc
* tests and minor changes
* remove location
* Generic thermostat restore operation mode
* Test restore operation mode
* Fix trailing whitespace
* Fix line too long
* Fix test duplicate entity_id
* Fix test
* async_added_to_hass modify modify internal state
* Test inital_operation_mode
* More restore state tests
* Fix whitespace
* fix test_custom_setup_param
* Test "None" target temp
* add ads hub, light and switch
* add binary sensor prototype
* switch: use adsvar for connection
* fix some issues with binary sensor
* fix binary sensor
* fix all platforms
* use latest pyads
* fixed error with multiple binary sensors
* add sensor
* add ads sensor
* clean up after shutdown
* ads component with platforms switch, binary_sensor, light, sensor
add locking
poll sensors at startup
update state of ads switch and light
update ads requirements
remove update() from constructors on ads platforms
omit ads coverage
ads catch read error when polling
* add ads service
* add default settings for use_notify and poll_interval
* fix too long line
* Fix style issues
* no pydocstyle errors
* Send and receive native brightness data to ADS device to prevent issues with math.floor reducing brightness -1 at every switch
* Enable non dimmable lights
* remove setting of self._state in switch
* remove polling
* Revert "remove polling"
This reverts commit 7da420f823.
* add service schema, add links to documentation
* fix naming, cleanup
* re-remove polling
* use async_added_to_hass for setup of callbacks
* fix comment.
* add callbacks for changed values
* use async_add_job for creating device notifications
* set should_poll to False for all platforms
* change should_poll to property
* add service description to services.yaml
* add for brigthness not being None
* put ads component in package
* Remove whitespace
* omit ads package
* Export climate metrics to Prometheus.
This adds climate_state and temperature_c metrics for each climate
device.
* Add more climate states to state_as_number
* check for none
* fix error from no store being set
* typo
* Lint
* fix default as per notes. Lint fix and make closest store None not False
* update default
* Added min and Events sensor types to prometheus
* Updated prometheus client and fixed invalid swith state
* Added metric to count number of times an automation is triggered
* Removed assumption that may not apply to everybody
* Fixed tests
* Updated requirements_test_all
* Fixed unit tests
* Correction of Samsung Power OFF behaviour
Addition of a delay after powering OFF a Samsung TV, this avoid status
update from powering the TV back ON.
Deletion of update() return statement, return value not used.
* Rename self._end_of_power_off_command into self._end_of_power_off
* Removal of unused line break in Samsung TV component
* Add iAlarm support
* Minor fixes to iAlarm
* Rename ialarmpanel to ialarm and add a check for the host value
* corrections in the value validation of ialarm
* add a missing period on ialarm
* 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
Brad Dixon
Mike Megally
PhracturedBlue
Pascal Vizeli
Paulus Schoutsen
Adam Mills
Matthew Treinish
Przemek Więch
Fabian Affolter
Daniel Perna
Greg Laabs
BryanJacobs
Michael Pollett
Andrea Campi
Nolan Gilley
Philipp Schmitt
Ryan McLean
Eitan Mosenkis
Dan Nixon
Pierre Ståhl
Fabian Affolter
Jan Almeroth
Erik Eriksson
uchagani
Adde Lovein
maxlaverse
perfalk
tringler
GreenTurtwig
Andrey Kupreychik
Andrey
tschmidty69
Anders Melchiorsen
Joe Lu
Marcus Schmidt
Lewis Juggins
Jeroen ter Heerdt
Alan Fischer
Daniel Watkins
Mitko Masarliev
William Scanlon
ziotibia81
Menno Blom
Roman
Craig J. Ward
Stefan Lehmann
Mateusz Drab
Paul Annekov
dasos
drop table USERS; --
Nicolas Bougues
Will Boyce
Brent Hughes
Oliver
Touliloup
Ludovico de Nittis
Nicko van Someren