New: the AI firewall watches the whole platform and explains each incident in plain words. See how it works

Z-Wave S2 on my Pi gateway: which nodes really need it?

Z-Wave S2 on my Pi gateway: which nodes really need it?

Solved 5 4

Hi, I’m a backend dev doing my first hardware project, so apologies for any wrong terms.

I’m building a small gateway for an office: Raspberry Pi 4 with a Z-Wave USB stick (Aeotec Z-Stick 7), Z-Wave JS running locally, and a Python service that publishes the readings to Hermetry on the v1/gw/* topics. The office has 12 smart plugs that measure power, 4 door sensors and 2 door locks on the server room.

When I include a device, Z-Wave JS asks me which security class to use and wants a PIN for S2. Some of the plugs say “S2” on the box, the door sensors are older and don’t. I can’t find a clear rule for when S2 is mandatory and when I can skip it. Inclusion with S2 also seems slower and I’m worried about traffic with 12 plugs reporting power every few seconds.

The Hermetry side works already: each node shows up as a child device under the gateway.

♥ 1

Not sure about Z-Wave, but on the Hermetry side keep the child names stable. If you use node IDs and re-include something, it gets a new ID and you’ll end up with a new child device.

♥ 0

Good point, I was using node-7 style names. Will switch to room names.

♥ 0

I ran Z-Wave in a council building pilot, so here’s how I’d split it.

“Mandatory” is about certification: since April 2017 every new device that gets Z-Wave certified has to support S2, and controllers too. Your stick does. That doesn’t force you to include every node with S2.

The classes are S2 Access Control (locks, garage doors, anything that opens a door), S2 Authenticated (needs the PIN, which is the first 5 digits of the DSK on the device label or QR code) and S2 Unauthenticated (encrypted, but no proof it’s the device you think).

  • Door locks: S2 Access Control, no discussion. Most locks won’t even accept lock/unlock commands without secure inclusion.
  • Door sensors: if they only support S0 or nothing, that’s what they get. S0 is chatty (three frames per command), so I’d rather run old sensors non-secure than S0, unless they’re security-relevant.
  • Plugs: S2 Authenticated. S2 adds a few bytes per frame, nothing like S0’s overhead. The traffic problem is the reporting interval, set the plugs to report on a 5 % change or every 60 s instead of every few seconds.

Keep the PIN sheet with the labels, you need it again if you ever re-include.

Accepted solution♥ 9

And for the 12 plugs, batch them on the gateway side too. One v1/gw/telemetry message can carry all of them, keyed by child name.

Timestamps in UTC or it didn't happen.
♥ 1

Re-included the locks with S2 Access Control and the plugs with S2 Authenticated, changed plug reporting to 60 s or 5 %. The door sensors are S0-only, so I left them non-secure. Mesh traffic dropped a lot and the locks finally take commands. Also renamed the children to plug-desk-03 style and batched all plugs into one gw message per minute.

♥ 0
Viewing 6 posts – 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.

Join the conversation

Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.

Share