This concludes my little gadget to track home energy use and solar energy production:
The graph shows production vs total consumption in 15-minute intervals for the last 5 hours. A summary of this infomation is shown at the bottom: “+” is total solar production in the last 5 hours, “-” is total energy consumption in that same period.
The actual consumption values are not yet correct because the home energy pulse counter is wired incorrectly, but they will be once that is fixed. The total home consumption is currently 1327 – 1221 + 7 = 113W, since the home counter is currently driven in reverse.
The graph is auto-scaling and I’m storing these values in EEPROM whenever it scrolls, so that a power-down or reset from say a battery change will only lose the information accumulated in the last 15 minutes.
Power consumption is “fairly low”, because the backlight has been switched off and the radio is turned off between predicted reception times. The mechanism works quite well when there is a packet every 3 or 6 seconds, but with longer intervals (i.e. at night), the sketch still keeps the receiver on for too long.
A further refinement could be to reduce the scan cycle when there are almost no new pulses coming in – and then picking up again when the rate increases. Trouble is that it’s impossible to predict accurately when packets will be skipped, so the risk is that the sketch quickly goes completely out of sync when packet rates do drop. The PLL approach would be a better option, no doubt.
But all in all, I’m quite happy with the result. The display is reasonably easy to read in daylight, even without the backlight. I’ll do a battery-lifetime test with a fresh new battery once the pulse counter wiring has been fixed.
The code has become a bit long to be included in this post – it’s available as homeGraph on GitHub, as part of the GLCDlib project. I’m still amazed by how much a little 200-line program can do in just 11 KB of flash memory, and how it all ends up as a neat custom gadget. Uniquely tailored for JeeLabs, but it’s all open source and easy to adapt by anyone.
Feel free to add a light sensor, a PIR motion detector, an RTC, whatever…
Onwards!
Can you please post a tutorial on using the graphic LCD? Nice work by the way.
Any proposals or ideas for a housing (preferably precut for the display)?
Enclosures are my big honking weak spot. I’ve looked into this several times in the past, never found a solution to my satisfaction (not just one-offs, but something which can be provided in the shop), and so I never got anywhere meaningful with it.
One day, I’ll figure it out. And trust me, it’ll be all over this weblog when I do. Suggestions always welcome.
How about a NEMA 4X stainless steel box with a cutout machined in the front for the display readout. These are weather tight and very durable. I’ve had some experience with mounting readouts in these with a mounting bezel or frame with pem nuts and a rear cross-brace. My background is mechanical design, machining and some sheet metal work with a side order of small-scale wind turbines. Shawn M.
A metal box will hamper RF reception, though.
Perhaps an enclosure like that used on a wireless router made from ABS, polyethylene, or similar plastic. Does it require an antenna? if so is it internal or external requirement? Is weather tight a requirement?
Have you considered putting something in the code to estimate time/date? count the number of sleep cycles and add it to a time variable? then upload a table to the flash memory from NASA or something with estimated sunset/sunrise times for the next 20 years?
Then it all boils down to how accurate are the timers from sleep mode in seconds/minutes off per year? if its less than 8 minutes per year, you would be pretty safe doing this. However, you are better with the sleep stuff than me.
Hmmm, another interesting idea… I wonder if having multiple microcontrollers in sleep mode (thus making them less accurate as a timer), all sending a “time update” packet – making them be off less time wise locally, could be used to get real time more accurately by using an average value of those “time update” packets to get a “real time” packet to send out to all of the nodes to be used for something more official where time is important. I mean, if one is running slower, and one is running faster (for whatever reason, temperature, chip manufacturer, flaw in clock crystal) Multiple nodes could be used to get a better, average number where imperfections on a single node would matter less.
Hi
Would you save more power, by letting the homegraph-device send a packet to the counter-device, asking for an update. That way you dont’ have to listen every 3 seconds at night (this might require an RTC to wake it up again) ?
Yes – but then (what is now) the transmitter needs to be in receive mode all the time. In this particular case, it would indeed be possible – in general, I tend to look for solutions where as much as possible can become battery-powered.
Maybe you can save some power by only turning the display on when someone is actually looking at it? Most smartphones have a proximity sensor that turn the display off when you hold your phone near your your ear, maybe you can implement this the opposite way?
Indeed. I was thinking of a PIR motion sensor or even simpler, just an LDR to only display things when there is enough ambient light. You could even add a separate light to this, such as a cheap reading light operated by a switch, to still allow reading at night. Just like paper books: add light to use ’em!
Lots of ways to go here – which was really the whole purpose of this project: to stir up some thoughts and ideas. I’ve got this things sitting next to me and besides being informative it’s now also a constant reminder of the need to take it further.
What about an “exponential backoff” for missing packets?
Yes, but… when you increase the time slot, you also have to increase the amount of time to listen, because the uncertainty increases accordingly. This definitely needs to be looked into, but I suspect that it’ll be a complex mix of trade-offs.
Nope, as long as you wait for a packet longer than the normal interval (since you normally send every 3s, I said to wait for a packet for 4s). Maybe you’ll lose the first packet(s), but as soon as you receive one, you’re locked in and start receiving every 3s.
Say display reached MAX_SLEEP (1h) during night.
05:00:00 display tries to receive (4s)
05:00:04 display returns to sleep
05:00:05 (!) missed first packet of the day
here packets continue coming every 3s…
06:00:05 another missed packet
06:00:06 display starts listening again
06:00:08 packet arrives while display is listening (interval reset to 2.8s!); receiver turned off as soon as packet is received
06:00:10.8 display starts listening again
06:08:11 packet arrives
You can mitigate desyncs due to missed/unsent packets by waiting 2-3 times before starting backoff (so the first missed packet isignored and doesn’t do anything to ‘interval’; the second is like the first; the third and the following double ‘interval’ and maybe make the listening time every time a bit longer).
You can expect being some millis out of sync after one missed packet, twice that after two, but once you listen for more than 3s you’re sure to catch a packet if it got transmitted)
Ah, ok, now I get it. Indeed, that’s a good way to get back on track once packets start coming in.
Hm, there’s clearly a lot of tricks one can play with all this. The other thing I’ll probably add soon is a once-a-minute time of day broadcast, for nodes to get a sense of time if they want it (this node would also be listening, so it can also act as a “service” for instant querying).
Same for sunrise/sunset calculations. The task will be to come up with a simple yet flexible setup. I don’t want everything in one node / point of failure, but I also don’t want hundreds of nodes each doing one trivial thing.
Maybe we could start thinking about generating and uploading code for a whole set of nodes. Wait two days please, for some news which could become quite relevant to this…
for enclosures: have you considered 3D printing? You can design one with http://www.blender.org/ or http://ayam.sourceforge.net/ (which has a Tcl interface and BSD licence) and either let it 3D-print by a companies like Shapeways or buy/get an Open Source printer like Ultimaker. You can then print if someone orders it. It also would be interesting, for some enclosures to incorporate the antenna in the enclosure, making it possible to use more advanced antenna designs.
I’ll be looking into this. Have a MakerBot here, but it’s not up to a good finish in its current state, and it still needs too much hand-holding, so not quite practical yet. But hey, more and more options on the horizon.