Hortsmann SIR-321 ( will not stay on )

The problem I have is that the device automatically switches off after 1 minute even though switch is in on position in OH.

In the item file the Switch declaration is there alongside with the Sensor channel.
The sensor channel is working fine.
The issue I have is that when I switch the “Switch” channel from OH or the physical device it will turn on for at most 1 minute, it looks like it switches off during the periodic polling of the device, i.e. after 1 minute at most.
I don’t know how I can resolve this, am I just missing out on some fundamental configuration relating to the state/status of the device that needs to be persisted/updated or could there be some other issue at a lower level?

My ultimate goal here is to replicate the physical run back time in OH by possibly providing 1 or 2 countdown time interval. I have seen examples of how to do this using a rule and virtual switch so this should not present a problem once I find the root cause of my initial issue.

Below is the output of the log file from when I switch on the device via the UI until the device switches to the off state when polling occurs.

openhab@s1:/opt/openhab2/conf/items$ cat run_back_device.items
Switch Run_Back_Switch “Boiler Switch” (Heating) {channel=“zwave:device:a863ae3c:node3:switch_binary”}

Number Run_Back_Temp “Hall Temp [%.1f C]” (Heating) {channel=“zwave:device:a863ae3c:node3:sensor_multilevel”}

openhab.log

2017-04-21 22:40:27.355 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Command received zwave:device:a863ae3c:node3:switch_binary --> ON
2017-04-21 22:40:27.355 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 3: Creating new message for application command SWITCH_BINARY_SET
2017-04-21 22:40:27.355 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-04-21 22:40:27.355 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-04-21 22:40:27.356 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 03 03 25 01 FF 25 6D 75
2017-04-21 22:40:27.356 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 3: Sending REQUEST Message = 01 0A 00 13 03 03 25 01 FF 25 6D 75
2017-04-21 22:40:27.363 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2017-04-21 22:40:27.364 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:40:27.364 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2017-04-21 22:40:27.364 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2017-04-21 22:40:27.364 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2017-04-21 22:40:27.364 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: Sent Data successfully placed on stack.
2017-04-21 22:40:27.380 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 6D 00 00 02 84
2017-04-21 22:40:27.381 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:40:27.381 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 6D 00 00 02 00 00 8A
2017-04-21 22:40:27.381 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 6D 00 00 02 00 00 8A
2017-04-21 22:40:27.381 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=6D 00 00 02
2017-04-21 22:40:27.381 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: SendData Request. CallBack ID = 109, Status = Transmission complete and ACK received(0)
2017-04-21 22:40:27.381 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:40:27.381 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:40:27.382 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=109, payload=03 03 25 01 FF
2017-04-21 22:40:27.382 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=6D 00 00 02
2017-04-21 22:40:27.382 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=109, expected=SendData, cancelled=false transaction complete!
2017-04-21 22:40:27.382 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-04-21 22:40:27.382 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2017-04-21 22:40:27.382 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 3: Response processed after 26ms/274ms.

2017-04-21 22:41:09.277 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 03 06 31 05 01 22 00 BC 59
2017-04-21 22:41:09.277 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:41:09.277 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 03 06 31 05 01 22 00 BC 59
2017-04-21 22:41:09.277 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 03 06 31 05 01 22 00 BC 59
2017-04-21 22:41:09.277 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 06 31 05 01 22 00 BC
2017-04-21 22:41:09.278 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2017-04-21 22:41:09.278 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:41:09.278 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:41:09.278 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class SENSOR_MULTILEVEL
2017-04-21 22:41:09.278 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 3: Received COMMAND_CLASS_SENSOR_MULTILEVEL command V1
2017-04-21 22:41:09.278 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 3: Sensor Multi Level REPORT received
2017-04-21 22:41:09.278 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 3: Sensor Type = Temperature(1), Scale = 0
2017-04-21 22:41:09.278 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 3: Sensor Value = 18.8
2017-04-21 22:41:09.278 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveMultiLevelSensorValueEvent
2017-04-21 22:41:09.278 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2017-04-21 22:41:09.278 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_MULTILEVEL, value = 18.8
2017-04-21 22:41:09.278 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 3: Sensor is reporting scale 0, requiring conversion to 0. Value is now 18.8.
2017-04-21 22:41:09.278 [DEBUG] [converter.ZWaveCommandClassConverter] - Converted temperature from 18.8C to 18.8C
2017-04-21 22:41:09.279 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:a863ae3c:node3:sensor_temperature to 18.8 [DecimalType]
2017-04-21 22:41:09.279 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=109, payload=03 03 25 01 FF
2017-04-21 22:41:09.279 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 06 31 05 01 22 00 BC

