Perhaps this link will be interesting to you
Can you elaborate on what is interesting 
At the end of the day, we need to find a way to differentiate these devices.
No - you are correct.
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.
I can collect any debug information if it helps
I can collect any debug information if it helps
Can I locally fix identifiers in the z-wave database?
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.
You would have to edit the JAR or compile your own JAR.
1 Like
it really doesnāt help you are right.
Just out of curiosity, I reached out to the Zwave Alliance. They do not consider this an interoperability issue.
While you are correct that the manufacturer ID, product ID, and product Type ID are suppose to be unique across different products from the same manufacturer, those data points have nothing to do with interoperability. Those data elements are for identification of the product. Even though there are 4 different products here, my only thought regarding their use of the same values may be due to the fact that their differences appear to be in their capacities, and from a Z-Wave perspective they are all the same. I do not know for certain but they definitely should have used different values for each product.
Interoperability is achieved through the process that the product goes through to obtain its Z-Wave Certification Number - the ZC08-16xxxx number in these cases. Interoperability testing is where the actual Z-Wave command classes in the device are verified as having been implemented correctly and that other requirements are met.
Identification from the controllerās perspective is done with the device type (basic, generic, specific) in older devices such as these, and the device type and role type in newer devices.
Even though a device should be able to be identified from the others, it is not a requirement because due to interoperability rules, a controller should be able to work with all products if it controls/supports all of the command classes in the device.
I agree - itās not an interoperability issue - the problem is that we canāt differentiate the different devices and that means we canāt present the correct channels and correct configuration for the different devices.
Ideally, the binding would have been able to generate the channels dynamically (although even with this, there would be a problem with configuration). However, when the binding was written, this was not possible in openHAB. This was added a little while ago, and the ZigBee binding uses this, but rewriting the ZWave binding to do this is not trivial.
However, even with this, we would have a problem as we simply cannot differentiate between the devices, and this is the problem we have here.
1 Like
I would also like to point out that in my opinion, these devices are non-compliant to the ZWave specifications by not using different product IDs for different products. The standards are quite clear in this respect -:
It clearly states that different product type and ID pairs must be defined for each product and that has not been implemented here, and that makes it impossible to differentiate between the products.
@chris,
Possibly in the manufacture of devices, the manufacturer has moved away from the specifications.
But I already have these devices. I am sure that many users have them.
There are not so many z-wave devices on the market. Now they are even more crowded out by manufacturers using wifi and zigbee. It was the only one type of switch that fit my requirements.
Refusing to support them is a bad way.
great that the problem is not on our side
Maybe its the way to differentiate these devices.
You can try to read the values in assiciation group 4 if this causes a timeout - then we have a single-button switch
That should not be possible - all ZWave devices must be certified by the ZWA to show that they meet the specification. Itās possible they donāt check this - or didnāt in the past at least, and weāve found some pretty bad bugs in devices that show the ZWA certification process is far from foolproof, but they shouldnāt be moving away from the spec and still be claiming itās a ZWave device.
I try hard to support devices that do not meet the spec - there are loads of bodges in the binding to try and work around issues with devices. However this is a tough one as it would require significant changes to the database, and also the binding in order to find a way to differentiate these devices.
Also, you are complaining a few times now that I am not helping you, but Iām spending quite a lot of time to support you, and I spend hours most days supporting openHAB.
This is not a commercial system - this is open source software, so you are also welcome to make changes. Iāve suggested that you can edit the JAR, or compile your own JAR to change the database - this would easily solve your problem.
There are a few ways it COULD be done, but it is a really large change to the binding to try and do this sort of thing. Remember, there are around 1000 devices supported in the binding today - the binding cannot hardcode stuff like this or it will become a really big mess.
I again suggest to look to see if there is a way to differentiate these devices based on the type/id/firmware version. Iām happy to try and help, but when manufacturers donāt follow the rules, you should really blame them and not me.
I understand your contribution to the development of the project. I really like openHab and I would not want to leave but something else. I well understand that you spend your free time developing this project, including communicating with me.
I have already partially achieved the result in unpacking, local changing the base and reassembling java packages.
I will definitely leave the script here (maybe someone else ran into this problem)
Total Devices 980
And my device in this database. it worked well before openhab 2.4 is released. Before buying, I checked on the database that it is supported. I bought one - checked the work, then bought for all the rooms.
Maybe hint in config file:
node 10 =ātkb_tz65d_00_000ā