Configuring ZWave Scenes

I’m not clear how ZWave scenes work in OpenHAB 2. Are they supported? It seems that in version 1 it was done via rules. Is that still the case?

With the latest build I’m unclear what I should do with ZWave devices which have channels to either respond to a scene or can send a scene command. The scene channels are defined as numbers, but how does one get either device to respond to or generate a specific scene command?

Specifically I have a Leviton appliance switch which will respond to a scene command, and the Homeseer HS-WD100+ which can send a ZWave scene with a double tap (which appears to be supported).

Happy to add this information to the documentation efforts.

1 Like

Currently you can trigger a rule from a scene controller in the same way as was done in OH1. There is a scene_number channel that will be updated whenever the scene is triggered from the scene controller, and you can use this to run a scene.

Programming ZWave scenes on devices isn’t supported on OH1 or OH2, and likewise, triggering a scene on a device wasn’t supported on OH1 either (or OH2 at the moment but we can always change that).

@chris, thanks for clarifying. I just wanted to make sure I wasn’t missing anything.

The rules should work just fine for my current needs.

@chris, looks like the device I’m using (Homeseer HS-WD100+) uses the central scene class to send scene commands and also provide an instant status workaround.

Is central scene support still a work in progress, or is there a way to hook into that via rules? I tried setting a rule on the scene number channel but it never seems to update.

central_scene is supported in the same way as scene_activation. I note that the WD100+ doesn’t have a channel defined in the database for scene_activation at the moment - only central_scene, so I guess it can send either?

So with central_scene, I should be able to write a rule triggered on that channel?

I created the following rule, but it never gets run even when I see in the logs that the biding is receiving a a central_scene command.

I wonder if the device database is incorrect and the scene number channel isn’t wired to the central_scene command? I wasn’t sure how to tell this from the database.

rule "Check Lights"
when
  Item zwave_device_7beacf31_node13_scene_number2 changed or
  Item zwave_device_7beacf31_node13_scene_number2 received update or
  Item zwave_device_7beacf31_node13_scene_number2 received command or
then
  logInfo("garagelights","##### zwave_device_7beacf31_node13_scene_number2 changed")

Logs show

2016-05-27 16:10:39.225 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 08 0D 05 5B 03 69 03 01 C3 
2016-05-27 16:10:39.233 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-05-27 16:10:39.238 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0B 00 04 08 0D 05 5B 03 69 03 01 C3 
2016-05-27 16:10:39.240 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 0D 05 5B 03 69 03 01 CB 
2016-05-27 16:10:39.242 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0B 00 04 08 0D 05 5B 03 69 03 01 C3 
2016-05-27 16:10:39.246 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=08 0D 05 5B 03 69 03 01 
2016-05-27 16:10:39.248 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Application Command Request (ALIVE:DONE)
2016-05-27 16:10:39.250 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 13: Starting initialisation from DONE
2016-05-27 16:10:39.252 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@15f15c9 already registered
2016-05-27 16:10:39.254 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Incoming command class CENTRAL_SCENE
2016-05-27 16:10:39.256 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 13: Received CENTRAL_SCENE command V1
2016-05-27 16:10:39.258 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 13: Received scene 1 at time 3
2016-05-27 16:10:39.260 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-05-27 16:10:39.261 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-05-27 16:10:39.263 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = CENTRAL_SCENE, value = 1
2016-05-27 16:10:39.265 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Transaction not completed: node address inconsistent.  lastSent=12, incoming=255
2016-05-27 16:10:39.268 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-05-27 16:10:39.272 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0B 00 04 00 0D 05 5B 03 69 03 01 CB 
2016-05-27 16:10:39.277 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0B 00 04 00 0D 05 5B 03 69 03 01 CB 
2016-05-27 16:10:39.282 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0D 05 5B 03 69 03 01 
2016-05-27 16:10:39.284 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Application Command Request (ALIVE:DONE)
2016-05-27 16:10:39.286 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 13: Starting initialisation from DONE
2016-05-27 16:10:39.288 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@15f15c9 already registered
2016-05-27 16:10:39.290 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Incoming command class CENTRAL_SCENE
2016-05-27 16:10:39.292 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 13: Received CENTRAL_SCENE command V1
2016-05-27 16:10:39.293 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 13: Received scene 1 at time 3
2016-05-27 16:10:39.295 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-05-27 16:10:39.297 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-05-27 16:10:39.299 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = CENTRAL_SCENE, value = 1
2016-05-27 16:10:39.301 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Transaction not completed: node address inconsistent.  lastSent=12, incoming=255

