Switch state doesnt turn on for a ZWave Dimmer when the Dimmer is turned on

No, I used to use the switch channel to display if its ON. Not to Dim the item.

Here, ill demonstrate the working system.

Absolutely the binding has changed, because here you see the presense of a switch_binary, which is no longer in ZW111 (this binding and screenshot is from 2.5.0 in October 2019)

Items;
Configured identical as the non working system


Switch FrontRoomSw1  "Front Room"                                    (Group_HabPanel_Dashboard,gLights_Random,gAllLights,gInsideLights,zWave)                      { channel="zwave:device:4296a94a:node26:switch_dimmer" }
Dimmer FrontRoomDim1 "Front Room [%d %%]"                            (Group_HabPanel_Dashboard,gAllDimmers,zWave)              [ "Lighting" ]                      { channel="zwave:device:4296a94a:node26:switch_dimmer" }

Heres the log showing the Dim command is sent, yet the Switch command turns on

09:17:35.845 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'FrontRoomDim1' received command 50
09:17:35.846 [INFO ] [arthome.event.ItemStatePredictedEvent] - FrontRoomDim1 predicted to become 50
09:17:35.848 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomDim1 changed from 0 to 50
09:17:37.979 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomSw1 changed from OFF to ON

Yes rossko57 and thats absolutely how it worked 2 months ago.

Yes, I would assume this is the case, but thatā€™s not what Iā€™ve been looking at here. What you are talking about should happen in openhab core. What Iā€™m looking at, and what I understand is the issue, is that @dastrix80 wants to send an ON/OFF command to the device.

No, thats absolutely what we are looking at and what Iā€™m trying to explain.

Iā€™ve mentioned im using OH2.4.0 stable. Systems are identical. ZWave binding is not, because the old ZWave Binding doesnt have ZW111 of hardware type 0204:006f or whatever it was. So I cannot revert to the old binding which worked.

Ok, Iā€™m totally lost.

The bottom line is that a dimmer item will accept both a SWITCH or DIMMER command type. If you send a SWITCH type, then the ZWave binding will send an OnOff command. If you send a DIMMER command, then the binding will send a Multilevel command. This is the same as it always has been except you used to have two different channels. Now there is one channel, but it should be exactly the same functionality.

I understand that you want to turn the light off, and you want to use the switch channel to do thiat, but in the log, you are sending a dimmer command -:

The binding is therefore sending a mulitlevel command to the switch - this all looks correct to me. If you want to send an OnOff command, then you should use a switch - again, this is the same as it always was.

There has been no change to the ZWave binding code, and certainly nothing in this area for a long time. Neither converters have changed for a long time - the multilevel converter changed in May, and the switch converter changed in August last year (so before 2.4 was released even).

I donā€™t think this is related to the binding at all - this is all handled in openhab as far as I know. If you set a channel to 50%, then it should be ON - again, to me that seems correct. Do I understand that you want this to show OFF, even though the dimmer is at 50%?

If there has been no change to the binding code, why does version 2.5.0.201910071835 have switch_binary channel as per my screenshot above?

Yet build #846 has no such channel for the same item?

No, I donā€™t want the item to show OFF if the dimmer is at 50%. And no, I do not want to turn the light off using a switch item.

I want the Switch Item to follow the Dimmer item. Thatā€™s all, nothing more.

May I suggest a different demonstration? Turn the knob or push the button or whatever, and capture the status update sent to openHAB that you you hope would update both your linked Dimmer Item to xx% and the linked Switch Item to ON/OFF, as appropriate.

Possibly the database has changed, but that doesnā€™t change functionality, just the available channels.

But it is isnā€™t it? Sorry - Iā€™m confused - you set the dimmer above to 50%, and the switch shows ON. What do you want to have here? OFF? Sorry - but I donā€™t understand the issue.

Sure.

This is the same demonstration. ON command to the Switch item, Dimmer item turns to 50 (last remembered position)

09:33:30.704 [INFO ] [arthome.event.ItemStatePredictedEvent] - FrontRoomSw1 predicted to become ON
09:33:30.705 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomSw1 changed from OFF to ON
09:33:30.706 [INFO ] [home.event.GroupItemStateChangedEvent] - gInsideLights changed from OFF to ON through FrontRoomSw1
09:33:30.706 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllLights changed from OFF to ON through FrontRoomSw1
09:33:32.498 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomDim1 changed from 0 to 50
09:33:32.499 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllDimmers changed from OFF to ON through FrontRoomDim1

Sorry - but what is this doing? All I see here is the dimmer at 50%, and the switch showing ON - what are you expecting?

(hint -clarify when the demo is of the ā€œold workingā€ setup and when it is for the ā€œnew unexpectedā€ setup)

hint: Say what you expect to happen as well :wink:

Sorry, im not sure how much more clear I can be.

