Damn - you should have mentioned that you were over this way… It was a great day though 
Yeah I should have - was over for work and had zero time to do anything bar work and make it along to the games. Definitely a bucket list item ticked being there to watch that :).
Hi Chris,
That looks awesome. It will certainly make it easier to update the database.
My thoughts are similar to Ben in that a description of the item would be useful.
Thanks for the help yesterday too! Learning much, so sing out if there is anything that I can help with!
Cheers
Andrew
Awesome work @Chris. I would second the idea that this could someday end up as a part of HABMIN2.
I guess the part that I wonder about is how to hook it all together to get the community working on keeping it up to date. Could you hook it into Github, and provide change comments, which could then go back to a commit for you to check out and accept?
Happy New Year! Sorry to hear about your interesting yet blustery holiday weather.
Great work Chris! Is the idea to eventually have the database exist entirely outside the codebase for OH2? This would be pretty slick with a button in Habmin that says “import latest database” or such. People can then edit away without having to touch binding code to use and test their creations and new devices.
This is definately a concern, and why I raise it here. The point of course is that currently, most of the updates to the database are performed by a small number of people, and most of the requests are from a wider community, so it shouldn’t be too bad (I hope). I would like to think that if a simple GUI tool were available, people would use it rather than write XML…
I would of course still look to export to Github, but I’m not sure it can be hooked directly to Github - it would more be an export function…
No - ESH requires the database to be within the JAR (although it might be possible to write something that allowed it to be outside, but it’s not how it is currently implemented)…
My concern with having the database outside of he JAR is quality control and version control - I’d be concerned that people would edit the database, and potentially screw something up, and the interaction with the Java side could get very messy. Currently the database includes options to make it work correctly with certain devices that have bugs (sorry - lets call them implementation features ) and if you set these wrong, we end up with something not working.
My personal preference is for people to contribute directly in a simple way… I can understand the rational behind wanting an external database, but as a maintainer, the uncontrolled nature makes me worry I’ll have a lot more headaches with support 
It is trade-offs, for certain, and part of the overall struggle @kai and team are going through with the core. How do you get more people involved to keep things current, but control the overall quality, feel, and vision of the product. I liken it to how Linus maintains the core kernel. Still not sure how he keeps up.
Maybe a channel thing where there is an experimental z-wave database, and a more hardened “production” one that has all the controls? It seems the problem will get worse instead of better with the rate of new products coming. The database maintenance site you created is certainly a step that will help either way.
Interesting idea. However, at the moment, people can compile their own JAR, and edit the XML, test and submit. Generally, the people who can do this are also the ones who are comfortable with editing the XML in the first place, so I’m not 100% sure it will really help?
Yep - that’s my view - try and make the whole process easier, and remove the whole XML thing from the users sight… Make it accessible so anyone can edit the database - provide people the ‘power’ to update the settings etc, and hopefully we’ll get a nicer database…
One of the problems with the current database is editing XML is prone to errors - or at least, formatting it up is not simple… It’s like writing HTML in a text editor - you can do it, but it’s gonna take a few attempts to get it right, and more to make it presentable… I want to put all this editing into a nice form, with a nice editor for editing the HTML bits…
Just a quick update on this - especially with respect to OH2 binding… I think the database is now mostly complete. It now allows uploading the node XML files from openHAB - this gets parsed and a list of endpoints and items/channels is generated (see below). This is then used to automatically generate the openHAB2 database XML file, and also the openHAB1 file (just for the configuration and association groups).
There is one last thing I need to add and that is the command class configuration options. These are options that we add to the command class to fix bugs/features of devices (ie to work around non standard implementations). Once this is done I will likely scrub the database completely and reload it from the current database so that I can start to migrate this toward OH2…
Again, if anyone wants to have a play, I’d welcome any feedback…
More information can be found here and the device list is here.
Cheers
Chris
1 Like
[quote=“chris, post:1, topic:5609, full:true”]
(if you want to play with the editor, you’d need to register[/quote]
Tried to register a couple of hours ago, no activation link was sent (also nothing in my spam folder).
Tried to register a second time now, still no activation link.
Could you have a look on your CMS?
Will do - I did get an email to say that you’d registered a few hours back - maybe it’s not sending externally…
It shows both your users are there. I see others have activated so I’m guessing it is sending (at least some times)…
I activated the first one… Will need to work out what’s up though, so thanks for the info…
I found a mail relay issue - I’ve now (hopefully) fixed this and have resent outstanding emails (but not the ones where I’ve manually authorised the accounts)…
Yes, thanks, mail from second registration was received some minutes ago.
I consider that the database is reasonably stable and I’d really like to start getting data into it so that we can get the OH2 database into shape. Thanks to everyone who has had a play - especially @xsnrg.
The system provides the following functions -:
- Simple editing of parameters, associations and other data
- Uploading of files associated with a device so we have a reference of user manuals etc
- Logging of changes, and a ‘review’ process that allows some level of quality control
- Upload of XML files from the nodeX.xml files to populate most of the devices detailed information
- Upload of OH1 database files so that we can add files that are created manually
- Copying of association and configuration parameters from one device to another new device
- Export to both OH1 and OH2 database formats
I’ve updated the information on how to use the system here. This should (I hope) provide plenty of information on how to use the database, but please feel free to ask any questions.
Note that you will need to register in order to edit the database, and also email me to add you to the editors list. I appreciate this is a bit of a pain, but it is needed to make sure rogues don’t screw things up (although the database is backed up hourly!).
At the moment we still need to manually take the output and add it to the binding…
There are a lot of outstanding requests for database additions, so I’d really appreciate it if people can help support openHAB by adding devices as much as possible - it should now be relatively easy to add entries using the data in the pepper database, or manufacturers manuals.
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list
Any questions, problems, or suggestions, please ask 
Cheers
Chris
1 Like
I’m not using OpenHAB now but will switch over to this product soon. I’ve several Z-wave moduls in use. I’d like to contribute to help with the database. So is there a backlog of devices to add/update or whatever?
regards
Ebel
There are a number of outstanding database requests scattered across the openhab issue lists, and the HABmin issue lists. My goal with the database is to empower people to add their own devices, and make it easy to improve the quality of the data (e.g. by adding further help, and nicely formatting it).
I’ve give you edit rights, so any help, or suggestions would be welcome. I’ll be interested to see if people do use it - if not, at least it’s easier for me, and the others who do help maintain the system, but I hope it will be of much wider use as I think it should make life easier for everyone (at least that’s the goal) 
Cheers
Chris
2 Likes
Hi Chris,
Thanks, I already looked at the Greenwave plugs and discovered that only the multi version was inserted in the database. I’ve Greenwave version with 6 plugs and the 1 version. I’ll try to add this one. Furthermore I’ve a Danefoss LC13, some Aeontec Multi 6 sensors, Aeontec bulbs and different Hue lamps.
Thank for the work of setting this up, I’ll give feedback.
cheers Ebel
Hi Ebel
I also have a Greenwave Multi-Plug and tried to add that one to the database. It looks like that there are several versions on the market, for example the UK version has only 5 plugs. So I assume we need multiple entries in the database.
UK (NP210-G-EN)
Device ID: 0x3
Device Type: 0x3
Plugs: 5
Can you please post the details for your device to see if the ID/Type is different.
Thanks
Joerg
Not sure if I did something wrong: I uploaded the XML for an existing entry (Greenwave NP210). This device has currently only basic information and no endpoints defined in the database.
The XML describes 5 endpoints, however after the upload it seems that no updates happened to the database. Is this the intended behaviour?
From what you describe, no, it’s no expected. I’ve seen errors with some XML files that can’t be processed - I’ll take a look at this as the database keeps a copy of what you loaded so I’ll check what happened…
Thanks
Chris