Issue of the topic: Multiple failures adding a new z-wave outlet switch.
I’ve recently had success adding other z-wave outlet switches to my system…largely uneventful…this latest one has stumped me. When I initially scanned, the system discovered quickly, but when I added it, the things list apparently corrupted. No things were listed and several now in the inbox. I pulled up the Things JSON and didn’t see an obvious corruption. I restored from backup. Everything back to normal.
Now, after the restore, I have the device showing in the inbox (full name / description), but when I go to add it, I get the error “Not Found.”
I rescanned, and now it shows with a much more abbreviated name. Go to add it…same error.
All of this is being done with the outlet plugged in within two feet of the controller (all at my equipment rack).
What’s going on here? I can’t find much info about “Error during thing creation: Not Found”
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.
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:
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!
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?
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.
