[SOLVED] Tkb_tz65d as TZ35S

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.

leave the possibility of manually specifying the type of devices through the configuration file of z-wave binding

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.

It’s not impossible, but it is a lot of work.

2 Likes

I just want to say again thank you for your dedication, @chris.

1 Like

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?

1 Like

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.

I expect a problem would occur if you had some of the dimmers too.

No problem now.
I use: dimmable switches (TZ65D,TZ65S), dimmable z-wave lamps (Domitech)

I meant mixing dimmable and non-dimmable switches with the same device definition.

I also have TZ66D (non-dimmable). I checked it work a year ago and everything was fine.
Next week I plan to install it. And can re-check

1 Like

I would like to join this topic. I’ve just installed a TZ36D. And seems I’m having the same issue?

  • The first switch is working (through relay, or through OH…).
  • The second switch not. Not getting a scene_number in OH?
Number  Sch_2Knops         "Patio2"  <contact>  { channel="zwave:device:2f4ef5d0:node74:scene_number" }
Switch  Sch_2Knops_Binary  "Patio"   <Light>    { channel="zwave:device:2f4ef5d0:node74:switch_binary" }

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?

Return it for a different brand switch. Since that brand reuses IDs we cannot support them. Any changes will break a different group of users.

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?

Can you recommend any particular type of z-wave switch?

What is device id?

Recommendations for Z-Wave can be region specific. I just installed an inexpensive switch from Zooz but it is only for US, Canada, and Mexico.

:confused: 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.

Am I correct that the controller is in the association group marked “controller” and there should only be one group per device with that flag set?

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.