SRT321 thermostat setpoints stopped working


#1

A strange one, but it appears that the thermostat setpoints stopped working today.
We are using SRT321s which are battery operated and send the setpoints on wake-up together with the go back to sleep command.
cmds << zwave.thermostatSetpointV1.thermostatSetpointSet(setpointType: physicalgraph.zwave.commands.thermostatsetpointv1.ThermostatSetpointSet.SETPOINT_TYPE_HEATING_1, scale: state.deviceScale, precision: state.p, scaledValue: state.convertedDegrees).format()

All fine until today…
My guess is backend, as the firmware update was a week ago, but any ideas why setpoints should suddenly stop working?


Z-Wave Library Changes Feb 2017
#2

As the multichannel control App sounds like it has the same problem, it appears that returning Z Wave commands in a response has been broken:

// Battery powered devices can be configured to periodically wake up and
// check in. They send this command and stay awake long enough to receive
// commands, or until they get a WakeUpNoMoreInformation command that
// instructs them that there are no more commands to receive and they can
// stop listening.
def zwaveEvent(physicalgraph.zwave.commands.wakeupv2.WakeUpNotification cmd)
{
def map = [name:“thermostatWakeUp”, value: “${device.displayName} woke up”, isStateChange: true]
def event = createEvent(map)
def cmds = updateIfNeeded()

	cmds << zwave.wakeUpV2.wakeUpNoMoreInformation().format()
    
    log.debug "Wakeup $cmds"

    [event, response(delayBetween(cmds, 1000))]      

}

I really think we need some Z Wave debugging tools so we can actually see what commands have gone out over ZWave, as logging is too high a level.
@duncan


#3

@duncan
You do realise that this is NOT a specific problem with SRT321 setpoints…
SmartThings has broken ZWave response with multiple commands!


(Duncan) #4

Yes, sorry I meant to link to the other thread from here.

I just moved this to its own topic in case people were looking for it, since it’s not related to the Z-Wave Library.