122
makezine.com
SKILL BUILDER: Z-Wave with RasPi
Next you’ll need a configuration file in JSON
format that looks like this:
{ “Login”: “LOGIN”, “Password”:
“PASSWORD”, “BaseUrl”: “http://
localhost:8083” }
Assuming you’ll run this code on the same Pi
that is running Z-Way, just replace LOGIN and
PASSWORD with the credentials you used when
setting up Z-Way. If you want to run from another
machine on your local network, also replace
localhost with the IP address of your Z-Way Pi.
(The version of this article on my blog describes
how to run from outside your local network, if
that’s a requirement; a link is in the Resources
section.)
Next, verify your build and configuration by
running:
java -cp target/zwave-1.0-SNAPSHOT-jar-
with-dependencies.jar
-Dcong=PATHTOCONFIG
com.shutdownhook.zwave.App
devices
Remember to replace PATHTOCONFIG with a
reference to your own file. If all goes well, you’ll
see a list of all the virtual devices attached to your
Z-Wave network (name, type, and ID). Woo hoo!
The code that communicates with the gateway
lives in ZWay.java, ready to use standalone in
your own projects. It’s pretty simple: provide
a ZWay.Cong and instantiate the object; use
getDevices to enumerate the network; get
status with getLevel; send commands with
turnOn / turnoff / setLevel; remember to call
when you’re finished.
Of course, there are always some fun details
under the covers. The class is a little lazy about
authorization timeouts — tokens expire in a
week, so we re-fetch them after six days, or each
time a new object is created. This interval isn’t
guaranteed, so it’s conceivable the strategy could
fail at some point, but that seems unlikely. And
do remember to call close on the object when
you’re shutting down — Z-Way remembers these
tokens persistently, so if you forget you’ll end up
with orphan tokens.
Stale device data presents another wrinkle.
Sending a Z-Wave command is basically fire-
and-forget; some devices send back updated
status, but many do not. And the ones that do, do
so asynchronously. So if you set a device value
and then immediately query the gateway, almost
certainly the data you get back will be stale. I tried
to balance performance and hassle by addressing
this in two ways:
1. The configuration UpdateOnCommand (default
true) causes every command to be followed
by an explicit update to the affected device. If
you don’t need to reflect command changes
immediately, this tends to keep the gateway
values up-to-date pretty well with minimal
chatter. Setting this to false makes the set
operation a little more performant, but at the
cost of more uncertainty about gateway values.
2. The status methods all take a
refresh(boolean) parameter. If this value is
true, you will (almost) always receive up-to-
date values, but the call will be a little slower
and result in a minimum of three network
requests. In refresh mode we ask for the value
(noting the update timestamp), request an
explicit update, and then re-fetch the value until
the update timestamp changes or we give up.
In most home scenarios, none of this is going to
matter that much; you can refresh at will, and the
default values will probably work A-OK. But it’s
always helpful to know what’s going on below the
waterline, so there you go.
A Handy Web UX
Command-line access is great, but for everyday
use an actual user interface is non-negotiable.
Mine is just a simple web interface that works
well on mobile screens (Figure
H
), pinned to my
phone’s home screen. Since it’s running entirely
on my local network, I’ve ignored login and wire
encryption,
although neither
would be super
complicated to
add.
Server.java
implements this
web interface
using three core
concepts:
F
H
M83_118-23_SB_Z-Wave_F1.indd 122M83_118-23_SB_Z-Wave_F1.indd 122 10/11/22 12:17 PM10/11/22 12:17 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.