Category Archives: Domotica

Bedroom floor lighting

  By Robert Hekkers | January 22, 2012 - 23:45 | Domotica
1 Comment

Last week I had some trouble getting out of bed during the night without hurting myself. So this evening I decided to do something about that; I need something that can light the floor while someone is walking through the bedroom at night. So I made a list of things with which I could make something useful for that:

  • An Arduino Duemilanove;
  • a Protoshield;
  • 2 PIR motion sensors;
  • a LDR;
  • a  IRLZ34N MOSFET to drive the LED strip;
  • a 12V power adapter;
  • about 2 m. of white LED strip;
  • 2 LEDs (one for power and the other for motion detection);
  • an Arduino enclosure.

 

Automatic Bed light for the night

There it is… our automatic bedroom floor lighting is being tested at this moment. The 2 PIR motion sensors will be mounted under the bed in a way that they will only be able to detect motion caused by moving legs, the LDR will be used to detect whether it’s dark in the bedroom or not and the white LED strips will be glued to the bottom side of the bed and will light the floor when motion is detected.

The fun thing is that this floor lighting is almost completely built from spare parts (except the enclosure). The 2 PIR motion sensors were the first motion sensors I ever bought, but the lenses were too big for my taste to actually use them. Under the bed the size of those lenses doesn’t matter. The Duemilanove is one of the many Duemilanoves I have laying around for testing/experimenting, so I can easily do with one less – I could also have picked an RBBB, Teensy or JeeNode. The number of unused protoshields made me decide for an Arduino. And all the other parts were all purchased in the past with the thought they’d be handy to have around for when you suddenly need them ;-)

No RF, Zigbee or Ethernet this time – this will be a solution that doesn’t need any other external input, nor do I think I’ll use the fact that someone’s walking through the bedroom in the rest of my system. Nevertheless, I’ll reserve some space on the Protoshield for a XBee Breakout board cause this would actually be a very good place for a Zigbee router on the 2nd floor!

The sketch will be a collection of code  from other sketches I’m already using, so I hope that at the end of this week I can finish this and never hurt my toes again ;-)

Nemef Radaris Evolution and Homeseer

  By Robert Hekkers | January 15, 2012 - 23:05 | Domotica
3 Comments

Last summer I became the proud owner of a Nemef Radaris Evolution electronic door lock. It’s in use for 6 months now and has been unlocked almost 1800 times. In that period of 6 months, the Nemef Radaris Evolution has proven itself as a really solid and reliable piece of equipment. I’ve never seen nor heard of a better solution (no, I don’t work there). If I would have written a full scale review about the Radaris Evolution, the conclusion would have been  ”Highly Recommended” – but since I don’t do reviews, you’ll have to do with just the conclusion ;-)

Combine the Nemef Radaris Evolution furniture with a Nemef RF Module and you’ve got all the the ingredients to fully integrate the Nemef Radaris Evolution door lock(s) into your Domotica system. However, that’s where things get harder – as far as I know, there’s no (consumer) software available for the connection between the Nemef Radaris Evolution and Home Automation systems. No Plugin, module, app or anything like that to monitor and/or control the Nemef Radaris. Only 3 guys (I know of) have implemented this in their own homebrew system; Pieter Knuvers is one of them.

But this can change very rapidly; I’m working on a Homeseer Plugin for the Nemef Radaris Evolution.

Homeseer Plugin screenshot

 

 

With this Plugin (and a Nemef RF Module (dutch link)) it will be possible to monitor and control up to 4 Nemef Radaris Evolution (dutch link) door furnitures. Opening the door, badge management (yep, you can stow away your programming card), viewing historical data (what badge was used where and when), it’s all in the Plugin. Want to give a badge access only during a certain time period on a certain day? The Nemef Radaris Evolution Plugin and a small script can accomplish just that.

The basis of the Plugin is almost finished now; I already tested the basic functionality by feeding my own historical data to the Plugin and this looks just fine.

Now it’s time to provide the necessary event triggers to Homeseer, so that the Nemef Radaris Evolution door furnitures can really become a part of that bigger picture, called Home Automation. ;-)

 

Energy flow in Watt

  By Robert Hekkers | December 8, 2011 - 22:01 | Domotica
7 Comments

Now that I have sensors on all the radiators  I can sit back, relax and watch everything happen. I needed some help of the rest of the family to keep the doors upstairs closed, cause that seems to be very hard for some, but after a few days they all knew that when the doors were closed, daddy was doing one of his experiments again.. yep, this house is one big laboratory ;-)

However, doing nothing is not really my style, so I went on reading about radiators, calculations etcetera and found some calculation tools for my RADSON Compact and Jaga Tempo radiators. And although it doesn’t add new data, I thought it would be fun to see if I could use the formulas used in these ‘Installer tools’ (in fact Excel sheets) for myself.

And I was right; based on radiator model, dimensions and specific properties it should be possible to calculate the actual heat output performance of the radiators in other circumstances (temperatures) . If you know the heat output conform the European standard EN442 (dutch) for a specific combination of model & dimensions, the so called n-factor (aka the emission line slope) and the air-temperature, you can calculate the heat output for any combination of flow- and return temperature!

