preload
Aug 15

From a Domotica perspective, our new Nemef Radaris Evolution is nothing more than a closed system. No communication, I/O or other ways to interface with it. But there’s a really good solution to this: the Nemef RF Module!

Nemef RF Module

The RF Module can be used for transmitting an ‘open’ command to Nemef Radaris locks, it can act as a wireless interface for RF Controllers and can also be used with products of other manufacturers. Last but not least this RF Module has a RS485 interface for easy integration into existing systems. The open ASCII protocol that is being used for the RF Module makes the combination of the Nemef Radaris Evolution and RF Module a complete solution for integration into any Domotica system, including mine.

The RF Module is also equipped with 4 relay outputs capable of switching max. 24V AC/DC @ 0,8A. On top of that, this RF Module has 3 inputs (the middle terminal block with the 6 connectors) which can be used for various pre-programmed purposes. More on that later.

In my case, the RF Module is connected to a RS48RS485 converter5 to Ethernet converter so that I can ‘talk’ to the Nemef RF Module over Ethernet.

In the last couple of weeks I’ve been working on the software side of things; classes that represent the RF Controller, RF Module and Badges have been developed and an interface class which takes care of handling the protocol and delivering the protocol data to the corresponding device class instances.

A preliminary version of the resulting page showing some of the information that’s available can be found here.

This RF Module enables me to:

  • Lock/unlock the door from my Domotica system (hence, from wherever I am);
  • Badge administration: adding and deleting badges from the RF Controllers memory and granting access to the in- and/or outside readers;
  • Configure the 3 inputs of the RF Module;
  • Switch the 4 relay outputs.

And of course, my system gets notified of all the real life events taking place on the Nemef Radaris Evolution, like

  • a badge that has been detected by a reader (which badge, which reader, whether access has been granted);
  • the status of the controller (deadbolt position, battery condition, latch status);
  • changes on each of the 3 inputs.

All this is done without the need for polling or any other kind of continuous communication; cool ; what more do you want..

More on the advantages of using the Nemef RF Module in an automated (home) environment later!

Tagged with:
Aug 10

GazeboDespite all the Domotica stuff going on every day, I was able to find the time to build a gazebo in our garden this summer. I finished this gazebo in late June. Well, not quite; I still have to take care of the lighting. And somehow, everything I build or do in my spare time just has to have a Domotica touch :-) This time, it’s the lighting. I could have chosen the easy way and just put a big bright light bulb in the middle for when it gets too dark outside, but that’s too ugly, easy and no fun at all.

So I contacted Marco Versluis of Mood LedLight and he offered to come over and have a look at the gazebo and discuss some options for some nice and good lighting. Although I’m not the type of guy who decorates the entire home inside and outside with flashing lights at Christmas time, I do like to have nice lighting in the garden during the time that it’s dark and we’re still downstairs; an example of this is a previous garden lighting project.

This time we chose to do the lighting with 6 RGB LED spotlights.RGB LED spotlight

At each of the 6 poles of the gazebo there will be a RGB LED spotlight which will light the pole and the inside of the roof. That should be sufficient to give good lighting while sitting under the gazebo on warm nights as well as a nice view from the living room when we’re inside.

OK.. I admit it, I just couldn’t resist buying a DMX decoder for those 6 RGB LED spotlights – so I can produce 256 x 256 x 256 colors, who wouldn’t want that in his back yard? ;-) And of course, these LED spotlights need to be controlled from my Domotica system, otherwise it wouldn’t be much fun, right?

I’m not worried about accomplishing this. I found a Arduino DMX shield that should take care of the DMX encoding. And since it’s an Arduino shield and I have some unused Arduinos here, this will be plug & play, hardware-wise. Developing a sketch to control it all from my domotica system shouldn’t be that hard either.

No, the thing that I’m thinking about most of the time is: what color should these LED spotlights produce? Just pick a color I (ehh, we) like? Neh, too easy. And I certainly don’t like some predictable color scenario that repeats itself every x minutes. Yuck!

Come on, my Domotica system has almost 900 device values, why can’t I create some RGB values out of all that constantly changing data and produce a real geeky lighting? (ah, that reminds me: I need a motion sensor for the gazebo and/or a button to override the geek-lighting scheme with something that’s more moderate and acceptable for non-geeks … :-)

