Background:I run two OpenHAB servers — one on OH 2.5.12 and one on OH 5.1.0. The OH 2.5.12 server is using an Aeotec Z-Stick Gen5 as the primary Z‑Wave controller (SIS Node = 1) and has worked fine for years. I want to add an Aeotec Z-Stick 10 Pro to the OH 5.1.0 server and have both Z‑Wave controllers active simultaneously, but I’m unsure how to configure the new stick correctly.
For OH5.x there was a fix in the ZW binding at startup, so the fix was not needed anymore.
Anyway, one possibility (and what I have done between OH instances) is to use the remote OH binding to bring in the items to OH5.1. All my rules run on one OH instance and all the charts, etc. are there too. The remote OH (OH 2.5.12 in your case) just runs ZW. I have done this to optimize direct connections between controllers and nodes. (ie I have a basement location (21 nodes) and an upstairs (36 nodes) network. Don’t know if that fits your goals.
That’s why I bought the Aeotec Z‑Stick 10 Pro for my OH 5.1.0 server — I hoped it would detect the 620 lock immediately, but it hasn’t. I suspect the existing active Z‑Wave network may be causing the issue, but my Z‑Wave knowledge is minimal. I’m stuck and would appreciate any help or suggestions from you or others on the forum.
Not sure I understand. To be clear the XML on your OH system is not the XML needed to make the device recognized.
I’d like to check the DB for your device, just to make sure we are on the same page. Do you have a message like this node x (0090:0811:xxxx::x.x)? or paste the contents of the property dropdown on the node UI page.
We agree on baby steps. My concern is the device is NOT in the ZW DB. If that is true, everything done so far was a (painful?) learning experience. Devices are recognized by the numbers (in hex), not the model information and I copied the node x message directly from the docs. It is also on your screen shot under the orange bar. Numbers might be covered up by the orange bar. This post is background. I want to confirm the numbers before doing anything else.
One thing to try to get these numbers (since I do not see them in your screenshot). On OH5 with the 10 Pro, put the ZW binding in Debug mode (UI setting page on the right), then put the controller in exclude mode from it’s UI page and press the EXCLUDE sequence from the lock manual. If the log shows that was a success, then go to inbox, zwave, scan while pressing the INCLUDE sequence from the manual. There should be the needed numbers in the debug log
I have one of these. Set up was no problem. Install the zwave and the zigbee binding, the protocols use different ports so you have to set them up as so. The zigbee bridge you should use is ‘ember’ then just pair everything as normal using the ‘scan’ button.
Yes, assume that screen is from OH5 inclusion? There was a bug in 5.1.0 about the exclude, but it looks like the lock is included. The exclude was to make sure it wasn’t still paired with the 2.5. Anyway the device is not in the Db, will need to update. I can get you a file, but maybe not today
It will need to be added using the procedure. You may be able to use a compressed file editor, like the last post of the reference.
I don’t think the lock got fully included in OH2.5 since the numbers were not in your screen shot, but excluding is always a good idea with failed inclusions. If you upgrade to the 5.1.1 patch release the exclude button will reappear in case you need it. (but shouldn’t). Also: If you are going to upgrade, do it before you update the jar. The OH upgrade will wipe the jar fix and you will need to do it again. The ZWDB will be updated in a stable 5.2 around June.
That gets it out of OH, but the device is still on the Z-stick and can be only paired with one zstick at a time.
Linux permissions are not my strong suit. I presume that the owner of the jar modify file is openhabian, but openhab itself runs under user openhab.
Rather than guess, the other option that should work is to remove the current ZW binding from the UI (store), and drop the modified jar in addons. You may have to run feature:install openhab-transport-serial in the console. (It is a dependency). Although more complicated, the advantage is that it should survive OH upgrades.
@apella12 Good news — after placing the modified JAR in /usr/share/openhab/addons, the Thing Type now appears as “Kwikset 620 Deadbolt variant.” and the Channels showed up.
I did need to tweak your XML: I replaced the semicolon with a colon. See below.
@apella12 Hi Bob, for some reason the Kwikset 620’s Alarm (raw) channel remains NULL. Do you have any idea why? Without the data, I don’t think I can write any rules.
I have no locks, so nothing to compare. What I would do is delete the thing, do not exclude, and then scan to pick up again. Everything should be preserved and maybe better.
