Z-wave device in database but unknown in openHAB

Samir.E · January 18, 2025, 5:04pm

Hi,
half noob here, trying to find out a problem that I have with a newly bought Z-wave device. I have read a lot of posts but now I am lost, maybe someone has a suggestion for me on how to go on to try to find the problem.

System:
Windows 10
openHAB 4.1.3 Stable
Aeon Z-wave Stick

Device with problem: NEO Coolcam Repeater NAS-RP01

I have a lot of other functioning Z-wave devices and they work fine. Bought the NAS-RP01 and stupidly enough did not check if it was compatible with openHAB. I am not going to use the device as a repeater (but it is a nice add on for me) but as a temperature sensor since it is included in the device.

I added the device to the Z-wave network with success the first try. It shows up in openHAB as Online - but unknown. It is not battery powered so it should send information immediately to openHAB (or the Z-wave stick). I waited 24 hours to see if it was correctly defined but no luck. Then I excluded it from the network and added it again. I have also tried to heal the device and also reinitialize the device. No change.

According to the docs for the Z-wave binding it is not listed as supported: https://www.openhab.org/addons/bindings/zwave/doc/things.html

However, it is listed in the openHAB database (from what I understand…): https://opensmarthouse.org/zwavedatabase/1544

OpenHAB has also generated an xml file in userdata\zwave: network_ef9886a2_node37.xml:

<node>
  <homeId>0xef9886a2</homeId>
  <nodeId>37</nodeId>
  <version>4</version>
  <manufacturer>0x258</manufacturer>
  <deviceId>0x716</deviceId>
  <deviceType>0x10</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>500</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
    <commandClass>COMMAND_CLASS_SECURITY</commandClass>
    <commandClass>COMMAND_CLASS_SECURITY_2</commandClass>
    <commandClass>COMMAND_CLASS_SUPERVISION</commandClass>
    <commandClass>COMMAND_CLASS_TRANSPORT_SERVICE</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
    <commandClass>COMMAND_CLASS_INDICATOR</commandClass>
    <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
    <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
        <name>Lifeline</name>
        <profile1>0x0</profile1>
        <profile2>0x1</profile2>
        <commands>
          <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
          <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
          <commandClass>COMMAND_CLASS_INDICATOR</commandClass>
        </commands>
        <associations>
          <associationMember>
            <node>1</node>
          </associationMember>
        </associations>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
        <name>LoTemp Alarm</name>
        <profile1>0x31</profile1>
        <profile2>0x1</profile2>
        <commands/>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
        <name>HiTemp Alarm</name>
        <profile1>0x31</profile1>
        <profile2>0x1</profile2>
        <commands/>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>4</int>
      <associationGroup>
        <index>4</index>
        <maxNodes>0</maxNodes>
        <name>LoHumi Alarm</name>
        <profile1>0x31</profile1>
        <profile2>0x5</profile2>
        <commands/>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>5</int>
      <associationGroup>
        <index>5</index>
        <maxNodes>0</maxNodes>
        <name>HiHumi Alarm</name>
        <profile1>0x31</profile1>
        <profile2>0x5</profile2>
        <commands/>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_REPEATER_SLAVE</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_REPEATER_SLAVE</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_SENSOR_MULTILEVEL</commandClass>
            <COMMAND__CLASS__SENSOR__MULTILEVEL>
              <version>10</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>11</versionSupported>
              <sensors>
                <entry>
                  <multilevelSensorType>TEMPERATURE</multilevelSensorType>
                  <multilevelSensor>
                    <sensorType>TEMPERATURE</sensorType>
                    <initialised>true</initialised>
                  </multilevelSensor>
                </entry>
                <entry>
                  <multilevelSensorType>RELATIVE_HUMIDITY</multilevelSensorType>
                  <multilevelSensor>
                    <sensorType>RELATIVE_HUMIDITY</sensorType>
                    <initialised>true</initialised>
                  </multilevelSensor>
                </entry>
              </sensors>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__SENSOR__MULTILEVEL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
            <COMMAND__CLASS__ASSOCIATION__GRP__INFO>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <autoSubscribeGroups>
                <int>1</int>
              </autoSubscribeGroups>
            </COMMAND__CLASS__ASSOCIATION__GRP__INFO>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
            <COMMAND__CLASS__DEVICE__RESET__LOCALLY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__DEVICE__RESET__LOCALLY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ZWAVEPLUS_INFO</commandClass>
            <COMMAND__CLASS__ZWAVEPLUS__INFO>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <zwPlusVersion>2</zwPlusVersion>
              <zwPlusRole>ROLE_TYPE_SLAVE_ALWAYS_ON</zwPlusRole>
              <zwPlusNodeType>NODE_TYPE_ZWAVEPLUS_NODE</zwPlusNodeType>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__ZWAVEPLUS__INFO>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
            <COMMAND__CLASS__CONFIGURATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>4</versionSupported>
              <configParameters/>
            </COMMAND__CLASS__CONFIGURATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>600</deviceManufacturer>
              <deviceType>16</deviceType>
              <deviceId>1814</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_POWERLEVEL</commandClass>
            <COMMAND__CLASS__POWERLEVEL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <powerLevel>0</powerLevel>
              <powerTimeout>0</powerTimeout>
            </COMMAND__CLASS__POWERLEVEL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_FIRMWARE_UPDATE_MD</commandClass>
            <COMMAND__CLASS__FIRMWARE__UPDATE__MD>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>5</versionSupported>
            </COMMAND__CLASS__FIRMWARE__UPDATE__MD>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>2</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>2</versionSupported>
              <maxGroups>5</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>2</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <libraryType>LIB_SLAVE_ENHANCED</libraryType>
              <protocolVersion>7.13</protocolVersion>
              <applicationVersion>3.4</applicationVersion>
              <hardwareVersion>4</hardwareVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_INDICATOR</commandClass>
            <COMMAND__CLASS__INDICATOR>
              <version>3</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <isGetSupported>true</isGetSupported>
              <supportedIndicatorsInitialised>true</supportedIndicatorsInitialised>
              <supportedIndicators>
                <ZWaveIndicator>
                  <type>NODE_IDENTIFY</type>
                </ZWaveIndicator>
              </supportedIndicators>
            </COMMAND__CLASS__INDICATOR>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION</commandClass>
            <COMMAND__CLASS__MULTI__CHANNEL__ASSOCIATION>
              <version>3</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <maxGroups>5</maxGroups>
            </COMMAND__CLASS__MULTI__CHANNEL__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SECURITY</commandClass>
            <COMMAND__CLASS__SECURITY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__SECURITY>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>
  <lastReceived>2025-01-18 16:16:02.384 UTC</lastReceived>
