Solar and power monitoring

We installed Solar a year ago. After digging through all the manuals and websites, unfortunately the technology inside inverters and battery chargers is still very primitive. At least 20 years behind what we’d consider modern functionality.

The battery chargers (from Midnite Solar) speak ModBus over Ethernet. The inverters (from Outback) spit out a lot of data over the network, but don’t allow any control via the internal network. Well, they do, but only via a proprietary protocol they don’t publish. It’s used by their hosted monitor/control website. If I could do just basic control (use/drop utility power, start/stop generator, use/charge batteries) via the network, I could build a significantly smarter system that would adapt to changes in solar production and power rates as well as weather predictions (make sure batteries are fully charged before a storm), but I’m stuck with a very clunky interface and features.

I also got a Rainforest smart meter device, which is a bit better. It gets information directly from my meter about how much I’m selling or consuming, which sends serial data via USB.

Putting all that together, wrote a ton of Python code on a Raspberry Pi to gather the current information from all the devices in the system, and using our power companies’ calendar of time of day rates, I display a current status of our power usage, which is displayed at the top of this post.

I also stash the gathered data in a database, so I can graph historical info as well…

This all works pretty well, it both hosts the information locally, and sends the graphs up to a hosted server, so I can view info when not at home.

I still want to come up with a better way to store the data outside of the Raspberry Pi, since the database will eventually fill the SD card, and SD cards aren’t the ideal medium for constantly changing data, so the card is eventually going to just fail. Probably a good winter project!

Closing the store for a while

With the big move also came a lot of work at my day job, and a lot of commuting. I did get the workshop built, and have built out a few projects: A security/sensor system driven by a Raspberry Pi, moving my weather station data gathering to Pi, and after we installed a solar array and grid intertie, put together software to monitor and graph and report on all that. Fun stuff, but haven’t written them up yet. Will be commuting less the 2nd half of 2016, and hope to be able to get back to hobby projects then. But, until then, here’s a picture of the new workshop. It’s big, it’s red, it’s a VoltBarn!

Back online soon!

Made a big move in 2014, moving full-time to Mendocino, CA. I have been working on planning and building a new workshop (the real VoltBarn!) for the past year, which has taken up all my recreational hobbyist time. Have a lot of things in the queue to work on later in 2015, once the workshop is finally done, hopefully by the end of February June 2015! But, here’s the workshop exterior as it has progressed so far…

SensorPack Wrapup

This has been sitting in draft mode for about 6 months, figured I’d just publish it in its current state, and improve when I get a chance. I’m now playing with a couple other receivers, one a handheld, battery powered version.

Putting together a kit with all the pieces for making a SensorPack, but didn’t get an Adafruit-quality how-to done, so never put it up in the store. Should just sell the parts, since everything is labled, no more challenging than a paint-by-numbers assembly.

The final bits for my overall SensorPack project isn’t really the sending hardware, have had that working for years in a couple incarnations. Polishing the software enough for others to work with is always a challenge, and is what put this project on the back burner for me. I did a lot more work on my various one-off display stations than I did on the SensorPack itself. I’ve built a variety of display stations, so decided rather than picking one project, I’d just detail the various projects I’ve built to display the resulting data, since they could actually be used to display data from any Internet of Things type sensing device.

This post is intended to put all the resources in one place, while I build out my “how-to” projects pages. This is draft one, will continue to work on it as I further refine the code and “how I did it” writeups.

I currently have 5 different ways of gathering/displaying data.

1) Laptop receiver

The most general purpose, is a bit of processing code that you run on a computer, with just an XBee receiver attached. It parses the output from any sensor packs in range, and (optionally) rebroadcasts their data, so it can act as a bridge, which helps if you have multiple receiving stations in the house, but have your sensor pack outside.

It provides the following features:

  • A primitive on-screen display of temp/pressure/humidty for any and all weatherstations in range
  • Can assemble and send XML POST messages to send to a webservice (I’ll document the Rails webservice elsewhere).
  • It will also update a WeatherUnderground weatherstation (you first have to set up an account with WeatherUnderground).
  • At one point, I had this also updating twitter accounts. After Twitter went to OAuth, I never reworked it for the new authentication mechanism, so I’ve removed all that code.
  • I also had it updating COSM, but they fairly regularly returned an error on update, which my processing code took as a reason to stop running, so the program would run for months unmonitored. 

Download the Processing code here (TBD)

2) Touch panel display

