Cant remove Associations

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?
image

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?

image

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?

But “invert percent” should just invert the percentage, right? 0xFF maps to 0% and 0x00 maps to 100%, instead of the other way around? If so, I don’t see how it would help. It’s not that the device reports an inverted value, but that it consistently reports the value it was last set to with the dimmer wheel on the physical device, instead of the actual current dimmer value.

In any case, “invert percent” doesn’t seem to be an alternative on the channel configuration. But setting “Command Poll Period” to disabled looks like the workaround I had in mind! Thanks. :slight_smile: Although the regular polling will probably mess up the value whenever it’s triggered, so I’m guessing the problem is not completely worked around even with this.

Hopefully the manufacturer can provide a firmware update that fixes this properly.

My understanding is some devices do not report their status without being polled. Others report their status automatically after change and do not need to be polled.

That’s true, but I don’t understand the relevance. This device reports automatically after a change. The problem is it reports the wrong value when polled.

You said this

But setting “Command Poll Period” to disabled looks like the workaround I had in mind! Thanks. :slight_smile: Although the regular polling will probably mess up the value whenever it’s triggered, so I’m guessing the problem is not completely worked around even with this.

My point is what you found was a solution, not a workaround.

Not quite. Without the poll/confirmation. OpenHab will not know if the command were correctly executed in the device.
For now, this will be a acceptable workaround. I will contact the manufacturer about this issue.

Thanks @kvolden @sihui @Bruce_Osborne

Not polling is not a solution to the device reporting the wrong value when being polled. It is a workaround because the problem still exists, it is just being worked around to make it have less of an impact. If it is polled, it will still report the wrong value, and this problem prevents successfully polling the device either for confirmation, or after resetting OH, or after a power outage, or for any other reason where a poll is appropriate. If this is indeed a bug in the device itself, the only solution is to get firmware fix or a replacement.

1 Like

Luckily the zwave binding developer and maintainer makes almost everything possible, even fixes devices which behave erratically. We should not question this but thank him every day of our openHAB installation life.

If you want to know more about it just read the docs:

The binding can perform a poll of the device shortly after sending a command to make sure that the command was implemented, and the binding has the correct view of the devices state. This is called "Command Poll Period" and may need adjustment for some devices that may update their state slowly (e.g. dimmers that have a slow transition). This is defined in milliseconds, and can be set to 0 to disable this polling.

Yes, that’s confirmed to work already. I’m thinking the regular poll is going to mess things up occasionally though, and it’s not clear from the docs if the regular polling period can be completely disabled as well. If setting to 0 does not disable it, I guess it could be set to some ridiculously high number, like 10 years, to prevent it from happening in practice.