No sooner had the Enphase Envoy been installed, I started exploring the web server installed on it. The Enphase Envoy uses your home wireless to send its data back to the cloud. You should be able to see the device on your router and find out its IP address. Connect to it using a browser to see the web pages that it serves up.
The normal pages have some basic info but the interesting stuff has been described in thecomputerperson blog. Have a look and do go past the blog into the comments. That is where some of the most interesting information lies.
One gold nugget was the call to get panel level information. The URL is http://[ip address]/api/v1/production/inverters
. If you try that on a browser, you are prompted for a user id and password. The user id is envoy
and the password is the last 6 digits of the serial number for the Enphase Envoy. The response is a JSON document listing each panel and their outputs. The values are the serial number of the panel (serialNumber
), the timestamp this information was last updated (lastReportDate
), the device type (devType
) which is always 1, the power last reported (lastReportWatts
) and maximum power ever reported (maxReportWatts
) - not sure how far back it goes - since last power up?
[ { "serialNumber": "121XXXXXXXXX", "lastReportDate": 1555658860, "devType": 1, "lastReportWatts": 1, "maxReportWatts": 297 }, { "serialNumber": "121XXXXXXXXX", "lastReportDate": 1555658777, "devType": 1, "lastReportWatts": 0, "maxReportWatts": 297 }, ... ]
The next step was to write a java (my go to language, ironically without a go to) program to query it frequently. Based on the results, it looks like
- Each micro-inverter updates its power output every 5 minutes
- They all update at different points in time
- As the sun sets, the output of the micro-inverters drops. It eventually hits 0 and after that stops updating. The timestamp stops changing after this.
- If there is no new data from a panel, the same data is sent out with each response.
- Once darkness falls and all the micro-inverters have fallen silent, the same data is sent out with each response till sunrise the next day.
With 32 panels in my array, pointing in different directions and few with shade issues, it would be useful to see the output of each panel over a nice sunny day. And one of the crucial issues with data is how to visualise the data, emphasising the features that you consider important. So much data and only two eyes to look at it!
One great visualisation approach I had stumbled on in the past was frequency trails (also referred to as ridgeline plots or joy plots). I saw this on Brendan Gregg's blog. He uses it for system performance. I decided to use this technique to display the performance across panels. Not having the patience to find, install and run software that might be used to display plots like these, I decided to code them from scratch using first principles. Using SVG in a browser seemed to be the best way to go about this. I have dabbled in SVG before - which is why I thought this was the way to go. The other option which I did not want to take on was D3 and that uses SVG as well. So I dove into an SVG tutorial and used that as a guide.
The java program queries the Envoy every 3 minutes. This ensures that it does not miss an update for any panel. It keeps that last response for each panel and checks if the latest response updates the timestamp for any of the panels. If it does, that is a new data point. It gets written into a text file. Every half hour the SVG file is rewritten with any of the new data. A new data file and SVG file is started for the new day at midnight. The SVG file is actually an HTML file with the SVG embedded in it. Leave it running for a few days and you end up with a data file and an SVG graph for each day.
The panels have been named and they are references in the graphs. Each panel is colour coded based on its orientation. A couple of them are under eaves. To keep a closer eye on them, they have slightly different colour. On a nice sunny day, the graph looks like this.
As the sun rises, N9-N13, N21 are the first to spring into action. The other north facing panels are slightly shaded by trees on the horizon. By 11 AM, most of the panels are generating except for N24, N26. These are shaded by the eaves and don't start generating till 1 PM. By this time, W32 has already started to shut down. It is shaded by some trees and it does not take much for it to taper off. The whole lot W27-W32 suffer from shade problems and don't seem to do the job expected of west facing panels. N21 is a real workhorse - first up at dawn and keeps on going till dusk. N10 generates the most power.
The peak power and total energy for the panels are on the right. Only 1/3 of the panels reach the max of 290+ W but every panel including W32 cross the 200 W threshold. The best energy output is 2 KWh. Almost every panel puts out at least 1 KWh except for W31 and W32. W32 is the runt of the litter at 0.66 KWh. The west facing panels W14-20, W27-29 do better than the east facing panels E6-8. The graph for a cloudy day looks like this.
A cloudy day seems to be the great equalizer. It brings most panels back in line. The shaded W31-32 manage fine but the shaded N24, N26 don't. Looks like shadows from a tree branch actually matter less on a cloudy day but solid shadows do. Here is a comparison of the panels for a sunny and cloudy day.
This graph shows both the relative output of the panels and the impact of cloud. It does hold a few surprises. Not all north-facing panels are good, west-facing panels are OK but some are affected by shade in this case. The shadow of the eaves is a problem and it gets worse on a cloudy day - so much so that its output drops below the usual worst performer. Cloud hits high performing panels pretty badly but makes hardly any impact on panels shaded by a tree branch or two.
No comments:
Post a Comment