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.
# The first commit's message is:
MSA-68: Spruce Irrigation controller and soil moisture sensors.
Modifying 'Spruce Irrigation'
Updated Spruce Scheduler, better stability, notifications, moisture & season adjustments
Updated device types, start scheduler from device
Code review for ST publication
Review for ST submission
Delete spruce-sensor.groovy
Delete spruce-scheduler-v2-1.groovy
Moisture control adjsut
# This is the 2nd commit message:
Deleted spruce-controller.groovy from 'Spruce Irrigation'
# This is the 3rd commit message:
Deleted spruce-sensor-v1.groovy from 'Spruce Irrigation'
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.
