Growatt inverter monitoring with Raspberry Pi

At home we have a small (2.5KW - 10*250w panels) PV system to try and offset our daytime electricity usage. This is connected to a 'Growatt' inverter that handily has both RS485 (wierd 2 pin plugs) and RS232 (9 pin D connector buried under a screwplate) outputs.

With the firmware on ours (installed Sept 2013) it supports modbus-rtu over serial 9600 8N1.

I had done some initial digging and experimentation (as announced on Whirlpool) but never really got sensible values out.When my guruplug (via a long USB to serial adaptor) finally died and I shelved the whole thing. With the completion of the structured wiring though I finally got round to reconnecting it and starting again.

Blue serial cable attached to structured wiring.

Small D9 Gender changer, + cisco console cable (all hail fleabay) gives a nice neat look on the outside, and in the garage I have another console cable plugged into the relevant patch outlet and a cheap usb-serial adaptor in a Raspberry Pi (which also has a GPS module connected, acting as a PPS NTP master)

Anyway, in the intervening time, someone had worked on my hacky scripts and wrapped the posting to PVoutput in an exec(curl) call -- first up I ripped that out and swapped for python requests.

I then went through the growatt modbus guide and made sure that it correctly calculated high and low byte values where these are split. The resulting script can be found on github,  and todays output can be seen on pvoutput. - a couple of charts are duplicated below.

Todays output v insolation prediction

As you can see, we had a couple of clouds going overhead today, so only generated 13KWh  vs 13.7 yesterday. Also the pvoutput fields are somewhat vague - 'Voltage' I've chosen to upload the array DC voltage rather than the grid AC volts (actually, I upload that and the grid frequency as extended data), and 'temperature' - I'd ideally like to have the panel temperatures, but upload the inverter temp so I can see if it's getting toasty. These can be seen on the 'all info' plot below

The observant of you will notice that the Etoday figure was slow to take off - this is because I didn't RTFM and discover that it's uploaded in watts, not kW...

Update 2016-02-08

If you pulled an early version of my code, please grab a new version - I realised the total lifetime generated (and any other 2*2word values) were off as I was doing thing[1]<<8+thing[2] and it should be thing[1]<<16+thing[2]. Ahem. 

The new version also just runs once in the background rather than being called from a cron entry every 5 mins, - it still publishes every 5 mins to pvoutput, but publishes all the messages (in json format) onto my message broker (MQTT) so I can draw a spiffy html5 canvas + websockets graph of whatever I fancy from 

solar/json {"Status": "Normal", "Etotal": 8705.3, "Tinverter": 46.1, "Pac1": 305.1, "ttotal": 32957749.5, "Vac1": 242.1, "PV1Curr": 1.1, "Etoday": 14.4, "Iac1": 1.3, "Pac": 305.1, "Ppv": 339.0, "Fac": 50.02, "PV1Watt": 339.0, "Vpv1": 303.8}

It also monitors the status, and if it changes to 'Fault' it'll look up the fault code and send an alert via pushover. 

Low-Level hardware hacking

In our 3 shiny new computer rooms (supercompute, IO, Tape - Each with slightly different environmental and cooling requirements), the architects have fitted a single temperature sensor on the back wall. Out of the airflow. This isn't giving us a terribly accurate picture of the supply air going into each rack, and so an alternative DIY method is underway.

A Raspberry Pi in each room (small, low enough power that it can be fed from PoE via a splitter) acts as the local 'head' and grabs the data to send it to a central message broker. From there, we can choose what to do and how to display it.

The sensor hardware consists of: A single DHT22 attached near to the Pi - As useful as these are on an arduino, on a R-Pi they are a bit harder due to the need for timing. The Adafruit interface for these grabs directly from memory address and seems well, a bit hacky. As suggested on IRC, a proper kernel module may be helpful. hint for someone else to complete :-)