2017-04-21 22:41:09.279 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=109, expected=SendData, cancelled=false MISMATCH

There’s not a lot to say - the log doesn’t show much -:

I would check the manual to see if it provides any information about what is needed to support the device in case it’s looking for something from the controller.

Looking at the manual, I would check the value of parameter 1. It states this is a failsafe timer - I’m not exactly sure what this means, but it might turn things off after a specific time (just a guess).

I’ve tried adjusting config 1 several times i.e.
1: Setting it to 0 which should disable the fail safe timer.
2: Setting it to 1 which should enable it.
3: Setting it to a value of 120 which should set to either 120 mins or seconds.

When I switch via OH the LED on the physical device switchs to the 120+ LED which id say is correct as the OH switch is a latching type and not push button to step through the 3 options like on the physical switch.

Sorry - in that case I don’t know. The log doesn’t have any information that’s of use - the device doesn’t send anything. It might be looking for something earlier that it’s not getting.

@chris

Posting the continued part of that log below in case there is anything in that as it was concatenated previously.
I dont see any errors either.

2017-04-21 22:41:09.279 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=109, expected=SendData, cancelled=false MISMATCH
2017-04-21 22:41:35.282 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 1E 00 01 03 25 01 FF 8D
2017-04-21 22:41:35.294 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:41:35.294 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 1E 00 01 03 25 01 FF 8D
2017-04-21 22:41:35.295 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 1E 00 01 03 25 01 FF 8D
2017-04-21 22:41:35.295 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 1E 00 01 03 25 01 FF
2017-04-21 22:41:35.295 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2017-04-21 22:41:35.295 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:41:35.295 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:41:35.295 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class SCHEDULE
2017-04-21 22:41:35.295 [DEBUG] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Received SCHEDULE command V1
2017-04-21 22:41:35.295 [WARN ] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Unsupported Command 5 for command class SCHEDULE (0x53).
2017-04-21 22:41:35.295 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=109, payload=03 03 25 01 FF
2017-04-21 22:41:35.296 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 1E 00 01 03 25 01 FF
2017-04-21 22:41:35.296 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=109, expected=SendData, cancelled=false MISMATCH
2017-04-21 22:41:36.732 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 3C 00 01 03 25 01 FF AF
2017-04-21 22:41:36.732 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:41:36.732 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 3C 00 01 03 25 01 FF AF
2017-04-21 22:41:36.732 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 3C 00 01 03 25 01 FF AF
2017-04-21 22:41:36.733 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 3C 00 01 03 25 01 FF
2017-04-21 22:41:36.733 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2017-04-21 22:41:36.733 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:41:36.733 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:41:36.733 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class SCHEDULE
2017-04-21 22:41:36.733 [DEBUG] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Received SCHEDULE command V1
2017-04-21 22:41:36.733 [WARN ] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Unsupported Command 5 for command class SCHEDULE (0x53).
2017-04-21 22:41:36.733 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=109, payload=03 03 25 01 FF
2017-04-21 22:41:36.733 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 3C 00 01 03 25 01 FF
2017-04-21 22:41:36.733 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=109, expected=SendData, cancelled=false MISMATCH
2017-04-21 22:41:37.683 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF EB
2017-04-21 22:41:37.683 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:41:37.683 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF EB
2017-04-21 22:41:37.683 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 18 00 04 00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF EB
2017-04-21 22:41:37.684 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF
2017-04-21 22:41:37.684 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2017-04-21 22:41:37.684 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:41:37.684 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:41:37.684 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class SCHEDULE
2017-04-21 22:41:37.684 [DEBUG] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Received SCHEDULE command V1
2017-04-21 22:41:37.684 [WARN ] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Unsupported Command 5 for command class SCHEDULE (0x53).
2017-04-21 22:41:37.684 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=109, payload=03 03 25 01 FF
2017-04-21 22:41:37.684 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 12 53 05 01 00 FF 30 00 00 1F 3F 00 78 00 01 03 25 01 FF
2017-04-21 22:41:37.684 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=109, expected=SendData, cancelled=false MISMATCH
2017-04-21 22:41:38.182 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 14 00 04 00 03 0E 53 05 01 00 00 00 00 00 00 00 00 00 00 00 B5
2017-04-21 22:41:38.182 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-04-21 22:41:38.182 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 14 00 04 00 03 0E 53 05 01 00 00 00 00 00 00 00 00 00 00 00 B5
2017-04-21 22:41:38.182 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 14 00 04 00 03 0E 53 05 01 00 00 00 00 00 00 00 00 00 00 00 B5
2017-04-21 22:41:38.182 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 0E 53 05 01 00 00 00 00 00 00 00 00 00 00 00
2017-04-21 22:41:38.183 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2017-04-21 22:41:38.183 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2017-04-21 22:41:38.183 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@773be2c9 already registered
2017-04-21 22:41:38.183 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class SCHEDULE
2017-04-21 22:41:38.183 [DEBUG] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Received SCHEDULE command V1

