ZWave - "HomePro" dimmer Node is recognized but shows no channels

[Marco_Bianchi]

I am configuring on openHAB my ZWave network and so far I saw that all my devices have been recognized correctly but one, that is actually recognized as a thing but shows no channels to link to an item.
This is an aged HomePro dimmer, but still works very well.
According to what I found searching in the community, as the device is shown correctly as a thing, I understand the correct way to address the issue is providing the node details xml file and ask to add it to the database, so I’m doing that here below.
If there’s any other info needed please kindly let me know and apologies if I missed it, I’m actually a openHAB noob.

Best regards

pi@raz:/var/lib/openhab/zwave $ cat network_d4299cd5__node_6.xml
<node>
  <homeId>0xd4299cd5</homeId>
  <nodeId>6</nodeId>
  <version>2</version>
  <manufacturer>0x7fffffff</manufacturer>
  <deviceId>0x7fffffff</deviceId>
  <deviceType>0x7fffffff</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>false</beaming>
  <maxBaudRate>9600</maxBaudRate>
  <sleepDelay>500</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
    <commandClass>COMMAND_CLASS_PROTECTION</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map"/>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SWITCH_MULTILEVEL</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_NOT_USED</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_MULTILEVEL</commandClass>
            <multiLevelSwitchCommandClass>
              <version>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </multiLevelSwitchCommandClass>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SWITCH_ALL</commandClass>
            <COMMAND__CLASS__SWITCH__ALL>
              <version>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
              <mode>SWITCH_ALL_INCLUDE_ON_OFF</mode>
            </COMMAND__CLASS__SWITCH__ALL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_PROTECTION</commandClass>
            <COMMAND__CLASS__PROTECTION>
              <version>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <localModes/>
              <rfModes/>
            </COMMAND__CLASS__PROTECTION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2023-01-14 07:13:34.655 UTC</lastReceived>
</node>pi@raz:/var/lib/openhab/zwave $

[anon71759204]

@Marco_Bianchi

This is an aged HomePro dimmer, but still works very well.

Your statement refers to the non-Z-Wave part of your dimmer?

Visually identify your dimmer and post the manufacturer and the model no. (it could be a ACT HomePro Dimmer, a HomePro ZD*, a Scientia Technologies device, …). Then we can check whether your device is in the OpenSmartHouse Z-Wave Device Database.

The important part in the XML file is:

<manufacturer>0x7fffffff</manufacturer>
  <deviceId>0x7fffffff</deviceId>
  <deviceType>0x7fffffff</deviceType>

The values 0x7f... are a strong indication that the discovery process (inclusion) went wrong. Without proper data in these data fields openHAB cannot identify your device.

Assuming your device is mains powered:
Remove the Thing from your Z-Wave controller:

Re-include it.
Check the new XML file for reasonable data in the manufacturer, deviceId, deviceType fields.
If they are reasonable: post the data, otherwise repeat remove/re-include.

Another option would be to increase the log level - but let’s reserve that for the case that the previous steps fail.

[Marco_Bianchi]

First thank you for the answer. That helped to clarify better the point.
The device model is an ACT ZDP200 HomePro dating back I guess 12 or 13 yrs ago.
I tried to remove and reinclude but at the moment no luck to have the manufacturer id populated in the xml.
Searching in depth on the community I could also find some other user that experienced my same issue but then gave up fixing it. It looks that this dimmer had been included in the database (that I assume is the one I am using, as it’s a fresh install), but is not recognized anyway because can’t read the manufacturer, deviceId and deviceType.

HomePro ZDP200 - In database, but unknown

@chris, logfile is running, how long does it have to run for? I followed the log with a tail -f and noted that the binding is comparing my node (NODE 19) to the database. It fails to so however 2017-10-01 19:39:39.864 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 19: Checking zwave:act_45602_00_000 2017-10-01 19:39:39.864 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 19: Checking zwave:act_zdm230_00_000 2017-10-01 19:39:39.864 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - N…

@anon71759204

Your statement refers to the non-Z-Wave part of your dimmer?

yes but not only: so far I used this dimmer with domoticz (but migrating the zwave part of my home automation to openHAB I had to disable that link to avoid conflicts in accessing the USB zwave dongle)

I wonder if it is possible as workaround to force the data in the xml file overwriting it manually and making it no nore overwritable (maybe changing the file permission? or anyway it would be overwritten by openhab at the following network update?)

[anon71759204]

Two options:
Ditch it (at least the Z-Wave part of your device …) or debug it.

Next steps for debugging:

ZWave - Bindings

As HomePro ZDP200 - In database, but unknown - #15 by chris suggests, it might be a problem with the NIF from your device, so we would need to see the NIF from the debug log.

If your device doesn’t claim support for manufacturer specific command class in the NIF, but does support it, it should be possible to add support for your device to the Z-Wave database.