Or “How to build a portable self-powered, self-licking ice cream cone.”  😀

Several years ago, I started building what I referred to affectionately as a self-licking ice cream cone: a Renewable Energy (RE) system that powered the same IoT system that monitored it. I’ve given several talks about this system, both its hardware and its software stack, and there are so many useful (and scalable) lessons I’ve learned that I really enjoy sharing. Still learning those lessons too, btw.

Recently, Stephen Chin asked me if I could put together a portable RE IoT system to demo in the MakerZone at JavaOne this year. If a picture is worth a thousand words, a fully-built and on-premises demo must be worth at least a million, right? The idea intrigued me. Could I create a 100% fully-capable representation of a (my) real working system that would be small enough to transport to conferences and meaningful for attendees to see? Yes…yes, I thought I could.  🙂

It has been a lot of work fun!

There is much to tell, but we’ll stick to the high points for this post. More to follow.

Hardware List and Related Observations

For the portable configuration, here is the hardware I used:

• One (1) 50W, 12V photovoltaic (PV) panel, bought via ebay
• One (1) Cyber 250 wind turbine
• One (1) 18Ah 12V deep cycle battery for energy storage and IoT system power
• One (1) sheet of Lexan cut to size and edged, courtesy of Regal Plastics in St. Louis
• One (1) Raspberry Pi, case, SD card, & wifi plug adapter – this serves as the IoT gateway device
• One (1) 5V DC voltage regulator, allowing me to step down the 12V battery output to the 5V required by the Pi
• One (1) Arduino Uno R3, solderless breadboard, combined mounting board – this represents an IoT endpoint
• One (1) Adafruit INA219 high-side DC current sensor breakout
• One (1) Virtuabotix DHT11 temperature & humidity sensor
• One (1) 4 channel DC 5V relay to control physical devices
• One (1) LED case cooling fan
• One (1) interior/dome light to represent building interior lighting
• Two (2) running lights to serve as loads for two RE inputs/charge controllers
• Two (2) solar charge controllers**
• One (1) 12 position terminal strip/wiring block
• Numerous (?) solder joints, wires, and cables

** I was able to use solar charge controllers for both solar/PV and wind inputs because the wind turbine I selected produces 12V DC power (vs. the AC power output of many turbines) and has a blocking diode to prevent overspeeding, and thus turbine damage. These charge controllers also have load connectors, to which I attached lamps to maintain loads on the inputs, further reducing potential for overspeeding.

This configuration closely follows my permanent installation at my house, albeit at a much smaller scale. For transportability, I’m using only a single 18Ah 12V deep cycle battery instead of several larger-capacity 12V deep cycle batteries wired in parallel to form an energy storage array. And input sensors have been reduced from a full weather station providing temperature, humidity, rainfall, wind speed & direction, ambient lighting, and atmospheric pressure readings to (for the demo system) temperature and humidity. Power readings are comparable for both systems, although I’m using a separate INA219 sensor on the demo system vs. integrated power sensors in the permanent system’s weather circuitry. And my portable system has no actuators to open windows in my power-generation building like my permanent system does. Since the demo system is fully visible to viewers, there was no need to configure a camera for visual observation/checks as I did at home. In actuality, there are few substantive differences between my 24/7/365 production system and this portable demo. 🙂

One nice feature of this portable rig: as configured, it produces far more energy than it consumes, even with a fan providing the “wind” and venue lighting providing the “sun”. Power won’t be a problem.

Software and Related Observations

The software stack for the demo system is nearly identical to that of the production system, with minor changes being made to accommodate the minor differences in attached sensors and physical devices.

I developed software for the Arduino microcontroller to run in Autonomous Mode using sensible defaults, turning on heat when ambient temperature inside the power-generation building is too low, turning on a cooling fan when it’s too hot, and opening windows on opposite sides of the building when temps climb and no rain is present (no windows in the demo config, of course). The Arduino represents an IoT endpoint that regularly (1x/second) polls attached sensors, assembles their readings, and sends them “upstream” to the IoT gateway. It also processes any inputs received from the gateway and acts accordingly; if it receives a command to switch to Manual Override, the software then accepts and processes any subsequent (validated) commands from the gateway until directed to resume with Autonomous Mode.

For the IoT gateway, I used Linux and Java SE Embedded to create a secure and standards-based stack. Raspbian Linux allows me to use utilities like ssh and vnc and to set up startup scripts for the demo config…and since it ships with Java SE Embedded, I have easy access to developer tool support and libraries for everything from RESTful web services to Websocket, which I use for system/cloud communication. I used the JSSC (Java Simple Serial Connector) library to create a wired connection from gateway to endpoint, Pi to Arduino, establishing a reliable comm link within the remote IoT system.

IoT systems are great! But without a way to communicate with, control, and harvest meaningful data from those systems, their usefulness is severely constrained. To unleash the full value of an IoT system, you need the cloud. I used Java SE, Spring Boot, and Spring Cloud OSS to do the heavy lifting with an HTML5/JS user interface, all running on Pivotal Cloud Foundry. I’m still tweaking and expanding it (in my copious spare time 😉 ), but it’s effectively feature-complete…and with only minor differences (to accommodate the sensor/device differences) between the permanent and demo systems.

