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!

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.

 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

]]> http://blog.hekkers.net/2011/11/22/hydronic-balancing/feed/ 12 http://blog.hekkers.net/2011/07/30/something-old-and-something-new/ http://blog.hekkers.net/2011/07/30/something-old-and-something-new/#comments Sat, 30 Jul 2011 21:22:09 +0000 Robert Hekkers http://blog.hekkers.net/?p=2136 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!

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

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

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:

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!

Today I finished modifying the doorbell with which I started yesterday. I drilled a 4.5 mm hole through the back of the doorbell and led a solid core CAT5 cable through that hole. This cable will be used to connect the doorbell switch and the 2 LEDs (a white and blue one) to the Jeenode that will be placed in the fuse box which is only 2 meters away. The legs of the LED were bent sideways right there where they come out of the LED housing and these legs were temporarily glued to the doorbell housing to secure the position of the LED for easy soldering. You can still see some residue of the glue (the white blur on the housing surface) where the legs of the right LED touch the doorbell housing.

To get a good insulation from the outside world, I pushed the cable through the hole, put hot glue on it and pulled the cable back  a few millimeters; this should suffice for proper insulation. After the wires were cut to the right length and soldered to the legs of the LEDs, it was time to check if everything was working. So I put the 2 halves of the doorbell housing on each other, pressed them firmly, and put the other side of the wire on a breadboard. With a 5V power supply, two 330 Ω resistors and a multimeter I convinced myself that everything was OK.

BTW, it’s a good thing I didn’t choose red as one of the colors for the LEDs; otherwise, a visitor might think he’s being held at gunpoint by a sniper with laser sight In other words, the LEDs are a bit too bright, so I think I’ll use a higher resistor value in the final version – that’s why I left the resistors out of the housing in the first place, cause I was anticipating “tuning” issues like this.

Well, now that I have verified that the doorbell is working OK, I can move on to the next step: the JeeNode, some more hardware and the software that goes with it!

So here’s the most important requirement: the new doorbell should always work. Besides that, I wanted the doorbell to have a distinctive ‘click’ as physical feedback and if possible, also a visible feedback for the person standing in front of our door pushing that doorbell button. Last but not least, the visitor should be able to find the doorbell while standing in front of the door while it’s dark outside. A white LEDs should be able to do just that.

I bought a wireless doorbell once, thinking I could remove the wireless part and just use it as a simple switch . But I was wrong; the button and wireless part were too much integrated for me to do something useful with the PCB that was inside. This wireless doorbell cost me about 30 euro, the looks were OK and I didn’t want it to end up on the shelf with all the rest of the things I’ve bought but never used. Sounds like a good opportunity for some DIY

I removed the PCB from the doorbell, glued a piece of experimenting board into the doorbell and soldered a PCB switch on top of the board:

Fits perfectly. With this switch you get instant feedback on whether the switch sensed your push because of the audible and tactile click, you can both hear and feel it very well. As visible feedback for pressing the button I decided to use a blue 3mm LED. This LED should cooperate with the white one, which should take care of night visibility: resulting in a blue indicator above the button when it’s pushed, and a white indicator while it’s dark outside.

While working on the new interior of the doorbell, I decided to use a JeeNode with EtherCard to control it all, thereby creating my own Ethernet-enabled doorbell. Why? Because I can!

To be continued.

Some characteristics of the A3214:

• 2.4 to 5.5V battery operation
• minimal power requirements
• pole independent switching
• small size

How small is small??

Allegro A3214

The magnet (upper left) measures 3x3x3 mm, the sensor dimensions are 4 x 3 x 1.5 mm. Yep, that’s really small

First thing I did yesterday, was putting this sensor on a breadboard and connecting it to a JeeNode. I wrote a small sketch that used LED2 of the Bridge Board to visually show the status of the sensor output:

#include <Ports.h>
#include <RF12.h>

Port one (1);
Port four (4);

void setup() {
  one.mode(OUTPUT); // LED2 of Bridge Board is connected to Port 1 Digital.

  four.mode(INPUT); // the sensor is connected to Port 4.
  four.digiWrite(HIGH);  // enable pullup
}

