Yes, above all we are in different parts of the world.
BTW, I visited Dayton, Ohio a couple of years ago. Nice place in Buckeye State.
Quite different in the north… Lake Erie is massive and there is a connected chain of giant Metroparks circling Cleveland, so very green. We’re on the south side of that abuting the Hinckley Reservation. Beautiful area if you can take the humidity and lake affect snow during the winter!
I found the XML on their website. It says openHAB XML, but it links to the Zwave Alliance website (not the right XML). Nice that they tried! The configuration parameters are not documented, but they are buried in a SmartThings (
) device handler that Inovelli provides.
@sihui, could you please double check parameter 6? This is the first time I used bitmasks in a device, but there are a couple of Aeon device I have that could use it.
EDIT: forgot to include this…
group3value += group3local? 1 : 0
group3value += group3way? 2 : 0
group3value += group3remote? 4 : 0
group3value += group3timer? 8 : 0
I think I just saw my mistake… but I see you’re replying, so I won’t touch it. 
I think it needs to be in hex, at least that is the way I used it once and that is what the database guide states:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide
The bitmask is (currently) defined as a hexadecimal value
| Line | Bits: | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | |
| 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | |
| 3 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
So masking Bit 4 (Line 1) should be 10 hex which would then be in the database 00000010
Masking Bit 3 (line 2) should be 8 hex, database: 00000008
One more: masking Bit 5 would be 20 hex, database 00000020
BUT: I’m not 100% sure because I have seen it configured differently in the database.
Maybe @chris can (again) shed some light on this 
1 Like
Ahh, I see. Very nice. I already was satisfied with Dayton, because I was heading from desert Texas and was excited to see green trees again 
1 Like
Thanks for looking again!
I only have one of the three of these I own moved to OP, but, the one seemed to bit acting odd. They are pretty good devices, though I had to replace a DOA triac on one.
I assume you refer to snapshot of zwave bindings?
I’ll do a google, but is there a write up of how one goes about setting up to use the snapshot?
I was meaning the OH snapshot. Here is a writeup for openHABian…
The word size is 1, so I thought I had it wrong so I changed it. But now I think I had it right in the first place 
. Best to wait for @chris… looking to have subparameters for values 1,2,4 and 8 that would sum up for parameter 6.
1 Like
From a quick read of your explanation, I think you have it correct 
I just had a look, and what’s in the database at the moment is incorrect. I guess you’ve listed bit numbers, rather than a bitmask (eg I see bitmask 3, which will result in an & 0x0003 - or 00000011 in binary). If it was implemented like this, it would not be possible to have subparameters that are more than a single bit - eg the bottom 8 bits might represent a level, the next 8 might represent individual bits. In this case, to get the level, we would have FF as the mask.
Thank you! I had years ago made sense of this for setting the Aeon HEM report groups, but too much time has passed and the light bulb hasn’t quite gone off in my head. But I think it’s warming up now! Since the word size is 1 (valid range is 0-15), wouldn’t the mask be 0000000F? But both would work?
So, for an Aeon HEM G1, parameter 101, word size 4… to report kWh for clamp 1 (2048, 0x0800) would use a bitmask of 0000FF00 (or 00000F00), with an option of ON=8?
Yes - if it’s the bottom byte/nibble, then this should be correct.
I think that each of the bits in this parameters are individual enable disable bits (right?).
So, the masks would look like the following (in red) for each bit. For each, the options are Enable=1, Disable=0 (or whatever label you want to give it).
Correct. Same for the ZNW39 parameter 6 options.
Bingo… now it makes sense! Putting the masks on the HEM doc clarified the masks.
This part still is unclear to me. For example, one of the NZW39 parameter 6’s has a mask of 000000FF, min/max 0/8, and options for 0 and 8. If this is correct, then I’m not understanding why the HEM would use an option values f 1 and 0. Or I still have the NZW39 setup wrong. 
If not, then the NZW39 is ready to be published.
EDIT: I think I understand this now. The NZW39 masks should be 1, 2, 4, 8, with options 0 and 1?
Thank you for taking the time to explain this!
I’ve just published the NZW39. And after all of that, found another NZW39 by another manufacturer in the db, but it was also empty. These appear to be identical devices with different manufacturer IDs.
You can copy the configuration from the Inovelli 
2 Likes
So, I follow the tutorial mentioned earlier to get this snapshot?
if I do, do I need to re-do/add all my things, items, and add-ons?
Will I also need to exclude my zwave devices beforehand?
That tutorial will upgrade your OH to 2.4 snapshot builds. Your bindings will be upgraded too. There are updates available almost every day. Chris will export the device database (including the NZW39) for the next build of the zwave binding, which happens about weekly. To update a binding, just uninstall/reinstall it.
No. Just delete your zwave Things and rediscover once you’re updated. The devices are stored in the controller, so this just clears the Thing definition and updates it from the new binding. No need to exclude/reinclude.
So, at this point, the new binding has been published and I can get that (by uninstal/install) without upgrading to the snapshot?
You will need the OH snapshot to be able to get the zwave snapshot binding. There are other ways, but this is the easiest. The zwave binding does not yet have the changes to the NZW39, since it has not been updated yet. Just be patient… it’s updated about weekly.
No rush, just making sure I grok the whole picture. 
No problem… that’s what the forum is for!