09:33:30.704 [INFO ] [arthome.event.ItemStatePredictedEvent] - FrontRoomSw1 predicted to become ON
09:33:30.705 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomSw1 changed from OFF to ON
09:33:30.706 [INFO ] [home.event.GroupItemStateChangedEvent] - gInsideLights changed from OFF to ON through FrontRoomSw1
09:33:30.706 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllLights changed from OFF to ON through FrontRoomSw1
09:33:32.498 [INFO ] [smarthome.event.ItemStateChangedEvent] - FrontRoomDim1 changed from 0 to 50
09:33:32.499 [INFO ] [home.event.GroupItemStateChangedEvent] - gAllDimmers changed from OFF to ON through FrontRoomDim1

This (above) demonstrates a working system on the Zwave binding from October.

This (below) demonstrates a non working system, on a ZWave binding from this week.

OpenHab versions are the same. Hardware is the same Model.

08:49:39.436 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'MasterBed_Dimmer1' received command 0
08:49:39.443 [INFO ] [arthome.event.ItemStatePredictedEvent] - MasterBed_Dimmer1 predicted to become 0
08:49:40.761 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'MasterBed_Dimmer1' received command 70
08:49:40.769 [INFO ] [arthome.event.ItemStatePredictedEvent] - MasterBed_Dimmer1 predicted to become 70
08:49:40.782 [INFO ] [smarthome.event.ItemStateChangedEvent] - MasterBed_Dimmer1 changed from 0 to 70

Notice the LACK OF ITEM channel being set to ON when the Dimmer item receives a command in the example ABOVE?

here is a working Zwave debug

Node26.txt (43.5 KB)

Correct - there is no switch channel so obviously this will not happen. There is only a switch item, and that should be set to ON if you display it in a sitemap.

This is how OH is meant to be used. There should not be both a switch and a dimmer - only one is needed as far as the binding is concerned.

The switch channel has nothing to do with it.

The old system, the new system, its not being used.

Both Items are bound to the dimmer channel, yet they are different.

The debug also shows they are different:

WORKS (below)


2019-12-05 08:49:39.606 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 25: SendData Request. CallBack ID = 68, Status = Transmission complete and ACK received(0)
2019-12-05 08:49:39.606 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 25: resetResendCount initComplete=true isDead=false
2019-12-05 08:49:39.608 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 25: Response processed after 161ms
2019-12-05 08:49:39.608 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 25: TID 629: Transaction completed
2019-12-05 08:49:39.608 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 25: notifyTransactionResponse TID:629 DONE
2019-12-05 08:49:39.609 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 25: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-12-05 08:49:40.767 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 25: Command received zwave:device:4711b0e7:node25:switch_dimmer --> 70 [PercentType]
2019-12-05 08:49:40.769 [DEBUG] [col.commandclass.ZWaveMultiLevelSwitchCommandClass] - NODE 25: Creating new message for command SWITCH_MULTILEVEL_SET
2019-12-05 08:49:40.769 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 25: SECURITY not supported
2019-12-05 08:49:40.769 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 25: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2019-12-05 08:49:40.771 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 25: Adding to device queue
2019-12-05 08:49:40.776 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 25: Added 630 to queue - size 4

Doesnt work (BELOW)

2019-12-05 09:46:23.598 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2019-12-05 09:46:23.598 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2019-12-05 09:46:23.598 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2019-12-05 09:46:23.598 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2019-12-05 09:46:23.598 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_BASIC V1 BASIC_REPORT
2019-12-05 09:46:23.598 [DEBUG] [ernal.protocol.commandclass.ZWaveBasicCommandClass] - NODE 26: Basic report, value = 70
2019-12-05 09:46:23.598 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-12-05 09:46:23.598 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BASIC, value=70
2019-12-05 09:46:23.598 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:4296a94a:node26:switch_dimmer to 70 [PercentType]
2019-12-05 09:46:23.598 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2019-12-05 09:46:23.598 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1f9cd940.
2019-12-05 09:46:24.322 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling...
2019-12-05 09:46:24.323 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling zwave:device:4296a94a:node26:switch_dimmer
2019-12-05 09:46:24.323 [DEBUG] [.internal.converter.ZWaveMultiLevelSwitchConverter] - NODE 26: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0

:confounded: Why did you say then ā€œNotice the LACK OF SWITCH channel being set to ONā€?

Iā€™m sorry, but Iā€™m totally confused as to what your issue is.

Arenā€™t these two different things? One is a command from OH to the device, and the second is a report from the device to OH.

Iā€™ve said before, but please describe what you expect to happen.

Unfortunately I donā€™t really think I can help here - sorry.

Can someone please help Chris understand the issue? I donā€™t know what Iā€™m doing wrong.

Switch Item, not switch channel. My mistake.

Here is a description of what used to happen, and what SHOULD happen in the new binding.

When two

items

are created, one of type Switch and one of type Dimmer that when the Dimmer item has a command send to it of between 1 and 100, then it should turn ON the corresponding Switch item. Both items link to channel switch_dimmer

When the Dimmer item receives a command of 0, it should turn OFF the Switch item.

Where did you get this description from? The binding will not do this - the binding knows nothing at all about items so it is absolutely unable to change an item state - it ONLY deals with channels. OH may do what you say above, but not the binding.

I think the documentation you quote above is probably incorrect due to this.