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
Hi Chris,
I looked at the Greenwave “NP210”, you entered. This is the 5 port NP210-G model. I tried to update the “NS210” entry end that didn’t go right. The NS210-U (F, G, B, I) is 1 port model, that seem to me are identical ones.
The NP210-KF is EU model with 6 ports instead of 5 ports UK version.
So should the ‘label/name’ in de database reflect the coutry specific models?
@chris in regards the various Greenwave versions I am wondering what is the logical key for the database? I assume it is manufacturer/type/id and one entry can have muliple of those, right?
No - not normally. As @luotaus suggests, the identification of devices within the database (well, within the binding really) is the manufacturer, type, id, and version. A device in the database can (obviously) only have one manufacturer, but it can have multiple sets of type/id pairs, and then we use a version range (ie min/max version). Most devices don’t use version, but Fibaro do - they have the same device, same references, but different firmware version, and different versions might have different configuration parameters…
So, back to the question… Generally, most manufacturers have the same type/id for the different country versions, so the binding can’t tell them apart, and there would be no point in having multiple versions in the database. Some manufacturers do have different type/ids for region, but since the configuration is the same, we just lump them into the same device, otherwise we’d have an even bigger database maintenance issue 
After some digging I think we need 3 entries in the database. I also suggest to rename the entries as there seems to be no mapping between the IDs Nxxxx and the OH relevant specification like # of plugs.
-
Name: GWPN6
Descr.: Multi-socket PowerNode (6-plug)
Type/ID: 0x3/0x4 -
Name: GWPN5UK
Descr.: Multi-socket PowerNode (UK, 5-plug)
Type/ID: 0x3/0x3 -
Name: GWPN1
Descr.: Single-socket PowerNode
Type/ID: 0x2/0x2
Ebel, Chris, does this looks good to you?
There is also a thread around the NP310. Once we are clear on the entries, perhabs we should continue the discussion there. Could be that as a next step we have to add different (firmware) versions.
1 Like
Looks fine to me.
There’s also this issue on github…
Hi Joerg,
Sure, this look good to me. I’ve had a quick look in the PDF that Vincent mentioned in the other tread en that’s a lot of nice information. Thanks
Ebel
@chris, not sure if this is a bug.
In the screenshot below endpoints 0-5 were uploaded via XML and endpoint 6 added manually. Now I cannot add the command classes for endpoint 6 as the “+” icon is missing.
Yes - this looks to be a bug. I’ll add the button tomorrow when I get home.
Thanks.
Chris