And…action!

More to Come

Come see me at JavaOne! This will be up and running in the MakerZone all week, so stop by to see it and chat with the crew there. If you have any questions, comments, or feedback of any kind, please ping me on Twitter at @MkHeck or leave a comment below. Hope to see you there!

Keep coding,
Mark

Related Posts:

• Nighthacking Interview: Jfokus
• Spring Boot for IoT Developers: Getting Started
• Adding Solar/PV to A MANAGEABLE Renewable Energy System
• Quick & Dirty How-to Guide: Install GlassFish 4 on Raspberry Pi
• Getting up & running quickly with Spring Cloud Sleuth

Renewable energy (RE) has long been a passion of mine, but practically speaking, it simply hasn’t been cost-effective to implement at a personal level. Factoring in credits, location, type of RE, etc. can often tip the scale, but generally speaking, an investment in RE would require more commitment than simply “running the numbers.” No judgment here, I understand and appreciate both sides of that argument.

In recent years, though, things have changed. Not entirely, and not across the board even now…but with inexpensive (yet quality) RE equipment being produced in the US, China, and many locations throughout Europe, one can begin to experiment with RE on a much smaller scale and determine if/how it makes sense for your particular situation.

As a software engineer, I also work to integrate whatever I build into a more manageable, usable system. Physical computing promises many things, which I’ll coarsely lump into the term “better living” – but to do it right requires more than just assembling some hardware. The intersection of devices with software and the greater internet results in what is often termed the “Internet of Things”, or the IoT…and this is where the potential for “better living” can skyrocket, if things are properly integrated. It’s a small and limited example, but how much more useful is a fully-integrated system that is easily managed from anywhere on the planet than a complex system composed of numerous components…all of which must be monitored individually and manually?

For this post, we’ll focus solely upon one small portion of that integrated system: adding PV, or photovoltaic (solar) panels to a functioning small-scale RE system. Before these additions, the system consisted of:

• Wind turbine
• Deep-cycle battery bank
• Arduino to control sensors, radio transceiver
• Temp/humidity and current/voltage sensors
• Radio transceiver, primarily for comm link to send readings

Now we’re adding a solar charge controller and initially, two 25W solar panels wired in parallel for a total of 50W maximum.

In future posts, I hope to elaborate on the software side because (as stated above) that is where the difference truly lies. For now, here are some pictures (and a very short video) of the PV addition:

Connecting the PV Panel

Mounting the PV Panels to the Backing Board

Initial Two Panels Mounted

Simple Wire Terminals on PV Board

Charge Controller Mounted, Not Yet Connected

Charge Controller Mounted AND Connected!
The “Sun” light indicates power from the panels;
the “Battery” light flashes while charging attached batteries.

And finally, a short video to give a glimpse of the PV portion of the system in action:

In future posts, I plan to provide more information about the “good stuff” (teaser: JavaFX, Java Embedded Suite, more Arduino, BeagleBone Black, wireless management, and more!), but a system must exist before it can be monitored and managed. As we continue to “build out” the system, those opportunities will only increase. Stay tuned, and please feel free to comment below or drop me a line. Thanks for visiting!

All the best,
Mark

Related Posts:

• Building a Portable, Self-powering, Cloud-Connected IoT demo
• Join Us at JavaOne 2014!
• Quick & Dirty How-to Guide: Install GlassFish 4 on Raspberry Pi
• Nighthacking Interview: Jfokus
• Spring Boot for IoT Developers: Getting Started

If you’ve worked (or played) much with Arduinos, you’ve probably run into “dead pins” – or wondered if you had. How can you tell which pins, if any, are unusable on an otherwise perfectly good board?

There are probably more precise ways of determining what is wrong, and perhaps even ways to repair some defects…but for those of us embedded folk who work far more with software than hardware, this is a quick way to confirm which pins don’t work properly with sufficient precision so you can label the board and move on. To quote Steve Jobs, “Real artists ship.”  🙂

To test digital pins, you need to test both pinModes: INPUT and OUTPUT. (There is also INPUT_PULLUP, but that is only relevant if using the internal resistors vs. external ones.) I created two sketches, one to test pins with a call to digitalWrite() to light up connected LEDs, and one to read a switch using digitalRead(). Those are the software components necessary, and they’re available at my ArduinoPinTests GitHub repository.

The hardware portion of the test can be easily assembled as well. Here are the items I used; feel free to substitute similar components as desired:

• Solderless breadboards (2, one for each: input & output)
• LEDs (6)
• Resistors, 220 Ohm (6) (for output test board)
• Resistors, 10k Ohm (2) (for input test board)
• microtivity IM211 push-and-lock switch (for input test board)
• Necessary wires to put it all together

It has been said that a picture is worth a thousand words. Here are two thousand for you!

Digital Pins (In) Test Board

Digital Pins (Out) Test Board

The Bottom Line

If you have pins you think may be dead on your Arduino or clone board, grab some spare parts, visit my GitHub repo, and within minutes you can find out if/which pins are out of commission and get back to configuring devices and pounding out code. Now…back to business!

All the best,

Mark

Related Posts:

• Building a Portable, Self-powering, Cloud-Connected IoT demo
• Adding Solar/PV to A MANAGEABLE Renewable Energy System