That means wait for the weekly database export and then a snapshot binding built with the new data. Manually install the binding using the installer script from this forum.
Sorry, missed this post and fixed it from the db history I think.
Ok, looking for that link/script now…
Thanks for the reply!
Thanks for fixing it… I’ll let you know when I get the updates on my end if it works or not! (I have no doubts though)
I have the link now. I was on my iPad earlier.
Thanks! I’m assuming it’s pulling the JAR from here?
And if so, what day would you suspect would have the database with the changes I need? (So I’ll know which day’s build to look out for).
I normally look for an update here first.
I see the last update was 2 days ago so possibly the current snapshot binding has the changes.
You can pull it from Jenkins but the devs prefer you use jfrog. I say whatever works
Well, I had already tried the binding from Jenkins (Build #34), and it still doesn’t work. Same error. So I guess I’ll wait for the next update and try again.
2020-05-14 11:11:37.191 [ERROR] [ore.internal.discovery.InboxResource] - Thing zwave:device:16ee7ee91d2:node30 unable to be approved: Duplicate channels zwave:device:16ee7ee91d2:node30:scene_number
Did you delete the binding from the Paper UI first?
Yes, it’s showing as uninstalled in Paper UI…
I even used the “Zwave Installer bash script” just to make sure…
@chris Has this fixed device been exported to a snapshot?
It was updated a few days back, but it looks like the only change was to the description.
@LennySh Have you deleted the Thing from openHAB and rediscovered & added it to get the new settings from the binding? Do NOT exclude from the network.
The change that was made in the last update at least was only the description, so I don’t think that will really make any difference.
No significant changes seem to have been made from what I can tell.
It looks like we have two devices with the same type and id
4952:3137 in the database:
which has the duplicate scene_number channel and
which does not have a duplicate channel.
I thought the database logic checked for that and rejected them both until someone resolved the issue.
It usually does, no idea what happened here …
It does, and it did - there is no duplication in the database.
The issue is there is only 1 database entry, but since the thing type uid was changed, it is now duplicated in the binding it seems - ie the same database entry has now ended up with two files since the names have changed.