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
Hi Joerg,
That’s correct and there is also a Danish version. The Greenwave site doesn’t give much help. I found these links:
http://wiki.mios.com/index.php/Z-Wave_Certified_Devices
http://www.pepper1.net/zwavedb/device?sort=product_name&sort_type=desc
And at some shops in the Netherlands de 1 plug version is also called “NS201-F (schuko)”.
Furthermore I’ve a PDF file with instructions for the Greenwave plugs.
Feel free to upload these manuals to the database. One thing that initially prompted me to make the database was having a consistent place to store all the manuals, so it would be good if we can attach them to the database entry… To do this, there’s a reference documents section toward the bottom of the page - just click the green + button.
I found a bug with the processing of the files - I reprocessed your file and it looks ok now.
Chris
Hi Ebel,
just for my understanding: is the XML file for you device also stating Device ID: 0x3
Device Type: 0x3?
Is the bug already fixed in the productive environment? Just checked and found the behaviour as before.
Yes - it should be fixed. I already processed your XML file (it gets stored into the database when you loaded it this morning) so the data is already added. The error you now see is simply saying that the type/id references (0003:0003) for this XML are already in the database - this shouldn’t be a big red error though so I’ll downgrade it to a warning…
It was my understanding that with the fix the entries for endpoints are getting created automatically in the database. In the XML there are 5 endpoints defined. But in the database I can only see the two entries I added manually. Or have I missunderstood something?
Hmm - ok, at the moment, if there are already endpoints in the database, then the XML importer doesn’t add new ones - this is to prevent conflicts. This implementation was the easiest (and seemed acceptable at the time) to implement rather than trying to deconflict each endpoint individually…
I’ll take a look to see if I can easily change this…
I decided to delete the two endpoints you’d added, and re-upload your XML file. You might want to take a look at the entry as it now stands - you’ll see it’s done differently to how you’d added the endpoints…
In this context, an endpoint is the same as an endpoint within the device - this isn’t directly a command class. An endpoint has multiple command classes, and each command class may have multiple ‘channels’ (to use an OH2 term). Most don’t, but where multiple alarms, or sensors are supported within a class, this is how it’s done…
So, to try and explain further (especially in case others reading this are interested, I’ve turned this into a bit of a tutorial), I’ll show the configuration for the endpoints of this device in the database (after the XML ingestion) -:
This is endpoint 0, which normally contains a lot of ‘service’ classes - eg all the associations, configuration, wakeup, version etc - basically stuff that users dont care about. Of course endpoint 0 also has some user classes, but you’ll see that the other endpoints don’t, so there are more classes in endpoint 0…
Now to look at endpoint 1 (which in the case of the NP210 is the same for the other endpoints!). Here we only see the more user oriented command classes - in this case the switch and the meter. You can also see what I mentioned about channels - the meter class supports two channels -the current power (watts) and the power consumed to date (kWh). These can be associated with items (in OH1) and channels (in OH2).
I hope that makes sense? If you enter an endpoint manually, this is how it needs to be built up - this is why loading from the XML is highly desirable 
From here, you can go through and rename the channels - eg the “Electric meter (watts) 1” might be better labelled “Plug 1 power” or something, so you can click on the edit button and change the label (remember though that this is a generic database, so don’t call it “Master bedroom” or something specific to your house - you can set this later in OH2 when items are defined, and this just becomes the default). There are also some other fields you can set - these are kind of like the options that we might have in OH1 items). There’s also the ‘Overview’ input where we can provide a description using a nice editor - this is later used to create the device instruction information (it’s not currently included at the moment though)…
I hope that helps provide some ‘instructions’ on the database use… (and yes, I know, I should put this into the instructions on the web site 
)
Makes totally sense, great work!
@chris,
Do you also want PR’s for your OH2 binding for the created files, or (what I expect) you’ll do a mass export of the database to the OH2 binding.
Yes, I’ll do a mass export at some stage - I’m just trying to align the OH1 and OH2 database names - hopefully it will work out ok! 
I’d like to get to the position where we can export reasonably directly from the database so that when people update things, even just to improve the explanations etc, it’s all reasonably seemless.
What I’m doing is to export each device one by one so that I can double check against the OH1 database to make sure we’re not missing some critical config - I’m assuming that the parameters and associations are sorted by those adding the data/XML…
This is relatively simple and I think this will ensure (as much as possible) that we don’t screw up the OH1 database. We then can be reasonably sure they two databases are in synch when we update these devices and it also ensures a systematic record of the changes, which is nice!
Currently I’m pushing the updated database to github here. At some stage it would be good to link this directly to the binding, but that’s for another day!
I will also need to double check that all the channel IDs are consistent within the OH2 binding which I’ll do over the coming days.
As of this morning we have 32 of 262 devices updated - thanks to all those adding their data. I’m sure there will be some manual ‘tweeking’ required, but hopefully it won’t be toooo painful
I’ve now created a summary page that summarises the state of the database - it’s something I’ll add to, but it’s useful to summarise things. It’s not linked into the menu system (yet) so until this is done the link below should work -:
Z-Wave Device Database Summary Page
Note that it is slightly slow to load (a few seconds) since it loads the whole database and performs the consistency checks on each device. This leads to the list of warnings and errors at the bottom of the page. The checks are work in progress - I add one each time I find an error so it’s possible to find other such errors . These errors/warnings are also listed on the top of the device page during editing…
I’m using Domoticz at the moment but will soon migrate to OpenHAB so I don’t have an XML file. The XML files I found where those in link I mentioned earlier: Z-wave SML files