This is a really simple setup, it uses five easy to assemble components:
– An Arduino
– A Protoshield (optional)
– An Adafruit Touch Shield
– An XBee shield
– An XBee (you have many choices, a great one from Adafruit many options from Sparkfun)

Download the Arduino code here

Simply follow the instructions to put together the Touch Shield, then attach the XBee shield to pins 2&3 and power, and the install the code. This program will automatically receive messages from any in-range SensorPacks, and will then display information for the first 4 that check in. It also will display a clock, and can turn the display on and off depending on the time of day. For clock functionality, project #1 will send out time packets every minute automatically, or you can figure out a different method.

The code was really challenging to get working, since with the Touch Shield library, and serial library for talking to the XBee, you have VERY little space left for user programs and data, but this has been pretty stable for me. Do note that if you tweek the code, and it breaks, it’ll tell you in random ways. Usually by the display doing weird things, or the Arduino spontaneously rebooting. A real bear to debug.

3) 4 display Serial LED

This is probably the most adaptable designs, but probably the worst written code. It was my first try at a receiver, and I never did a cleanup, whcih would have been an re-write. As written, the software supports 4 LED displays, but you can use less than 4 with no issues. Building is also pretty simple, you can use any Arduino you want, 1-4 serial LED’s, an XBee shield and an XBee. An optional protoshield could make things a lot cleaner, I’m still running my first version I put on a tiny breadboard and tossed in a project box.

It also supports a clock in one display, and an on-board temperature sensor, and a light sensor to dim the LED’s based on ambient light. I have mine set up with one LED displaying time, one the internal temperature, and the other two rotating through temp/humidity/pressure for two different SensorPacks.

Components:

Download the Arduino code here

4) Big clock

This was a fun project to design and build. It uses these really big LED’s I got from Sparkfun. I liked the look so much, I designed a circuit board to hold the shift registers, and make wiring up the LED segments MUCH easier than on a breadboard, but the code obviously doesn’t care how you wire it all up, it just sends data to the shift registers.

The challenging part here will be wiring everything up in the right order so the LED’s display the right information. It’s going to need it’s own more detailed tutorial, but I include it here now for completeness. If you are comfortable with Arduino coding and wiring up shift registers to LED’s, you shouldn’t find it very difficult to get working.

5) An Android device

This was mostly an exercise in learning how to write a non-trival Android app, but I actually use this more than any other method for checking on my sensors. I have it working well on my Droid Razr, and on my Nook Tablet, which I hacked with a Honeycomb OS port.

Unfortunately, ICS changed how XML parsing worked in an incompatible way for me, and my code stopped working. Requests went out, but the returned XML was no longer parsed. I spent several days trying to figure out how to rework it, and then got bored with it all. I left my Nook and Razr as Honeycomb devices, so I have two working displays. So, I’m not bothering to link to the code here, since it won’t work on a newer version of the OS.

I’d accomplished my real goal, writing a non-trivial Android app. I was disappointed in the vast differences in the evolving ADK though, so decided to wait a couple major revisions for Google to stop making incompatable changes from version to version. As a spare-time hobbiest, I just don’t have time to rework my code every major release.

Station display improvements

I now have the real-time station display working almost perfectly. It can be read on my Android running Nook from across the room, indicates which items changed since the last refresh, along with increase/decrease indicators, and the old value. Only thing missing at this point is wind direction, but I get the information in different formats from WeatherUnderground and my VoltBarn Sensor Packs, so need to do a bit of parsing/normalization. But, this does what I wanted to get done with the Nook, a usable weather display station for all the stations I have scattered about in one spot, and that spot can be anywhere from a house to the pub to the train. Plus, with the multiple views, you can see the consolidated info for all the added stations, an attractive set of gauges, or a highly readable display station.

Next big Android/Weather Station feature

As always, its the magic behind the image that is the cool part here. A constantly updating display screen, inside the basic applications framework. The new bits here are that the screen runs as a separate intention, scrolls between all the loaded weather stations (check out the screen indicator at the top). It auto-updates the screen every 30 seconds. A few optimizations remain, like only updating the surrounding screens, and cancelling the update timer when the app is in the background. There’s no need to get the info for, and update screens that aren’t adjacent to the current screen.

I’ll be building a landscape version that I can read from across the room on the tablet. Will probably display the wind speed and direction graphically, but the other values are probably best seen via text. Gauges are pretty, but not really readable from a long distance, unless you’re not showing the full information available.