RaZberry: upgrading to 2.0.0 and modules part 3

Now that I finally had a working setup with RazBerry on 2.0.0 I could start doing some serious logging. Not like seeing the results on the screen for a few minutes and concluding it’s all OK, but logging everything to a text file and analyzing the results during a period that could easily take 2 or 3 weeks. I always do that before adding a new type/kind of hardware to my system – it has to be 100% reliable, because I don’t like searching for an answer to questions like “Why didn’t that Visonic sensor trigger a rule in my rules engine to set the brightness of that Insteon controlled light bulb to 20%?”.

But this time it only took 24 hours to see something was wrong here. And it’s not the result of some bug in the module, but coming directly from the RaZberry – and that’s what worries me the most, actually. Here’s what went wrong during the last 48 hours, all very wrong sensor values:

Temp Sensor: 7.0 = -2971.1
Lux Sensor: 7.0 = -9463
Lux Sensor: 7.0 = 0.0601529
Lux Sensor: 7.0 = -28353
Temp Sensor: 7.0 = 23.5
Temp Sensor: 7.0 = 16.7
Temp Sensor: 7.0 = -1742.8
Temp Sensor: 7.0 = 23.5
Temp Sensor: 7.0 = 23.5
Lux Sensor: 7.0 = 30569
Temp Sensor: 7.0 = 21.9
Temp Sensor: 7.0 = -309.6
Temp Sensor: 7.0 = 15220400
Lux Sensor: 7.0 = 27
Lux Sensor: 7.0 = 27
Lux Sensor: 7.0 = 3
Lux Sensor: 7.0 = 0.0006696
Lux Sensor: 7.0 = 26
Temp Sensor: 7.0 = 5.8
Temp Sensor: 7.0 = 2198.9
Temp Sensor: 7.0 = 15028.7
Temp Sensor: 7.0 = 23
Lux Sensor: 7.0 = 1758910
Lux Sensor: 7.0 = 17664
Temp Sensor: 7.0 = -2664.5
Lux Sensor: 7.0 = 29475
Lux Sensor: 7.0 = 20798
Lux Sensor: 7.0 = 0.16683
Lux Sensor: 7.0 = 0.017478
Lux Sensor: 7.0 = 4.47507
Lux Sensor: 7.0 = -31466
Power Sensor: 8.0 = 6302.02
Temp Sensor: 7.0 = 60.757
Lux Sensor: 7.0 = 4893
Lux Sensor: 7.0 = 1950140
Temp Sensor: 7.0 = -565.1
Lux Sensor: 7.0 = 63
Lux Sensor: 7.0 = 63
Lux Sensor: 7.0 = 0.413177
Lux Sensor: 7.0 = 63
Lux Sensor: 7.0 = 63
Lux Sensor: 7.0 = 64
Lux Sensor: 7.0 = 64
Lux Sensor: 7.0 = 113
Lux Sensor: 7.0 = 12608
Lux Sensor: 7.0 = 1657
Lux Sensor: 7.0 = 64
Lux Sensor: 7.0 = 64
Lux Sensor: 7.0 = 68
Lux Sensor: 7.0 = 68
Lux Sensor: 7.0 = 68
Lux Sensor: 7.0 = -16060
Lux Sensor: 7.0 = 0.017486
Lux Sensor: 7.0 = 68
Lux Sensor: 7.0 = 68
Lux Sensor: 7.0 = 68
Temp Sensor: 7.0 = 14950600

Line 1: no comment. Line 2: lights will be switched on, roller shutters will go down. Line 13: fire alarm! Line 23 during daytime: roller shutters will go down because the room will soon be warmed up too much by sunlight. And what about lines 52 and 53: where the hell do they come from?? Need I go on? With this poor result, I don’t even trust the binary (true/false) sensors anymore…

Mister Bwired experienced the same with identical hardware & module – also strange values. And something similar was also mentioned  the z-wave.me forum. Same issue? Hmm. I was ready to stop with all this ZWave stuff; back to hardware that does work.

