Dimmer association and physical inputs are not being registered

Setup, Configuration and Use Runtime
21

Ok, I’m running the snapshot now, and the zwave version reports as “2.0.0.201607180103”.

This version seems to have quieted down the debug chatter a little bit in terms of getting the thing added. Unfortunately making changes with the physical switch (the dimmer adjustments register fine) doesn’t seem to provide any feedback to OH. In fact, pressing the physical switch doesn’t even seem to register anything in with debugging turned on, unless I’m reading it wrong. I was tailing the log and watching it when I physically toggled it off and on.

I uploaded a new log (here: https://dl.dropboxusercontent.com/u/11926364/openhab-new.log) if you are curious to see the new behavior. Kind of a bummer overall (not that it’s your fault at all). One of the reasons I went with z-wave was because I thought the protocol being standardized would lead to these devices “just working”. But this has been a monster struggle just to get a toggle switch to properly report state. I suppose it could just be my switch as well, but in the past everything I’ve read is people using polling and stuff like that. Never mind getting it to return to the previous brightness state when toggling.

As usual, thanks for all your efforts in helping me.

22

I’ll take a look this evening, but make sure that the association is still set. The binding can’t really change what the device sends, so as long as the association is set, then there shouldn’t be any change from before.

23

Actually, a quick look at the log seems like it’s working -:

Looking at the following log, this shows an incoming off command. There’s no command sent from the binding before this, and it is preceeded with the NIF, so I assume therefore that this is from the device following a manual state change. This seems to indicate that the channel zwave:device:zwave:node3:switch_dimmer gets set to o (ie OFF) and this wasn’t working before as this is a BASIC command.

To me this looks like it’s working from the binding perspective at least.

2016-07-18 18:13:16.342 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-07-18 18:13:16.345 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-07-18 18:13:16.345 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-07-18 18:13:16.345 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-07-18 18:13:16.345 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 
2016-07-18 18:13:16.347 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 03 03 20 01 00 D3 
2016-07-18 18:13:16.347 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 3: Application update request. Node information received.
2016-07-18 18:13:16.349 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2016-07-18 18:13:16.349 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@7891fccb already registered
2016-07-18 18:13:16.349 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=27, payload=03 03 26 01 39 
2016-07-18 18:13:16.350 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 
2016-07-18 18:13:16.351 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=27, expected=SendData, cancelled=false      MISMATCH
2016-07-18 18:13:16.351 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-07-18 18:13:16.351 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 03 03 20 01 00 D3 
2016-07-18 18:13:16.352 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 03 03 20 01 00 D3 
2016-07-18 18:13:16.353 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 03 20 01 00 
2016-07-18 18:13:16.353 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2016-07-18 18:13:16.353 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2016-07-18 18:13:16.354 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@7891fccb already registered
2016-07-18 18:13:16.354 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class BASIC
2016-07-18 18:13:16.356 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Received Basic Request
2016-07-18 18:13:16.357 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Basic Set sent to the controller will be processed as Basic Report
2016-07-18 18:13:16.358 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 3: Basic report, value = 0x00
2016-07-18 18:13:16.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-07-18 18:13:16.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-07-18 18:13:16.360 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2016-07-18 18:13:16.361 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:zwave:node3:switch_dimmer to 0 [PercentType]
2016-07-18 18:13:16.363 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=3, callback=27, payload=03 03 26 01 39 
2016-07-18 18:13:16.363 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 03 20 01 00 
2016-07-18 18:13:16.369 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=27, expected=SendData, cancelled=false      MISMATCH
24

@chris should all zwave devices have openhab in association group #1? I cleared my mapdb with all the fun from the changes in the OH2 last week and have been having issues as well and noticed that the group 1 associations are blank. Haven’t had time to try to debug anything else yet

25

No - it depends on the device. Different manufacturers use different groups for different functions. The database specifies if OH should be added to a certain group or not.

As per the above, it looks to me like the association is set. Note that what you see in HABmin might not be 100% representative of the real device configuration depending on the initialisation stage. If initialisation is complete, then it should reflect the correct device configuration.

26

Thanks. I’m start pulling some debug logs tonight to see if we can figure out what is going on with my system since I have the same Cooper dimmers

27

Hey @chris, wanted to chime in again.

I flushed my log file and went through a pretty simple process consisting of the following sequence of events:

Light off
Start openHAB
Physically turn light on.
Physically dim light
Physically turn light off.

I agree with you that the controller (and debug logs) appear to reflect all of these inputs, so I’m really stoked about that.

I think now that the disconnect is probably with respect to how the item entries are configured. The “dimmer” item type appears to properly reflect state for me now, but the “switch” type does not.

I’m admittedly a bit vague on the proper way to configure an item now that openhab2 has this new “channels” go between. In openhab1 I had certain flags in place in the item definition to get stuff like the switch item returning the lights to last state (of brightness), versus it going up to 100% every time.

In openhab 2, turning the switch on sends it to 100%. I thought that defining the item with the channel reference would be enough, but perhaps this is not the case, and there just isn’t adequate documentation regarding this yet.

My items are defined as below:

Dimmer FamilyRoom_Light_Dimmer "Dimmer [%d %%]" <slider> (gFamilyRoom,gLights) { channel="zwave:device:zwave:node3:switch_dimmer" }
Switch  FamilyRoom_Light  "Recessed Lights"  <light>  (gFamilyRoom, gLights)  { channel="zwave:device:zwave:node3:switch_dimmer" }

In any case, this might be beyond the scope of this particular topic, but I wanted to give you some reassurance that I definitely think we’re in a better spot than we were a few days ago… it’s just down to this last little bit for me personally.

Thanks for all your help. This kind of involvement is why I keep using OH.

28

Personally, I would just use a single item. This is a Dimmer, so I would recommend only using a dimmer and not confusing things with multiple items.

Now you’re probably thinking I’m mad as you also want a switch. This however is a different issue - what is rendered in the sitemap is a widget, and you can render a switch, or a slider, both against the same item -:

Slider item=FamilyRoom_Light_Dimmer
Switch item=FamilyRoom_Light_Dimmer

There’s no need to have two items to do what you want…

No for the question of fags to set the last state - this isn’t something that is implemented at the moment. This needs a configuration option to be supported and I’ll need to add this.

29

Haha, nah not mad. I’ve considered it myself actually. That maybe I’m trying to get too cute with the whole situation.

I’ll switch over to a single item definition to simplify, and probably just roll with the dimmer-only for the time being.

The “last state” support would be awesome, but really is only necessary with a switch item, anyway. Looking forward to this support being added.

I feel like we should mark this as solved, so I’m going to mark the post where you said you’d released an updated. Let me know if I shouldn’t do this.

Thanks again for everything.