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)
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, 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.
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%?
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.
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
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?
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.
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.