Hi sihui,
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!
Thanks,
Jab