OH2 Z-Wave refactoring and testing... and SECURITY

chris · August 29, 2018, 6:13pm

For most devices, this is not necessary, and not recommended. For the devices I’ve tested, including the BE469 that I have, it was certainly not necessary.

Maybe there are some old devices out there that still need this, but it should be the exception rather than the rule (still worth keeping in mind if things don’t work ).

Ben_Douglas · August 29, 2018, 6:28pm

Yes, I understand. I just wanted to emphasize that you may think you are close enough to the controller, but you may not be. Over 20 tries at 20cm did not work. The first try at 1cm worked. FWIW, my other same model lock securely included at a distance of ~ 1m.

chris · August 29, 2018, 7:05pm

I’m afraid you’ll have to excuse me for still suspecting that the distance is not the real issue here .

chris · August 29, 2018, 7:12pm

@peter_oh what controller do you have? The only thing that looks a little strange in your log is that the call to end the inclusion mode times out. This doesn’t happen on my stick. This might indicate something strange with the controller, or, the delay might cause the secure inclusion to time out (although I don’t think so as it’s still only waiting about 8 seconds after the initial inclusion before the key exchange starts, but it’s still a little close to the edge if the specific lock is maybe also a little on the “quick” side).

Otherwise, all looks ok.

I will see if I can reduce the timeout on the last call to see if that helps…

peter_oh · August 29, 2018, 7:13pm

It’s an Aeotec Z-Stick Gen 5

chris · August 29, 2018, 7:14pm

Ok, blows that theory - same as mine

Thanks.

chris · August 29, 2018, 7:19pm

I see the same issue with no response on my Gen 2 stick. I know Aeon are running old firmware in many of their controllers still.

I’ll try and reduce the timeout if possible

sihui · August 30, 2018, 8:50am

If you trigger on received update and your FGMS config parameters are set for example wrong, that resetting can happen very easily.
So the only chance to get any help is to:

post your rules
post a debug log from where motion begins
provide info WHICH FGMS your are using (parameters can be different between firmware versions)

mstormi · August 30, 2018, 8:52am

Pardon?
Do you run the binding that this thread is about (development version), or do you run the version that comes with the 2.4.0 snapshot ?

This thread is about that binding, so may I kindly ask you to open another thread first and get your issue sorted out there?
And you should post your rules, items and zwave debug level logs, otherwise noone will be able to help.

Eventually come back here when you have reason to believe that there’s a misbehavior in the (development version) binding (I don’t think it is).

dastrix80 · August 30, 2018, 8:52am

Thanks Markus & Sihui, ill open a new thread

dohabandit · August 31, 2018, 6:24pm

I am running the development snapshot as of August 27th. (Had to go into karaf and remove the snapshot bundle for zwave and enable the addon/development jar, so yes I am running the “development” snapshot).
Anyway, I got my BE469 lock to securely join and I added a bunch of switches and a couple sensors after getting BE469 securely added. Yesterday I added a couple Aeotec dual channel power meters. It is reading the meters sensor values, but now my switches are intermittently working. Sometimes I send on on/off command to a thing for a switch item and it works. Sometimes it doesn’t.
In Habmin, the thing will intermittently no longer show active channels and the switch item isn’t showing.
In my openhab.log file, I see references to nodes that do not exist! I only have 29 total devices/nodes. My log file is sometimes jumping as high as Node 148!

2018-08-31 03:07:20.658 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 48: Not initialized (ie node unknown), ignoring message.
2018-08-31 05:01:28.499 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.
2018-08-31 05:01:29.169 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 148: Not initialized (ie node unknown), ignoring message.

Zwave node xml config files:

ls -la /var/lib/openhab2/zwave
total 324
drwxr-xr-x  2 openhab openhab  4096 Aug 29 10:11 .
drwxr-xr-x 11 openhab openhab  4096 Aug 24 23:22 ..
-rw-r--r--  1 openhab openhab  6063 Aug 31 02:32 network_ea85d234__node_10.xml
-rw-r--r--  1 openhab openhab  6624 Aug 31 02:36 network_ea85d234__node_11.xml
-rw-r--r--  1 openhab openhab  6625 Aug 31 02:38 network_ea85d234__node_12.xml
-rw-r--r--  1 openhab openhab 10291 Aug 30 21:28 network_ea85d234__node_13.xml
-rw-r--r--  1 openhab openhab  9857 Aug 30 21:23 network_ea85d234__node_14.xml
-rw-r--r--  1 openhab openhab 10478 Aug 31 02:39 network_ea85d234__node_15.xml
-rw-r--r--  1 openhab openhab 17869 Aug 31 02:39 network_ea85d234__node_16.xml
-rw-r--r--  1 openhab openhab  9821 Aug 31 02:39 network_ea85d234__node_17.xml
-rw-r--r--  1 openhab openhab  9821 Aug 30 21:23 network_ea85d234__node_18.xml
-rw-r--r--  1 openhab openhab  3348 Aug 31 02:35 network_ea85d234__node_1.xml
-rw-r--r--  1 openhab openhab 22550 Aug 31 02:38 network_ea85d234__node_20.xml
-rw-r--r--  1 openhab openhab 24742 Aug 30 20:29 network_ea85d234__node_26.xml
-rw-r--r--  1 openhab openhab 20111 Aug 31 02:36 network_ea85d234__node_28.xml
-rw-r--r--  1 openhab openhab 19674 Aug 31 02:34 network_ea85d234__node_29.xml
-rw-r--r--  1 openhab openhab 13078 Aug  8 14:34 network_ea85d234__node_2.xml
-rw-r--r--  1 openhab openhab 24624 Aug 31 02:34 network_ea85d234__node_3.xml
-rw-r--r--  1 openhab openhab  7083 Aug 31 02:37 network_ea85d234__node_4.xml
-rw-r--r--  1 openhab openhab  6921 Aug 31 02:37 network_ea85d234__node_5.xml
-rw-r--r--  1 openhab openhab  6868 Aug 31 02:37 network_ea85d234__node_6.xml
-rw-r--r--  1 openhab openhab 13698 Aug 31 02:37 network_ea85d234__node_7.xml
-rw-r--r--  1 openhab openhab 13673 Aug 30 15:19 network_ea85d234__node_8.xml
-rw-r--r--  1 openhab openhab 13690 Aug 30 15:19 network_ea85d234__node_9.xml

