But what matters is not so much the groups - but the COMMANDS that are sent. Groups are simply a configuration setting. We need to know the command classes that are used to send commands between the device and the gateway.
I will try and find time to work this out from the database. Ultimately though we are stuck - either we fix your issue and break it for someone else, or we leave it alone. Ideally we’d try and get feedback from others with these devices so we can understand where the error really is.
The switch sends commands to devices(Domitech Smart LED ) using a z-wave without OH. I can’t setup it using one assotiation group.
The problem has appeared with this update TZ35S reporting as TZ65D . I have already suffered. I reported a problem a few months ago. Please roll back the changes. I think if were more association groups to set up this it would not be a problem. The problem appears when the association group is only one
@chris
I tried to install earlier versions of OpenHub. In version 2.2, the type of my z-wave switches is determined correctly (TZ65D Dual Paddle Wall Dimmer). And I can do all the necessary settings. https://dl.bintray.com/openhab/apt-repo2/pool/main/2.2.0/
Both are bad and will cause problems for someone - either someone doesn’t have a channel, or someone will have errors with their network due to incorrect definitions.
Basically, this incorrect definition makes things pretty difficult unless there is some other way to differentiate these devices - currently that is the firmware version, device type and device id.
@chris if you add this device as TZ35D
then users of TZ35S can configure group 1
and users of TZ35D can set up groups 1-4
and we will all see 4 groups in the settings, which is a bit incorrect for the one-button version users
Tell me if I’m wrong.
But you miss off other issues such as the binding will request configuration and associations that do not exist in the device as the database is wrongly configured. This will cause users delays and timeouts in these devices.
As I said - both options when incorrectly applied will cause problems if the device someone has isn’t the one that is defined.
At the end of the day, we need to find a way to differentiate these devices.
You cannot make database changes locally, if I recall correctly.
Since the company reused the device type & id, how do we know they did not reuse firmware numbers too?
Since device type & id are supposed to be unique, I guess there is nobody who can revoke their zwave certification for these devices.
You would think certification would check for reuse of the type/id pair.
Button 2 on these switches controls through association groups. It does not have a physical relay or dimmer. and it becomes completely inoperative if I could not set up association groups.
Ok, I understand your issue and you can keep posting these comments but it doesn’t help.
As I have said a few times now - the way to resolve this is to try and find a way to differentiate these devices. Otherwise we just keep moving the issue around - we fix it for you, and break it for someone else - we can’t keep going around in circles like this.