In the meantime René Klootwijk, who’s also creating his own Home Automation system, also developed a module to interface with the RaZberry. His module can be used to forward events from zway to your own server using a REST API. René was my last hope actually; his module worked different from mine so maybe the results were different also (as in: better)? I tried his module during the last 24 hours and guess what: perfect! I can’t explain why and I’m not even gonna spend time on it – it’s working, so be happy! All you have to do is create a little webserver to receive the information, add some MQTT and  you’re done:

RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":49,"sensorType":3,"vDevId":"ZWayVDev_zway_7-0-49-3","value":32,"timestamp":1422388041}
RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_7-0-48-1","value":"off","timestamp":1422388068}
RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_7-0-48-1","value":"on","timestamp":1422388104}
RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":49,"sensorType":1,"vDevId":"ZWayVDev_zway_7-0-49-1","value":23.7,"timestamp":1422388154}
RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_7-0-48-1","value":"off","timestamp":1422388170}
RECEIVED: {"status":"online","nodeId":3,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_3-0-48-1","value":"on","timestamp":1422388631}
RECEIVED: {"status":"online","nodeId":3,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_3-0-48-1","value":"off","timestamp":1422388634}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_8-0-37","value":"off","timestamp":1422388641}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0,"timestamp":1422388641}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_8-0-37","value":"on","timestamp":1422388653}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0.8,"timestamp":1422388653}
RECEIVED: {"status":"online","nodeId":9,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_9-0-37","value":"off","timestamp":1422388683}
RECEIVED: {"status":"online","nodeId":9,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_9-0-37","value":"on","timestamp":1422388685}
RECEIVED: {"status":"online","nodeId":9,"instanceId":1,"cmdClass":37,"vDevId":"ZWayVDev_zway_9-1-37","value":"off","timestamp":1422388687}
RECEIVED: {"status":"online","nodeId":9,"instanceId":1,"cmdClass":37,"vDevId":"ZWayVDev_zway_9-1-37","value":"on","timestamp":1422388689}
RECEIVED: {"status":"online","nodeId":9,"instanceId":2,"cmdClass":37,"vDevId":"ZWayVDev_zway_9-2-37","value":"off","timestamp":1422388691}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0.6,"timestamp":1422388692}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0.7,"timestamp":1422388693}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0.9,"timestamp":1422388694}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_8-0-37","value":"off","timestamp":1422388695}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0,"timestamp":1422388696}
RECEIVED: {"status":"online","nodeId":7,"instanceId":0,"cmdClass":48,"sensorType":1,"vDevId":"ZWayVDev_zway_7-0-48-1","value":"off","timestamp":1422388697}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":37,"vDevId":"ZWayVDev_zway_8-0-37","value":"on","timestamp":1422388701}
RECEIVED: {"status":"online","nodeId":8,"instanceId":0,"cmdClass":49,"sensorType":4,"vDevId":"ZWayVDev_zway_8-0-49-4","value":0.9,"timestamp":1422388701}

Now the only thing that still bothers me is the battery which was empty after 2 weeks…

RaZberry: upgrading to 2.0.0 and modules part 2

RaZberryWell, I messed up things very badly right after finishing my previous post about the RaZberry, cause I somehow managed to create a complete mess. Going from firmware 1.7.2 to 2.0.0, back to 1.7.2, 2.0.0 again, several re-installs of the Z-Way for RaZberry software, messing with modules, stopping in the middle of something because it was getting too late etc… Not good; it wasn’t stable anymore.

And I just didn’t have enough time to figure out what I’d done wrong… so last Saturday I decided to start all over again -flashed a fresh Raspbian image on the SD card and did a clean install of v2.0.0. After re-including all the Z-Wave devices I saw them all returning in the Z-Way Home Automation UI; so far so good. I copied my ‘BindHA’ module to the ../automation/modules directory, restarted the z-way-server and went to the Modules section in the Preferences.

And there it was (back again):

Zway modules

After selecting it and NNF (and I think restarting the z-way-server once more, can’t recall anymore) the NodeJS script on my PC was starting to get updates:

