zWave Schedule Capability - Setting

General Discussion
1

Hi All,

Trying to get a device handler working for the Horstmann / Secure SIR 321 switch - basically a switch for turning on a heating load (towel radiator, immersion heater etc). It’s a fairly basic device that broadly acts as a zwave switch but also has the ability to run for a defined period of time. The physical button can set it to run for 30, 60 or 120 minutes but via zwave you are supposed to be able to run it for between 1 minute and 1 day (1440 minutes).

Now I know I could achieve the same scheduling functionality using Smartthings and the scheduling options available however I was trying to get the native zwave functionality working, however I can’t for the life of me get it to work.

Although the zwave scheduling is quite complex this device only really accepts a very simple variant - basically you set the schedule to start now and how long you want it to run for.

Looking at the zwave specs you have to send the following command:

image
image.png532×688 27.2 KB

However I can’t figure out in Smartthings how to do this. The right command looks to be to return one or more physicalgraph.zwave.commands.schedulev1.CommandScheduleSet statements, however the spec for that seems to be missing the last element of the zwave spec - i.e. the actual commands you want the device to run (available options are:

Integer durationByte
Short durationType
Short numberOfCmdToFollow
Short reportsToFollow
Boolean res51
Short scheduleId
Short startDayOfMonth
Short startHour
Short startMinute
Short startMonth
Short startWeekday
Short startYear
Short userIdentifier
List<Short> payload

) as per https://graph.api.smartthings.com/ide/doc/zwave-utils.html#scheduleV1/commandScheduleSet.

Based on the zwave spec I think I basically need to send it a binaryswitch on event (so command class 0x25, command 0x01 and value 0xFF (for on)). I’ve tried guessing there is an undocumented property with a few obvious guesses (e.g. cmdBytes, cmd) but no joy. Trying using the useridentiifer (which is not in the zwave spec but is in Smartthings interpretation) doesn’t seem to work either. The device will respond to a schedule get command and basically shows no schedule set irrespective of what commands I sent it!

Has anyone had any luck using the zwave schedule specific commands? Anyone from the Smarthings team clarify how this should be set?

Thanks in advance!

Andrew

2

You might want to try using the zwave tweaker of guidance and inspiration

3

have you tried using the payload (list) for this?

4

Thanks sidjohn1 and Tony for the suggestions.

sidjohn - that definitely looks like a useful DTH and I’ll double check, however I think the issue is more how to send the info to the device rather than what it supports.

I managed to find out that if I select the button on the device which makes it run for say 30 minutes then run a CommandScheduleReport I get a valid response showing the schedule has been set. However I have my suspicion ST hasn’t properly implemented the schedule command class - the response I get is:

command: 5305, payload: 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF

ST parses this as:
CommandScheduleReport(startMinute: 63, reportsToFollow: 0, scheduleId: 1, userIdentifier: 0, startWeekday: 0, reserved371: 0, durationByte: 120, numberOfCmdToFollow: 1, startDayOfMonth: 0, reserved241: 0, startYear: 255, activeId: 3, res51: false, startHour: 31, durationType: 0, startMonth: 0)

Which I think has a couple of errors but most notably does nothing with the last three bytes (25 01 FF) which is exactly the command I need to send!

@Tony - I did think of that, however you get the error that the payload is read-only (I think it is constructed by ST from the various properties).

5

Just to add I also tried manually adding the required elements onto the formatted zwave command before it is returned from the associated command in the device handler, but no joy.

6

It’s actually doing nothing with the last four bytes. The 03 is giving the length of the binary switch command in bytes, which ST isn’t parsing. When you tried adding the command to the end of the formatted zwave command, did you include the length byte? Based on the spec, you should be appending “032501FF” to the formatted set schedule command.

Also, note that the spec says that startYear, startHour, and startMinute need to be set to 255, 31, and 63 as shown in the ST parse if they’re not being used.

My best guess would be to give this a try as your formatted zwave command for a 30 minute run time:

def cmdSchedule = zwave.scheduleV1.commandScheduleSet(scheduleId: 1, startYear: 0xFF, startHour: 0x1F, startMinute: 0x3F, durationByte: 30, durationType:0, numberOfCmdToFollow:1).format()
def cmdSwitch = zwave.switchBinaryV1.switchBinarySet(switchValue: 0xFF).format()
def cmd = "${cmdSchedule}03${cmdSwitch}"
7

Hi Phil

yes you are right in terms of it failing to parse the last four. And yes I did add the 03 byte count as well. I wasn’t setting any start times etc as per the zwave spec because it only supports a ‘start immediately’ and the spec says:

4.75.4.1 Start Time option: Start now
The start now option is used to make a configured schedule start immediately (upon reception of the
Schedule Set Command).
A node that supports the start now option, MUST support the creation of a schedule starting
immediately when all start time fields are left unspecified.

However your suggestion on the star times seems to have done the trick - can I ask where you saw that?

Either way thanks very much!

Andrew

8

You’re welcome! A little further down in 4.75.5.1, for example:

Start Year (8 bits)
This field is used to set the year for which the schedule is to start. This field MUST be in the range 0…99 or set to 0xFF. Values in the range 0…99 MUST indicate the actual year last 2 digits. A node MUST accept a value lower than the current year to allow schedules starting in the next century. The value 0xFF MUST be used to indicate that the start year is unspecified.

It lists values for other fields when unspecified, but these are the only three that are nonzero. They’re also the only three where a zero value has meaning, so it makes sense why they went this route. It would be nice if the ST object defaulted to the unspecified value for these instead of zero though.