So basically, I’m looking for “something” that should produce a smooth changing, unpredictable RGB value based on device values originating from our house… There’s enough to choose from I guess… like using door/window open/closed status as bits for one of the 3 RGB bytes, or on/off statuses,  motion detection, total power usage for the R value, water usage for the B value…  well, I’m still thinking what to choose – suggestions are welcome!

 

Tagged with:
Aug 07

Whoa, some articles I wrote about the Visonic Powerlink a couple of months ago, seem to be rather popular again the last couple of days; I can see that in the WordPress Site Stats panel. And I can also tell you why; it’s because there are a number of people that have joined forces recently to reveal the protocol that’s being used by the Powerlink to communicate with the Visonic Powermax (Plus/Pro) alarm system. And for some reason people land om my blog, although my articles are not really related to the latest progress that is being made on opening up the Visonic PowerMax alarm systems.

It all started by a user named utz who started a topic on the MiCasaVerde forum and started another topic on the Domoticaforum Europe some weeks later, asking for help on reverse engineering the RS232 communication between the Visonic alarm system and the Powerlink. Well, he got some help allright :-) A member of the Domoticaforum even started a fundraising to buy a Powerlink especially for this goal – interfacing with the Visonic system without the need for a Powerlink!

Visonic RS232 moduleYes, all you need to communicate with your Visonic alarm system is a Visonic RS232 module, which will save you around 150 Euro on the Powerlink(2) hardware. Another advantage of bypassing the Powerlink is that the RS232 method always works (haven’t read any problems so far), in contrary to the stablity issues and even complete failure to get a PowerMax Pro communicate with a Powerlink2!

By the time I came back from vacation and read about it on the Domoticaforum, some members had already joined in reverse engineering the protocol. There’s even a Wiki for documenting everything that has been discovered about the protocol.  I (and lots of other people) immediately saw the big potential of this RS232 approach, and the decision to buy a RS232 module was made in a split second, cause I wanted to start doing some testing too.

Every now and then you come across a topic of which you think: “Wow, this is cool, very cool!”  This is one of those rare topics… thanks to all the guys that are helping on reverse engineering and documenting the protocol, cause this is a real breakthrough regarding integrating a Visonic alarm system into a Home Automation system!

Since I’m currently working on some other project, I haven’t been able to spend much time on this Visonic RS232 hack yet but I will, soon..ASAP…

I’ve got some great plans with this!

 

Tagged with:
Aug 06
Nemef Radaris Evolution

Nemef Radaris Evolution

Since about a month we have a new door furniture on our frontdoor; the Nemef Radaris Evolution. It has been a long-cherished wish to have a electromechanic lock and now we have one, with the Radaris Evolution as matching furniture.

The Radaris Evolution that was installed on our frontdoor is equipped with 2 RFID readers; 1 on the outside and 1 inside and also has a lever on both in- and outside. To access the Radaris Evolution you can use keyfobs, remotes or credit-card sized transponder cards.

The lock is a multi-point lock, which means the lock doesn’t just have a single dead bolt; this lock has 3 hook bolts. This lock certainly provides much more security than the one we had before because this lock is SKG ** security rated and also has the dutch police “safe living” hall mark. Free levers on both sides make sure the mailbox isn’t that much of a security issue anymore either.

It’s obvious that this lock has been designed with security and convenience in mind all the time; we’ve had an electronic lock before, but this Nemef is of a  different league; you just can’t compare those 2.

The Radaris Evolution is battery-operated and can be used with 2 AA alkaline batteries, or if you prefer a longer lifetime, lithium batteries of the same size. Alkaline batteries should be able to keep the Radaris Evolution working  for  a maximum of 5 years or 45.000 operations.

Now why is this Nemef Radaris Evolution so important to write about it on a Domotica related weblog? Well, more about the Domotica link later; I have to finish some things first!

Access granted

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tagged with:
Aug 02