Sun Jan 18 2015 21:15:10 GMT+0100
On/Off 8.0 = false
Sun Jan 18 2015 21:15:12 GMT+0100
On/Off 9.1 = true
Sun Jan 18 2015 21:14:21 GMT+0100
On/Off 9.1 = false
Sun Jan 18 2015 21:14:22 GMT+0100
Power: 8.0 = 0.5
Sun Jan 18 2015 21:14:57 GMT+0100
On/Off 9.1 = true
Sun Jan 18 2015 21:14:58 GMT+0100
Power: 8.0 = 0.6
On/Off 9.1 = true
Sun Jan 18 2015 21:14:59 GMT+0100
Power: 8.0 = 0.7
On/Off 9.0 = false
Sun Jan 18 2015 21:14:59 GMT+0100
On/Off 9.0 = true
Sun Jan 18 2015 21:15:28 GMT+0100
Motion, Open/Close 3.0 = true
Sun Jan 18 2015 21:15:32 GMT+0100
Motion, Open/Close 3.0 = false
Sun Jan 18 2015 21:15:33 GMT+0100
Motion, Open/Close 3.0 = true
etc...

Back in business! 🙂 So what does a line like “Motion, Open/Close 3.0 = false” mean? That a binary sensor value of device devices[3].instances[0] became false (0, zero). Likewise “Power: 8.0 = 0.6” means that the power usage for devices[8].instances[0] became 0.6 W and “On/Off 9.1 = true” indicates that devices[9].instances[1] switched to on.

That’s it, I can use this to feed my HA system with information from the RaZberry by turning this information into a MQTT topic & payload – done!

Some things still need to be done though; like support for newly added Z-Wave devices without the need to restart the module, some code cleanup etc., but I can start using Z-Wave devices now if I want to.

RaZberry: upgrading to 2.0.0 and modules

RaZberry on a PiI’m beginning to like the RaZberry, despite the problems I had with it the last few days. Why? Cause it’s open, you can add your own stuff to it- it’s different from all those other closed systems you see so often. Should have done more with it much sooner … I bought the RaZberry @ CeBIT 2013, ordered a Wall Plug when I got home and tinkered with both for a while when that Wall Plug arrived. But since I had no plans on buying more Z-wave hardware (it wouldn’t add anything I didn’t already have – well, problemz maybe), the RaZberry board soon ended up on a shelf cause I needed the Raspberry for something else.

Until I got my hands on a Fibaro motion sensor 2 weeks ago … this sensor was almost ‘irresistible’, I just had to use it. So that’s when I picked up the RaZberry project again to see if I could get the RazBerry integrated into my own HA system.

After I made some progress, I mailed Pieter (who also bought a RaZberry at the CeBIT and ordered the same motion sensor) and he installed my code. But he encountered strange things; weird behavior and messages like “Cannot set port to 8083: Cannot bind to port”, “Object.keys called on non-object”, needing to reboot in order to get things going again etcetera. Strange …

Browsing the web I found out that there was a new 2.0.0 firmware for the RaZberry so I decided to upgrade. Suddenly I had exactly the same problems as Pieter; so I reverted back to 1.7.2 and the problems disappeared again.. So Pieter must be running on firmware v2.0.0 – we checked this and the source of the problems was found. Something must have changed that resulted in my code crippling the whole RaZberry environment…? So I kept my RaZberry running on v1.7.2 until I had the time to find a solution for this, cause staying on v1.7.2 just wasn’t a solution.

This afternoon I had some time to resolve the issue. Although being a complete newbie on Z-Wave (and RaZberry in particular), I did realize that editing the main.js file to get my own code running was not such a good idea; an upgrade made the changes to main.js disappear so there would probably be a better way to extend the RaZberry system with my own add-ons. User Modules seemed like the way to go, as if it was made for what I was doing 😉

So I put my code, almost unchanged, into a User module. It still didn’t work… same problems. Binding worked and the callback was still being executed. Although not completely, so something in my code was still blocking something … I figured out that it must be the blocking /ZWaveAPI/Data/… HTTP call I did, so I rewrote that one to an async version and my problems were gone. Why? I still don’t know; for that I don’t know enough (about how the RaZberry API’s work internally – but I’m glad I found a way to get my upload to my HA system working again :-).

