This seems to have disappeared. You should be able to find he engineering manual on the Aeotec support website though and the Aeotec manuals normally provide all the information needed to add the associations and parameters. If we can get this manual uploaded to the database then we can take a look at it…
Odd.
Anyhow, I had saved a copy.
I have added it to the record.
Yes, there is a lot of info on the parameters and such but I have no idea how to decipher it. Looking forward to seeing what you add so I can learn how to better add devices into the database.
Cheers!
=C=
Or explain how to read the guide so I can do it.
=C=
It’s simples
As an example, you need to take the data from the manual -:
And add it to the database -:
Add a new parameter -:
Click OK
The add the options where there are some (as in this parameter there are 3 -:
And repeat with the other options…
I’d suggest to have a go - if you’re really uncertain, just do one parameter, and then myself, @sihui or @mhilbush can give you pointers
Ok. I have added them all in and added the missing options form the one you added.
- Several were ranges and did not have options defined so I did not add options.
- Several had 'Units" (MS, K, etc) and I added them in but they do not display on the summary page, only in parameters editor.
- I assume all 0x values are hex and translated accordingly. The only reason I mention is is because on page 9 of the tech guide it refers to ‘Parameter 10’, not ‘Parameter x10’. So I may have been wrong on converting them.
Beyond that, hey, it compiles, it’s gotta be right…right?
Cheers!
=C=
Looks good to me.
Ok.
I think this is ok. I’ve never entered units before…
Correct. You did the right thing.
A couple additional comments.
Wouldn’t hurt to add the EU type:id. It’ll save someone from having to edit the DB down the road. So in the DB it would be
0003:0002,0103:0002
I’m surprised to see all these marked as No. Double check the node.xml file to see what these should be. I’d expect to see at least Always Listening and Routing, and maybe Beaming.
Done
I didn’t know for sure so I left them as is. I’ve marked the two obvious ones you mentioned as yes. I left Beaming as no because (other than inferring from the name) I’m not entirely sure what it is. I looked over the XML file and did not see anything that said Beaming. What am I looking for?
Also, this device supports Z-WAVE PLUS Version 2, is that the same as ‘Supports Security’ ?
Cheers!
=C=
In the node.xml, it would look like this.
<listening>true</listening>
<frequentlyListening>false</frequentlyListening>
<routing>true</routing>
<security>false</security>
<beaming>true</beaming>
Different. Z-Wave+ is a next generation tech that improves range, battery life, etc. Security is, well, security.
Ok, double checked the XML and all of them and they are all false.
I’ve updated the Device.
Cheers!
=C=
@chris If they’re like that in the node.xml, then the device must’ve reported them that way? Have you ever seen a case where a device reports all these as false?
It’s this device.
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/949
From the tech guide:
" The RGBW Bulb is a security (s0) Z-Wave Plus device, so a security enabled Z-Wave controller is needed for take full advantage of all functionally for the LED Bulb."
Does that mean Supports Security is YES?
Cheers!
=C=
I would think so. Another reason to question why all those values are false. OTOH, my lock supports security, and it reports Security=false.
If you have a debug log, it will show what the device actually reported. It would look something like this.
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: ProtocolInfo
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Listening = true
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Routing = true
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Beaming = true
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Version = 4
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: FLIRS = false
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Security = false
2018-11-21 07:24:36.842 [DEBUG] [al.protocol.serialmessage.IdentifyNodeMessageClass] - NODE 81: Max Baud = 40000
Happy to turn debug on and grab those. Do I need to remove the device from my controller first and then re-add?
Cheers!
=C=
If the node is fully initialized (which should be the case if there’s a node.xml), you can tell the binding to reinitialize the node.
In HABmin, on the node thing that you want to reinit, select Tools → Advanced Settings, then select Tools → Reinitialize the device.
Ok, new to openhab so I’m not quite sure what this means.
I do NOT have /var/log/openhab2/debug.log
If that is what I need, how do I enable it?
I went into openhab-cli console and did
log:set DEBUG smarthome.event
That turned on a ton of logging, but nothing like what you described.
I did reinit the device and the only thing useful I can see was this line:
2018-11-28 08:20:38.950 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 28: Device discovery could not resolve to a thingType! 0371:0103:0002::2.0
Which, as you can see, isn’t very useful.
Cheers!
=C=
Oops. Sorry for assuming…
WOW. Ok, that generated 950+ lines of debug code labeled NODE 28.
I THINK these are the lines we are looking for:
[rialmessage.IdentifyNodeMessageClass] - NODE 28: ProtocolInfo
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Listening = true
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Routing = true
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Beaming = true
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Version = 4
[rialmessage.IdentifyNodeMessageClass] - NODE 28: FLIRS = false
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Security = false
[rialmessage.IdentifyNodeMessageClass] - NODE 28: Max Baud = 40000
Given this, I’ll update the flags LISTENING, ROUTING, and BEAMING on the item. Should I update data rate to reflect MAX BAUD?
As to why the XML file was wrong, that’s beyond my pay grade.
Cheers!
=C=
Ignore the DATA RATE question, I updated MAX BAUD.
=C=
Looks good!
Yeah, it’s a little verbose. But there’s a tool to make it a lot easier to analyze.
Not sure about that either…
Question:
Now that this is done, do I have to wait for the database to be exported or can I export this one item and put it somewhere that openhab will see and use?
Cheers!
=C=