This week I had some spare time to finally deal with some things that should have been dealt with a long time ago. Things like checking my backup and performing a restore, tuning various things in my Home Automation system, and all those other things you can’t (or don’t want) to spend time on too much, but that still have to be done sometime. One of those things is time synchronization; keeping all the machines running with the same time.

One of the worst performing virtual machines regarding time synchronization is my CentOS based firewall. I started using this firewall by converting a VMWare virtual appliance to Hyper-V with the vmdk2vhd tool and it has been running flawless ever since – but with 1 irritating issue: time keeping. 2 seconds per minute is a lot! And it looked like the issue got worse when I switched from Windows Server 2008 to 2008R2 in March of this year. Let’s fix this!

I’m neither a Linux nor a Windows expert – I like to think I used to be in the days where Windows 2000 and Linux distro’s like FC3 were considered up-to-date, but since then I gradually lost track of things, primarily due to the fact that I wasn’t spending enough time with these OSes anymore. I found other hobbys ;-)vi is a nightmare for me (on Linux I prefer joe, a Wordstar-like editor), just like I have a big dislike of the recent versions of Windows Explorer – on the other hand, I do know how to configure and use Apache, IIS, Postfix, MySQL and MS SQL Server and such.

So now I had to dig into something fuzzy as time synchronization: NTP, peers, offset, jitter, delays… OMG, why doesn’t it just work like it is supposed to? Well, it seemed the NTP server running on my firewall gave up on syncing very quickly because of the very large time shift of 2 seconds per minute, so I had to find a way to correct that and help the NTP server a bit. And as it happens quite often, I Googled for a solution to my problem and hey, I’m not the only one experiencing this, what a surprise!

Even the exact combination of Host OS and guest OS that I am using is mentioned a lot, like here for example. After reading some more pages regarding this issue it seemed I only had to do some small adjustments here and there and my NTP server would be fine:

  • Disabling Time Synchronization in the Hyper-V Integration Services;
  • Add the parameters “notsc divider=10” to the kernel line in grub.conf;
  • Add “tinker panic 0” as first line in ntp.conf;
  • Remove the lines “server 127.127.1.0” and “fudge 127.127.1.0 stratum 10” from ntp.conf;
  • Restart the VM.
According to the experts, this should do the trick and it did; like clockwork!
Jul 30

While I’m logging data and waiting for it to become substantial enough to test another project with, I thought it would be nice to kill the time and start building some new sensors: motion, temperature and light.

My goal is to monitor the complete second floor. For the 3 bedrooms I want to monitor motion, temperature and light. The passage will only require motion and light, while measuring the humidity in the bathroom would be nice too.

So, for that I need the following:

  • 5 * motion;
  • 4 * temperature;
  • 5 * light;
  • 1 * humidity.

I already have the motion sensors (PIR), the temperature sensors (1-Wire DS18B20), light sensors (LDR), enough JeeNodes, so all I need is a new humidity sensor.

OK; the amount of sensors I want to use is a bit too much for a single JeeNode I guess. Maybe 2 JeeNodes will suffice? I didn’t do any math on this yet, but I don’t think a single JeeNode can do the job all on its own. 2 JeeNodes maybe, cause the temperature sensors can be on a single 1-Wire bus, so those sensors won’t use up much ports on the JeeNode; and maybe I can use an Analog Plug to measure the LDRs? We’ll see. But for now, I assume I’ll need more than 1 JeeNode. However, I don’t like to spend an XBee module on each of those JeeNodes, cause I want to keep it relatively low cost. Yeah I know, there are cheaper alternatives for XBee..

But wait, I’ve still got an Arduino Fio; I’ve bought it sometime in January, not for a specific purpose but just to have a look at it, and I never found a good use for it yet. This Fio is also based on the ATmega328P and runs at 3.3V and 8 MHz. And it also has an XBee socket and USB connector. And it’s getting old, gathering dust on the shelf…

Now why don’t I use this Fio as a ‘hub’, or ‘central node’? It shouldn’t be too hard to make the (1,2,..) JeeNodes talk to this Arduino Fio over a few wires and use the Fio to transmit all the sensor values to the Zigbee coordinator; now that would be nice! I could power this Fio with a small USB power adapter and run a few wires (for power and serial connection) to the JeeNodes. Maybe I could just as easily use 1 JeeNode per room; this leaves enough ports available for future expansion… well, let’s think this one over for some time!

