Hate to be pest but I noticed the
ZSE18 Motion and Vibration Sensor
also has the controller permanently in group 2. Could you see if that is also a DB issue?
Thanks
Done.
Not sure what happened. I know there war a recent database restore but that should not have done this.
Thanks again.
I would note that these fixed associations of controller in Group 2 go back quite a bit (months)
I overlooked this during first approval in 2018 
1 Like
When will the these fixes be available. And how do I update them? I tried searching, but I seemed to find different answers and dead links?
That depends on when busy @chris exports the database so the new snapshot bindings get the changes. It appears my last changes were after his last export.
@sihui
I would love to mark the thread as SOLVED, While i’m waiting on the latest snapshot with the changes on
Namron, I included three new Namron Dimmers, but this time I even got the wrong binding.
That entry has not changed since openHAB 2.5.3.
This is not a database problem as the manufacturer id is different.
1 Like
I’m not sure I follow…
My Namron dimmers says ID:0202:0002, and the first one did get the correct entry a couple of weeks ago
Now there’s a new entry in the database (EcoBridge, upd 2020-03-12) with the same Type:ID
Could two database entry have the same Type:ID?
Devices are differentiated via manufacturer id AND (logical AND) device type AND device id.
Yes, as long as the manufacturer id is different.
Thanks.
I’m contacting the manufacture, and ask whats changed. The products are identical, but somehow they must have change the hardware.
I don’t think this can be solved by the manufacturer. There seems to be something wrong with your openHAB installation.
First thing to do is: remove the Thing and readd it. I doubt this will help, though.
Next thing to do: exclude the device, factory reset and reinclude.
Also check your firmware version (application version in your xml file) and try to find out if your device has a newer firmware than devices before. But: this should also not show the problem your are seeing …
Thanks! Ill try reinclude with factory reset
The reason I wanted to contact the manufacture is that EcoDim, is suspiciously identical to the Namron, and my first thought was some kind of rebranding…
Again, thanks @sihui. sorry for beeing a complete noob
update:
Actually, the manufacturer did make a mistake and somehow manage to print the wrong Man ID on the devices. A batch of these devices are being recalled
0x0438 = 1080 would be the right man id
0x0431 = 1073 = wrong
Again, thanks @sihui for pointing out the man id
Finally got the binding, and readded the devices. Now the Associations are gone from group 2 and 3. Thanks @sihui
I was hoping this would sort out my issue with the dimmers “changing” status back, every time I’m changing it remotely.
received command 62
predicted to become 62
changed from 15 to 62
changed from 62 to 15
(lights actually changes ands stays 62%)
(Manually dimming does rapport correctly)
Anything obvious I should be looking in to? Or could it be more issues with the entry?
Try setting the “invert percent” value in you channel config.
I’m not OP, but I can confirm that there is no “invert percent” alternative in the brightness channel config. There is only the “Restore Last Value” parameter, with the alternatives “Restore Last Value” and “Restore Full Brightness”. Out of curiosity, why do you suspect “invert percent” could help?
From the log, it looks like the controller sends a SWITCH_MULTILEVEL_SET command with 62%. This is received by the device, which proceeds to set the dimmer value correctly (the lights actually do change to 62% brightness), and then it ACKs the command. The binding proceeds to set the value of the channel, and the associated item, to 62%. About 1.5 seconds later the controller sends a SWITCH_MULTILEVEL_GET command to the device, and the device ACKs the command and reports a value of 15%. This value is wrong.
More generally, what happens is that after the controller has sent its SWITCH_MULTILEVEL_SET command, it sends a SWITCH_MULTILEVEL_GET command, and the value received through the latter is not actually the correct current dimmer value. It is the dimmer value that the device was last set to with physical manipulation of the device. So you turn the dimmer wheel to X percent, then X percent is what the dimmer will send as its response to SWITCH_MULTILEVEL_GET until the dimmer wheel is turned to some other value.
So this looks to me like a hardware bug in the device. A potential workaround that I’m not sure is possible is if OH did not send a SWITCH_MULTILEVEL_GET command after it has sent a SWITCH_MULTILEVEL_SET command. Is this something that is configurable in the zwave binding on a per-device basis?
Either it is this or the “Command Poll Period”. Why not just trying and report if it helps or not?