I'm working on a new driver for the Aeotec Gen5 Home Energy Monitor. This device supports S0 security.
I've been successful in writing the basis of a driver. I have a series of commands that run against the device, and am receiving some responses back on my parse method.
The weird behaviors I'm seeing is as follows:
Driver sends a S0 secure command (Meter Get) to the unit (zwaveSecureEncap() converts 320128 => 988100320128)
Device sends back a non-secure report (Meter Report)
Expected: Get a secure message back that I would have to de-encapsulate and pass on
Driver sends a COMMAND_CLASS_SECURITY V1 securitySchemeGet() command to the unit
Device does not respond (at least nothing is hitting the parse() method)
Expected: any sort of response
Device has config parameter set for CRC16 encapsulation enabled.
Device sends packets without CRC16 encapsulation
Expected: CRC16 encapsulated packets that would have to be de-encapsulated and passed on
Device is supposed to report usage information in a Multi Channel report to devices in Association Group 1
Hub (Node ID 1) is in Association Group 1
Hub does not receive messages from device (no messages hit the parse() method.
Expected: Device receives messages on a regular basis.
I am hoping someone can shed some light on this issue. It seems almost that some messages are getting filtered before hitting the parse() method. I am logging as soon as the method is called, and I can confirm that nothing is hitting it, other than the aforementioned Meter Report message that comes through unsecure.
Some more notes:
The deice shows S0 in the ZWave settings panel, and has the appropriate command classes listed on zwave.securityV1.securityCommandsSupportedGet()
It's also directly connected to the hub, no intermediary devices.
Ok.. for starters.. C7 de-encapsulates security and CRC16 before sending to parse, this is handled at the SDK layer in C7..
.. yea this is not going to work. why would you need this?
Going to need more detail on this.. But the device needs to send to multi-channel endpoint 0 when addressing the hub or the packet will get dropped at the SDK layer..
That's fantastic. Thanks for the information. I thought I was going crazy.
I was trying to figure out what level of security the device reported, but I've found another way to get what I want.
Per the engineering sheet:
For HEM 2 phase version, the MultiChannel Command supports 2 end points, which corresponding to 2 clamps. Clamp 1= Endpoint 1. Clamp 2= Endpoint 2. The Multi Channel CC encapsulates Meter Command Class, which can get the measurement of watt (W or kVar), KWH or kVarh, voltage and current from the clamps.
It sounds like this is an incompatibility then? Any way around this?
Thanks so much for the help, this has been very enlightening.
I would strongly recommend you stay away from S0 for a device that's capable of producing a significant amount of data, where S0 is going to do nothing but bog you down...
If you really want to mess with it, get your driver working perfectly first, then worry about the S0 bits...
If you're serious about writing zwave drivers, set your self up with silabs zniffer software, you can't really go too far with driver development without being able to sniff wireless frames.
So I managed to use the Z-Wave PC Controller SW and an Aeotec stick to get the device reporting multichannel. Next step is to get it all working in the driver without using manual ZWave commands.
The trick was getting the multichannel stuff set right, and then importantly, turning off CRC16 encapsulation. Is there a chance there's a bug with the automatic de-encapsulation on the C-7? Maybe when there's both S0 and CRC16?
This is my first HE driver and first time messing with Groovy/Java, so there's a bit of a learning curve over what I'm used to.