Tagged with:
Jul 26

Yep, today the old Doorbell has been removed and my new Ethernet Doorbell is in use! As you can see the white LED was on when I took the picture on the left, which means that it was dark outside at that time. By polling my Domotica system, the doorbell ‘knows’ whether it’s dark outside or not. Of course it’s not the doorbell itself, but the hardware behind it that does the ‘knowing’: a JeeNode with Ethercard.

All I had to do today was some soldering, finishing the doorbell sketch and pulling the UTP cable through the hole in the wooden door frame. Those last 2 items made it all take a total of 9 hours before I could actually say that the job was completely finished…

Using XMLRPC to communicate to my Domotica system was a bit too much for the 2 kilobytes of RAM on the ATMega. Strings like

<?xml version=\"1.0\"?><methodCall><methodName>GetDevice</methodName><params>
<param><value>DUSKDAWN1.DAYLIGHT</value></param></params></methodCall>

just to get the current value of a dusk/dawn sensor made the amount of free RAM disappear very quickly, so I decided to use another approach I already used some years ago. It hasn’t been used for some time, but it was still available and ready to use. Now all I have to send to my Domotica system is a

GET DUSKDAWN1.DAYLIGHT

and a Indy IdCmdTCPServer takes care of supplying the response. This saves a lot of RAM! Free RAM went up to 900 bytes again, where the XMLRPC method made RAM drop below 200 bytes. And an additional bonus: no need for XML parsing of the response ;-)

 

The picture below shows the hardware that’s making it all possible: a JeeNode, an EtherCard and a modified Utility Plug. The cable at the bottom goes to the doorbell, the yellow cable on the right goes to an Ethernet switch and the top right cable is the power supply.

 

And below the sketch that’s currently running on the JeeNode:

 

