I have switched to OH3 and just got around to fix the zwave stick / pi4 problem.
I successfully connected all zwave devices but my two Garage Door Controller.
They are not initializing as the binding does not find the thingType.
[wave.discovery.ZWaveDiscoveryService] - NODE 5: Device discovery could not resolve to a thingType!
They were working without problems in OH2 and 2.5 and are listed as ZW062 in the compatibility lists.
Can I somehow tell OH the correct device ID to get the initialization done?
Or is the ZW062 somehow not anymore supported?
This could be something with initialization (possibly taking too long, possibly with the security, possibly too far from the controller), but it is hard to say. This is a case for a zwave debug log. My suggestion is to to exclude, then delete thing, then run the scan while in Debug mode. If you can move the device and plug it into the USB near the controller that could/might help.
I don’t have the device, but the zwave database looks in order.
The zwave controller is set to secure include all devices and I successfully included other devices further from the controller. But as this is a barrier device the security thematic could be more restrictive than the other devices.
Also what is interesting, the affected devices are shown like this Z-Wave node 5 (0086:0003:003E::1.12)
Is there a best practice zwave debug guide? Or do you mean setting the binding debug level to debug?
I will try it later this day / tomorrow.
Just set the binding to debug level.
It is not required, but I have a separate zwave log as explained at the bottom of this link
Also for self help and an easier to read file use this
I don’t know what the numbers mean.
Edit: Just checked the database. I think the numbers are related to the manufacturer and item
It says this in the UI:
This device has not been fully discovered by the binding. There are a few possible reasons for this -:
The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like “Z-Wave node 1 (0082:6015:020D::2.0)”).
The other working devices did not have the Type-ID displayed.
I will set up the logging and report back.
I have logged the inclusion in this case the new included controller is node 8.
zwave.log (835.9 KB)
What is interesting, that when checking for the device, there is no ZW062 listed:
zwave_2.log (192.6 KB)
So I tend to think, as you do, that there is something with the database. The first part of your numbers ( 0086:0003:003E) does align with device entry. However, there does appear to have been an edit to the device on July 19, 2021 which could explain why it worked before, but not now. When the device is “modified”, but waiting review, it will not make it into the binding. I pulled a past binding from early July and the device was missing from the resource list, but in an early august version it is back.
I think the next step is to update the binding (and hopefully pull in the device). I’m not sure of your set-up but there are several ways to do this. What version of OH3 are you on? Are you adding the binding via the UI, or do you have it in the addons folder? Have you just updated the binding before?
I have OH 3.1.0 Running and the zwave binding installed via UI.
As I see on github, there is currently only the first Milestone available for 3.2.0.
Do you think this will be stable enough to run on an live environment?
Also is there a compiled version available somewhere?
Or should can I compile the 3.1.0 version with the newer device list?
Generally the milestones should be okay, but I have to say I’m on 3.1.0, but use a custom zwave binding in the addons folder. As to the zwave binding itself, even the latest 3.2 snapshots are very stable. The underlying program has changed very little in the last couple of years. The major reason it is updated every few days is for the zwave database, which is constantly changing (as you unfortunately experienced).
What I don’t know, with my snooping skill level, is whether the zwave binding in the first 3.2 OH milestone was compiled with the file you need, so I would hate to recommend that and have it not work either.
The latest Zwave jar is here It should work with OH 3.1
It may be overkill but I follow the following:
- Uninstall the UI zwave binding
- SSH into my Pi; Stop OH
- sudo openhab-cli clean-cache
- start OH
- When available (wait a minute or two); sudo openhab-cli console
- Feature:install openhab-transport-serial
- Lastly add the new jar to Addons
- Wait 30 seconds (and pray)
I have seen others take different steps, so if you have a process you are more comfortable with, go for it.
edit: If the device isn’t automatically recognized, try to delete thing from the UI Node 8 page (do not remove from controller), go to inbox and scan
Ok, I have no problems doing these steps and can try it.
One thing stopping me to do it right away: is the openhab-transport-serial affecting other addons?
I got modbus and rfxcom and more running and dont want to break them.
I always get a little shy at this point. I don’t want to make things worse for you (i.e. first do no harm). Eventually there will be a version of OH3 that you are comfortable with AND an UI Z-wave binding with your device. It was just bad luck the zwave database was undergoing a modification of your device with the 3.1 stable release. It is always safest to have the binding added via the UI. There can be changes in the underlying programs that are used in compiling the code that create problems
That said; I believe that the openhab-transport-serial is automatically installed (or deinstalled) when you add/delete the zwave binding using the UI. It is just not automatically installed with a Zwave jar in the addons. I know nothing of the other bindings, but if they are running now they should not be affected. If there is a problem feature:uninstall ?
Lastly, it is a good idea to do a backup before you start down this road.
- sudo openhab-cli backup --full
I’ll have my fingers crossed.
I got it running and the ZW062 is now recognized correctly.
I’ve set the log back to INFO and let it running like this.
I check the updated UI installation when 3.2 is stable.
@apella12 Thanks a lot for your support!