So that’s what I did last evening – preparing my system for these semi-realtime heat output calculations.

First I had to add some more flexibility to the database; creating fields for this purpose only didn’t feel right, so I added a free text field in which I could ‘dump’ anything I want – device specific properties. As an example, here are the properties of one of the radiator devices in my system (it feels like ‘Domotica system’ doesn’t quite cover the capabilities anymore):

TYPE=RC
QN=1407
N=1.3404
TAIR=BATHROOM.TEMP

This means this device:

  • is of type RC (as in Radson Compact), 
  • has a heat output of 1407 Watt, based on its dimensions and EN442 at 75/65/20 °C (that’s flow, return and air temperature);
  • has an n-factor of 1.3403;
  • and that the air temperature can be taken from the device value called BATHROOM.TEMP (a foreign key, so to speak)

So every line defines a device specific property, which are dynamically added to the base device class at run-time.

And I had to write 2 Delphi functions to do the math, primarily based on these formulas:

Q is the variable that needs to be calculated, the rest is all known – piece of cake!

Just make sure you take care of unexpected results, like divisions by zero or raising negative values to a power- working with live data can produce strange results, where a radiator can suddenly start cooling instead of heating :-)

I added the calculated heat output (the “W” column) in the table with all the other sensor data as can be seen below:

real-time calculated radiator heat output

Cool! Although these heat output numbers are based on pretty accurate formulas and properties provided by the manufacturer, the real-life numbers will probably be lower. Dust, bad airflow caused by windowsills and such will always result in deviations. How much? Dunno…

RF to Zigbee gateway

  By Robert Hekkers | December 2, 2011 - 18:00 | Domotica
9 Comments

The last piece of missing hardware is finished. The picture below shows the 2nd RF to Zigbee gateway I had to make to be able to receive all the Hydronic balancing sensors I made earlier this week. One of those sensors just couldn’t make it through 3 walls all day long, so I created  a temporary solution on a breadboard to solve this.

A very simple yet effective way (for me) to get the sensor data where I want it (in my Domotica system) with minimal effort.

The JeeNode acts as a RF receiver and just echoes everything with a valid CRC to the Digi XBee; from there it eventually arrives at my Zigbee Coordinator with which I can communicate over TCP/IP.

The JeeNode runs a slightly modified version of the RF12Demo sketch made by Jean-Claude Wippler. I used the NewSoftSerial library to create an additional Serial port, and added a few print statements for the XBee port, right there where the RF12Demo Serial.println()’s the received RF data to the Serial port. Compile, Upload, setting the RF band,  group- and node ID and I’m done!

This JeeNode is powered by a 5V USB adapter and the XBee gets its power from the 3.3V JeeNode ports. The XBee uses a Zigbee End Device AT firmware (2864) with the Sleep Mode set to Pin Hibernate. But because pin 9 is wired to GND, this means that the XBee is permanently on.  Only 3 wires are needed to connect the XBee to the JeeNode: 3.3V, GND and a JeeNode digital pin to the XBee DOUT.

That’s it – moving on with where this all started with: understanding the flow of  heating energy in our house!

HB sensors finished and installed

  By Robert Hekkers | November 29, 2011 - 23:29 | Domotica
5 Comments

Almost ready to start investigating hydronic balancing (HB) … ;-)

 

 

 

 

 

 

 

 

 

 

 

 

Everything is in place and working except for 1 sensor, which is too far away from the receiving JeeNode (which forwards all the data to my Domotica system). So I’ll have to build another RF receiver for that; the missing parts will arrive tomorrow I hope. In the meantime I started creating a webpage to display all the information I want to observe, so I don’t have to switch between browser tabs and go from one page to the other. Another thing that has to be done is program the thermostat, so that the boiler will have to burn at full power for a few hours every day, so that I can see what happens.  I’ve already seen some things that need to be adjusted!

 

It’s them floats again..

  By Robert Hekkers | November 24, 2011 - 00:10 | Domotica
Comments Off

I keep a close eye on a lot of things, including my own Domotica system. Not just things like empty batteries in the sensors, but also the software behind it all. Things like exceptions that occur, memory usage, cpu usage and stuff like that. It keeps me informed about the ‘health’ of it all, so I won’t end up with a system with lots of memory leaks or other nasty bugs scattered throughout the system; and which will be much harder to find once it crashes due to not enough memory…

Yesterday I saw something strange happening to the memory usage:

Memory usageImmediately after I upgraded my system, memory usage started to increase to values that I had never seen before. It’s always a straight line with a variance of +/- 2 KB after 24 hours of up-time.

Strange, cause all I had done was adding a few lines of code to support the hydronic balancing sensors; nothing exciting actually. I checked if all objects were destroyed after use; nothing wrong. I did a restart; same thing happened again. The only thing the code had to do was calculate 2 temperatures out of 4 integer values; what could be wrong here?

Digging a bit deeper I saw these messages in the logs, a few per hour:

Exception:Database Server Error: SQL State: 01000, SQL Error Code: 3621