//
// Doorbell
//
#include <EtherCard.h>
#include <Ports.h>
#include <RF12.h> // needed to avoid a linker error :(
// ethernet interface mac address, must be unique on the LAN
//char website[] PROGMEM = "virtualxp.hekkers.lan";
char website[] PROGMEM = "domoticaserver.hekkers.lan";
static byte mymac[] = { 0x74,0x69,0x69,0x2D,0x30,0x31 };
static byte myip[] = { 192,168,10,75 };
static byte gwip[] = {192,168,10,60 };
static byte dnsip[] = {192,168,10,10 };
static byte hisip[] = {192,168,10,40 };
Stash stash;
MilliTimer DuskDawn;
MilliTimer HeartBeat;
byte Ethernet::buffer[600];
byte HP3=0;
byte VP3=0;
byte night = 0;
byte vnight = 0;
#define DDINTERVAL 60000  // 10 minutes = 600 seconds
#define HBINTERVAL 9000   // 1.5 minutes = 90 seconds
//
// LED & button related stuff
//
Port BlueLed (1);
Port Button (3);
Port WhiteLed (4);
int freeRam () {
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
void(* resetFunc) (void) = 0; //declare reset function @ address 0
void setup () {
Serial.begin(57600);
Serial.println("[Doorbell_01]");
Serial.println(freeRam());
if (ether.begin(sizeof Ethernet::buffer, mymac) == 0)
Serial.println("Failed to access Ethernet controller");
if (!ether.staticSetup(myip, gwip, dnsip))
Serial.print("IP address setup failed");
ether.printIp("IP:  ", ether.myip);
ether.printIp("GW:  ", ether.gwip);
ether.printIp("DNS: ", ether.dnsip);
if (!ether.dnsLookup(website))
Serial.print("DNS failed");
ether.printIp("SRV: ", ether.hisip);
ether.hisport = 8000;
// port 3 = doorbell button
Button.mode(INPUT);
Button.digiWrite(HIGH);   // pull-up DIO
// BlueLed = push LED
BlueLed.mode(OUTPUT);
BlueLed.digiWrite(0);
// WhiteLed = night LED
WhiteLed.mode(OUTPUT);
WhiteLed.digiWrite(0);
DuskDawn.set(1);
}
static void send_callback (byte status, word off, word len) {
Serial.println("<P<\r\n");
Ethernet::buffer[off+600] = 0;
Serial.print((const char*) Ethernet::buffer + off);
Serial.println("...");
}
static void poll_callback (byte status, word off, word len) {
const char* res = (const char*) Ethernet::buffer + off;
Serial.println("<G<\r\n");
Ethernet::buffer[off+600] = 0;
Serial.println(res);
if((res[0]=='R')&&((res[1]=='='))) {
night = (res[2]=='1')?0:1;
Serial.print("n=");
Serial.println(night, DEC);
}
if(res[0]=='E') {
resetFunc();
}
Serial.println("...");
if (night!=vnight)
{
WhiteLed.digiWrite(night);
vnight = night;
}
}
void PollDuskDawn(){
//return;
Serial.println("?");
byte sd = stash.create();
stash.println("DUSKDAWN1.DAYLIGHT");
stash.save();
// generate the header with payload - note that the stash size is used,
// and that a "stash descriptor" is passed in as argument using "$H"
Stash::prepare(PSTR("GET $H"), sd);
// send the packet - this also releases all stash buffers once done
ether.tcpSend(poll_callback);
Serial.println(".");
}
void SendStatus() {
Serial.print("P");
byte sd = stash.create();
stash.print("DB2=");
stash.println(HP3, DEC);
stash.save();
// generate the header with payload - note that the stash size is used,
// and that a "stash descriptor" is passed in as argument using "$H"
Stash::prepare(PSTR("PUT $H"), sd);
// send the packet - this also releases all stash buffers once done
ether.tcpSend(send_callback);
Serial.println(".");
}
void loop(){
ether.packetLoop(ether.packetReceive());
if (ether.clientWaitingGw()) return;
if (DuskDawn.poll(DDINTERVAL)) {
PollDuskDawn();
}
if (HeartBeat.poll(HBINTERVAL)) {
SendStatus();
}
HP3 = !Button.digiRead();
if (HP3 != VP3)
{
if (HP3) {
Serial.println("Button Pressed!");
BlueLed.digiWrite(HIGH);
WhiteLed.digiWrite(LOW);
SendStatus();
HeartBeat.set(HBINTERVAL);
}
else
{
Serial.print("Button Released\r\n");
BlueLed.digiWrite(LOW);
WhiteLed.digiWrite(night);
}
}
VP3=HP3;
}

That’s it! On to the next adventure ;-)

 

Tagged with:
Jul 03

Today I continued working on the Doorbell controller hardware & software. First I had to solder a Utility Plug, but I did it somewhat different than usual, I guess:

Utility Plug

(sorry JC, I seem to have some sort of “destructive” way of using your creations ;-)

The way I’m going to use this Utility Plug is not standard; the only reason I want to use this Utility Plug is to have a good-fitting RJ12 plug sticking out of the enclosure in a way that it keeps the whole construction as strong as possible. I could just as easily have glued a RJ12 Plug into the enclosure, but with the headers plugged into the carrier board I think I have a stronger construction than without the use of this Plug.

Since I will need to use more than 1 JeeNode Port (a button and 2 LEDs), I made sure that the Utility Plug headers were isolated from the Plug but were still usable construction-wise, so I cut all connections between the headers and the PCB, as can be seen in the picture above. Instead of using the headers, I soldered an Extension cable to the Utility Plug; this way I can do whatever I want with those 6 wires! After checking the header isolation with a multimeter and connecting the Extension cable wires to the JeeNode ports, I was ready to start writing some code. But first, let’s specify how this Ethernet enabled doorbell should behave. It should:

  • Periodically query my system and ask whether it’s dark outside or not and turn on the “night LED” inside the doorbell based on that. If the query fails, it should always turn on the night LED;
  • Switch on the blue “signalling LED” when the button is pressed; if the white night LED is on at that moment, it should switch that one off;
  • Switch off the blue “signalling LED” when the button is released; if it’s dark outside, it should switch the white night LED on;
  • Periodically send a heartbeat to my system;
  • Only send a “Doorbell pressed” message to my system once in a specific time-frame (1 second or so, to eliminate jitter).