The main sensor array is a set of DS18B20 sensors from fleabay (cheap if you're ordering 50 at a time) attached to the sheepwalk i2c interface 'RPI2'. These are then strung around to suit depending on location (ie, for our watercooled racks I'm going to affix the sensors directly to the flow/return lines on the watercooled racks to give us the delta-T across each set of door radiators (The BMS only gives flow/ret temp overall) which when tied to the internal temp sensors in the back of the racks should give us an idea of how well we're shifting the heat away from the machines. All this hardware comes in at less than 100 AUD per room - and some soldering time to make up the sensor chains to suit. To get an idea of the stratification (and therefore how do we position floor tiles relative to the overhead extraction vents) I'm going to put 15-20 sensors on a piece of plastic waste pipe to get a nice vertical profile - cue trip to bunnings (local DIY store) later this weekend.

Software

Hat-tip to the excellent MQTT people - nice n simple to use a python publisher script to send to a mosquitto broker on the lan. From there we can republish to Xively (useless as it doesn't respect timezones in the plotting so I can only see data I sent 8h ago...), Google spreadsheet (in a refactor of the original adafruit idea, and currently to a simple python curses console

Once we go into production and kit is running properly I plan to use the broker for all the machine status info and we'll dispatch accordingly for alarming.

More info and code will appear at https://github.com/ivecops/EnvMon

Metering Musings

I've been intermittently trying to get our smart metering datafeed out to to a server for better logging, but I don't want to run a 300W PC to tell me my baseload in the house is 300+N W. There are several clamp meter / arduino designs thanks to the folks like OpenEnergyMonitor and Nanode, but things should be easier as there's a nice serial out already documented by ERDF (there's also the upcoming 'linky' interface but we're still on old-school)

How much does all this malarkey cost -- off the shelf there are USB opto interfaces, but they're about €50 each (erk) I originally purchased an arduino datalogger shield (€40 + an arduino) hoping to use it with a nanode, but I  didn't get ethernet sending working (even after the slight hardware mod) - possibly due to known issues with stash depletion

So - where do we go (cheaply) from here? a R-Pi gives me cheap hardware with more stable ethernet but I'd have to interface in the opto tty interface (gpio? usb?) as there's no onboard serial. Plan B is to use my bifferboard and use the console interface: small, yep. Low power, yep. Decent ethernet and OS (openwrt) - yes.

So, time to order some parts and get down to prototyping...

apcupsd via Python to Pachube

In python, the 'default' URL accessing toolkit (urllib2) doesn't support PUT, however I've discovered requests which a) does and b) is in Fedora. So one apt-get install python-requests.noarch and you're off.

So - one trivial script (reusing much of the code for my MQTT variant) you get https://gist.github.com/1903259. The only minor niggle was working out how to prepend the minimum extra json content (version and datastreams) as I'd not used the json libs before. (Hmm yet another github toy - embeddable gists with syntax highlighting. Nice) Update now I have 24h worth of data - plot attached

Teleinfo update

I''ve been using a teleinfo shield on a nanode to try and datalog our electricity usage, but the logging to the CSV file kept truncating as if the arduino had locked up. There have been discussions elsewhere that this may be related to the code in arduino 1.0 so I decided to rewrite a step at a time to try and debug the problem.

Some observations on the way:

1) having to flip a jumper over on the shield between programming and run is *very* annoying in a cold garage, so I'm going to rewire it slightly to use SoftwareSerial on a spare input (leave JP1 open and wire from one side of it to a spare pin) - I already have a link since the shield tries to use DIG6 by default which is used by the red LED on a nanode.

2) the arduino IDE doesn't like anything other than 8N! on the serial monitor. close it and use kermit. if you can't read serial with kermit, then it's *very* broken :-)

3q) our usage is going UP not down :-( -- lowest figure I managed to get the baseline to was 340VA

With a very simple logger

    Serial.print(char(meter.read()));

I can stream the output to a kermit session log as

^B
ADCO 040222048573 <
OPTARIF BASE 0
ISOUSC 30 9
BASE 040912359 ,
PTEC TH.. $
IINST 002 Y
IMAX 029 J
PAPP 00340 (
MOTDETAT 000000 B^C

next trick is to try and get the processing organised into blocks and validate the checksum, but my code doesn't seem to detect the stx/etx properly

void loop() {
if(meter.available()>0) {
  if((c = meter.read()) == 02) {     // start of block
    Serial.println("DEBUG: Start Loop");
    while((c = meter.read()) != 03) {      // Loop until end of block
      Serial.print(char(c));
    }
    digitalWrite(LED, LOW); // Flash LED
    delay(50);
    digitalWrite(LED, HIGH);
  }
}
}

so mode debugging called for. Once thats done, then I'll send the values to an emon style display over rfm12b

Metering

So I finally got round to wiring in the 'Teleinfo' shield into my EDF meter (see my earlier post for more info) and left it running while we're away. Hacked up an initial couple of graphs using trusty gnuplot: exhibits A and B -

It's rather easy to spot where the fridge-freezer kicks in, but more worrying is the fact that the baseline never dips below 170VA. The only things that should have been running in that time was my via-eden server, with one HDD, the livebox and samknows monitoring box. I suspect I need to investigate more.

Made a minor hack to the shield as digi-6 is used by the LED on a nanode - but digi-7 is free.
Details were tweeted over here. Next up is to get it sending the info out to main box (well, another nanode or my bifferboard) and spitting to pachube and / or a jeelabs display board.

EDF metering and 'Tele-Info'

Just discovered via some google-fu that we have a Sagem C1000 series meter in the house, which includes

* Interface de télé-information client permettant le raccordement à un système de gestion d'énergie

so, with a bit more googling I discovered that it's 1200 baud, 7 bits one stop. and lo - there's even an arduino shield already made for it!

--- update ---
Have discovered that there are many hacks around to parse this teleinfo - some of which need a licence fee (!!!) and do fancy things like export to bdpv.fr

Sample of the data stream is at http://www.planete-domotique.com/blog/2010/03/30/la-teleinformation-edf