Merge in bug fixes and renames to match with new repository layout.
Deleted spruce-controller.groovy from 'Spruce Irrigation'
Deleted spruce-sensor-v1.groovy from 'Spruce Irrigation'
Deleted spruce-scheduler.groovy from 'Spruce Irrigation'
Modifying 'Spruce Irrigation'
Merge in bug fixes and renames to match with new repository layout.
1. Missing break in case 32 for AlarmReport
2. Bugfix - Not reporting all codes programmed into the lock causing SmartApps to fail while awaiting a codeReport notification (once a code is programmed into a lock it should be notified because there is no way to read back codes from the lock, apps awaiting a codeReport will go into an infinite programming loop to trying to update the codes and awaiting a codeReport notification indicating a successful programming)
Commenting out fingerprint temporarily to avoid potential conflicts with other devices as this devices is specifically for a Korean deployment in AP01 - see DVCSMP-1425
Previously parse was returning null which causes the platform to create an event
using the message passed to parse. We don't want that to happen so return
an empty list instead.
Resolves:
https://smartthings.atlassian.net/browse/SMJN-38
The previous threshold multiplier was found to be too low so motion was
being detected while the sensor was idle. This new value of 630 seems to
produce better results.
The previous axis value parsing code was very fragile. For example, this
code block:
def unsignedY = hexToInt(part.split("13")[1].trim())
would fail when `part` was "13xx13", where "xx" is any value. The split
assumed the value "13" was present only once in the string, and everything
after the "13" was the value. When "13" was part of the value this code
would interpret only "xx" as the value, instead of "xx13".
The new parsing code is not fragile like this. It knows exactly what bytes
of the string are X, Y, and Z and parses the values correctly.
Garage Door use case works + implemented code review feedback
Implementing code review feedback + inverted the signedY to match Centralite like behavior.
Implementing code review feedback + inverted the signedY to match Centralite like behavior.
The code can only correctly handle the accelerometer readings when they
are all received in the same message. Individual reads of the attributes
results in individual read attribute responses which led to events with
incorrect values. The most straightforward fix is to not read the attributes
in the first place and rely on attribute reporting to report the values
at the appropriate time.
Resolves:
https://smartthings.atlassian.net/browse/DVCSMP-1315