I’m almost there! Most of these items are already working, but there are still some small issues to be resolved.  As always, the details take most of the time..

Tagged with:
Jun 26

The list of  devices in our house that need an Ethernet connection in order to work, just keeps on growing and growing. There was a time (some years ago) where I knew the IP address of each device by heart, but I gave up on that some time ago.. currently, my local DNS contains over 40 hostnames; just try to remember those (all of them!).

The number of switches keeps increasing too; currently I have 5 of them. And what is the most likely cause of a network going down? Right, a switch that stops working – this has happened to me twice now; and at both incidents the power adapter was the cause. So it seemed like a good idea to start tracking all those network attached devices, so that in the case of a dis-functional network it would become much easier to locate the root of the problem; at least, I hope so ;-)

Let’s start pinging all those devices! I found a nice Delphi unit that uses the standard Windows icmp.dll and the ICMPSendEcho function to ping an IP address and created an interface that would take care of periodically pinging all the Ethernet enabled devices and interfaces I had defined in my database and which were capable of replying to a ping.

The result can be seen here; a very basic page where I can see which Ethernet devices are on or off. Although ping is a very basic tool in itself, combined with a Domotica system you can do a lot of things with the information once you start logging them. I know the power consumption of most of the devices in our house, so now that I know when they’re being used or not, I can estimate their power consumption for example. Or I can issue an alert on the User Interfaces when the printer is on for more than an hour, cause in daily practice only a few sheets are printed and someone forgets to switch the printer off afterwards. Or I can send myself an SMS when a critical device stops responding to a ping. Or …

All new opportunities!

Jun 23

2 days ago the hardware for the doorbell controller arrived; a JeeNode v6, a Carrier Board, an Ether Card and a Utility Plug. After building the first 3 items on the day they arrived, I was ready to do some tests yesterday. I installed the latest Arduino IDE, the latest RF12, Ports and Ether Card library and hooked up the JeeNode to a USB BUB. I saw the RF12demo sketch appearing in the Serial Monitor; so far so good.

Let’s see if there’s an example sketch in the JeeLabs Ether Card Libary I can quickly modify for testing; yep, the getStaticIP sketch looks OK; I changed some IP addresses, the page to request on my web server and the request interval. I pushed a patch cable into the RJ45 plug, uploaded the sketch and bingo!

Ready! Hmm, no, not really. It all seemed to work perfectly, but after a while I saw strange replies in the Serial Monitor window and I could tell they didn’t belong there. These replies came at times where there hadn’t been a request for several seconds, so where was this reply coming from? I searched the code but couldn’t find out what the status code 3 meant that was returned with these strange replies. Hmm, I don’t like this. Just ignoring those strange replies was easy to do but it just didn’t feel right. There had to be something wrong; I mean, have you ever heard of a garbage filter on a NIC? Me neither.

I decided to dig a little bit deeper. The next morning, while on my way to the office, it hit me: the HTTP 1.1 protocol, doesn’t it use persistent connections by default? And does the connection get closed by either side after the reply has arrived? I checked RFC 2616 and I was right, so the first thing I did when I came home was checking my IIS logs and found the evidence for open connections being closed by IIS after a certain idle period:

192.168.10.203 3031 192.168.10.13 80 - - - - - Timer_ConnectionIdle

That could very well be the cause of those garbage replies I saw on the JeeNode!

Looking at the sketch I saw that the request didn’t contain a Connection:close header line. So my server did not close the connection.. after changing the request to HTTP 1.0, the behavior of the server changed and it closed the connection after sending the reply. This was also visible by the extra header line the server added to the reply: Connection:close. And guess what: the garbage replies no longer appeared and everything’s fine now. Now that traffic between server and JeeNode was clean, I could start working on the enclosure.

I disconnected the USB BUB, grabbed an enclosure and started cutting out holes for the DC jack and the RJ45 plug:

Doorbell controller in enclosureDoorbell controller in enclosure

 

 

 

 

 

 

With the enclosure almost finished I connected a 5V power adapter to the DC jack, put the patch cable back in and I saw the requests arriving at my server again. Perfect!

Doorbell controllerDoorbell controller: case closed

Tagged with: