Once the thermostat choosen, the next move was to see how to interconnect the Raspberry Pi and the Z-Wave network.
After investigation, it appears that there are 2 possibilities by 3 main manufacturers:
- USB Sticks with SigmaDesigns SDK (the company behind Z-Wave). Compatible with Z-Wave plus.
- USB Sticks with a inclusion button by Aeotec (Z-Stick S2)
- USB Sticks running Z-Way by Z-Wave>me (ZStick)
The other possibility, still by Z-Wave>me is called the Razberry and is an add-on for the Raspberry Pi. Cool... but not really future-proof.
As I mentionned before, Z-Wave is a very closed world, at the opposite end of Open Source. Fortunately, reverse engineering was done and there is a Z-Wave free software library called Openzwave. There is even a Python wrapper!
If the compilation part takes ages, it is totally painless. But all first attempts were failures and I couldn't understand what was going on... Even using the control panel. Associating 2 of the elements (Thermostat, actuator, static controller) was fine but all three together didn't work as I expected. Even following the numerous recipes found on the forums.
Then I found a way which works for me:
- Reset/Exclude everything.
- Include the Actuator on the Thermostat (back to the way the pack was when delivered).
- Set the RaspberryPi/Stick in "ReceiveConfiguration" mode.
- On the SCS317: Setup/Set up Z-Wave/Controller Shift to promote the Raspberry as the Primary Controller.
After this, the all 3 elements are connected:
- Node #1: Thermostat SCS317
- Node #2: Actuator SSR303
- Node #3: Raspberry Pi/Stick (Primary)
Now, what can I do?
Z-Wave learning curve is rather steep and badly documented (because of the NDA).
Another particularity is that almost everything is asynchronous... and very slow. Especially when it comes to the SSC317. In order to minimise the battery usage, operation can wait for... hours!
Other example, on the Control Panel, things can take several minutes before one received a response. Not talking about the state of the network which most of the time doesn't seem to reach the "Ready" level! :-(
Well, the thermostat is recognised by openzwave but half the interesting functions are not (yet) implemented. It looks like if openzwave was mainly developed for switches and relays. Sadly enough, anything around the schedule commands (0x53) are not taken into account so there is, at the moment, no way to read/write the 7-day programme.
I wasn't able to read either the current temperature set point (which is odd because it should work).
After playing a bit, I decided that Z-Wave is not yet totally fonctional without a proper certified box. I'm still wondering what the implementation of Z-Way is like and if it is more advanced than openzwave.
The values I can access to are:
- Status of the switch on the actuator (on/off).
- Status of the thermostat (Heat/Idle). In theory the same as above.
- Current temperature of the room (when changing).
- Thermostat battery power
- A few other random values and versions...
For the moment, I shelved idea of overriding the On/Off of the heating remotely (but this works fine). Since I want to use Python3 for the main software and this project is in Python (or C++), the simplest set-up was to have both running separately.
One process is responsible for the z-wave management. Every 5 minutes, a refresh of value is requested (will be honoured... or not) and a few second later, a JSON value file will be dumped.
The main process can then read this JSON file and do what it wants with the values (mainly sending them to RRD).
I'll re-evaluate my options at a later stage.