Not very self-explanatory either, but it was evident that something was wrong here. Again strange, since SQL Server has been running without any problem since I use it; that’s 5 years! I looked up the SQL command that triggered this error response and there it was… a string value of ’0.689999999999998′ was written to a fixed-length field and it didn’t fit!

But where does this ’0.689999999999998′ come from? Working with floats of course!

The 2 temperature values are each calculated by dividing a word (2 bytes) by 100; this results in a float with a maximum of 2 decimals (duh). But by storing these 2 temperatures in float variables and subtracting those 2 (to calculate the temperature difference), the result of 28.06 – 27.37 wasn’t 0.69 but the error triggering 0.689999999999998…

Of course, I know this and I should have anticipated on that – I forgot to round the result of the subtraction to 2 decimals!

Hydronic balancing

  By Robert Hekkers | November 22, 2011 - 22:36 | Domotica
12 Comments

This weekend I came to the conclusion that whatever I do, I’ll never get a well performing central heating without hydronic balancing. I’ve been watching how the temperatures in all the rooms of our house react and where the energy goes to – it’s a mess! No matter how well I’ll be able to control the kettle, temperature control in all the rooms will still be a mess without a hydronicly balanced system.

So this weekend I decided to stop what I was doing (building the Opentherm Gateway) and first try to do something about this balancing issue.

Hydronic balancing is not something I’m familiar with, and I certainly don’t have the tools for it ; but what i can do is provide enough information with these sensors; I don’t know if I’ll succeed, but it’s worth to give it a try.

Sensor for Hydronic balancing The first thing I need to know is how much energy flows through the radiators. Well, I can do that, I guess… A JeeNode with RF transmitter and 2 1-Wire DS18B20 sensors can provide me information about how much energy each radiator produces by measuring the flow- and return temperatures of each radiator.

I’ve got a bunch of JeeNode kits still waiting to be used, enough 1-Wire sensors, batteries and all other components needed, so what am I waiting for??

So this weekend I built a first sensor and a RF-to-Zigbee ‘gateway’ so I can receive all the sensors without the need of USB, RS232 or an additional Ethernet port.

The first sensor is operational now; more will follow!

Red = flow temperature, Blue = temperature drop

Sending notifications

  By Robert Hekkers | November 17, 2011 - 20:38 | Domotica
2 Comments

Yesterday, late in the evening, I saw an intersting post on the Domoticaforum; airox added  (among many other things)  a way to send notifications from his Home Automation system to Android devices by using the Notify My Android (NMA) platform. Hey, that sounds interesting; I just had to check it out today!

After registering and generating the first API key, I could start sending my first notification. The API is simple to use, and the code I had to write for my (home-brew) Domotica system was too:Delphi code for using NMA

 

I installed the NMA App from Google Market on both my HTC Desire HD and my Asus Transformer TF101 and sent my 1st notification. Cool! Now I can choose between SMS, Notifications and email, and send more messages to my phone than I currently do. For example, I send a SMS to my mobile every time the doorbell rings, cause I like to know about deliveries of new goodies :-) Some other, less important events, are sent by email. Now a third option is available, which looks really cool, if I may say so ;-)

 Notify My Android

 

 

Controlling the radiators is not enough

  By Robert Hekkers | November 12, 2011 - 23:32 | Domotica
7 Comments

This is the next episode in the never ending story to get a good central heating; not just in the living-room, but in all the rooms; and totally integrated in my Domotica system. Today I received a box full of parts; diodes, resistors, capacitors, a PIC – 33 different parts in total.

A pile of parts

These parts will be used to build this Opentherm Gateway. I think most people who have ever searched for a way to control their Opentherm controlled central heating system will already know the site I referred to, cause it pops up really quick in the search results of any search engine – it’s one of the scarce good resources that are available when you want to integrate your central heating system into your Home Automation system.

But why do I want to control my central heating system? Do we need it, since we’ve already got Radiator Thermostats on all the radiators in our house? Yes we need it, and I’ll explain why.

The biggest “problem” we’re facing is that we have  a single thermostat that’s controlling the central heating right now, and this thermostat is in the living-room. The influence of the sun on the temperature in the livingroom is huge. Today, with a reasonable amount of sunlight, the 6 m2 of glass on the south side of the livingroom result in producing enough energy to warm up the living-room to a temperature above the thermostat setback. That’s good, very good, and we want to keep it that way of course! But the result of this free energy is that our central heating system stops burning around noon, as you can see below (showing the in- and outgoing water temperature of our boiler):

Central heating behavior

The central heating hasn’t been burning from approx. 13:00, cause there was no need for it anymore. There’s no need to explain what happens to the rooms on the 2nd floor; they all cool down, and there’s nothing I can do about it.

Another problem is that the temperature of the water which flows through the radiators, isn’t high enough for the radiators to radiate enough to heat up the rooms upstairs during the time that the boiler does burn. The result of all this: even if we’d want to, the temperatures upstairs will never reach more than 19° Celsius. We don’t need those higher temperatures, but that can change – and it will.

So how can I change when and (more important) where the central heating pumps energy into our house? I decided to give my Domotica system a role in this. The Opentherm Gateway is part of the solution. More about the ‘how‘ later….