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

After getting your hand on a Z-Wave data holder in the ZWay library, the next step is to register a listener for getting notified when a change occurs on this data. The ZWay library provides the following methods for managing data holder listeners: zway_data_add_callback() zway_data_remove_callback() zway_data_add_callback_ex() zway_data_remove_callback_ex() zway_data_acquire_lock(aZWay); ZDataHolder dataHolder = zway_find_device_instance_cc_data(aZWay, 2, 0, COMMAND_CLASS_SENSOR_BINARY, "level"); if (dataHolder != NULL) { zway_data_add_callback_ex(aZWay, dataHolder, &dataChangeCallback, TRUE, this); } else { cerr << "No data holder for deviceId=" << (int) mDeviceId << endl; } zway_data_release_lock(aZWay); The following code will register the following "dataChangeCallback" function in the ZWay stack and make sure it is invoked when the Z-Wave binary sensor with node ID 2 gets triggered. void dataChangeCallba

Having now my sensors now installed "properly" (well, the sensors are hell to mount on PVC) on the door and windows at home, it is time to set-up my little ZWay application to get notified when these sensors are generating some events. More precisely, when a window or door gets open... The ZWay API provides the possibility to install some callbacks when "data holder" are changed. Therefore the first thing to investigate is the data holder. There are a few functions to get a hand on a data holder: zway_find_data(...) That one requires a data holder as argument, so that's not the one we need. zway_find_controller_data zway_find_device_data zway_find_device_instance_data zway_find_device_instance_cc_data These are the functions to use; to get the "root" of the data holder, you can simply provide an empty string as parameter e.g. ZDataHolder dataHolder = zway_find_device_instance_cc_data(theZWay, 2, 0, 48, ""); Given a bit o

