# By Juan Pablo Risso (3) and others
# Via Kris Schaller (24) and others
* 'master' of github.com:SmartThingsCommunity/SmartThingsPublic:
PROB-870 - Harmony fails to save credentials
add missing translations
add event translation
Removed canInstallLabs()
remove segmented style input to prevent iOS crash
PROB-537 - Fix error in line 335
MSA-68: Spruce Irrigation controller and soil moisture sensors.
# This is a combination of 3 commits. # The first commit's message is: MSA-68: Spruce Irrigation controller and soil moisture sensors.
DVCSMP-1480 Fixed ArrayIndexOutOfBoundsException
Convert closure to method
Revert "Convert closure to method"
Closure was causing sandbox issues locally
Bugfixes for codeReports
Fix Homeseer Multi Instance encap parse PROB-398
Merge pull request #135 from kwarodom/fibaroSmokeSensor
It seams like the user removed some activities on Harmony side without removing them from SmartThings. This is causing an issue when adding new activities. This fix checks if the activity still exists before creating a new device.
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
