Yet Another Developer Blog

Finally "back to work" and trying to finalize a first fully working version of my home alarm system... I am now looking at how to use my alarm device, a " FortrezZ strobe and alarm " ZWave device. I added a small extension to the rzwaveway library for that matter. It is a simple interface for controlling the state of the alarm and enabling or disabling the strobe light and siren. zway = RZWaveWay::ZWay.instance zway.setup(hostname) zway.start device = RZWaveWay::Extensions::SSASirenStrobeAlarm.new(device_id) device.enable_strobe sleep 5 device.enable_siren sleep 5 device.disable Unfortunately it seems that the "SetWithDuration" function of the SwitchMultiLevel command class does not work (at least from the Z-Wave Me web UI). I guess it would have helped to implement a "pre-alarm warning" (e.g. some short bips to notify when the alarm is armed). The best solution I could find so far to ...

The first ZWave devices I bought one year ago were window/door sensors. I started with 3x Everspring SM 103 sensors as I got a bulk price for them. Initially everything worked fine, until a few months: One sensor, attached to a window, suddenly stopped communicating with the controller; changed the batteries, re-included into the network, did a reset, but still the same. Even at 30 cm from the controller, sometimes it takes a few seconds (to a minute) to wake up and send an event. Weirdly after it wake up a first time, it seems to work fine for a few... but after some time, it "lags" again. Finally, I replaced it with the "test" spare sensor I had. Second sensor, the door sensor... Ok, that one was badly treated: since the base was too big to be installed next to the door, I installed the base on the door and the magnet on the side. Clearly a bad idea. This probably did not help. Recently this one also started to "miss" wake ups, but worse, it also mi...

Still working on the Ruby [ dark ] side (although I wish I had more time and motivation to go on with my C++ :-)),... I finally implemented something that makes it possible to "invoke" ZWave command class functions on devices. In Ruby life is easy and this was implemented quite easily: after all, calling a function in ZWay ends up being just a simple HTTP call. In my little rzwaveway  library gem I added the notion of "extensions" ("plug-ins" would have been a good name too) that define a clear API (meaning, not a low-level ZWay function call) for a known ZWave device interface. As a first test, I implemented support for the ZWave siren/strobe alarm device I bought earlier this year. The code for it looks like this: module RZWaveWay module Extensions class SSASirenStrobeAlarm include CommandClasses def initialize(device_id) @device_id = device_id end def disable set_value(0) end def enable ...

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