I recently (last week or two) updated to the 2.0.0 released version of openhab, along with the associated zwave binding I installed using PaperUI. One of my devices is coming up as ‘unknown’. I went to the database webpage to enter it, but it’s already there (and has been for months). But, it does not seem to be in my local database. How do I get my local database in sync with the web database? Is there a regular process where the zwave binding downloads new database entries? Do I have to poke it somehow to do so? Really feels like it should be automatic.
A search gave these clues
I tried uninstalling and reinstalling the binding in PaperUI. It didn’t work. Database still not updated.
An important part there was -
if you are using the snapshot version, it will update to the latest version.
If you only want to upfate zwave
Database updates and using snapshot builds shouldn’t be tightly coupled. There needs to be a way to update the device database without using alpha code.
1 Like
You don’t need snapshot builds (runtime and binding) for that update, you just need to update the stable binding to a snapshot binding.
Unfortunately there’s no current alternative due to the way the framework works (ie ESH). It reads the XML files from the JAR and the startup relies on this.
I’m also not a real fan of allowing ‘ad-hoc’ changes to the database - eg allowing people to use whatever files they decide without control over what’s used. We’ve seen in the past bugs being reported that are attributed to the database - in my opinion the database is part of the code, and should be validated and tested as part of the code. This is standard practice with data driven applications.
So you’re happy to use an “alpha database” but not “alpha code” - interesting 
Given the database drives the code, bugs in either can have similar consequences.
1 Like
I would hope that the binding code wouldn’t crash if there were semantic errors in the database. Does it not validate its inputs? Also, as I understand it, there’s an approval process already in place for database updates. People can’t just submit them and then they go ‘live’. And syntactic errors in the database should be nonexistent, since entries should be validated before being added to the database.
At the very least, there should be a way of indicating to the openhab zwave binding user that there’s a newer database entry for one of their ‘things’, and offer to allow the user to download the update for that one ‘thing’. There could be caveats in the message that it has not been validated, but might fix behavior. And, there could be a rollback option if the user finds it doesn’t work.
Right now, I have things that don’t work at all because there are missing database entries, which already exist in the database registry online.
1 Like
No - it probably won’t - but if you have wrong information in the database, then it WILL stop your device working, so the result is the same.
Sure - as much as possible and where appropriate. But if you change something from a alarm_motion to alarm_general, it will stop working and the binding simply can’t validate this.
Yes - but just as with code changes - if you change the database, or the code, there might be errors, and as I said above, this can prevent thing working.
Correct - this is not the issue.
I work on data driven systems all the time - code and databases go hand in hand and I’m afraid that the misconfiguration of a database in such a system will prevent it working the same as a code bug.
Then you can use the snapshot version (assuming builds are working of course ;)) - simple.
Don’t get me wrong - I can understand your concern, but to say that errors in the database are any different than errors in the code is not true - both have the ability to stop the system working even if a database error probably can’t actually cause a crash.
I would also like to see some level of ‘online database’ and I started to code this. If implemented, it would only be for configuration parameters, however at the moment, ESH simply doesn’t allow this - you just need to update to the latest snapshot - sorry.
Hmm… seems like a shortcoming of the ESH platform. Can you provide any pointers into the code/docs as to why this is not possible? I’ll poke around, but it seems like the zwave binding could just make its own outbound network request to a database server on the net to download updates.
Maybe - it’s a constraint that we live with - all systems have them… There are ways around it clearly.
It can make an outbound request - that’s fine, and I’ve already coded this in the past. However, reading the database isn’t the problem - the XML files (ie the database) are read into the system when the binding starts. It’s then not possible to override this information anywhere else - we can add to it (the zwave binding does this) but you can’t remove the stuff that’s read in from the XML.
So, we could elect to remove all configuration from XML and just have the online database. You might be happy, but others would complain. The configuration system is a fundamental part of ESH - not the binding, and the REST interfaces interface to it - not the binding.
As I’ve already said, it’s important to have a consistent dataset - code and database. I don’t really see this as a major issue as there is a simple workaround which is to use the file with the updated database 
.
For the zwave binding, this seems like a good idea.
How does one do this for just the zwave binding? There seems to be no way in the PaperUI to specify that I want to get snapshot builds of zwave, but stable versions of everything else.
No - I will not implement this - sorry. It means OH becomes a cloud only system (at least for ZWave) and I don’t believe that’s wise.
There are many discussions about this on the forum. I agree at the moment it’s a bit of a pain as it needs to be done manually (a bit like it was in OH1 with dropping JARs into the addons folder) but this will also be fixed soon with the introduction of the Marketplace.
Tried updating to the 2.1.0 snapshot version of zwave to get the database update I need, including installing openhab-transport-serial, but it didn’t work at all. All the things were stuck in the ‘configuring’ state and never advanced. Went back to the released version and things are working again.
This is why I think the zwave database should be separated from alpha code.
1 Like
I understand your point, but I’ve already said that in my view, the best approach is for the binding as a whole to be validated - this means the database, and the code. This is standard for data driven applications.
As already said, a bug in the database can also cause the same sort of problem - devices can be stuck in the configuring state where they don’t advance.
I’ll leave it at that on this topic.
Regarding your problem with upgrading - I don’t know what this is, but I wouldn’t call the 2.1 binding ‘alpha code’ - there have been very few changes to the master branch since the 2.0 release other than for database updates - the majority of changes are in a separate branch. It’s also highly likely there will be no further changes to the binding before 2.1 is released.
Hmm… well, I installed the snapshot, and no zwave things could be initialized. It doesn’t seem quite ready for release yet, unless it also needs the whole 2.1 runtime updated as well?
Possibly a problem with this snapshot
It might - I don’t know. Really though, reports like “it doesn’t work” aren’t useful in solving any issues.
No - this thread is talking about the main 2.1 snapshot - the thread you reference is talking about the development binding.
As I described above