Something within openHAB seems to be out of sync.
The message “Error during thing creation: Not Found” doesn’t seem to be specific to the Z-Wave Binding.
You could try to enable Z-Wave debugging, see ZWave - Bindings | openHAB - but:
@chris
Am I right in assuming that a Z-Wave debug log wouldn’t help much since the creation of Things happens within the openHAB core?
Can’t explain all that has happened, but you could try to exclude via the Controller UI ‘Exclude Devices’ and the manual instructions for exclusion, then try to include again via the inbox zwave scan. If it happens again IDK, but maybe… Should be discovered as a new node number.
Edit: the debug during the reinclusion process is a good idea.
I’m novice to intermediate on this platform, but I’m on board with the thinking that this error probably isn’t rooted in the z-wave layer. That said, I’m inclined to think there’s something about this device (or the way it’s being defined) that’s choking OH.
I excluded it. New scan discovers it as a new node (was 58, now 59). I add it, get past the Not Found error with a response that the device was approved. BANG! Things are hosed again.
So, I pull up /var/lib/openhab/jsondb/org.openhab.core.thing.Thing.json and node59 is there with a thingTypeUID that matches what I’d expect for this device model. I haven’t connected every dot, but my take is that when this definition gets into the Things DB, it corrupts. That’s not a z-wave issue, but if this is a meaningful observation, it suggests something fairly specific to this device’s default Thing definition.
Thoughts? Next steps?
Restore from backup and test whether Z-Wave devices different from your GE55249 can be included.
Some observations:
First, I am sorry. I also have no experience with an inclusion crashing the whole system. Do you have other devices of this type that worked okay?
I think @anon71759204 may have it regarding the scene number (or at least a lead) see this thread (do you get any message like that?)
Compare to
Super helpful. Thanks for the extra set of eyes!
First, yes, other z-wave devices are still including. When I did the restore earlier today (following the Things list getting hosed), it turned out my latest backup was prior to adding a different z-wave smart plug. So, when I restored, that plug was discovered and I added it back to OH with no issue. So, I feel pretty confident the system is in a fairly good state until this device is introduced.
Regarding the parameters and endpoints, all makes sense. Making assumptions and jumping ahead…I’d love input on the mechanism of correction.
Should I code up a Thing file manually, excluding/correcting the problematic elements? I may be oversimplifying, but that would seem to work around the apparent corruption occurring with the defaults.
Only other path I can figure is to “uncorrupt” the json by hand editing. I’d probably have to figure out how to edit as openhab user for that to work properly.
Assuming the duplicate scene_number channels are the problem, @chris needs to delete one of them from the device information in the database (JASCO - ZW4106). Authority to delete is limited. Then once a new binding is created your device should work.
AFAIK there is no way to fix in OH, but I have never tried. I believe that any changes will get overwritten from the device XML contained in the zwave jar (src/main/resources/OH-INF/thing/ge/zw4106_0_0.xml). That is the file that needs to change with a new DB update.
Not sure if this is still an issue, but Chris deleted the duplicate scene_number channel yesterday from the JASCO ZW4106. I’d make a backup and exclude the previous attempts to give the new binding the best shot. The backup is in case this wasn’t the problem after all. As an alternative to just updating the binding, the OH3.4RC1 also has the updated zwave binding as will the 3.4 Release on Monday?
Thanks very much, Bob. I feel like we’re close, but I’m missing something (probably) trivial.
I went into the discovery screen and removed the pending results. I rescanned, and when my result came back, I attempted to add. This time, it’s no longer hosing the system (that’s a great improvement, of course). It’s also failing to add, though. Here’s what the log shows:
Thoughts on next steps to push this over the edge? Thanks again!
Since node 59 was from before, it was not excluded (using the controller UI to exclude). It is still showing the duplicate channel so has a stale version.
Ah, got it! The term “exclude” didn’t immediately click properly with me. Sorry.
So, I got it excluded at the controller. It’s now discovered as node60. Still getting the same error, though. Log says unable to be approved: Duplicate channels zwave:device:[controllerID]:node60:scene_number
Must still be missing some nuance. Forgive any ignorance on my part. Really appreciate the help. We’re close!
Did you update the binding? Edit or OH?
I confirmed it’s v 3.4.0 of the zwave binding. My OH is 3.3…after backup, I attempted to deploy the latest via openhabian-config, but that encountered an error during unpack of openhab_3.4.0-1_all.deb (haven’t got to troubleshoot that yet).
Interesting side observation…my Things list did eventually go bad (like it was more promptly before), seemingly without doing anything further to aggravate. So, I’ve restored my backup. Current state appears to be stable, and I’ve uninstalled & reinstalled the zwave binding from the openHAB distribution.
Would I need to download from a different repo to get this latest binding version or is 3.4 the latest? I saw in Jenkins he had some references to 4.0 on some artifacts. I suspect without a manual download, I’m still using the outdated binding…until I figure out how to get OH 3.4 successfully deployed.
Hmmm… The OH3.4 zwave snapshots should work with OH3.3. I saw the 4.0 references too, but unsure if those can be used. I think they were set up for the next development cycle What does the openhab-cli console show for bundle:list |grep ZWave?
262 | Active | 80 | 3.4.0 | openHab Add-ons :: Bundles :: ZWave Binding
This seems consistent with what I get in the app UI.
So, if 3.4 is the latest binding version and doesn’t depend on OH 3.4, I should be able to carry on regardless of the deployment issue I’m encountering with OH.
I would say yes, but can’t explain why the duplicate channels are still showing up OpenSmartHouse Z-Wave Device Database and they clearly have been removed.
Edit: I’m wondering if looking inside the jar file might provide a clue of some sort. How did you update the binding? Do you have a jar file in the addons folder or did you do a bundle:update 262 <location>?
Again, forgive the OH noob ignorance, but if I did either of those, it was abstracted from my view. For better or worse, I updated the binding by the app UI, which (for bindings) is essentially a remove/reinstall sequence with an experience much like installing a mobile app from an App Store. The net of that displayed a v3.4 of the binding.
In any case, I did later manage to get the OH 3.4 update deployed. The waters are still muddy on what precisely was critical to overall success on this issue, but the Thing is now being accepted without error, and it’s working as expected. I wish I could pinpoint the success factor on my end for posterity, but I think we can safely confirm that old binding was the apparent problem it’s respect to his device.
Thanks so much for your persistence. You’re an asset to the community. I hope to contribute more going forward as I learn the platform more deeply.
I know of no way to update the binding through the ui in the manner you did. I also do not know how that became labeled 3.4, but there is a lot I don’t know 
. Anyway the upgrade to all 3.4 is an acceptable and known way to get the latest 3.4 binding, so I think that is what fixed the issue, finally…