</node>

So from what I understand openHAB does somehow recognize the device but somewhere down the line it is defined as unknown. But this is a bit above my pay grade. Sorry.

This is the thing:

Since the device is Unknown, there are no channels so I cannot really do anything with it. At least that is from what I understand.

Now (when I am writing this) I realize that I actually get an error when I reinitialize the device:

2025-01-18 18:07:01.884 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 37: Device discovery could not resolve to a thingType! 0258:0010:0716::3.4
2025-01-18 18:07:02.126 [INFO ] [commandclass.ZWaveVersionCommandClass] - NODE 37: Command Class COMMAND_CLASS_BASIC has version 0!

It would be very nice if someone could point me in the right direction so I can try to solve this problem myself. Because I am now a bit lost…

AndrewFG · January 18, 2025, 5:46pm

You may need to wait for up to 24 hours before a newly added ZWave device has fully informed the Stick about its capabilities…

JustinG · January 18, 2025, 5:46pm

The Z-wave database is not automatically pushed to OH when it is updated. The database is included in the Z-Wave binding. You are on a version of OH that is fairly old at this point and as a result you are using a Z-Wave binding that has an old version of the database. You may not have the database version that includes this device.

If you search the forums you will find several sets of instructions on how to download and install a new version of the Z-Wave binding, but a full upgrade to a more recent OH version would also work and have several other benefits besides.

Samir.E · January 18, 2025, 6:02pm

Oh, I thought that since openHAB generated the xml-file, it somehow recognized it. Thank you for telling me about this, I will upgrade shortly!

apella12 · January 18, 2025, 8:19pm

There is going to be a little more of an issue than an OH upgrade, although that is a good idea. Refer to this post for more explanation. Assuming that the ZW DB device looks like your device you could try to overwrite the current file in the ZW binding (which as noted above has the ZW Db included.) using this procedure and this file
nasrp01_0_0.xml (9.9 KB)
(folder shenzhen, not zooz). If it works okay I’ll update the ZW DB

Samir.E · January 19, 2025, 7:31am

Thank you, I will come back to you with the result as soon as I have time to test this!

Samir.E · January 19, 2025, 3:16pm

Hi again Bob,
I am a bit hesitant to do the procedure described since it is a bit above my understanding if something goes wrong. The part with uninstalling the z-wave binding is especially not appealing since I have a lot of z-wave devices - will they still be there if I install the jar-file?

