Almost done. Database is very slow today, need to upload the manual. Will try again tomorrow.
After final review you need to use the latest snapshot or development zwave binding.
Almost done. Database is very slow today, need to upload the manual. Will try again tomorrow.
First of all thank you for dedicating time adding this device, I’m really appreciated
I’m still having issues with the correct recognition from OH2, even after downloading the latest snapshot and dropping it in the
Am I missing something?
Maybe just a little bit of patience
You need to watch the “last exported” date at the lower portion of the database entry, As soon as you are seeing a valid date, the new entry goes into the binding. After the next build of the snapshot zwave binding you need to upgrade and should have the device available.
I am having a similar problem with the switch. The manafacturer ID is coming back as FFFF. To get it working, did you simply crack open the bindings JAR and edit the relevant TKB___.xml file to change the manufacturer ID to FFFF from 0118?
Anything else necessary? Assuming that this needs to be re-done any time you update OH aswell!
If that is the case you need to wake the device up manually a couple of times …if it is battery operated.
If a device is not in the database you should add it so other users can benefit from that.
Hi Sihui, the device is a TKB-TZ55D wall switch. Its wired, so doesnt need to be woken up etc…
However, on joining the network, it comes up as an unknown device:
"Unknown Device Z-Wave Node X (FFFF:0003:0004…).
The “FFFF” seems to be an invalid manufacturer ID being returned. I believe it should be 0118.
Above, someone suggested that the device was faulty if a manufacturer ID of FFFF was being reported? I have two and both of them report as FFFF.
As regards adding to the database, I originally started to do this and had uploaded the XML. However, the system reported a) that it looked like it was already in there as TZ65D (as opposed to my TZ55D). But there was also an error in red that this device has already been deleted!
I have no problem continuing to add to the database, but I am not sure if that is what I should be doing given that it is marked as previously deleted and/or the fact that I would have to input with an incorrect manafacturer ID to get OH to pick it up etc…!
Thoughts / suggestions?
That one is already in the database:
You are still talking about the TZ55D, right?
As said, it is in the db, no need to add anything.
What does your xml tell you about the manufacturer code? If it is FFFF also, I would exclude and reinclude the device, maybe in between reset it to factory default (although successful exclusion already should have done that, but just in case).
Yes, I am talking about the TZ55D.
The problem is that two of my devices (I have two of them!) both report a manufacturer code of FFFF.
To double check, I did as you suggested. Removed both from Openhab, then reset them to defaults and then re-added them to OH. However, the node.xml files for both report a manufacturer code incorrectly:
<node> <deviceClass> <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass> <genericDeviceClass>MULTILEVEL_SWITCH</genericDeviceClass> <specificDeviceClass>POWER_SWITCH_MULTILEVEL</specificDeviceClass> </deviceClass> <homeId>0xf6bfc734</homeId> <nodeId>10</nodeId> <version>4</version> <manufacturer>0xffff</manufacturer> <deviceId>0x4</deviceId> <deviceType>0x3</deviceType> <listening>true</listening> <frequentlyListening>false</frequentlyListening> <routing>true</routing> <security>false</security> <beaming>true</beaming> <maxBaudRate>40000</maxBaudRate> <supportedCommandClasses> ....
I am guessing (that unless there is a bug on OH), the device is not conforming to specification and/or is faulty as it should obviously not be reporting FFFF.
I did contact the supplier in relation to same and suggested that this behaviour was incorrect, however, they advised:
"…Z-Wave controllers should use the Command Class data reported during the Inclusion stage to determine how to control a device as opposed to relying on Manufacturer, Device Type or other such data, which may or may not be set.
If both the Class Generic and Class Specific data has been retrieved successfully by the Z-Wave controller then that should be all that is required for the Z-Wave controller to be able to control the device, in this case by creating a Dimmer type UI object.
I would suggest submitting a support request to the Openhab2 developers as it would be up to them to ensure that the device is represented correctly based on the Command Class data that it reports…"
I cannot imagine that this is true, but I did try looking for z-wave specification documentation to refute the claim the a valid manufacturer code is not required!
Assuming its faulty (and not an OH bug) and assuming that the supplier refuses to accept a return / replacement (well known supplier at that!), I was think about how I could get it to work. Specifically, could I simply add a custom XML in JAR in /addons that identified my device as (say) TZ55Dx with FFFF as a manufacturer code. Obviously same wouldn’t want to be added to the database as it would be a hack / workaround…
Any thoughts on any of above welcome!
This is above my paygrade, but we should ping @chris to clarify that information (be patient, he is travelling around the world this week and may not have time to answer in a short timeframe).
What I do know is:
the binding checks manufacturer ID, device id, device type and firmware version.
Beyond that I only have to offer:
Will await input from @chris and in the mean time, try out the custom approach to see if it can at least get the device working in the interim.
Clearly it is impossible to identify the device without valid identification values. I know that somewhere in the ZWave spec, it is stated that the device should have unique IDs to allow identification, but I need to try and find this and the internet at the hotel is not so good. When I get a chance, I will try and find this.
See below -:
This states that the manufacturer ID MUST carry the unique ID for the manufacturer - clearly, FFFF is not the correct ID for TKB.
The registry shows the following ID is allocated to TKB -:
While what the manufacturer says is partly correct - ie that the binding could use the command class data reported from the device, and this is what is done, that doesn’t make it a compliant product. It is also impossible to know what configuration is available without using these definitions since the device doesn’t report this, so the ONLY way to know the configuration is through the manufacturer and device type information.
I should add, that with the 800+ devices we have in the database, this is the only device that doesn’t respect this requirement.
Thanks Chris. That is what I would have expected intuitively. I am still trading e-mails with both the supplier and manufacturer and will report back!
Thanks for the help. The manufacturer identified that there was a problem with a batch of units having an incorrect manufacturer ID. The provided an OTA update for the units and they are now working as expected. Thanks to everyone for your help.
As an aside, I think it is worth pointing out that Vesternet (https://www.vesternet.com/) from whom the switches were purchased were completely useless. They are the ones that supposedly offer “Lifetime Tech support” and demanded that a Z-Wave devices manufacturer ID doesn’t need to be valid and that platforms such as Openhab should be able to seamlessly handle devices that have incorrect or invalid manufacturer ID’s!
I guess its very easy to offer to provide free “Lifetime Technical Support” if the answer to any support inquiry is ‘its your problem, its nothing to do with what we sold you…’. Poor show Vesternet. For sure, a website / supplier to avoid in the future.
In contrast, well done TKB for quickly accepting the problem and providing a solution. No hassle, no fuss.
Congratulations for solving it!
I have the same model (TZ55D) and the same issue (manufacturer = 65535). The homepage (www.tkbhome.com) doesn’t give much support. Could you please share a bit about your contact with them and how the issue was solved, so I can be as specific as possible when contacting them?
Hi Magnus, happy to help you resolve.
Step 1: Go to https://www.silabs.com/products/development-tools/software/z-wave and download the latest “PC Controller” software (you will have to register to get the download)
Step 2: Install onto your PC/Laptop and also install the z-Wave driver that is in the drivers folder.
Step 3: Plug-in your z-Wave z-Stick device to your laptop/PC and start-up the PC Controller application.
Step 4: Within the software, configure the COM port to match the COM port of your z-stick and verify that the software can see the z-Stick
Step 5: Factory default your TKB-TZ55d, wait a minute or two and put into inclusion mode.
Step 6: Select the ‘include (plus icon)’ within the software and you should see your TKB unit appear in the list of z-Wave devices after a few seconds.
Step 7: Select the OTA menu in the software and in the side menu click on your TZ55d device, then click the “GET” button on the right hand pane
Step 8: If your unit is defective, the GET should populate the manafacturer ID with 0xFFFF.
Step 9: Select the OTA formware file and then click the update button. It will take about 2 minutes to complete.
Step 10: After the update has completed, the TKB device will be factory reset and ready to go. However, the reference to the device in the PC Controller software will now be defunct as the device has been factory reset.
If wish, you can can now just enroll back into your OH installation. Alternatively, if you want to check it worked, follow the steps above to re-include back into PC Controller and click the “GET” in the OTA section to verify that the manafacturer ID has changed to the correct one!
Hope this helps,
Thanks for taking the time to put together a great step-by-step instruction!
I’m with you down to step 8, yes it populates with 0xFFFF. But in step 9 I need a firmware file and I’ve searched the tkbhome.com site (and others) for it, but to no avail. I will try to get it from the manufacturer.
Thanks for your help,
I reached out to the manufacturer to make sure it was ok for me to share the OTA firmware and they are fine with it, so here it is!!
Note: Not allowed to upload a ZIP file directly here, so hosting on JumpShare. If someone with more privilages than me can upload a ZIP, then please feel free to do that to make it easy for everyone!