Trouble with S0 ZWave Device Driver

Hello,

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.

1 Like

Hoping someone on staff might be able to chime in here.

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.

is there a reason you require s0.. i belive it is the same as this paired non secure?
with the built in driver

If S0 is supported by the device, I want my driver to support it.

I think with the info @bcopeland provided, the S0 stuff is sorted. Now the only bit to sort out is the Multi Channel endpoints.

good luck, s0 is very innefficiant , too chatty and generally not recommend.

Thanks. I'll need it. :slight_smile: 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.

you also started with one of the most complex ones. multi channel are probably the most complex drivers

I remember my first.. Once you get it, you will enjoy it..

1 Like

I'm not familiar with the device, but usually you have to to use multi-channel association and set the destination (the hub) with endpoint 0..

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...

1 Like

Thanks, I'll look down this route.

In my day job, if it's not encrypted it doesn't happen, so I'm used to always encrypting everything. I'll start without S0 and then see how things go.

Is there any way to see if a message sent to the hub was sent with security? A flag in the description parameter in the parse method maybe?

By the way, thanks all for responding. Really appreciate it.

Parse handles incoming data.

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.

1 Like

Yeah, I'll definitely be buying one next month.

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?