Is there some other switches I can set to get more ZWave debug output to help troubleshoot this issue?
If I restart the openhab service, my control of devices works for a couple minutes until it stops.

mhilbush · September 1, 2018, 12:25am

Are you possibly experiencing this issue?

github.com/openhab/org.openhab.ui.habmin

HABmin "loses" item-channel links

opened 02:28PM - 07 Jul 18 UTC

mhilbush

For a very long time I've seen the situation where HABmin loses the item-channel… links. This manifests itself in the HABmin UI on the Thing display. The **Channels** pane shows *0 Active* channels, when in fact there are one or more than one *Active* channels. Opening the **Channels** pane shows all the channels, but the items linked to those channels are gone. Doing a page reload corrects the problem. I believe I've tracked this down to the scenario where the status of the thing has changed. The best example is when the Last Wakeup Time attribute is updated. Scenario to reproduce: - Load HABmin - Click on a node Thing and observe the number of *Active* channels. It should be 1 or more. - Wake up the node - Click on another node Thing - Click on the original node Thing and observe that the number of *Active* channels is 0. I tried to trace through the Angular code to see what's going on. Unfortunately, my Angular skills are really poor. ☹️

You could put the binding into debug mode, which will generate substantially more information about what’s going on. In the karaf console, you can type the following to go into debug mode.

log:set DEBUG org.openhab.binding.zwave

And the following to get it out of debug mode.

log:set INFO org.openhab.binding.zwave

That’s strange. Hopefully debug mode will shed some light about what’s going on.

Lolodomo · September 1, 2018, 12:24pm

My SD-Card in my RPI is certainly almost dead and can no more be written.

I can find these errors every day during the night:

2018-09-01 02:18:34.091 [ERROR] [l.initialization.ZWaveNodeSerializer] - NODE 1: Error serializing to file: xxx/openhab/userdata/zwave/network_efceec2d__node_1.xml (Système de fichiers accessible en lecture seulement)
2018-09-01 02:18:34.102 [ERROR] [l.initialization.ZWaveNodeSerializer] - NODE 1: Error serializing to file: xxx/openhab/userdata/zwave/network_efceec2d__node_1.xml (Système de fichiers accessible en lecture seulement)
2018-09-01 02:18:37.115 [ERROR] [l.initialization.ZWaveNodeSerializer] - NODE 2: Error serializing to file: xxx/openhab/userdata/zwave/network_efceec2d__node_2.xml (Système de fichiers accessible en lecture seulement)
2018-09-01 02:18:37.124 [ERROR] [l.initialization.ZWaveNodeSerializer] - NODE 2: Error serializing to file: xxx/openhab/userdata/zwave/network_efceec2d__node_2.xml (Système de fichiers accessible en lecture seulement)
...

@chris : just for my information, what feature leads to the writting of these files every day in the night ?

Lolodomo · September 1, 2018, 12:36pm

Additional question: in my userdata/zwave folder, I find a XML file for each of my Z-Wave nodes except my minimote (node 13). Is it normal ?

chris · September 1, 2018, 12:40pm

The data get serialised after the heal, and also after any configuration change.

Probably not. Normally there should be a file for every node once it has completed the initialisation (ie the interrogation phase, where the binding reads a load of information out of the device that describes all the features it provides.

mhilbush · September 1, 2018, 12:44pm

Minimotes can be hard to get to complete initialization. Since they don’t wake up on their own, you need to wake them up manually, sometimes repeatedly.

Lolodomo · September 1, 2018, 12:48pm

Do you know the action to wake up a minimote ?

Lolodomo · September 1, 2018, 12:48pm

Ok I was almost certain that it was the nightly heal.

sihui · September 1, 2018, 1:25pm

DB is your friend:

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/74

Press and hold the button labeled “Learn” for 3 seconds – The Minimote will stay awake for 30 seconds.

jwiseman · September 1, 2018, 8:39pm

First off, the new binding is a huge leap forward on zWave front.

Here’s how I resolved this with the new binding with the same 4 devices being UNKNOWN.

deleted the 4 offline zWave devices via paper ui
shut down OH2.3
copied the 1 XML file that was working /userdata/zwave and made 4 others changing the name of the node for each file name
edited each XML file and changed the node to match the file name node (you may have to pull the XML file out of /userdata/zwave to edit it because the directory is pretty locked down for edits)
deleted and recreated the /userdata/cache & /userdata/tmp folders
reboot NAS
started up OH2.3
waited for paper ui to start and went into and the 4 nodes were defined correctly now

Hope this helps someone . . .

Best, Jay