I have 3 different type of devices that I’ve been unable to receive data for after re-installing Openhab:
BE469 Touchscreen Deadbolt
NGD00Z-4 Garage Door Controller
ZWA008 Door/Window Sensor 7
The first two existed and worked prior to the reinstall of Openhab (have not been excluded/reset/re-included), and the third is new and was freshly included. Now, all 3 show in HABmin that “Using Security” is false (red X). The third was included from HABmin within 15 seconds, and I thought it should have been securely included.
The paperUI page shows dashes, whitespace, or %NaN% for different fields of the Items of these Things, so it seems I’m not getting any data from them.
For the first two, do I need to remove and re-include them?
For the third, am I missing something on securely including it?
Adding to what @jswim788 said, if you’ve still got a backup of your old installation then you can copy the security key from your ZWave controller in PaperUI and paste it into your new installation. Then you’ll need to reinitialize your lock and garage-door controller.
For your Sensor 7, you might need to wake it up quite a few times to get it working. However, if you change your security key then you’ll have to remove and re-include it.
Note that secure inclusion increases Z-Wave traffic significantly, which could cause network issues and will impact battery life. For these reasons, some folks recommend only using it for devices that can unlock your house, and leave everything else insecure.
Kernel: Linux THANATOS 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
java version “1.8.0_161” Java™ SE Runtime Environment (build 1.8.0_161-b12)
Openhab: openHAB 2.5.4 Release Build
ZWave Binding: 2.5.4
ZWave Controller: Aeon Labs Aeotec ZStick
Gotcha! I thought the pairing worked at the controller level, but I suppose that makes sense if OpenHAB itself handles security.
I have a backup, but am unfamiliar with how to take down the 2.5 OpenHAB and put up the old one. The link you posted suggests the key is also stored in a file – could I just copy that over straight from the backup? If so, where is this file?
I’ve been triggering the sensor repeatedly and can’t seem to get any event in the events.log file.
Gotcha. I would prefer these Sensor 7 to be non-secure then – but how can I do that properly? It seems like the sensor expects secure, Openhab has it as non-secure, and there’s no option to change this in HABmin or in the sensor’s docs.
Look for this file in your backup: /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.Thing.json
Inside it, look for the “security_networkkey”. That’s what you want. You can use PaperUI to set it on your new installation. Edit the controller thing (probably need to click on ‘show more’), and put your old key in. I have not done this personally. @rpwong’s link has some useful info on getting it working again.
Edit: you could stop OH and edit this json file in your new installation as well. Be very careful if you do this, but it is an editable text file.
I was guessing that you’d still have your old installation on another SD card, in which case you could just put it back into your Raspberry Pi to get the key (either via PaperUI or the file).
I’d probably just do a full reset on the sensor, remove it from openHAB using Habmin, and then add it again. I’d be surprised if it defaults to expecting secure inclusion, but I don’t know much about it.
Got the lock and the garage door! Thanks. I followed the reinitialization in Upgrade to 2.5 - zwave secure device not working but struggled to find where to do this. It turns out this is an option in the Thing settings in PaperUI, but not in the Thing settings of HABmin. After clicking reinitialize and save, the devices showed as “Secure” (green check mark) in HABmin and functioned as expected. I can control them through HabPanel. Thanks!
Ok! I did this by entering exclude mode on controller, excluding the sensor, deleting the Thing from HABmin, then re-including the sensor and adding the Thing. It came back with a new node ID (27 instead of 24), which I suppose makes sense. But the openhab.log showed:
2020-05-19 16:39:59.775 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 27: Command Class COMMAND_CLASS_BASIC has version 0!
Is that a problem?
The sensor shows up in HABmin and PaperUI as not secure, which is desired. But after activating the sensor, manually waking it up, and waiting for over 30 minutes, there doesn’t seem to be any events in the events.log file or any state showing up in PaperUI Control tab. All I see is:
The settings for the sensor itself is shown here, and it shows that I have Items for the contact sensor, alarm, and battery level:
I believe I have followed the docs on adding these devices, I’m just unable to see anything from them.
I opened the Karaf console, ran log:set DEBUG, and then restarted openhab. This is the log file from this start for about 12 minutes, where I was triggering the ZWave node ID 27 sensor about once every minute. After 7 minutes at 20:48, I hit the alarm button, which is the documented “Wakeup” method.
Use Habmin, select your z-wave controller, choose z-wave network settings and set “Secure Inclusion Mode” to “Entry Control Devices”. This includes only door locks or similar in secure mode. Set “All Devices” would include all nodes in secure mode as long as they support security.
I had similar problems with the Aeotec ZWA008 Door/Window Sensor 7 inclusion. First device took more than 1 hour. I fed the others with a 3.5V power supply (remove battery while using external power). But inclusion still takes time. You must triple click the tamper switch to wake up the device. The LED flashes than 5 times. You can check the different stages of initialization during inclusion in Habmin. Sometimes it didn’t continue. Then I clicked the tamper switch not only 3 times but multiple times, may be 20 or thirty times. Finally, it finished inclusion, set controller to association group and generated the XML file.
Thanks for the suggestion! I went to do this and found that the “Secure Inclusion Mode” was already set to “Entry Control Devices”. May this be an issue with the manufacturer being unknown in Openhab’s database? I do recall seeing unknown manufacturer warnings in the log and in HABmin.
Mine seems to have finished inclusion according to HABmin, unless I’m misreading this. Do you think there’s a step incomplete and that excluding and re-including with your method may be necessary?
Did you check if an XML file with the right node number was generated in your /var/lib/openhab2/zwave folder? And please check if “Controller” was inserted in your association group 1:Lifeline (in Habmin). If this is not the case try to wake up the device multiple times and veryfy wake up in the log. It is always recommended to activate debug log for zwave if a device makes trouble.
Bruce, you are right, association is set automatically by binding. But I had seen it multiple times that inclusion didn’t finish with this battery device and one indication for that is that the Controller wasn’t set automatically, association goup 1 kept empty. I didn’t mean to set it manually, just check if it is done by the system. And second indication is the XML file.
I just checked this, and there is no .xml file for these sensors in /var/lib/openhab2/zwave/. What does this mean?
Ah, thanks! “Controller” did not show up there, however when I add it to 1: Lifeline, click Save, then go to a different Thing and back, the 1:Lifeline text box shows empty still and no XML file exists. Immediately as I click “Save”, my /var/log/openhab2/events.log shows this:
2020-05-26 17:41:14.994 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:730141c1:node27' has been updated.
2020-05-26 17:41:14.998 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=]
and the /var/log/openhab2/openhab.log shows:
2020-05-26 17:41:57.231 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Configuration update received
2020-05-26 17:41:57.235 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Configuration update set group_1 to [controller] (ArrayList)
2020-05-26 17:41:57.238 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Association 1 consolidated to [controller]
2020-05-26 17:41:57.240 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Unknown association group 1