I’m extremely new to OH and I’m hoping someone can assist me with updating the z-wave database. I’ve acquired the logs and XML generated by openHab during the inclusion process. I hope this information is enough to assist in the process.
I am using 2.3.0 z-wave binding and included the device using Habmin (secured; high powered). I did run the inclusion log through the cd-jackson @chris website but I’m not sure how to post that here (apologies).
Z-Wave Node 014 (010F:1401:2000:4.0)
Unknown Device
This device has not been fully discovered by the binding.
The device initialisation is not complete.
|zwave_class_basic|BASIC_TYPE_ROUTING_SLAVE|
|zwave_class_generic|GENERIC_TYPE_SWITCH_BINARY|
|zwave_frequent|false|
|zwave_neighbours|1|
|zwave_version|4.0|
|zwave_listening|true|
|zwave_plus_devicetype|NODE_TYPE_ZWAVEPLUS_NODE|
|zwave_deviceid|8192|
|zwave_nodeid|14|
|zwave_routing|true|
|zwave_plus_roletype|ROLE_TYPE_SLAVE_ALWAYS_ON|
|zwave_beaming|true|
|zwave_secure|true|
|zwave_class_specific|SPECIFIC_TYPE_POWER_SWITCH_BINARY|
|zwave_manufacturer|271|
|zwave_devicetype|5121|
239 │ Active │ 80 │ 2.3.0.201802082157 │ ZWave Binding
Seems I’m having difficulty sharing the OH log data during the inclusion since it’s not in the appropriate format (e.g. XML/JSON). So any guidance here would be appreciated. And apparently I’m not using the latest binding as I see an update was posted on Feb 25th of this year. I did search through the database and was unsuccessful in locating this particular device.
Not needed, the device is definitely not in the database.
After adding the device to the database you need to wait for approval, then for the next build and then you need to upgrade to that latest zwave binding.
Please before starting this can someone (probably @Private) check if the parameters and associations are “the same” (ie close) to those in the FGWP101. If they are, then we can copy the current parameters and then just change/add anything that’s different. This will likely save time - of course, if anyone prefers to just add them all again, then that’s also fine
If it’s “just” the numbering, then this still might be quicker. Normal users with editing rights can change the numbers - or maybe this is just asking for a mess .
In any case, if there are quite a few differences, then it might just be safer to start the entry again.
I checked again, also the allowable ranges are mostly different and have to be adapted. More changes which would be needed:
1 has to be deleted
change 10 to 11
delete 12
change 13 to 12
change 14 to 13
delete 20
switch 22 with 21
and so on …
@Private, I guess you need to register and add the parameters
Thanks to @sihui nd @chris for all your assistance and timely response. I’ve registered and I’ll begin to add all the configuration params once I have editing rights.
Thanks and here comes my shout… In the case of a parameter that’s range based, should I bother with adding it as an option (default, upper and lower)? I started to do this then figured I’d ask. SO many options to enter. I’m also a bit confused on how to handle the following notations:
Endpoint 0 has no command class linked to the basic class.
Endpoint 1 has no command class linked to the basic class.
Endpoint 2 has no command class linked to the basic class.
Device supports associations, but no groups are defined.
No - probably not. If there are specific options, then you can add these, but otherwise you can just set the min and max.
As an example, there might be a range of 0 to 100, and an option of 255 meaning disable. In this case, you can set 255 as an option, the min and max to 0 and 100. There is a tickbox “allow free entry” -:
I believe I have everything added, I’ll take another look later tonight but would appreciate a quick review to verify I’ve done this correctly. I did have some trouble with Parameter [3] as I inadvertently added 2 options I couldn’t remove (last 2 which are both zero with no data).
I’ll get this added to the binding in the coming days. I have some fear that there are some issues as endpoint 1 and 2 don’t look complete for some reason. It might not matter as everything is available in endpoint 0, but let’s see…
I’ve loaded the following bundle (below) and re-interviewed the Fibaro Wall Plug. Here are some observations as there appears to be an issue but I’ll let you determine if it’s a user error.
243 │ Active │ 80 │ 2.3.0.201803041016 │ ZWave Binding
21:04:56.249 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 15: Application Command Request (ALIVE:REQUEST_NIF)
21:04:56.249 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 15: Decapsulating COMMAND_CLASS_SECURITY
21:04:56.250 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 15: Error decapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:893) [?:?]
at javax.crypto.Cipher.init(Cipher.java:1249) [?:?]
at javax.crypto.Cipher.init(Cipher.java:1186) [?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:501) [243:org.openhab.binding.zwave:2.3.0.201803041016]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:303) [243:org.openhab.binding.zwave:2.3.0.201803041016]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1170) [243:org.openhab.binding.zwave:2.3.0.201803041016]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:440) [243:org.openhab.binding.zwave:2.3.0.201803041016]
This may be a good time to provide some supporting log data. Just give me an idea of what your looking for (inclusion, wake-up etc, the whole enchilada).
Yes, appears to be a ‘me’ issue. Directly related to ‘me’ not storing the security key prior to removing the binding (shame). Since I’m just using a few Fibaro (various) devices, I decided to hard reset the controller, exclude and include (w/ security @ high power). Things are looking good so far, although I do see that none of the devices are using security (odd).
Another beginner question. Can someone explain how the following files are managed when one excludes a device. In my case (see post above) I excluded devices 10-15 then reset my z-stick controller. I re-included the devices afterwards (2-8).
-rw-r--r-- 1 openhab openhab 18511 Feb 12 21:26 network_00000001__node_12.xml
-rw-r--r-- 1 openhab openhab 19328 Feb 12 21:40 network_00000001__node_13.xml
-rw-r--r-- 1 openhab openhab 15575 Mar 3 02:30 network_00000001__node_14.xml
-rw-r--r-- 1 openhab openhab 25057 Mar 3 19:25 network_00000001__node_15.xml
-rw-r--r-- 1 openhab openhab 25788 Mar 7 03:55 network_00000001__node_2.xml
-rw-r--r-- 1 openhab openhab 18049 Mar 7 08:06 network_00000001__node_3.xml
-rw-r--r-- 1 openhab openhab 20231 Mar 7 04:11 network_00000001__node_4.xml
-rw-r--r-- 1 openhab openhab 29755 Mar 7 02:44 network_00000001__node_5.xml
-rw-r--r-- 1 openhab openhab 17234 Mar 7 03:13 network_00000001__node_6.xml
-rw-r--r-- 1 openhab openhab 6043 Mar 7 02:44 network_00000001__node_7.xml
-rw-r--r-- 1 openhab openhab 10414 Mar 6 21:44 network_00000001__node_8.xml
-rw-r--r-- 1 openhab openhab 17528 Feb 6 17:39 network_00000002__node_10.xml
-rw-r--r-- 1 openhab openhab 17861 Feb 7 19:59 network_00000002__node_11.xml
-rw-r--r-- 1 openhab openhab 19170 Mar 4 20:57 network_f7340b2e__node_10.xml
-rw-r--r-- 1 openhab openhab 17886 Mar 4 20:32 network_f7340b2e__node_11.xml
-rw-r--r-- 1 openhab openhab 16000 Mar 4 20:33 network_f7340b2e__node_14.xml
-rw-r--r-- 1 openhab openhab 1860 Mar 7 02:44 network_f7340b2e__node_1.xml
In log output, I often see this message cycle through.
14:06:02.738 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 14: Node not found - has this node been removed?!?
Is it recommended to garbage collect and dispose of the unused XML files ? I’m curious why I’m only seeing the above log entry when there were other devices removed in the same manner.
.
