ESP8266 | brainwagon

Previously I had written up a bit on my project that I have called my “solar satellite station.” I used quotes around the word “solar” in the title because for the past couple of months, it has mostly been sitting on my workbench in my garage, occasionally powered up by a 12V charger rather than the sun. My hope is to get it out into the sunshine fairly soon, but that’s rather waiting on a couple of changes to the software. Most importantly, it consumes rather too much power than I would like which I suspect is that it runs continuously, even though it samples the data (temperature, pressure and current) only periodically. If I utilized the deep sleep mode of the ESP8266, chances are excellent it would reduce the power consumption by a factor of ten or more.

But that is a post for another day. Today, I thought I would bore you with graphs from the data that I’ve been logging. Currently I have detached my charger, so it has been running from the battery power (a 7.2Ah lead acid battery, if you haven’t been following along). First, the temperature in my garage:

It’s not exactly warm in my garage, but it is south facing, so when the sun comes up I get about a 10 degree boost in temperature.

The skies were clear last night, but we are expecting some rain today (indeed, it’s already begun) and we don’t have much sun today, so I would expect it to be a bit chilly. On to atmospheric pressure:

Pressure has been dropping pretty significantly over the last 24 hours.

This was sensed with the MPL3115A2 sensor from adafruit. This is about as significant a drop as I’ve seen in recent memory. The prediction is that we are going to see three or more inches of rain in the next couple of days. Neat.

Now, onto power and current consumption. I have separate INA219 voltage/current sensors monitoring the lines to the solar panel as well as the battery. The “solar panel” in this case is currently an unplugged charger. As you can see the current is zero amps, so the battery is not being charged at all. The voltage has dropped by about half a volt in the thirty six hours or so that the graph spans. The voltage is actually pretty much equal to the battery voltage, since the charge controller has a common positive between the panel and battery circuits. Power is the product of voltage and current, and is of course zero as you would expect.

Moving on to the battery side of things:

The battery side indicates the total consumption of all elements of the system. You can see that it’s average about 74 milliamps at 12.65 volts, or about 936 milliwatts. This is the combined consumption from the charge controller and its inefficiencies, as well as powering the two ESP8266 (one is still being used as a serial bridge for debugging) and all the various I2C sensors. If we call that 1W, then we can estimate the total capacity of the setup pretty easily. The battery is a nominal 12V at 7.2Ah, or 86.4 Watt/hours. That means that we’d discharge the (large and rather heavy battery) in under four days. Since I really want the battery to be discharged no deeper than 50%, a couple of days is probably all it can really take.

I know I can do better. Currently it’s maintaining two processors, each with their own WiFi connections. If I removed my debugging one, power would immediately drop by half. And I really need to get back to using deep sleep mode. I prototyped a deep sleep version of the code that just sent temperature, but I haven’t worked on deploying it yet. I also want to shift to using my own MQTT server. Perhaps we’ll get to it this weekend. Until then, I’m off into my garage to cut up boxes for the recycling bin. Have a good weekend, all.

This weekend I mostly did work on further organization and cleaning of my garage workshop. This included taking out the old dog door and cutting a plywood cover to block it up, putting up a monitor mount so I could hang a new $80 22″ HDTV that I could use as a monitor, and then some general cleaning and organization of four shelving units.

But as I finished, I thought I would go back and try to understand the issue with my solar project. When I had taken it in from the outdoor location, it seemed to go off line, and no longer connected to the Adafruit IO service that I have been using. I suspected that I knew what the issue was, but today was first time that I could sit down and actually debug it.

The problem arises because of the haphazard way I cobbled together the code that runs on the ESP8266 module. It begins (in its Arduino setup() function) by probing for the existence of all of the I2C sensor modules that are installed. When I first coded this up, I wanted it to check just so I could be sure that the peripherals where installed and accessible via the bus. Thus, if it didn’t detect the peripheral, it printed a warning message and then entered a dead loop, where the watchdog timer would force a reset.

Of course, when the module is deployed in the garden, this isn’t especially useful. As I coded it, the check occurs even before the WiFi network is initialized, so no message gets sent. This also prevents the system from being able to be reflashed with an OTA update. Not a good state of affairs.

This was the state when I sat down at the workbench today. I could have simply hooked the ESP8266 module up via the USB to my laptop and worked on debugging it that way, but I had a new technique available, so I decided to use it. I had a second module programmed with the esp-link software (as I described in a previous posting) so I was able to monitor the boot messages.

What I discovered was that the MCP9808 temperature module was not being found by the I2C bus probe. To help with debugging, I decided to write some code that would try to probe all available I2C addresses, and print out a nice table of all the peripherals it found.

What it revealed was that the MCP9808 was actually being detected at address 0x19, whereas the default location was 0x18. The module does have three address pins to allow you to change its address, but according to the schematic, it has resistors in place that should pull the address low.

I’m was confused why it was acting as if A0 is pulled high, but I decided to just install a jumper to tie it to ground. And, boom! Booted right up and started to log data again for the first time in a week.

So, it’s working (after a fashion) but it does spawn a bunch of new tasks for me to work on for the next few days.

First, why did I need to tie the address pins explicitly low? Never seemed to have to do that before. It puzzles me, and I’d like to resolve it.
Rewrite the application. In fact, I’ve already begun on this. The biggest change is that it’s much more forgiving about the absence of peripherals that it expects to find. Notably, it connects to the WiFi network first, and only then does it start to probe the I2C network and take telemetry measurements. It’s also careful to ensure to process messages related to the Over The Air (OTA) updates, so that if I do need to update the software, it will be listening for the updates.
And while we are at it, I think it’s time to stop using Adafruit IO’s MQTT server. It’s a good, quick and easy way to get started, and allows you to setup a quick dashboard, but there are a number of problems that make it less than ideal. In particular, it doesn’t support retained messages properly, either in the client side or on the server. I have installed the mosquitto server, and will eventually move to that instead. I have decided to shift to the PubSubClient library which also appears to work with SSL and provides the retained message support that I like.
The current version is rather overactive: it records telemetry once a minute and pushes it to the servers. In between, it’s running, just busywait-ing in a loop, on the off chance that it receives a request to update its firmware. The new version should update telemetry at a longer interval, and use deepsleep to lower its power requirements in between.
The current version of the software is one-directional: it just sends telemetry to the broker. But MQTT is a bidirectional protocol, and it can receive information from the broker as well. I’ve tested this a bit, and envision it be able to send new configuration messages to the sensor.
In particular, we can use retained messages to set the “mode” of the sensor. When the sensor wakes up, it will receive a retained message from the broker indicating what mode it should be in. If it is in battery saving mode, it does a read of all its sensors, sends them to the broker and then goes to deep sleep to save energy. If the mode was “wait for update”, then it can enter a loop where it stays alive, waiting for a firmware update.

That’s about it for now. Stay tuned for more (and eventually code on github).