After a while I found out that my Usermodule didn’t always start – it felt like some dependency wasn’t met after a restart (sudo service z-way-server restart) so I changed the module.json and added a autoloadPriority and set it to 9999, like this:

{
  "autoload": true,
  "singleton": false,
  "autoloadPriority":9999,
  "defaults": {
    "title": "HA system binding",
    "description": "Report sensor values to my HA system by HTTP",
    "device": ""
  }
}

Now my module will be loaded later then all the rest; found it on the Z-Wave-Me/home-automation Wiki on Github. The code is still very fresh, it’ll need some more time to prove itself, but so far everything is looking good.

BTW, how nice would it be if MQTT would become part of the RaZberry system …

The Fibaro FGMS-001 on RaZberry and Z-Wave, The Interoperable Standard ?

Well, maybe the fact that the Z-Wave logo can only be found at the bottom of the package of the FGMS-001 was an omen for another story about bad luck. Here it goes.

Fibaro FGMS-001After successfully binding to events in the Z-Way API and getting the required information into my home-brew Home Automation system, I focused on the FGMS-001.

It’s a real beauty; small, flexible, you could almost say that Fibaro reinvented the motion sensor and even managed to fit some additional sensors into the ‘ball’ which are useful @ lots of places in the house.

So I was very excited to see this sensor working. Inclusion went fine, but then the trouble started. My binding worked fine, but no sign of Temp & Lux values? I also saw an error in the z-way-server.log:

Packet CC::MULTI_CHANNEL_CMD_ENCAP_V2 is too short: required at least 5 bytes, got 3
Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)

That doesn’t look good, so I searched for the error message; according to this seems I need a better/newer XML file, so I did. Motion was working, but Temp & Lux weren’t being updated. After a while I found out that this doesn’t happen by design – you have to change some parameters in the configuration. OK, did that. Wrong – you can’t use the RaZberry Expert UI to change those values, cause it messes up the entered values – enter “10” but this is changed to “32769” once you tab your way to the next textbox. Imagine what happens after applying such a value – temperature measurement every 9 hours.

So to finally get things going, I had to do it myself from a command prompt (setting Temperature interval to 600 seconds):

wget http://192.168.10.xxx:8083/ZWaveAPI/Run/devices[7].instances[0].commandClasses[112].Set(64,600,2)

Yep, by the time I got this far the device counter had already reached 7, with just 2 sensors. And the battery is at 88% now, after almost 3 days – what was it, 2 years battery life? I’ll believe it when I see it. The FGMS-001 has lost a lot of its ‘glamour’ in just 2 days.

So what is this, a sensor from a bad batch? Still in beta stage? Z-wave.me forum blames Fibaro for not following the standards of the holy grail of Home Automation called Z-Wave. Is this true and if so, why do this? Can’t they read?  Or is there some other purpose for this kind of deviation? I don’t know and frankly it doesn’t even really matter – what it results in does matter.

Cause all these little deviations make Z-Wave unreliable, immature – you never know whether it’ll work out of the box or not. Lots of techies will be able to solve this sort of issues, but the majority won’t. Killing. And imagine the IoT, with a predicted >25 billion devices around 2020, being driven by Z-Wave … it gives me the shivers!

Meet the Fibaro Wall Plug FWGPF-101

Fibaro Wall Plug

Today I received a Fibaro Wall Plug FGWPF-101.

I shut down my RPi running RasPlex, exchanged the SD card for the one with the RaZberry software on it, booted the RPi and from the RaZberry UI I included the Fibaro Wall Plug (Plug from now on). Within 2 minutes the Plug was ready to play with 😉

Lets have a closer look at what this Plug can do:

– handle 2.5 kW continuous load (resistive load, so watch the cos φ)
– Radio: Z-Wave, 1 mW @ 868.4 MHz
– Range: 30 m indoors
– Dimensions: D x H 43 x 65 mm
– Crystal RGB LED ring which can be used for a number of things
– Measuring momentary and historic power usage
– Local control by a small push button

