Yet Another Developer Blog

The past month brought a bunch of changes in my developer carrier. Change of job team, office, city... and technologies. One of these was to start learning a new language for developing software: Ruby! It is quite a change from the programming languages I went through before (in short, Turbo Pascal, C, C++, Assemblers, Java, C#). I was advised a very good Ruby book,  Eloquent Ruby  and some fancy "training exercises", the " Ruby Koans " to start learning about Ruby. After a few days I realized that a better exercise for me would be to re-implement my "home zwave proxy" (developer in C++, using directly the ZWay C library); and well, it was a good idea. After 4 weeks (well, a few hours in the evenings), with some basic knowledge of Ruby, I almost managed to reach the same "level of functionality" as my native C++ application. "Almost", because there is definitively something I miss in this fancy Ruby world: real callbacks on event...

Right, it was about time to invest into some new ZWave devices for my home. Christmas being over....... I finally made up my mind and ordered: A smoke sensor: Fibaro FGSS-001. A wireless siren & strobe alarm: FortrezZ SSA1 So far I managed to include the smoke sensor device; the ZWay configuration screen were initially not right and I had to update the ZDDX definitions in order to get it right: it was missing the XML file for this brand new device: " 500-010f-0c00-1000-03-03-34-02-01.xml " (note that there is a nice ZWave device database here ). For that matter, I discovered that there is a script meant for that purpose: "/opt/z-way-server/ZDDX/UpdateXMLs.sh" I did not install yet the alarm device; too risky :-) My C++ Razberry proxy software needs some rework and device abstractions first...

Until now, my "Home server" Google application (running in the cloud :-)) was using basic XMPP for sending sensor notifications to my phone. With that, each time a sensor changed status, a small text message was sent to me, appearing in my Google Talk application, telling me what sensor changed, the time etc. Easy, simple, very basic: a few lines of code, done. Even an event history for free! However this basic solution started to be annoying: No easy way to integrate the notifications with my "Client" Android application. Impossible to use this if the Android Google Talk application got upgraded to "Hangouts": I tried and indeed, I never got a single message when using Hangouts. Apparently, this is a known limitation ? Luckily last month I finally discovered Google Cloud Messaging  and had a bit of time to "practice" during the holidays. In short, it makes it possible to easily received/send messages from/to an Android device; the send...

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...