2017-04-21 22:41:38.183 [WARN ] [mmandclass.ZWaveScheduleCommandClass] - NODE 3: Unsupported Command 5 for command class SCHEDULE (0x53).

What version of the binding are you using?
Also, please format logs with the </> button so they are more readable.

Apologies, I’m working off the phone at the minute so formatting etc. may not be up to standard.

I’ll check the version later but I was working off the snapshot distribution download last week so it should be recent.

Interesting, I found a topic here on a different forum which I think suggests the GET causes the switch to go to the OFF state. Firmware issue perhaps.

Hi there. I’m using this device with Smartthings and discovered that the following command turns the switch off : zwave.switchBinaryV1.switchBinaryGet().format()
Instead I now use a variable and populate and the issue has gone:
def switchval = outlets.currentValue(“switch”)

Hope this helps you as it seems you may be experiencing something similar with polling/refreshing the status of the switch…

If I understand this correctly, it’s not the switch that changes state - it’s just that the GET returns off if it’s requested shortly after the SET is sent. They then delay and send another GET later and it works.

The switch still toggles on, then automatically off again, then on again the next time it is polled but at least it does eventually get to the right state.

Maybe I misread this, but it seems that this is just that the first GET straight after the SET returns OFF still. This isn’t uncommon, but it’s not the problem you have - in your case the switch is actually switching off (right?).

Yes the physical device actually switches off, the relay drops out but the LED and OH UI still shows that the device is ON.
It can’t be any physical overload relay in the device as when the device is unpaired from the zwave controller it will function as expected as a standalone device.

2.1.0-snapshot is the binding version

I see there is a SCHEADULE command listed in the doc, would this be how the timeout should be set?
Would this be part of the .item configuration that I’m missing?

This command class isn’t currently supported by the binding. I’d suggest to scan around the web and see what you can find out - ie if this command class is the problem. Or, possibly even drop the manufacturer a message. If it’s the problem, then I’ll increase the priority on implementing the parts required.

Thanks for the feedback on that Chris.
I just emailed the manu. office in the U.K. but I’d be surprised if they respond with any tech. info.
I guess if that class is not currently supported then it’s fairly cut and dry, device defaults to the minimum 1 minute interval.

I’m glad that I’m “thrown in the deep end” with my choice of device, steep quick learning curve.

Why do you say that? There’s hundreds of command classes - many aren’t used. It could well be the case that this device requires this class, but I certainly wouldn’t assume it’s the case just because it’s not supported at the moment.

My statement was based on what I saw in the device manual as the SCHEADULE class had references to setting the timeout for the device. Page 27 of the link to the manual.

This is the specific piece of text from that:
Schedule Supported Get Schedule Set
Schedule Get
Schedule Remove Schedule State Get
Schedule ID: 0x01
Supported CC : Binary Switch SET command Type of Schedule : Start now
Duration type : Minutes
Maximum schedule duration: 1440 minutes
Note: No override and fallback mode is supported. The binary switch set command and pressing the BOOST button will over ride the schedule & vice - versa.

Obviously I’m new to zwave and OH so I could well be wrong but it seemed a reasonable logical conclusion as we had ruled out lots of other causes.

Hopefully the manufacturers will reply to my mail which might shed some further light.

Ok, let’s see what/if they reply. I’ve had good success with getting information from some suppliers, and not so much off others, so let’s see…

The question though isn’t just about implementing this class - the question really is what (if anything) the device is expecting to see. For most command classes, the controller initiates the transmission so we know what we want to do, and what we expect back. In this case, if the device is asking for something in order to work, then implementing the command class may not help…

@chris Good news :slight_smile:

I have not heard back from the manufacturer but I did take another look at the manual.
The cause of the device switching off after ~1 min was as a result of field 5 being incorrectly configured by a factor of 10.
I had set the field to 22 to correspond to 22 deg celsius, the resolution/scaling factor was 0.1 therefore the value I set was actually 2.2 deg celsius.
Changing the field to 220 solved my issue.
I just need to sort out my virtual switch now to properly switch off the device after x minutes.

As you correctly pointed out the SCHEDULE class will not be needed in this case as the virtual switch workaround should suffice.

Thanks for your help.