Fork of https://gitlab.com/helioslabs/gozw and https://gitlab.com/helioslabs/zwgen.
Working with the authors of https://github.com/stampzilla/gozwave and https://gitlab.com/helioslabs/gozw to create a unified Z-Wave library for Go. Currently a work in progress.
Join the #gozwave channel on the Gophers slack.
Golang Z/IP Portal
/dev
named
usbserial*
or usbmodem*
(or similar), you need to install the FTDI VCP
driver for your platforminterceptty
,
which is an extremely useful serial port / tty proxy (it will allow you to see
the raw data being transmitted to/from the controller).
./configure && make && sudo cp interceptty /usr/local/bin
interceptty -s 'ispeed 115200 ospeed 115200' /dev/<serialdevice> /tmp/<serialdevice>
/tmp/<serialdevice>
go get -u github.com/gozwave/zwgen
make install-deps
in the zwgen folder rootmake install
in the zwgen folder rootmake build
in the zwgen foldergo get ./...
in the gozw folder rootgo generate ./...
in the gozw folder rootgo run cmd/portald/main.go
go run cmd/gatewayd/main.go
Application Layer < ---- > Security layer
|
V
Serial API Layer
|
V
Session Layer
|
V
Frame Layer < ---- > Frame parser
|
V
Transport Layer
Handles reads/writes with the serial port. In the case of future implementations that do not use a USB-UART driver, it should be possible to substitute an implementation for some other I/O device (UART/SPI/etc).
It satisfies several interfaces from the io
package. In the future, it should be possible to dump a long-running Z-Wave interaction (output from interceptty, for example) to a file, then use that file as input to reproduce crashes.
Parses incoming frames using the frame parser and determines how to proceed based on the parser result. Handles parse/receive timeouts, as well as transmission of ACKs/NAKs.
Facilitates the request/response flow by queueing requests when awaiting responses and callbacks. Implements the Host Request/Response Session state machine as described in INS12350 section 6.6.3.
The following image is a visualization of the session state machine:
Exposes an API to make Z-Wave function calls (such as AddNodeToNetwork
and SendData
).
Whenever possible, methods exposed by this layer should block until their corresponding Z-Wave operation has completed (e.g. AddNodeToNetwork, which has a complex workflow consisting of multiple callback functions, should block until the entire process has concluded, and return the newly added node or an error).
The application layer abstracts the Z-Wave protocol so that user implementations do not need an in-depth understanding of Serial API functions or command classes. It manages the network at a high level by keeping track of nodes, acting as a proxy to the session layer, and receiving data frames (typically command classes whether GETs or REPORTs) from the session layer.
For background, see SDS10865 (yep, the whole document; it's not that long).
Provides utilities for encrypting/decrypting messages, storing and timing out nonces, and security sequence counters.