The first thing I noticed was the very tiny manual: A4, printed on both sides with a very small font. I downloaded the Operating manual as PDF, maximized Adobe Reader on one of my 22″ HD resolution screens and still had to zoom to 121% before i could start reading. MS Word counts > 3100 words on a single-sided A4 – I’ve seen better.

The Plug itself looks great though! The white surface is glossy and the LED ring looks nice too. But the biggest advantage is the size – it’s really small!


3 different Plugs

I took a picture of 3 plugin modules I have and as you can see 4 Fibaro Plugs will easily fit into that box with 4 sockets; Insteon will manage 2 (and 4 with some extra force) but PLCBUS is the big loser here: only 2 will fit.

The first I did was trying to get a feeling about how fast the Plug responded to On/Off switching from the RaZberry UI. Well, what can I say.. comparing it to X-10 or PLCBUS is useless in terms of responsiveness, those 2 will never win. But I also have a Insteon Hub and an Insteon On/Off Module on my desk and I can control this On/Off module from my homebrew Home Automation system. So i tried both Fibaro and Insteon and I’m not sure, but I think Insteon is a little bit faster: the clicking sound of the Insteon module relay seems to have a smaller ‘silence gap’ with the clicking sound of the mouse than the Fibaro Plug. But maybe I’m biased, so I’ll redo this ‘measurement’ in another way 😉

I’ll test this more thoroughly in the next few days, but before I can do that I need to be able to control this new Plug from my system – that’s the only way I can really compare the two. And I’ll add PLCBUS to the competition as well, just for fun.

After that I’ll do some range testing and see how really well (reliable) this Fibaro Plug performs in a real house, compared to those other 2.

Stay tuned!

 

PS, a message for Mr. Essent – my wife’s hairdryer did turn the LED ring of the Fibaro Plug dark orange, while my hobby equipment all stayed in the green zone! 😉

Getting rid of some outstanding issues

I tend to lose interest in things by the time they’re almost finished – that may sound strange (I don’t 😉 ), but it’s the truth and it’s a habit that’s hard to beat. Knowing that I will get something working, doesn’t always mean I will make it that far and complete the whole job. The main reason is that there’s so much more to explore and learn, and that’s the most interesting part of it all; the thrill of learning more each time you start something new, right? In a way, being able to unlock the front door with my smart phone is just a nice side effect…

So while I’m still waiting on some Z-Wave hardware for my RaZberry, I started doing those last bits on some of my earlier projects.

Security system

Getting our security system connected to the rest of my Home Automation system has always appealed to me. With RFXCOM and an Alphatronics interface I did have access to the information of the sensors, but controlling the security system can be very handy too, for example arming it when everybody has gone to bed.
I did some experiments with a Powerlink in 2011, connected the system to my LAN in 2012, tested this with some experimental code, helped others to get things working, but there is where it ended; during a re-shuffle of some Serial-to Ethernet servers our security system was disconnected and I kinda ‘forgot’ about it; however some recent ‘events’ in the neighborhood brought the job of integrating the security system higher up on the to-do list.

Someone was so kind to give me his PowerMax code which has already been tested at various locations and the last 2 weeks I’ve been busy ‘porting’ the VB code to Delphi, testing the code with my own security system and monitoring everything to see if it’s all working OK. And it is… so now it’s time to take the last step and start using that interface. The biggest advantage is that my Home Automation system knows exactly the same as the security system does:

  • Panel Status (e.g. Armed, Disarmed, …);
  • Panel State (Ready, Alarm, Zones in memory, …);
  • Sensor information ( Open, Closed, Motion, Battery Low, ..).

By getting the information directly from the security system itself, it won’t matter anymore if RFXCOM or Alphatronics receiver will miss some packets – now I’ve got 100% correct information. And now I also have several new things I can do with my security system:

  • Arm and disarm the security system from my Domotica system;
  • Arm the system and bypass certain zones if I want to;
  • Control the security system from anywhere and with any User Interface;
  • Disarm the Security system event-based; for example, when someone opens our Nemef Radaris RFID front door with a badge;
  • Arm the system when the front door is being locked.