I have confirmed that the device in the database (https://opensmarthouse.org/zwavedatabase/1544) is the same as my device.

Does your suggestion mean that the device will not be in version 4.3.2 stable if I download that and install it? I would actually rather do the upgrade of the whole system (if it is containing the correct z-wave binding for this device) than start with the replacing of the xml-file inside the jar.

The upgrade process I have done a number of times and feel I have control over that - the changing of the xml-file inside the jar and replacing the jar, not so much.

Should I still go ahead with the changing inside the jar file?

apella12 · January 19, 2025, 5:00pm

I did go ahead and add your TYPE:ID to the DB entry, but it still needs to be approved by the developer. I also asked to have the recent ZW DB updates added to the next patch release OH 4.3.3, but there is no guarantee or even if there is going to be one. It will not be OH 4.3.2.

I recognize that the procedure is intermediate in difficulty, if you want to wait and see what develops. Your device should should still provide the repeater function, you just won’t get the sensor readings

Samir.E · January 19, 2025, 5:07pm

Hi Bob,
thanks for your answer, good to know that it is not included in the current stable release.

If I super simplify the processes described on the various pages (which are not for Windows which of course confuses me), is this the right approach?

Update the current jar file (outside of openHAB) with the supplied xml-file.
Uninstall the current Z-wave binding.
Replace the jar file in \userdata\tmp\mvn\org\openhab\addons\bundles\org.openhab.binding.zwave\4.1.3 with the jar file I just edited and replaced the xml-file in.
Install the z-wave binding again.
OR - should I drop the jar file in the addon-directory instead?

If the above is not correctly understood, I will wait for a later openHAB release.

apella12 · January 19, 2025, 6:47pm

I’d say

find the current jar on your windows machine
Create the file structure in the guide and COPY the current jar into the jarmodify directory
Move the above XML into the /jarmodify/OH-INF/thing/shenzhen folder,
update the jar per guide EDIT: make sure you have the jar command in your java folder-see my second post on the link above
From there two options, both reversable
a) uninstall current Zwave binding using the UI and put the modified jar in your addons folder. Reverse if needed (remove modified jar from addons and use UI to reinstall Zwave). Since you copied the original jar it will be unchanged.
b) use the bundle:update command in karaf pointing to the modified jar (no need to mess with current binding in the UI). To reverse, re-copy the original jar over your modified version and use the bundle:update to revert back.

EDIT2: you may have to delete the repeater thing on the UI page (do not exclude) and then rescan ZW from the inbox to pick up the new properties.

Samir.E · January 19, 2025, 8:12pm

Hi,
did what you wrote as exactly as I could. No errors anywhere in my commands, they looked like they worked (the jar command and the bundle:update command). Followed the instructions on the pages you referred to.

When I look at the jar-file after it was supposed to be updated (with bundle:update) I noticed it had exactly the same modified date as before. Restarted openHAB. Deleted the device, rescanned and added it again. No change, nothing under Channels.

Did something that you are not supposed to do: shut down openHAB, copied the modified jar file and replaced the one that had the same date. Restarted openHAB, deleted the device, rescanned, added it again. No change.

This leads me to believe that I am maybe not working with the correct original file… Mine is located in: “C:\openHAB\userdata\tmp\mvn\org\openhab\addons\bundles\org.openhab.binding.zwave\4.1.3”
I couldn’t find any other jar file for z-wave though.

No errors in the log.

Sorry but I am lost again and I totally understand if you don’t have any more time to spend on this. I am very grateful for all the time you already spent.

apella12 · January 19, 2025, 9:45pm

There could be windows vs Linux issue particularly with the jar -uf file command (forward slash versus back slash). EDIT: for the sake of science, I updated a jar with Windows, and it worked fine
In command prompt: C:\Users\Robert\GitHub\zwjar>jar uf org.openhab.binding.zwave-4.3.1.jar ./OH-INF/thing/shenzhen/nasrp01_0_0.xml

Using file explorer does the original file have a different date than the one in the location you modified? EDIT: the folder you referenced looks okay for the original

You don’t by chance have a WSL environment installed?

EDIT: Also I have this BreeZip extractor for Windows (It is kind of a pain with ads) but can look into a jar (at least the XML files). You could see if your file was changed.

Samir.E · January 20, 2025, 2:36pm

Hi Bob,
if you use the wrong slash, then you immediately get an error. So I used the backward slash with the windows command and that worked fine. Forward slash was used for the bundle:update command in the console.