When I said earlier “I note that the WD100+ doesn’t have a channel defined in the database for scene_activation at the moment - only central_scene” - I got that around the wrong way. It only has scene_activation - not central_scene.

Sorry for the confusion…

Got it thanks, that makes sense. I’ll (try) to update the database.

I’ve just done it (swapped the two scene classes around)… Let’s see if we get further tomorrow :slight_smile:

@chris, thanks for updating the database – it now works. A rule can now pick up the scene command.

I have two related follow-up questions related to some trickery of this new switch.

  1. Can a rule (or other method) tell the ZWave binding to requery the state of a device? To get around the instant status patent (I presume), this switch sends a central_scene command when the switch is changed locally. To get OpenHAB to see this I created a rule to do a posUpdate, but it’s not perfect (and I don’t believe will handle dimming).

  2. Is it possible to get the time value of the central_scene command (as displayed in the scene_set case statement in handleApplicationCommandRequest)? This switch allows for a double tap which sends only a central_scene command and doesn’t turn the local load on. Unfortunately it sends the same scene number as a single tap, but with a different time value (why couldn’t they just send a different scene number?!?).

Yes - you need to send a command with RefreshType.REFRESH as the value.

See the discussion here -:

No - I’m not sure how to pass this data to an item since an item can only contain a single value. I’m open to any ideas, but maybe we need to define a new data type at some stage that can better handle scenes (ie not just the time field).

Thanks for pointing me to that threat, the refresh command did the trick.

Since there seems to be a few devices that need a refresh as a result of an update – would it make sense to add this to the binding? Either through a device database flag per channel or a config setting in the UI (maybe using a tag)?

Regarding the central_scene, what about adding another channel that provides the scene number and time concatenated e.g (01003) – something like central_scene_raw? I think alarm type channels could benefit from this as well. I’m assuming this is simpler than trying to add new properties to items in the system?

Yes - this is the plan. There are hooks in the binding to do this.

We could do this, but it’s messy! It might work as a stopgap, but it would be better to try and do something ‘properly’.

Why?

Easier, yes. As above, it’s messy and I think it’s better to define proper concepts to handle this sort of thing rather than hacking something that will remain a bodge for years to come.

I think alarm type channels could benefit from this [raw data] as well.

Why?

Instead of just an On/Off for an alarm channel, I’d like to get the actual alarm code. For example the lock that’s been giving me so much grief reports various device events through the alarm channel.

As above, it’s messy and I think it’s better to define proper concepts to handle this sort of thing rather than hacking something that will remain a bodge for years to come.

Makes complete sense. I’ll wait patiently :slight_smile:

Yes, I agree, and this will be supported, but not through a “raw data” channel. The new notification class will support these events - it’s different than the alarms…

@grizzlyjere

For what its worth, I did implement the CENTRAL_SCENE command in openhab V1 to accommodate the HomeSeer switches. I’m using both the HS-WD100+ dimmers and HS-WS100+ switches in my home. It does have the means to create items that include both the “scene” number and “key” identifier. Both of these are needed to interpret the HomeSeer double-tap and triple-tap events.

Take a look at my pull request comments you can see an example of the item definitions for all the HomeSeer switch events.

https: //github.com/openhab/openhab/pull/4431

I realize this may not help you for openHAB2, but maybe open up more discussion about how to implement this going forward.

Thanks, Robert

Thank you for this. Just picked up some of the HomeSeer HS-WD100+ swiches. Please excuse the ignorance, but how would you teach OH what each scene should be - by creating rules?

Edit: also- does anyone know which version of the z-wave binding is required to support these dimmers/switches?

The latest OH2 snapshot now sends the timing information with the scene channel. So for example, when pressing On at the switch the scene command will receive “1.0”. A couple tap on will receive “1.3” if memory serves me correctly.

You can then use a rule on the scene channel to sort out how you’d like to handle the various scene commands from the switch.

For example, the following rule turns on my secondary lights if the light switch it turned on, or the on switch is double tapped. It turns them off then the main light switch is turned off, or the of switch is double tapped.

  if(garage_lights_scene.state.toString == "1.0" || garage_lights_scene.state.toString == "1.3")
  {
    logInfo("garagelights1","## Garage Lights On")
    sendCommand(garage_overhead_switch,"ON")
  }
  if(garage_lights_scene.state.toString == "2.0" || garage_lights_scene.state.toString == "2.3")
  {
    logInfo("garagelights1","## Garage Lights Off")
    sendCommand(garage_overhead_switch,"OFF")
  }

There’s a good example here -: