* Bump Ecovacs dependency (sucks)
Update to new version of sucks, which switches to a custom-built SleekXMPP that turns off certificate validation. This is to fix issues caused by Ecovacs serving invalid certificates.
* Update requirements file
* Bump Ecovacs dependency (sucks)
Update to new version of sucks, which switches to a custom-built SleekXMPP that turns off certificate validation. This is to fix issues caused by Ecovacs serving invalid certificates.
* Update requirements file
Add `unique_id` to all rachio entities
Add platform discovery to rachio component
Move config options from switch.rachio platform to the rachio component
* Bump sucks (Ecovacs) lib to 0.9.3
Changed code that was in place as a workaround pre-0.9.2. This version bump fixes a few issues.
* Update requirements_all
* Ecovacs Deebot vacuums
* All core features implemented
Getting fan speed and locating the vac are still unsupported until sucks adds support
* Move init queries to the added_to_hass method
* Adding support for subscribing to events from the sucks library
This support does not exist in sucks yet; this commit serves as a sort of TDD approach of what such support COULD look like.
* Add OverloadUT as ecovacs code owner
* Full support for Ecovacs vacuums (Deebot)
* Add requirements
* Linting fixes
* Make API Device ID random on each boot
* Fix unique ID
Never worked before, as it should have been looking for a key, not an attribute
* Fix random string generation to work in Python 3.5 (thanks, Travis!)
* Add new files to .coveragerc
* Code review changes
(Will require a sucks version bump in a coming commit; waiting for it to release)
* Bump sucks to 0.9.1 now that it has released
* Update requirements_all.txt as well
* Bump sucks version to fix lifespan value errors
* Revert to sucks 0.9.1 and include a fix for a bug in that release
Sucks is being slow to release currently, so doing this so we can get a version out the door.
* Switch state_attributes to device_state_attributes
* Fix ISY leak sensors always showing UNKNOWN until a leak is detected
Added some logic that handles both moisture sensors and door/window sensors
* Handle edge case of leak sensor status update after ISY reboot
If a leak sensor is unknown, due to a recent reboot of the ISY, the status will get updated to dry upon the first heartbeat. This status update is the only way that a leak sensor's status changes without an accompanying Control event, so we need to watch for it.
* Fixes from overnight testing
State was checking the incorrect parameter, and wasn't calling schedule update
* Remove leftover debug log line
* Remove unnecessary pylint instruction
* Remove access of protected property
We can't cast _.status directly to a bool for some unknown reason (possibly with the VarEvents library), but casting to an int then bool does work.
* Fix ISY leak sensors always showing UNKNOWN until a leak is detected
Added some logic that handles both moisture sensors and door/window sensors
* Handle edge case of leak sensor status update after ISY reboot
If a leak sensor is unknown, due to a recent reboot of the ISY, the status will get updated to dry upon the first heartbeat. This status update is the only way that a leak sensor's status changes without an accompanying Control event, so we need to watch for it.
* Fixes from overnight testing
State was checking the incorrect parameter, and wasn't calling schedule update
* Remove leftover debug log line
* Remove unnecessary pylint instruction
* Remove access of protected property
We can't cast _.status directly to a bool for some unknown reason (possibly with the VarEvents library), but casting to an int then bool does work.
Sensors that were defined via sensor_string were not getting properly identified as binary sensors when they had a uom defining them as binary (the other three methods of detecting binary sensors worked though.)
The Universal media player inherits the states of the first child player that is not in some sort of "Off" state (including idle.) It was not considering the "unavailable" state to be off. Now it does.
* Fixed 3 small issues in isy994 component
1. FanLincs have two nodes: one light and one fan motor. In order for each node to get detected as different Hass entity types, I removed the device-type check for FanLinc. The logic will now fall back on the uom checks which should work just fine. (An alternative approach here would be to special case FanLincs and handle them directly - but seeing as the newer 5.x ISY firmware already handles this much better using NodeDefs, I think this quick and dirty approach is fine for the older firmware.) Fixes#12030
2. Some non-dimming switches were appearing as `light`s in Hass due to an duplicate NodeDef being in the light domain filter. Removed! Fixes#12340
3. The `unqiue_id` property was throwing an error for certain entity types that don't have an `_id` property from the ISY. This issue has always been present, but was exposed by the entity registry which seems to be the first thing to actually try reading the `unique_id` property from the isy994 component.
* Fix ISY994 fan detection
ISY reports "med" in the uom, not "medium"
* Add special-case for FanLincs so the light node is detected properly
* Re-add insteon-type filter for fans, which dropped in a merge error
1. FanLincs have two nodes: one light and one fan motor. In order for each node to get detected as different Hass entity types, I removed the device-type check for FanLinc. The logic will now fall back on the uom checks which should work just fine. (An alternative approach here would be to special case FanLincs and handle them directly - but seeing as the newer 5.x ISY firmware already handles this much better using NodeDefs, I think this quick and dirty approach is fine for the older firmware.) Fixes#12030
2. Some non-dimming switches were appearing as `light`s in Hass due to an duplicate NodeDef being in the light domain filter. Removed! Fixes#12340
3. The `unqiue_id` property was throwing an error for certain entity types that don't have an `_id` property from the ISY. This issue has always been present, but was exposed by the entity registry which seems to be the first thing to actually try reading the `unique_id` property from the isy994 component.
1. FanLincs have two nodes: one light and one fan motor. In order for each node to get detected as different Hass entity types, I removed the device-type check for FanLinc. The logic will now fall back on the uom checks which should work just fine. (An alternative approach here would be to special case FanLincs and handle them directly - but seeing as the newer 5.x ISY firmware already handles this much better using NodeDefs, I think this quick and dirty approach is fine for the older firmware.) Fixes#12030
2. Some non-dimming switches were appearing as `light`s in Hass due to an duplicate NodeDef being in the light domain filter. Removed! Fixes#12340
3. The `unqiue_id` property was throwing an error for certain entity types that don't have an `_id` property from the ISY. This issue has always been present, but was exposed by the entity registry which seems to be the first thing to actually try reading the `unique_id` property from the isy994 component.
Leak sensors were using the "wet" node as a negative node, which prevented them from ever gettng a Dry status unless the user pressed the button on the hardware after every Hass reboot.
This change ignores the Wet node, as it is just always the exact inverse of the Dry node. We don't need to watch both.
* Fix detection of if a negative node is in use
Fix a problem where every negative node gets detected as in-use. Code was not checking the correct property.
* Allow protected access
Leak sensors were using the "wet" node as a negative node, which prevented them from ever gettng a Dry status unless the user pressed the button on the hardware after every Hass reboot.
This change ignores the Wet node, as it is just always the exact inverse of the Dry node. We don't need to watch both.
* Huge ISY994 platform cleanup, fixes support for 5.0.10 firmware
# * No more globals - store on hass.data
# * Parent ISY994 component handles categorizing nodes in to Hass components, rather than each individual domain filtering all nodes themselves
# * Remove hidden string, replace with ignore string. Hidden should be done via the customize block; ignore fully prevents the node from getting a Hass entity
# * Removed a few unused methods in the ISYDevice class
# * Cleaned up the hostname parsing
# * Removed broken logic in the fan Program component. It was setting properties that have no setters
# * Added the missing SUPPORTED_FEATURES to the fan component to indicate that it can set speed
# * Added better error handling and a log warning when an ISY994 program entity fails to initialize
# * Cleaned up a few instances of unecessarily complicated logic paths, and other cases of unnecessary logic that is already handled by base classes
* Use `super()` instead of explicit base class calls
* Move `hass` argument to first position
* Use str.format instead of string addition
* Move program structure building and validation to component
Removes the need for a bunch of duplicate exception handling in each individual platform
* Fix climate nodes, fix climate names, add config to disable climate
Sensor platform was crashing when the ISY reported climate nodes. Logic has been fixed. Also added a config option to prevent climate sensors from getting imported from the ISY. Also replace the underscore from climate node names with spaces so they default to friendly names.
* Space missing in error message
* Fix string comparison to use `==`
* Explicitly check for attributes rather than catch AttributeError
Also removes two stray debug lines
* Remove null checks on hass.data, as they are always null at this point
* Fix detection of if a negative node is in use
Fix a problem where every negative node gets detected as in-use. Code was not checking the correct property.
* Allow protected access
* 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 DEBUG-level log for db row to native object conversion
This is now the bottleneck (by a large margin) for big history queries, so I'm leaving this log feature in to help diagnose users with a slow history page
* Rewrite of the "first synthetic datapoint" query for multiple entities
The old method was written in a manner that prevented an index from being used in the inner-most GROUP BY statement, causing massive performance issues especially when querying for a large time period.
The new query does have one material change that will cause it to return different results than before: instead of using max(state_id) to get the latest entry, we now get the max(last_updated). This is more appropriate (primary key should not be assumed to be in order of event firing) and allows an index to be used on the inner-most query. I added another JOIN layer to account for cases where there are two entries on the exact same `last_created` for a given entity. In this case we do use `state_id` as a tiebreaker.
For performance reasons the domain filters were also moved to the outermost query, as it's way more efficient to do it there than on the innermost query as before (due to indexing with GROUP BY problems)
The result is a query that only needs to do a filesort on the final result set, which will only be as many rows as there are entities.
* Remove the ORDER BY entity_id when fetching states, and add logging
Having this ORDER BY in the query prevents it from using an index due to the range filter, so it has been removed.
We already do a `groupby` in the `states_to_json` method which accomplishes exactly what the ORDER BY in the query was trying to do anyway, so this change causes no functional difference.
Also added DEBUG-level logging to allow diagnosing a user's slow history page.
* Add DEBUG-level logging for the synthetic-first-datapoint query
For diagnosing a user's slow history page
* Missed a couple instances of `created` that should be `last_updated`
* Remove `entity_id` sorting from state_changes; match significant_update
This is the same change as 09b3498f410106881fc5e095c49a8d527fa89644 , but applied to the `state_changes_during_period` method which I missed before. This should give the same performance boost to the history sensor component!
* Bugfix in History query used for History Sensor
The date filter was using a different column for the upper and lower bounds. It would work, but it would be slow!
* Update Recorder purge script to use more appropriate columns
Two reasons: 1. the `created` column's meaning is fairly arbitrary and does not represent when an event or state change actually ocurred. It seems more correct to purge based on the event date than the time the database row was written.
2. The new columns are indexed, which will speed up this purge script by orders of magnitude
* Updating db model to match new query optimizations
A few things here: 1. New schema version with a new index and several removed indexes
2. A new method in the migration script to drop old indexes
3. Added an INFO-level log message when a new index will be added, as this can take quite some time on a Raspberry Pi
* Bugfix: remove superfluous domain filter
This filter is already applied later in the function by the `filters` object, where it is conditionally applied when appropriate. This fixes the problem where we get a domain filter even when searching for a single entity_id, which needlessly harms the query's performance.
* Performance: build different query when only getting single entity
When querying the history of a single entity, we can use an entirely different method for the "synthetic zero data point" by simply sorting by date and doing a LIMIT 1. This performs thousands of times better than the multi-entity query when the current recorder_run has been going for a while.
* Add entity_id filter to single-entity request
The entity_id filter was handled inside the `filters.apply` logic which is used in most cases, BUT didn't work when no `filters` was passed in to the method. Now it'll work even if no `filters` object is passed in.
* Fix linting errors in history.py
* Undo removal of domain filter
Putting back the domain filter that was removed in 76a6371705dcd57483e55dcc03435ae867c184d2 - there are use-cases where get_states is called without a filter object, so we need the domain filter to work in those cases as well.
* Fix truncated comment
Greg Laabs