This weekend I updated my system.

Done!

Nemef Radaris Evolution

Nemef Radaris Evolution

One of those other things that got disconnected some time ago in a 90%-finished-state. While working on a Plugin for the Nemef Radaris, I stopped using the Nemef RF Module from my own system to test the Plugin, and I never started using it again afterwards. A big loss? Well, the Nemef Radaris doesn’t need a HA system, it works completely autonomously (for obvious reasons), so in some way we didn’t really miss the ‘Domotica link’.. today I finished some loose ends in the code and it’s working 100% now.

Next!

Web interface

Web Interface

I’m very bad at creating nice-looking icons myself, it’s just not my cup of tea. Most of the times I try to find some icons on the web, but I’ve never been able to find an icon collection that has all the icons I need. So it becomes a mess very quickly, and ugly.. too ugly to use (and to show off..)

And my requirements are really not that high – as long as the icons speak for themselves and have a somewhat similar ‘look’ , I’m easily satisfied (I think).

After finding a new collection of icons on the domoticaforum this week, I decided to use that one. And there’s 1 big benefit with this collection: I know the person who made these icons, so if I miss some specific icon, I know I won’t be lost…

On to the next item!

So, even if the outcome of my new Z-Wave tryout with the RaZberry will be disappointing, waiting for Z-Wave has already brought some positive things, namely finishing some things that should have been done a long time ago. OTOH: waiting this long is OK – just once every 3 years or so, not more often please!

Raspberry Pi and RaZberry as Z-Wave controller

Today the first Raspberry Pi (RPi) arrived.  In size it equals an Arduino Mega, but the nice thing about the RPi is that it’s running Linux, which adds a whole new range of possibilities.

For example (and that’s what I’m going to do with it, for now) turn it into a Z-Wave controller with the use of a RaZberry.

RPi with Razberry on top

Powered by the adapter of my old smartphone, a standard 4GB SD card inserted to the left and a network cable to the right and the RaZberry connected to the GPIO. Power the thing up, wait about 30 seconds, start an ssh session to the RPi and you’re good to go!

Well, some preparations had to be done though, but those were all very easy and went very smooth.

First, make sure you have a SD card and a USB card reader. I didn’t, so I went to a local shop for those items after work. The image that has to be written to the SD card can be downloaded from here. Windows users will also need a tool to write the image to the SD card, for that I used Win32DiskImager. I inserted the SD card into the card holder of the RPi, connected the network cable and power adapter and saw the LEDs starting to blink. So far so good..

Next I used PuTTY to login. User pi, password raspberry. I followed the instructions on the screen (sudo raspi-config) to set the Time Zone and things like that and was done within half an hour or so, including preparing the SD card.

One of the first things I did was installing joe, my favorite editor on Linux (with Wordstar keystrokes, yeah!). That’s when you get reminded of the fact that the RPi is not your regular full-blown desktop PC – it took a bit longer to install than I was used to. I really don’t wanna know how long it would take to compile Apache from source… 😉 Well, never mind, that’s not what I’m going to use this RPi for anyway.

After shutting down the RPi I connected the RaZberry to the GPIO and booted again. The software for the RaZberry can be installed very easily:

wget -q -O – http://razberry.z-wave.me/install|sudo bash

After a 2nd reboot I could now surf to http://<rpi-ip-address>:8083/ and watch the demo User Interface of the RaZberry:

RaZberry demo UI

 

And after that… this exciting new adventure stopped, due to the lack of Z-Wave hardware. I can’t wait to find out if this combination of a RPi and the RaZberry add-on will enable me to use Z-Wave without too much hassle, cause that’s my ultimate goal – ‘talk’ to Z-Wave hardware through the RaZberry JSON API and not having to worry about every little detail – there are too much other things to explore, right??

Z-Wave power-strip

Yesterday the Z-Wave power-strip I mentioned earlier arrived, in a light-weight large-size cardboard box mostly filled with air. After unpacking the air and reaching the bottom of the box, there it was: the GreenWave Reality PowerNode. Wow, I have never seen such a shiny bling-bling power-strip in my life 😉

