Yet Another Developer Blog

It seems that ZWay 1.4.1 got finally released ; well, at first sight it looks to be the same as the previous release candidate ("v1.4.1-rc1"). Therefore it was time to update my raspberry pi with this newer version. Hopefully this should now enable support for the ALARM command class. Nothing got broken in terms of recompiling my existing code. Good - but: It seems necessary to re-include/re-interview the ZWave devices. The data holder model for my binary sensor has changed! Previously, the "level" boolean value for my sensor was obtained using: zway_find_device_instance_cc_data(aZWay, 2, 0, COMMAND_CLASS_SENSOR_BINARY, "level"); Now there is no more data holder under this name. It is: zway_find_device_instance_cc_data(aZWay, 2, 0, COMMAND_CLASS_SENSOR_BINARY, " 1. level"); Not very clear why, but this works as before for me. But the good news is that no...

According to the ZWay forums , the upcoming version of the ZWay RaZberry software (1.4.1?) will finally support the ZWave Alarm command class. Why is that interesting? Well, if you plan to use your RaZberry for a home security system, this command is kind of important: a ZWave device sensor sends this command when it gets tampered (e.g. when a door sensor gets detached from the door). And so far the Alarm command was not supported :-( As soon as it gets released in a final build, I will try that and give some feedback here!

Looking at the constant evolution of the Android platform and how bad the phone manufacturers are supporting it on their older phone platforms, it is clear that a smartphone is not a "life companion". With about one or two major versions of the Android platform coming out each year, its lifetime is clearly short. At some point: It gets "stuck" in one particular Android platform release. There is no more main storage (flash) space. It is getting slow running some applications. It does not support anymore the newest market applications. It is not as "fancy" as recent phones :-) My old smartphone, an HTC Legend , reached that point; 3 years after I bought it, I am now part of one of the smallest Android platform group according to the  Android "platform version" distribution  : Froyo. My phone lacks storage space every day, each time an application update pops in for instance. It is impossible to update the good old Google Talk application...

The libcurl library does not provide a clear example on how to issue HTTP PUT operations in a REST context; the examples are mainly about file transfers . For my proxy application this is not really what I need: I want to perform a REST HTTP PUT, keep it simple, meaning without using the "Expect" and "Transfer-Encoding" that libcurl adds by default. After some struggling I discovered that this behavior can be changed by using the following code: CURL * pCurl; struct curl_slist *headers = NULL; headers = curl_slist_append(headers, "Content-Type: application/json "); headers = curl_slist_append(headers, "Content-Length: 12345 "); headers = curl_slist_append(headers, "Expect:"); headers = curl_slist_append(headers, "Transfer-Encoding:"); pCurl = curl_easy_init(); curl_easy_setopt(pCurl, CURLOPT_VERBOSE, 1); curl_easy_setopt(pCurl, CURLOPT_PUT, 1); curl_easy_setopt(pCurl, CURLOPT_URL, " https://your-server.app...

In order to be able to refresh the persisted state of my binary sensors on my little web application, I extended my "Z-Wave proxy" to send some information when it initially starts. It retrieves data from a few "data holders": The current level (if the sensor is triggered or not). The configured wake-up interval. The last sleep time. The last wake-up time. The battery level. The following code can be used to do so. const ZWBYTE COMMAND_CLASS_ALARM = 113; const ZWBYTE COMMAND_CLASS_BATTERY = 128; const ZWBYTE COMMAND_CLASS_SENSOR_BINARY = 48; const ZWBYTE COMMAND_CLASS_WAKE_UP = 132; [...] bool level = findInstanceDataAsBoolean(aZWay, COMMAND_CLASS_SENSOR_BINARY, "level"); int wakeUpInterval = findInstanceDataAsInt(aZWay, COMMAND_CLASS_WAKE_UP, "interval"); int lastSleepTime = findInstanceDataAsInt(aZWay, COMMAND_CLASS_WAKE_UP, "lastSleep"); int lastWakeUpTime = findInstanceDataAsInt(aZWay, COMMAND_CLASS_WAKE_UP,...

Z-Wave battery powered devices implement a periodic "wake-up" where it contacts the controller; for the door sensors I am using, I configured the wake-up to happen every 5 minutes. Now, how to capture this in the ZWay library? It is again the same as for other events: register a callback on a certain "data holder". Here this data holder is found on: device instance level; command class: 132 (wake up); path: "lastWakeup" (there is also another one "lastSleep", so far it is not clear to me which one is the best to use). Here is a sample code registering a call-back for this event: zway_data_acquire_lock(aZWay); ZDataHolder dataHolder = zway_find_device_instance_cc_data(aZWay, mDeviceId, 0, COMMAND_CLASS_WAKE_UP, "lastWakeup"); if (dataHolder != NULL) { zway_data_add_callback_ex(aZWay, dataHolder, &aliveCallback, TRUE, this); } else { cerr << "No data holder for deviceId=" << (int) mDeviceId...

Now that I know a bit better how to use the ZWay library, and that I refreshed a bit my C/C++ knowledge, I can finally complete the first use-case of my home security system: getting notified of an event on my phone (my good "old" HTC Legend running Android 2.2). For a long time I have been wondering and hesitating about the "server" part of my system. The Raspberry Pi could of course play this role, but it would not be "safe" since cutting the home power or un-plugging it would void the "security system". Yes of course I could put the Raspberry Pi on battery, hide it somewhere in the house and use WiFi to connect to others networks in case my home Internet connection would drop, but then again, cutting the power of the whole neighborhood would still kill my system. So it had to be something external. Looking at prices for getting my own Linux private server, that would be something like 5-15 Euros a month. That sounds rather stupid since for...