I certainly appreciate your frustration, but we have a problem with these devices due to the manufacturer, and we either keep changing them back and forward each time someone complains, or we need to draw a line in the sand, and unfortunately you ended up on the wrong side of the line. I think changing back and forward though is bad for everyone as we don’t have any stability.
I’m not sure what you are getting at?
This config file will provide the information for this device. What we also need (somehow) is to know what the other devices firmware versions are so that we can see if there is a way to differentiate between then.
Maybe I miss your point, but with only one file we can’t tell the difference between multiple devices.
This reminds me of a similar situation with Wi-FI standards. Testing for WPA2 focused more on compatibility than meeting the standard so some manufacturers cut corners compromising security.
For the new WPA3 standard that is required for Wi-FI 6 certification they are testing to meet the standard.
Unfortunately that doesn’t help the situation here.
ZWave and ZigBee both (in theory) test against the standard, but of course there is always the question of how well defined tests are, and the ZWave standard is not written like a set of requirements so it’s probably easy to miss things.
Unfortunately openHABs thing definition system using the XML files that come from the database can only be read from the binding JAR file, and not from a local system. This has been debated many times. If the ZWave binding wanted to do something different we’d have to write another system to implement this outside of the openHAB framework.
This is an unfortunate situation and I haven’t read through every post. In case nobody has suggested this to get @maxsm able to use the device, the distributed jar file can be manually modified. You’d then delete and rediscover the TZ65Ds. You can then go back to the production binding (just don’t delete the Things). Not a solution, but at least a workaround?
you’re right. But I am strong enough to do it myself;).
You gave me a great link. I used it to prepare the script.
In my case, the situation is a bit simpler - the devices are already in the database.
I applied script yesterday and re-created the device. Everything works as it should. Moreover, I have several one-button switches(TZ65S). One-button switches apper as two-button switches (it have same id) and there are no problems with that.
When I understand this topic, the second switch is only usuable by groups?
I would like to control a KNX relay with it over OH, so guess this switch (TZ36D) is a bad choice?
Any suggestions?
Maybe a stupid question, but isn’t possible to configure a ‘group 4’ in OH somehow?
If I understand it correclty, the second switch can only send a ‘command’ to group 4 in a zwave network?
So if a zwave device in that network is also in group 4, and notice this, OH should be able to see it?
Correct?
What do you mean by this? There is no “group 4 in the network”. A group number is only valid for each device - commands are not sent to groups at all, but are sent to the nodes in a group defined on each device.
In general, nodes have no visibility of groups on any other devices other than themselves.
Normally, yes, but this naming is not consistent. For ZWave+ devices, there is a clear policy - older devices have no such requirement and different manufacturers do different things.
It depends… For ZWave+ devices there is a clear policy. There is only 1 lifeline group, and the controller should only be in this group under most conditions. For older devices it very much comes down to how the manufacturer designed the device and sometimes multiple links to the controller may be needed.
Care should be taken when adding the controller in multiple groups though as this can cause problems due to message duplication, so you need to understand what is happening.