Since Maarten Damen already discussed some of the software related aspects of this power-strip, I’ll only talk about my hardware related observations.

The power cord, which is 130 cm long, looks good. Thick and solid, like a power cord should be that has to supply 6 sockets. Personally I prefer straight plugs, but as most plugs are these days, the power cord of this power-strip also ends with a right-angled plug.

The bling-bling level of this power-strip is high; high enough for my son to ask “What’s that??”.  “A power-strip, my son.”  “Yeah dad, I can see that, but is there something else you can do with it as well, or what? Cause it looks so, ehh, unusual?” “Yes, with this power-strip I can switch off the TV in your bedroom from the other side of the world, ain’t that cool?”

 

The power-strip has a On/Off button and some sort of dial. Pushing the button feels a bit cheap; no real ‘click’; and a very soft push is enough to switch the power-strip on or off. This button works too easy for my taste, which increases the risk of turning the complete power-strip off accidentally. The dial feels a bit cheap too; in my opinion, there’s some imbalance between look and feel here..

The 6 sockets have child protection, feel solid and keep the plugs in place firmly enough. Each socket uses 45 mm of space. With a lot of adapters this can be a problem, as with all other power-strips I have, so this power-strip is neither better nor worse as a standard power-strip in that perspective.

A standard procedure for everything with a power cord that comes into our house, is measuring the standby power usage. With nothing plugged in, this power-strip uses ≈ 3.5 Watt. That’s about 30.5 kWh per year. IIRC that’s about 0.9% of the yearly power consumption of an average household. (in my case, that percentage is much lower 😉

So the first impression is OK. I’d love to see what’s inside, but that will not happen. Yet. First I’ll hook it up to Homeseer to see if and how it works before I open it up; so that when I close it again and the strip doesn’t work anymore, I know who to blame…

 

Z-Wave?

Never thought this would happen, but I’m going to try Z-Wave. Yeah! Ow yeah? We’ll see..

Maybe I only read the wrong forum topics and maybe I only talked to the wrong people, but the things I read and heard about Z-Wave never gave me a good feeling about it. Z-Wave users have to deal with scheduled network optimizations, short battery life, incompatibility issues, vaporware, products where the parts have to be held together with some good old DIY with pieces of tape – hell, they sometimes even have to wait for 48 hours before a new device becomes usable… and it’s being accepted by the Z-Wave users?? I don’t get it. I will never accept those kind of things, that’s for sure.

So maybe this Z-Wave adventure will be a very short one. And maybe not. At least I’ll be able to make up my mind about Z-Wave based on my own experiences for a change, once I’ve got my own hardware to test with. Maybe it’s not that bad after all … always an optimist!

The thing that triggered this Z-Wave initiative was a post on the Domoticaforum where this power-strip was discussed as an alternative for one of those vaporware products I mentioned. This powerstrip seems to be a re-branded GreenWave Reality PowerNode and I would really like to have 1 or 2 of those in my house.

So last week I ordered one at the NUON Energy shop (no, you can’t buy Energy in the shop) and ordered a Aeon Labs Z-Stick.

One tiny problem left to solve – the software side of things. From what I’ve read, the best option to get Z-Wave operational is using the OS Open Z-Wave initiative, but how do I make this work in my Delphi based system? Searching for more info revealed very little to start with, and I don’t want to spend too much time on the software side while I haven’t decided if Z-Wave is a go or not… there has to be an easier way for that; at least for this experiment.

HouseAgentAnd there is – HouseAgent. Maarten Damen, the maker of HouseAgent, only lives ‘a few blocks away’ from me and he has also bought this power-strip! And he has made a Z-Wave Plugin for his multi-platform Home Automation software. So why not install HouseAgent, let HouseAgent do the Z-Wave stuff and pull the data I need out of HouseAgent? That would be perfect!

Maarten told me his system has a REST API, which shouldn’t be that hard to interface with, no matter what programming language you use. Right, lets do it!