It’s not a description, it’s a proven to operate exactly like this as per my logs above.
Then you are just mistaken. The binding does not work this way. As I said, the binding does not have any knowledge of any item so it cannot do what you have said it should do.
Chris, you can clearly see it doing exactly what I describe. I’ve been using it for over 12 months. How can I be mistaken?
Let me see if I can summarize
This device used to have both a switch_binary and a switch_dimmer channel
You could link these channels to OH Items of Switch and Dimmer type, respectively.
When something happened at the dimmer, whatever the cause, the new status would be reflected in both those Items states e.g. 70% and ON
The current database has lost the switch_binary
Never mind, can we link the remaining switch_dimmer channel to both Switch and Dimmer types?
Yes you can - but it “doesn’t work” in that the the Switch Item no longer gets updated for ON/OFF status.
It seems to me you want the switch_binary restored really.
1 Like
Sorry, then I give up. The binding does not do what you think it does. The binding does not know about items - it ONLY knows about channels. What you are describing is the functionality in the openhab core - this is where channels are linked to items.
The binding has not been doing this, so I’m afraid to say that you are mistaken.
rossko57, this is 100% accurate. Thank you.
Then this must be a problem in openhab mustn’t it? As I keep repeating above, the binding does not know anything about items.
Chris, OK.
I can provide you the binding version that absolutely does this and you can test it yourself.
Here it is:
It may be, and this is probably where the confusion lies - when I get a log, I look at what the BINDING does. I don’t tend to look at what the CORE does. As I have said, the binding does not manage items in anyway.
The CORE is identical between both versions.
2.4.0.
Sorry - I can only repeat myself - The binding does not manage ITEMS. It only handles CHANNELS.
Sorry - but I give up. I’ve tried to help here, and have spent a lot of my time tonight trying to help you when I’m really very busy, so I now need to finish other work.
Chris views the zwave database as something separate from the binding code.
@vzorglub @mhilbush @Bruce_Osborne @sihui am I going crazy? Have I lost my mind? What am I doing wrong
I’m not sure how that is relevant?
The bottom line is that bindings do not manage items, so I have no control over how a channel is mapped to an item. This is done in openhab core - not in the binding. It is not related to the database, or the code - the database only defines channels - not items. The user defines the items, and openhab core provides the links between the items and the channels. If a switch item is not being updated when a dimmer channel changes, then I don’t think that is a problem in the binding is it?
Clearly you guys do not believe me, and maybe I’m totally wrong here so please provide some insight into how the binding can impact this?
restoring the switch_binary channel I dont think will make a difference as in my working example, there are no items bound to it.
Maybe it will, I don’t know. But visually, it’s the only difference I can see between binding versions, despite Chris saying the binding has not changed.
If there is a bug, then shouldn’t we try and fix it? What the binding is doing is (as far as I understand) the correct implementation. A device should not provide both a switch channel and a dimmer channel - only a dimmer is required.
Sorry - it seems I now need to prove that I’m telling the truth?
So this is as I said earlier -:
This is clearly well before October when you said it was working.
Chris, if you have the means with a Aeotec Nano dimmer, test it using the binding I provided and 2.4.0.
That’s the only way I suspect, unless someone else can support my claims/issue
