Skip to content

[ICP-13020] EZMultipli - fix for timeouts after color change #34180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 24, 2020
Merged

[ICP-13020] EZMultipli - fix for timeouts after color change #34180

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2d1c567
Fix for timeouts after color change
PKacprowiczS Jun 15, 2020
d5dfd90
Added piece of code which prevents inifnite loops
PKacprowiczS Jun 17, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 22 additions & 4 deletions devicetypes/drzwave/ezmultipli.src/ezmultipli.groovy
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -135,6 +135,8 @@ def setupHealthCheck() {
def installed() {
sendEvent(name: "motion", value: "inactive", displayed: false)
state.colorReceived = [red: null, green: null, blue: null]
state.setColor = [red: null, green: null, blue: null]
state.colorQueryFailures = 0
setupHealthCheck()
}

Expand Down Expand Up @@ -247,15 +249,30 @@ def zwaveEvent(switchcolorv3.SwitchColorReport cmd) {
result << createEvent(name: "color", value: hexColor)
// Send the color as hue and saturation
def hsv = rgbToHSV(*colors)
result << createEvent(name: "hue", value: hsv.hue)
result << createEvent(name: "saturation", value: hsv.saturation)
// Reset the values
RGB_NAMES.collect { state.colorReceived[it] = null}
if (state.setColor.red == state.colorReceived.red && state.setColor.green == state.colorReceived.green && state.setColor.blue == state.colorReceived.blue) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I'm confused. Wasn't the original issue that you couldn't count on state.colorReceived to be correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the key part of it, was setting it back to null here https://github.com/SmartThingsCommunity/SmartThingsPublic/pull/34180/files#diff-923fb700963e1771dfa88fd274738f37L253
Now, even if for a first report there is an invalid value in state map, querying it once again, generally solves problem

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so do we still want to restrict this to only the values we're setting? If we can avoid it I'd like to in order to preserve inter-operation with other z-wave controllers

unschedule()
result << createEvent(name: "hue", value: hsv.hue)
result << createEvent(name: "saturation", value: hsv.saturation)
state.colorQueryFailures = 0
} else {
if (++state.colorQueryFailures >= 6) {
sendHubCommand(commands([
zwave.switchColorV3.switchColorSet(red: state.setColor.red, green: state.setColor.green, blue: state.setColor.blue),
queryAllColors()
]))
} else {
runIn(2, "sendColorQueryCommands", [overwrite: true])
}
}
}

result
}

private sendColorQueryCommands() {
sendHubCommand(commands(queryAllColors()))
}

def zwaveEvent(physicalgraph.zwave.Command cmd) {
// Handles all Z-Wave commands we aren't interested in
log.debug "Unhandled $cmd"
Expand Down Expand Up @@ -324,6 +341,7 @@ def setColor(value) {
return
}

state.setColor = [red: myred, green: mygreen, blue: myblue]
cmds << zwave.switchColorV3.switchColorSet(red: myred, green: mygreen, blue: myblue)
cmds << zwave.basicV1.basicGet()

Expand Down