On my desk i have a JeeNode, equipped with a Pressure sensor. This JeeNode is also controlling a XBee Series 2 module which is configured as Zigbee End Device. All this is battery powered. Calculations on power usage of the JeeNode+Sensor+XBee are good enough to expect an acceptible battery life. A Sparkfun XBee RS232 holds another XBee module, configured as Zigbee coordinator. This setup has been operating for more than a week now. It all looks stable enough to go ahead and connect the Zigbee network (ok, it’s only 2 nodes right now ) to my Domotica system and actually do something with it; something different from logging the incoming pressure data to a text file and reviewing this file periodically to see if everything is still up and running; so i added another (the 16th) interface to my Domotica system: Zigbee!
In fact all the hard work had already been done in an earlier stage where i created an API-mode interface for Zigbee; in essence, the only thing left to do was making this interface ‘talk’ to the rest of the Home Automation system, add some records in the database for this new sensor type and write a routine that would convert the incoming packets to the measured values of temperature and pressure.
Wow! It’s great to see my first Zigbee based sensor really working! The pressure data is being stored in the database, so in a few hours i can start creating an additional web page to show a pressure chart… and here it is!
BMP085 Pressure sensor data
Next on the list: finding a suitable, small housing, making a light sensor, a motion sensor, humidity sensor, … the list is to long!
Now that i have 2 JeeNodes up and running for more than a week and everything’s working fine, it’s time to do some calculations on power usage of the sensors. First thing i wanted to know was how much power a combination of a sensorless Jeenode and XBee module was using, so i created a sketch that would give me some ‘inside’ information about what was going on inside the Jeenode. The sketch i made informs me about a couple of things, like:
- the timespan the JeeNode is awake to power up the XBee, send a packet to the XBee and wait for it to finish transmission;
- the timespan the XBee is powered to send that packet of 10 bytes.
With these numbers i should be able to roughly calculate the power usage of this sensor. The power that is used by the JeeNode while it’s awake is about 35 mA, while the XBee uses around 40 mA while transmitting. When both the JeeNode and XBee are in deep sleep, the combination of both uses only 60 μA.
The time measurements i did to find out the timespans mentioned above gave me the following figures: the total time the JeeNode is awake to read a sample from the Pressure sensor, wake the XBee, transmit the data and go back to sleep is 40 ms. The time that the XBee is awake is around 25 ms. With a sample interval of 30 seconds, and a 2000 mAh battery, i have calculated a battery life of more than a year; increase the interval to 60 seconds (still good enough for this type of information) and batteries should survive more than 2 years… i think.
Just ask me in a year or so ..
But good enough to go ahead with the expedition!
I like to automate things… but sometimes it just doesn’t work out as planned. Today my power usage counter reached it’s maximum value and started counting from 0 again.
I knew this would happen some day, i thought i had it all covered in my Home Automation system, but it didn’t work out as planned; i had to fix some power usage records in the database today. The charts looked like complete garbage!
In my system i keep detailed information about every piece of hardware i use and how it is being processed. The hardware that i use for counting the Wh pulses contains a counter of 3 bytes, ranging from 0..FFFFFF hex (0..16777215 decimal); that’s 16777 kWh.
So what did i do a long time ago to prevent a counter rollover from giving me work that i don’t want to do? I created a ‘counterbits’ field in my database where i can store the number of bits a countervalue is based on. With this it’s easy to calculate the maximum counter value to expect. So far so good.
Whenever a countervalue is received with a smaller value then the previous one, the ‘counter rollover protection’ mechanism starts working.. it calculates the (additional) offset to be used based on the ‘counterbits’ field, adds this to the current value of the ‘counteroffset’ field in the database and this new counteroffset value is added to the value that was received. No need to do anything; complete automatic counter rollover recovery.
But don’t mess up your database resulting in a counterbits value being set to zero!!!
Then it won’t work… so despite all effort, today i had to browse the tables with the historical data and fix some values… and wait another 2-3 years to enjoy having this automated…