I have this too.
Sorry guys, I’ve not had the chance to look at this over the last day as I was not at home yesterday. I’ll take a look tonight - this is related to the hold-off timer.
Apologies for the hassle…
when I last checked you were doing this out of goodwill in your spare time, so an apology is neither expected nor required!
6 Likes
Hey there,
I’m planning to buy a zwave door lock, so I guess I should migrate to this version of the binding, right?
Are there any plans to merge both z-wave bindings, or deprecate the old one and continue with this one?
Do I have to remove all things and re-add all the nodes via HABmin? I guess I dont need to have physical access to the nodes, since they are still connected to the Aeotec USB stick, right?
Thanks for your help!
Best Sebastian
Correct. You need to install the version from the link in the first post of this thread. You also should confirm whether or not the door lock is in the database. If it’s not in the database, then you’ll need to do a little extra work to have it added. Odds are pretty high that it’ll be in the database.
Yes, @chris plans to replace the current master version with this version soon once a couple issues get sorted out.
Yes. You need to delete the node things (including the serial controller), then add them back. No need to exclude/include. A while back, I posted the steps I followed to migrate from master to development, in case you want to see what I did.
True, with one possible exception. If you have battery devices, you will need to wait for each of them to wake up before the initialization can complete. Having physical access can help speed up the initialization because you can wake them up manually.
3 Likes
With the commit - Database update (#964), a new definition was added for the Fibaro smoke detector (FGSD002). The original defintion was changed to include:
versionMax" 3.1
My smoke detectors are version 3.3, and now when I try to add them from the inbox using PaperUI, I get an "Error: 404 - Not found, and the smoke detectors just remains in the inbox. Nothing in the log files! Even when logging zwave debug. Should I change log level on something else?
In the jsondb folder the DiscoveryResult file shows that it is using the new definition.
I assume there’s something wrong with the new definition file. I have tried deleting the cache and tmp folders.
New File: fibaro_fgsd002_3_2.xml
Original File: fibaro_fgsd002_00_000
On the device database homepage I can see that the new definition was approved on the 19th of July.
Approved on 2018-07-19 17:35:25, and last exported on 2018-07-20 23:16:28
I would suggest to delete it from the inbox and try a rediscovery to see if it improves things. I don’t think a problem in the database shouldn’t prevent a device being added as a thing.
Done that many times. Same result.
This was done because of this post:
I have been able to discover and add my smoke detectors up until the last developer version. With the latest version I devices are discovered correctly, but I cannot add them as things.
Z-Wave Node 008: FGSD002 Smoke Detector
FGSD002 Smoke Detector
As a quick local work around I have changed to versionMax and versionMin in fibaro_fgsd002_00_000 and fgsd002_3_2.xml so that version 3.3 will use the original file. Then it works.
I would like to know if anybody has tried to add a fgsd002 version 3.3 with the latest development version (24th of July).
Please provide the XML file for your device - or some information on it. From a quick look at the database, I don’t see anything obviously wrong with the database that would cause this, and my suspicion is it’s something specific to your system with respect to the change in thing uid.
These files are taken from the current org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar (24th July)
fgsd002_3_2.xml (16.9 KB) Not working
fgsd002_0_0.xml (15.5 KB) Working
By the way, is org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar (24th July) now build of the master branch? I guess it must be because the change adding fgsd002_3_2.xml has not been committed to the developement branch.
I’m seeing this, but with some WALLC-S switches - running OH #1318 and zwave binding 2.4.0.201807242215.
I think these also got updated recently in the zwave database.
Here is the xml file:
network_f1e8718f__node_29.xml (14.2 KB)
EDIT:
Found some warning message in the log:
19:33:38.645 [WARN ] [ig.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type zwave:zwaveme_wallcs_00_000.
Nope, three month ago:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/145
These files are generated by the database - I can easily get them directly from the database, and I did a comparison on them earlier.
What I was after is the XML that OH generated for your device.
If its the xml file in the zwave folder you want, then its not generated.
Here’s the DiscoveryResult:
org.eclipse.smarthome.config.discovery.DiscoveryResult.json (1.1 KB)
any changes with the Fibaro Door/Window Sensor 2 (FGDW-002) ?
I actually try the DevBinding 2.4.0 from 24th July - The Sensor give me a:
2018-07-26 21:38:41.464 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 4: Device discovery could not resolve to a thingType! Manufacturer data not known.
… now with 2.4.0 - Manufactrer data not known ?! … hm…
This means that the binding hasn’t downloaded the manufacturer data from the device. You need to wake it up so it can initialise, or wait for it to wake up by itself (may take a few hours or a day or so - depending on how your system is configured).
okay - I´ll try. The FGDW-002 are battery powered, so this can be a reason.
Now with the 2.4.0 dev. binding - my zwave USB Stick are new named : “ZWave Plus USB Dongle”.
Is that correct ?