* Use constant for offline state
* Use constant for no game name
* Rename trade and play constant their proper names
Trade and Play are not the correct names for the states. For instance
Play might be seens as the user is actually is playing, which is not
correct as there is no such state is returned from the Steam API.
Just having "trade" does not say much about what is happening and
might be misintepreted that the user is currently trading, which is not
correct either.
We instead use the names from the underlying library for naming the
states [1]
[1] 2e518ad84f/steam/user.py (L109)
* Get the proper game name if no extra info is given from the api
The third `current_game` parameter that was used before hold
extra information about the game that is being played. This might
contain the game name, it might also be empty. The correct way to
get the game name is to fetch it from the API depending on the
game id that might be returned in the `current_game` attribute if
the user is playing a game.
To not break existing implementations we keep the functionality
to first go with the extra information and only then fetch the proper
game name.
* Refactor getting game name to its own function
This cleans up the code and removed "ugly" else statements
from the sensor and makes the game fetching easier to read.
* Let state constant values be lower snake case
* Return None instead of 'None' when no current game exists
* Initialize steam app list only once to benefit form caching
* Return None as state attributes if no current game is present
* Fix statistics sensor mean and median when only one sample is available.
With only one data point stddev and variance throw an exception.
This would clear the (valid) mean and median calculations.
Separate the try..catch blocks for one-or-more and two-or-more stats so
that this doesn't happen.
Test this with a new sampling_size_1 test.
* test_statistics trivial whitespace fix
* 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!
* 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
* 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
* 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
* Refactored WHOIS sensor to resolve assumed key errors
Altered it to now set an attribute key and value only if the attribute
is present in the WHOIS response. This prevents assumed keys (registrar)
from raising a KeyError on WHOIS lookups that don't contain registrar
information (onet.pl, wp.pl, for example).
* Removed non-used self._data
* WHOIS sensor now creates a new local attributes dict and overrides
* Corrected typos, refactored error cases to clear state adn attributes
* Resolved double return and refactored error logging
* Creates a AmcresHub object to protect some private attributes on the logs
* Uses hass.data to pass AmcrestHub to components
* Prefer constants
* Removed serializer since it's using hass.data and simplified camera entity constructor
* small cleanup
Adding another sensor to output the numeber of items in the SABnabd queue. This is an alternative to displaying filesize, just a preference thing, as it is more meaningfull for me the way I use SABnzdb.
Note this is my first time coding on github and I have no idea if I am doing things right, I assume that all I needed to do is add a couple of lines to the sensors available and also another line as to what to extract from the SABnzdb API, in this case I have called the sensor "queue_count" and it gets the value from the noofslots_total which as I understand - each slot is a separate download item.
hope I did this correctly - also I don't have a separate instance of home assistant running for testing so I have no way to test this code (and I don't know how I would switch to the dev channel either). As I said I am a newb!
* Refactored to new global json saving and loading
* Fixed emulated_hue tests
* Removed unnecassary error handling
* Added missing newline
* Remove unused imports
* Fixed linting error
* Moved _load_json wrapper out of the config class
* New sensor viaggiatreno.
I've messed up the previous PR so here it is in a new one.
Should include also all corrections from @pvizeli
* fixes from PR 10522
* fixed import order
* requested changes from MartinHjelmare
* Fix ValueError exception
structure = '>{:c}'.format(data_types[register.get(CONF_DATA_TYPE)][register.get(CONF_COUNT)])
give:
ValueError: Unknown format code 'c' for object of type 'str'
* Minor typo
