I actualiy did some tests yesterday.
Here are some logs.
But I dont know well the zwave protocol si I cannot understand well logs neither.
The device is “node 57”, so I filtered logs with this pattern.
node57.txt (82.2 KB)
During these tests I tried to send NIF (simple press, 3-press, 5-press, 10-presses etc. long presses also)
I’ve just changed the lux level changed report parameter on one of my sensors from 100 to 50 and then manually woke the device by pressing the button three times. I didn’t see new activity in the log until I physically moved the sensor closer to the Zwave USB stick and woke it again. I then saw this in the log:
2022-10-07 17:30:33.039 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 45: SendData Request. CallBack ID = 180, Status = Transmission complete and ACK received(0)
2022-10-07 17:30:33.039 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 45: resetResendCount initComplete=true isDead=false
2022-10-07 17:30:33.039 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: TID 60605: Transaction not completed
2022-10-07 17:30:33.112 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: Application Command Request (ALIVE:DONE)
2022-10-07 17:30:33.112 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 45: resetResendCount initComplete=true isDead=false
2022-10-07 17:30:33.112 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 45: Incoming command class COMMAND_CLASS_CONFIGURATION, endpoint0
2022-10-07 17:30:33.112 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 45: SECURITY not supported
2022-10-07 17:30:33.112 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 45: Received COMMAND_CLASS_CONFIGURATION V1 CONFIGURATIONCMD_REPORT
2022-10-07 17:30:33.112 [DEBUG] [otocol.commandclass.ZWaveConfigurationCommandClass] - NODE 45: Node configuration report, parameter = 9, value = 50, size =1
2022-10-07 17:30:33.112 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 45: Got an event from Z-Wave network: ZWaveConfigurationParameterEvent
2022-10-07 17:30:33.112 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 45: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_CONFIGURATION, value=org.openhab.binding.zwave.internal.protocol.ZWaveConfigurationParameter@708677b7
2022-10-07 17:30:33.112 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 45: Update CONFIGURATION 9/1 to 50
2022-10-07 17:30:33.112 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: Commands processed 1.
2022-10-07 17:30:33.112 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@55851e0b.
2022-10-07 17:30:33.112 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@55851e0b.
2022-10-07 17:30:33.112 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 45: notifyTransactionResponse TID:60605 DONE
2022-10-07 17:30:33.113 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 45: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
The parameter still shows “pending” in the OH UI though. 
OK I made some other tests.
Previously I was only enable “ZWaveTransactionManager” in debug logs, now I enable all “org.openhab.binding.zwave” and I have much more information.
It seems that there is definitely a bug in the plugin : when i try to update the field 18 “Light Intensity Offset Calibration”, logs are showing : “NODE 57: Update CONFIGURATION 1/1 to 1”.
Which is definitely not the right number.
For example, when I change the field 6 “Temperature Offset Value”, it will successfully returns : “NODE 57: Update CONFIGURATION 6/1 to -17”.
Do you know if the plugin is still maintened ?
OK, more investigations lead me to previous disucussions in this thread : it is a mess between what openhab display in the configuration page and the real capabilities of the device in the config database.
Real fields are here : node-zwave-js/nas-pd07z.json at master · zwave-js/node-zwave-js · GitHub as previously posted by someone.
With this information, we can update the field “99” which is the real number for “Light Intensity Offset Calibration” (instead of 18), and the lux meter works perfectly with this field.
Other fields in “pending” state are obviously not been set in declared fields in the database configuration file.
As noted above the Device DB is community maintained. The blog explains how to register, and request write access. I can see from the manual attached that parameter 18 is actually 99. Also there appears to be some question marks on some of the other parameters. if you have a manual, it should not be too hard to fix.
I went ahead and updated the DB based on the attached manual. It also had the same parameters as a photocopied manual on the reference tab for the device, so I felt okay making the changes without owning the device. It was reviewed, approved and merged into the latest Zwave snapshot binding jar.
Rereading this post, I’m a little concerned the manuals do not match all the github zwave-js/node parameters (5 -17 are different), so there may be actually two versions (an older and newer?) and a separate DB entry may be needed. However, without a manual for another device it is really guessing.
What are the entries on the UI page for manufacturerRef for your device? The DB entry has two 0010:0718,0010:0720 under the PIR 5 in 1
1 Like
I ordered one of these just for fun, it arrived today and I’ve included it in my OH 3.3 install. The thing properties are as follows:
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SENSOR_NOTIFICATION
zwave_frequent false
zwave_lastwakeup 2022-10-22T15:32:04Z
zwave_neighbours
modelId NAS-PD07Z
zwave_listening false
zwave_plus_devicetype NODE_TYPE_ZWAVEPLUS_NODE
zwave_version 2.6
manufacturerId 0258
manufacturerRef 0010:0718,0010:0720
dbReference 1428
zwave_deviceid 1824
zwave_nodeid 89
defaultAssociations 1
vendor Shenzhen Neo Electronics Co., Ltd
zwave_routing true
zwave_plus_roletype ROLE_TYPE_SLAVE_SLEEPING_REPORTING
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_NOTIFICATION_SENSOR
zwave_devicetype 16
zwave_manufacturer 600
I thought I might as well include all of them for completeness.
The node XML file contents are:
<node>
<homeId>0x184e68c</homeId>
<nodeId>89</nodeId>
<version>4</version>
<manufacturer>0x258</manufacturer>
<deviceId>0x720</deviceId>
<deviceType>0x10</deviceType>
<listening>false</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_BATTERY</commandClass>
<commandClass>COMMAND_CLASS_WAKE_UP</commandClass>
<commandClass>COMMAND_CLASS_ALARM</commandClass>
<commandClass>COMMAND_CLASS_SENSOR_BINARY</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_BINARY</commandClass>
<commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
<commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
<commandClass>COMMAND_CLASS_ALARM</commandClass>
<commandClass>COMMAND_CLASS_BATTERY</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>Basic Set</name>
<profile1>0x71</profile1>
<profile2>0x7</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_SENSOR_NOTIFICATION</genericDeviceClass>
<specificDeviceClass>SPECIFIC_TYPE_NOTIFICATION_SENSOR</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>0</instances>
<control>false</control>
<versionSupported>0</versionSupported>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__BASIC>
</entry>
<entry>
<commandClass>COMMAND_CLASS_SENSOR_BINARY</commandClass>
<COMMAND__CLASS__SENSOR__BINARY>
<version>2</version>
<instances>1</instances>
<control>false</control>
<versionSupported>2</versionSupported>
<isGetSupported>true</isGetSupported>
<types>
<binarySensorType>TAMPER</binarySensorType>
<binarySensorType>MOTION</binarySensorType>
</types>
</COMMAND__CLASS__SENSOR__BINARY>
</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>LUMINANCE</multilevelSensorType>
<multilevelSensor>
<sensorType>LUMINANCE</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_SLEEPING_REPORTING</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>
<entry>
<int>1</int>
<configurationParameter>
<index>1</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>2</int>
<configurationParameter>
<index>2</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>3</int>
<configurationParameter>
<index>3</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>4</int>
<configurationParameter>
<index>4</index>
<size>1</size>
<value>0</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>5</int>
<configurationParameter>
<index>5</index>
<size>1</size>
<value>1</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>6</int>
<configurationParameter>
<index>6</index>
<size>1</size>
<value>0</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>7</int>
<configurationParameter>
<index>7</index>
<size>1</size>
<value>0</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>8</int>
<configurationParameter>
<index>8</index>
<size>1</size>
<value>10</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>9</int>
<configurationParameter>
<index>9</index>
<size>1</size>
<value>20</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>10</int>
<configurationParameter>
<index>10</index>
<size>1</size>
<value>50</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>11</int>
<configurationParameter>
<index>11</index>
<size>1</size>
<value>100</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>12</int>
<configurationParameter>
<index>12</index>
<size>2</size>
<value>30</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>13</int>
<configurationParameter>
<index>13</index>
<size>2</size>
<value>30</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>14</int>
<configurationParameter>
<index>14</index>
<size>2</size>
<value>50</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>15</int>
<configurationParameter>
<index>15</index>
<size>2</size>
<value>180</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
<entry>
<int>99</int>
<configurationParameter>
<index>99</index>
<size>2</size>
<value>450</value>
<readOnly>false</readOnly>
<writeOnly>false</writeOnly>
</configurationParameter>
</entry>
</configParameters>
</COMMAND__CLASS__CONFIGURATION>
</entry>
<entry>
<commandClass>COMMAND_CLASS_ALARM</commandClass>
<COMMAND__CLASS__ALARM>
<version>8</version>
<instances>1</instances>
<control>false</control>
<versionSupported>8</versionSupported>
<alarms>
<entry>
<alarmType>BURGLAR</alarmType>
<alarmState>
<alarmType>BURGLAR</alarmType>
<reportedEvents/>
<outer-class reference="../../../.."/>
</alarmState>
</entry>
</alarms>
<v1Supported>true</v1Supported>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__ALARM>
</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>1824</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_BATTERY</commandClass>
<COMMAND__CLASS__BATTERY>
<version>1</version>
<instances>1</instances>
<control>false</control>
<versionSupported>1</versionSupported>
<batteryLevel>100</batteryLevel>
<batteryLow>false</batteryLow>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__BATTERY>
</entry>
<entry>
<commandClass>COMMAND_CLASS_WAKE_UP</commandClass>
<COMMAND__CLASS__WAKE__UP>
<version>2</version>
<instances>1</instances>
<control>false</control>
<versionSupported>2</versionSupported>
<targetNodeId>1</targetNodeId>
<interval>3600</interval>
<minInterval>20</minInterval>
<maxInterval>86400</maxInterval>
<defaultInterval>43200</defaultInterval>
<intervalStep>1</intervalStep>
<isGetSupported>true</isGetSupported>
</COMMAND__CLASS__WAKE__UP>
</entry>
<entry>
<commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
<COMMAND__CLASS__ASSOCIATION>
<version>2</version>
<instances>1</instances>
<control>false</control>
<versionSupported>2</versionSupported>
<maxGroups>2</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>2.6</applicationVersion>
<hardwareVersion>1</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>2</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>2022-10-22 15:31:54.637 UTC</lastReceived>
</node>
I hope that helps.
Edit: I’ve just noticed that there’s no battery level channel, there are battery level channels on all the older PD03Z sensors I have.
It does help, but first I have one question from my lack of knowledge, I’m a little surprised how your XML was created with the version of the device in the DB with OH 3.3. The version I edited had parameters 16, 17 and 18, but your XML doesn’t (correctly if what I believe is true). Does your UI page show those parameters?
On the helping side, the XML confirms my suspicions that the parameters in the manual attached above do not align with the device and need further editing. Leveraging the information on the zwave-js site there is a 5 in 1 device with numbers 0020:0718 & 0020:0720 that match the manual. The device you have and others in this thread possess have numbers 0010:0718 & 0010:0720. I was trying to get this split into two devices the Zwave DB and get a device owner to test an XML but had made no progress on either front 
.
At this point I’m just leaning towards a re-edit of the 0010:0718 & 0010:0720 device in the DB along these lines
Five in one -config1.pdf (228.5 KB)
I also manually created an XML as to what these changes would look like. If you are familiar with the process to update a .jar this could be tested. If not, that is okay.
naspd07z_0_0.xml (15.5 KB)
Lastly I think the battery channel is missing because the routing flag is set to true and that is only the case with USB inclusion. That can be fixed
The battery channel is missing because the battery command class is not defined in the database. The database will automatically create the battery channel if the command class is defined.
The battery command class is in the XML, but not the database, so I guess at some stage the device was included using non-battery power. The routing flag is indicative of this, but the routing flag is not in itself related in any way to the battery channel.
1 Like
I’ve never included that sensor using USB power. I took it out of the box, took the back off, pulled the little tabs out that insulated the two CR123 batteries from the battery contacts and included it in my network. I did think it was odd that it listed itself as a routing device.
Sorry - I wasn’t clear. The person who included this into the database had likely included using USB power because the BTTERY command class was not added to the database. Or maybe there’s another explanation, but this is likely to be the cause.
Reading comprehension fail on my part 
Yes, I’m quite happy to do that, no problem.
Great. Based on your XML everything should work fine, but what I would like to confirm is that parameters 12,13,14,15 and 99 can be changed without the “pending”. Basically the “pending” means device did not accept the change either because it is out of range or not a valid parameter. Also I updated the test XML to include the battery channel.
naspd07z_0_0.xml (15.7 KB)
Thanks
Thanks for updating the database, that’s very kind of you.
I’m a bit confused about what you want me to do with the XML file you attached above. I thought you wanted me to install a new jar of the zwave binding once the DB changes have been incorporated into the latest build. I’ve done this in the past in various versions of OH. Is there something I can do with the XML file?
Never mind. I haven’t updated the db yet. I usually test what I plan to update by using the jar -uf or use maven to create a custom jar. In this case, I’ll just update the db next week. It seems we are are on a weekly update cycle, so if all goes well, should be a new snapshot jar by next weekend.
I don’t have a dev environment set up so I can’t compile from source. What do you mean by jar -uf?
[The general idea is explained with this 2.5 post](Modify a zwave binding jar to add/change a zwave device while waiting for a build - Tutorials & Examples - openHAB Community)
In this case it would look something like
jar -uf org.openhab.binding.zwave-3.4.0-SNAPSHOT.jar ./OH-INF/thing/shenzhen/naspd07z_0_0.xml
But don’t feel obligated. I think we are okay as is.
@higgers Edited the DB basically to match your XML (and the zwave-js version) and went on vacation and forgot to mention here. Feel free to test. Changes were in 3.4M4 and zwave binding #189 and later.