Back after a while... and a son! Here is a piece of code that can be used with the latest version of the ZWay library. It makes it possible to retrieve the Z-Wave device list and display the device names and associated XML file (each recognized device can be associated to an XML that contains a bunch of meta-data: name, description etc.). int main(int argc, char ** argv) { ZWay theZWay; ZWError result; memset(&theZWay, 0, sizeof(theZWay)); result = zway_init(&theZWay, "/dev/ttyAMA0", "/home/pi/src/razberry-proxy/config", "/home/pi/src/razberry-proxy/translations", "/home/pi/src/razberry-proxy/ZDDX", stdout, Warning); if (result == NoError) { result = zway_start(theZWay, &terminationCb); if (result == NoError) { printf("Discovering...\n"); result = zway_discover(theZW

The Z-Wave "RaZberry" installation comes with everything needed to be able to do some custom development in C; everything is installed in the /opt/z-way-server  directory. There, one can find: A set of (documented, nice!) C header files found in /opt/z-way-server/libzway-dev : CommandClassesPublic.h FunctionClassesPublic.h ZDataPublic.h ZDefsPublic.h ZErrors.h ZPlatform.h ZWayLib.h A set of libraries found in /opt/z-way-server/libs : libmicrohttpd.so libv8.so libzwayhttp.so libzwayjs.so libzway.so For the ZWay stack to run properly, it is needed to provide the necessary configuration files. Instead of using these directly from the installation folder, I made a copy in order not to mess up too much with my working/configured setup. The following directories from the ZWay installation folder are needed: config translations ZDDX For experimenting I made a small Makefile in order to build and run. main.out: main.c gcc -I/opt/z-way-server/li

Having a "Raspberry Pi" as a DHCP server is of course not my end goal. There are plenty of ideas I have about what it could do... Home automation is one of them. So finally, after a long time hesitating between various extensions, devices and technologies, I finally ordered some new fancy toys: First of all, a Z-Wave extension board for the Pi: the "Razberry" from Z-Wave.me . Unfortunately expensive (but well, a USB dongle is also too), but quite a nice little extension board. A set of Z-Wave sensors; as security was my wife first concern and my budget limited, I bought three door/window contact detectors ( SM103 from Everpring ). Z-Wave  seems to be definitively an expensive choice compared to ZigBee , but well, at least I found easily some devices, and guess what, so far it works out-of the box!  So now, time to look at APIs and see how to get further... As a start, I would like to be able to control things from my phone and be able to get notified w

Today after turning my laptop I had the bad surprise to get no Internet connection; worse than that, no network connection at all: no DHCP address assigned to me :-( Looking at the logs on Raspberry Pi ( /var/log/syslog ), the issue is clear: Feb 7 22:53:42 raspberrypi dhcpd: No subnet declaration for eth0 (no IPv4 addresses). Feb 7 22:53:42 raspberrypi dhcpd: ** Ignoring requests on eth0. If this is not what Feb 7 22:53:42 raspberrypi dhcpd: you want, please write a subnet declaration Feb 7 22:53:42 raspberrypi dhcpd: in your dhcpd.conf file for the network segment Feb 7 22:53:42 raspberrypi dhcpd: to which interface eth0 is attached. ** Feb 7 22:53:42 raspberrypi dhcpd: Feb 7 22:53:42 raspberrypi dhcpd: Feb 7 22:53:42 raspberrypi dhcpd: Not configured to listen on any interfaces! [...] Feb 7 22:54:11 raspberrypi kernel: [ 51.380450] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Feb 7 22:54:12 raspberrypi ifplugd(eth0)[1343]: Link beat de

Since my last post, although my [fun][geek] evening time was limited, I managed to fix a few issues on my home network, thanks to my Raspberry Pi. First, I made it reachable from the Internet. Nothing difficult there: I already had this setup for my "old" Dell Linux machine. Just a matter of: Assigning a fixed local IP address to the RPI. Configuring a NAT rule on the Internet gateway that maps an external port (e.g. 12345) to the SSH daemon port on the RPI (port 22). Having a small client that registers the Internet gateway external IP address to a free dynamic  DNS service. For that I installed and configured " ddclient " with an account from DynDNS . Cool... How geek, now I can remotely connect to my home network from the Internet. Well, this is needed for later: I want it to be the center and the entry to my home network. Home-automation, security here we go! Since my [fabulous] Internet gateway still refuses to persist DHCP static lease bindings,

I will not be using the "Raspberry Pi" as "a common PC"; there are already too many of these at home. And well, for the use-case I am thinking of, it is not needed. So the first step is to make it "headless". For my initial experiment, I took the default Linux distribution " Raspbian wheezy " (16/12/2012); I preferred to start with the "official" distribution (I assume, the most stable and the easiest to begin with).  I made sure I would have at least: A connection to the screen: that meant for me a cable HDMI to DVI. A network connection to my home modem. A USB keyboard. Everything went well, except that the keyboard I used (a Logitech Wireless keyboard K340) did not work out of the box. For some obscure reason, if the USB dongle is connected at boot-time, I don't get the keyboard to work; but, if I unplug and plug again the dongle after the RPI booted, it worked just fine... After that I could finally start. Good

Yesterday I finally got my " Raspberry Pi "... and after unpacking it, I couldn't stop being nostalgic: "Wow, what a step my first computer... my good old 8086 ". A long time ago, in a galaxy far, far away... I used to live in France, and I used to have an old 8086 (my first own computer - thanks Dad !). It was a piece of hardware: a huge box, a huge screen... Internally it was a beauty: nothing compared to today's PCs where the cabling is always a big mess, the cases have always issues with dust etc. But, what an evolution when I try to compare it to my new toy. Memory, my precious:  640k of RAM was cool. But sometimes, after booting or running a few programs, there was not enough to run stuff. Optimization was not about "add more memory" or "run garbage collector". I remember, it was about writing the perfect " autoexec.bat " with its " config.sys " and avoid loading unnecessary drivers etc. 10M of hard-disk