Zooz Zen34 Remote Switch unknown device

Have you linked any Items to those channels?

If not, that is expected behaviour of openHAB, I believe. Review openHAB concepts on the website for details.

Yes, I linked “Items” to those channels. Same result

I have also opened a ticket with Zooz to see if they have any insights.

I was wrong about this config being successfully applied… In the UI, my changes show as “Pending”

That is a battery operated device. I missed that first time. You normally need to wake it up many times for the binding to complete device discovery./

Sometimes deleting the Thing from OH (NOT exclude from the network) and then scanning / adding helps. The Thing keeps the same id so your Items should be OK.

I actually have one of those configured on my test OH system.

Zooz support is awesome but I doubt it is a device issue.

I had some weird behavior after upgrading the binding. I resolved it by setting the lifeline, basic set and switch multilevel all to my controller node.

NO!!

Only Group 1 should be set to controller for Z-Wave Plus. That is old behaviour back from early Z-Wave days and can cause issues with modern devices.

I tried deleting (without removing from the network) and re-added. Same result.

I tried deleting AND excluding and then re-added. Same result.

I tried deleting, excluding, factory resetting, then re-added. Same result.

I checked the “Range Test” on the device and regardless of whether I am right next to my OpenHAB Z-Stick or anywhere else in the house it shows “Red” which is supposed to mean it cannot reach the Z-Wave hub directly or indirectly (through repeaters).

I’m stumped. Still waiting to hear back from Zooz as well.

More generically, what is the step by step process for updating to the snapshot binding in OH3? The script referenced earlier in this thread does not work with OH3.

I tried the following:

  • Download latest snapshot from openHAB-ZWave [Jenkins]
  • Place jar in $OPENHAB_HOME/addons
  • Uninstall bundle via karaf console
  • restart openhab

When openhab restarts, I get the following error:

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [268]
  Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"

Am I missing a step? Pulling the wrong jar? Something else?

Current OH 3.1.0 snapshots are not compatible with OH 3.0.x due to breaking changes in OSGi version.

I understand OH 3.0.2 is supposed to be released in about a week. Hopefully it will use the newer OSGI version to be compatible.

So at the moment, is there a way to get updates to the zwave device database in OH3? I just bought a whole bunch of 700 series zooz devices that don’t seem to be in the release version of the database but I believe were added recently

Not only that 3.1.0 binding had a broken database. I recently added Zooz ZEN73 and am working on ZEN74.

I spent the last week helping Chris get OH 2.5 binding snapshots working & tested. I might be able to update a 3.0.x binding jar file with the updated database but it would be unofficial. I tested it with 2.5.x based off a script here in the community.

What unsupported devices do you have?

I have not seen this strange frozen inclusion status in a ZEN34 (I have successfully added these devices to my own network), but this sounds very much like the behavior reported in a few other devices (e.g., here and here). If you check out your z-wave logs debug while you are waking up the device, I expect you’ll see no wake-up signal at all. If that’s the case and then this is a similar situation and somehow during the inclusion process the device gets stuck in a state where it can no longer communicate with the controller so no amount of waking up will finish the inclusion process and a factory reset is the only method to get the device back out of this state.

With the three devices I had that suffered this issue, I could never get them included via the binding with many attempts and dozens of wake-ups. I resorted to open z-wave control panel and they all included on the first try only needing a single wake-up. After they were included using ozwcp they have functioned in OH 100%. I am aware of the discussion currently gong on here, but can only report my own experience. Ozwcp worked immediately, where OH could not after weeks of troubleshooting.

I have a bunch of ZEN30, ZEN76, ZEN34.

ZEN34 is cool! I have one but have not yet put it into use. It was one that got missed in 3.0.1 due to a change on GitHub :frowning:

ZEN30 is in the database but not in 3.0.1

ZEN76 is also defined but not in 3.0.1

I need to see if I can find a 3.0 binding jar file to update. Perhaps I can work on that this evening,

Thanks! I’ll check back here tomorrow :slight_smile: :crossed_fingers: :pray:

I downloaded, compiled, and ran OZWCP, but every time I try to “Add Device” it just crashes with “Invalid homeId”. Oh well…

That is the downside of the database but there are upsides also. I know it does not normally take that long to get it in a release. OZW just uses what the device reports. The binding makes the same calls but prefers the database over the reported capability.

Hope you are not expecting any support for OZWCP :upside_down_face:

1 Like

Nope, no way it was a database issue. It was 100% a inclusion issue. All three devices were in the database (one was a device that had been working with a previous install of OH2 for nearly a year). As soon as ozwcp handled the inclusion, the binding recognized and properly added the things because they were in the database, the binding just could not do the inclusion.

I filed a github issue and had a brief discussion with Chris that ended with him closing the issue. NOT blaming him; this is on me and not him. He gets enough issue false positives that he is 100% in the right to have high burden of proof standards. This is on me not him, I just don’t know what’s going on under the hood well enough to find the smoking gun evidence I need to convince him.

Yeah, sorry. I can’t help with that other than to say make sure you 1) stop OH first or ozwcp can’t access the device, 2) two have selected the correct device in the dropdown at the top of the page, and 3) make sure the user running it has dialout privileges.