void loop() {

  one.digiWrite(four.digiRead());
}

It worked, wow! Moving the magnet towards the sensor made the LED go off (the output is high when the magnetic field isn’t strong enough), moving the magnet away made the LED go on again. The distance between sensor and magnet when the output value changes is approx. 10 mm.

Today I wanted to do some power usage measurements, so I changed the sketch a bit:

#include <Ports.h>
#include <RF12.h> // needed to avoid a linker error 
#include <Sleep.h>

#define DEBUG 0

int INTpin = 3;
Port one (1);

volatile boolean wdt_expired=0;

// Interrupt Serive Routine that will be executed when the Watchdog Timer expired.
ISR(WDT_vect) {
  wdt_expired=1;
}

//****************************************************************
// 0=16ms, 1=32ms,2=64ms,3=128ms,4=250ms,5=500ms
// 6=1 sec,7=2 sec, 8=4 sec, 9= 8sec
void setup_watchdog(int ii) {

  byte bb;
  int ww;
  if (ii > 9 ) ii=9;
  bb=ii & 7;
  if (ii > 7) bb|= (1<<5);
  bb|= (1<<WDCE);
  ww=bb;

  MCUSR &= ~(1<<WDRF);
  // start timed sequence
  WDTCSR |= (1<<WDCE) | (1<<WDE);
  // set new watchdog timeout value
  WDTCSR = bb;
  WDTCSR |= _BV(WDIE);
}

void setup(void)
{
  pinMode(INTpin, INPUT);
  digitalWrite(INTpin, HIGH);

  one.mode(OUTPUT); // LED2 of Bridge Board is connected to Port 1 Digital.

  #if DEBUG
  Serial.begin(9600);
  #endif
}

void loop(void)
{
  #if DEBUG
  Serial.print(millis(), DEC);
  Serial.print(" I'm awake, caused by ");
  #endif  

  if (wdt_expired==1){
    wdt_expired=0;
    #if DEBUG
      Serial.println("the WDT");
    #endif    

    // Do something, like sending a heatbeat
    // sometimes

  }
  else
  {
    // External interrupt triggered!
    byte val = digitalRead(INTpin);

    // disable LED during power measurements
    //one.digiWrite(val);  

    #if DEBUG
    Serial.print(val, DEC);
    Serial.println(" INT0");
    Serial.print("Doing some serious stuff now...");
    #endif    

    // measure awake
    delay(5000);

    #if DEBUG
    Serial.println("finished!");
    #endif
  }

  //
  #if DEBUG
  Serial.print(millis(), DEC);
  Serial.println(" Sleeping...");
  delay(100);     // wait for serial to finish
  #endif                        

  // go to sleep and wake up
  // on watchdog or IRQ pin change
  setup_watchdog(9);
  Sleep.powerDownAndWakeupExternalEvent(1, CHANGE);     // sleep function called here
}

That’s very good… I’m sure this power usage will be good enough to live on 1 set of AA batteries for a long time.

Of course, Door & Window sensors is the most obvious application for these sensors. But the small size makes me wonder if I can come up with more useful ideas…

On to the next step!

After soldering the row of pins that will be pushed into the breadboard, I wanted to see what it was going to look like. I took a random breadboard and immediately saw something was wrong here.. I’ll never be able to connect the JeeNode to the Bridge Board ?! This is strange; this being a design flaw was out of the question of course, so I took another random breadboard. Now the Bridge Board (better: the breadboard ) dimensions are correct! Just look at the horizontal white line across the Bridge Board; this should be in line with the outside of the breadboard:

The cause is quite obvious: not all breadboards are equal in size (click the images for more detail). The left breadboard that fits perfectly has a width of 54.2 mm while the breadboard on the right, which is unusable in combination with the Bridge Board, measures 64.5 mm. Well, this is something I never realized before: even breadboards with the same amount of tie points can have different dimensions. So much for standardization…

So if you’re a potential Bridge Board user, watch out what breadboards you buy.