jar uf c:\openHAB3\jarmodify\org.openhab.binding.zwave-4.1.3.jar c:\openHAB3\jarmodify\OH-INF\thing\shenzhen\nasrp01_0_0.xml

bundle:update 302 file:///c:/openHAB3/jarmodify/org.openhab.binding.zwave-4.1.3.jar

After running the jar command (no errors) the original file in jarmodify directory clearly changes the modified date correctly.

However, after running the bundle:update command (no errors), the date for the original file “C:\openHAB\userdata\tmp\mvn\org\openhab\addons\bundles\org.openhab.binding.zwave\4.1.3\org.openhab.binding.zwave-4.1.3.jar” is clearly NOT changing the date for latest update. This does not feel right but that is just what I think. If it is supposed to change with the bundle:update command, then that command is updating something else or not working. But no visible errors.

WSL: no.

There is no need (in Windows) to have a special tool to look in the jar file, just rename to zip and then it is totally accessible.

So, I have checked the contents of the xml-file in the original file (date 2024-06-10) and then compared it to the xml-file you provided. I have made ten random checks in the file, especially with some numbers and I cannot see any difference at all - I have not however run a digital comparison between the files.

So basically what I am saying is that the original jar-file already contains the xml-file you provided.

I redid the whole procedure with jar and bundle:update to double check. And after that I did the above check. Also no change in behavior of the device, no channels available.

If I check in openHAB when the device has been added I get some tingling feeling that something is not right. The manufacturerID in the xml file says 0258, in the openHAB screen it says 600 - but maybe this is not the same reference. Is the device recognized as something totally different and we are dealing with the totally wrong manufacturer…? I am lost…

apella12 · January 20, 2025, 4:04pm

Something is amiss. Can you check the updated jar for this line in the file. It is the only one that counts
<property name="manufacturerRef">0010:0722,0010:0716</property>
I added the 0010:0716, so that could not be in your original jar.
Also check to make sure the file is in OH-INF/thing/shenzhen/ with the other shenzhen devices EDIT: and there is only one entry that looks like nasrpxxxx

Otherwise everything checks out. 600 = 0x0258; TYPE 16 = 0x0010; ID 1814 = 0x0716 (unless my math is wrong

Samir.E · January 20, 2025, 6:34pm

Hi Bob,
you gave me the clue to solve this. I will try to elaborate on what I did to make this work.

When I was going through the updated jar file to look for the things you talked about, I realized that there was a whole new structure on top of what was supposed to be there - and this structure was my own openHAB folder. Since I was not sure about how to use the folder structure commands (relative) on both the jar command and bundle:update, I used absolute paths. Thou shalt not do that…

So I had a completely separate absolute path in the jar - no wonder it did not work. Since I still was a bit unsure how to do this (a bit tired I must admit) I did the whole thing like this. Don’t scream…

I copied the original jar file to a folder outside of openHAB.
Changed the extension to .zip, this makes it possible to browse the file completely like a normal folder structure in Windows.
I took the xml-file you gave me and copied straight in to the correct place in the zip file (replacing the original).
Changed the extension back to jar.
Since I guess there is something that needs to be registered in a database or similar when using bundle:update, it is not enough to just copy the new updated file in the right place and restart openHAB (I could not get it to work anyway). So I took the original file and put it back, used bundle:update on the same original file (from outside openHAB) so it would register correctly (wherever it happens) and then we were back to normal (where I started basically).

The reason for doing the first step (putting it back manually) was that I did not want to have the new extra structure in the jar file, I just wanted the original. I got the sense that if I did bundle:update with the extra structure in it, it would still be there - so update means only adding. Makes sense.

When I had the original in place without the extra folder structure, I did bundle:update again but now with the updated jar from outside openHAB (the one I brutally copied the xml file into).

Even if I used the method of renaming the jar to zip, copying the xml file in place, renaming back to jar it worked fine. So immediately after this operation, if I deleted the device and added it again, openHAB recognized it straight away. And now I am up and running!

If someone reading this and wants to do it the proper way, figure out the relative path ways and don’t do like me and use absolute paths - it will not work.

As usual - super thanks for having this great community that can help you when you get stuck and of course especially a big thanks to you Bob!

All the best

Samir

apella12 · January 20, 2025, 8:39pm

Not sure I understand all what you did but can’t argue with success. Others have edited the XMLs in the jar, but don’t know what tools everyone has so always point to the jar update first.

One note is the bundle:update method won’t survive a OH upgrade. Keep your notes. Hopefully the change to the DB will be included in a potential future OH 4.3.3, so it won’t be an issue.