Enphase Data Access

sandeen · May 2011

Re: Enphase Data Access

rahvin wrote: »
So I took the base64 stored MD5 hash from the password file posted earlier and converted it to the raw Message Digest 5 format which leads to the below MD5 value.
be44b27c9d80c8afb0e6f58bad374a56

I was thinking along the same lines, but how did you do this? I'm not sure it's possible... but I may misunderstand. I think crypt() md5's the password many times, while the rainbow tables are usually for a straight, single md5 hash that (windows?) uses ...

rahvin · May 2011

Re: Enphase Data Access

sandeen wrote: »

I was thinking along the same lines, but how did you do this? I'm not sure it's possible... but I may misunderstand. I think crypt() md5's the password many times, while the rainbow tables are usually for a straight, single md5 hash that (windows?) uses ...

From reading the crypt man files it's apparent that default is a single run MD5 stored in base64 format. Salt values can be provided but older versions of Busybox had a known vulnerability of not applying salt. Based on the password has provided there is no salt so they didn't bother to patch the known vulnerability. There is also no indication that they've run multiple times with crypt. The beauty of getting that password file is that you can see the configuration so you know what you are trying to crack. Salted double MD5 would be very secure but as I said the known Busybox vulnerability patched several years ago still applies to this install. Something that's indicative IMO of the value they place on security and the danger these things pose to an internal network.

After reading the man files it was apparent that to use the value I needed to convert it from base64 (22 char) to the hex MD5 format (32 char). I'm guessing that base64 is used to store the value because it uses less memory, probably a carry over from the days when a few bits of memory was substantial cost. Anyway, a straight up conversion to hex only generates 30 chars meaning that some form of checksum is also incorporated into the value. I found a binary converter on the Internet that will convert the base64 value to the hex that MD5 uses.

http://home2.paulschou.net/tools/xlate/

Once I used the converter the output to MD5 was recognized as a valid hash. So then just run it through the rainbow tables. I did make a mistake though, the tables I ran it through were an incomplete subset of the 99.6% tables. (32gig versus 320gig for the full set). So I've been downloading the full tables over the last day or so, I'm sure Comcast is going to love me downloading 300+ gig over a 3 day period. Once the tables are fully downloaded later this evening I'm going to run the hash through them.

I hope it's successful but I don't have high hopes. After a little more investigation my original theory that they might be doing everything with a user account appears to have some backing based on some of the data posted. It's very possible that the root account has a big (12+) random char password that will be darn near impossible to crack and impossible to extract with rainbow tables.

Has anyone looked at the user account to see what's available through it? Does is have sudo ability? Is it part of the admin group? I'm curious because it might be easier to crack the user account password.

sandeen · May 2011

Re: Enphase Data Access

I don't think that what you've done is correct. If we encode "password" via crypt() we get:

$ openssl passwd -1 -salt "" password
$1$$I2o9Z7NcvQAKp7wyCTlia0

and in your tool that yields MD5: 4b4503ca8e9b1005ba6d5bea23f5e375

However, entering "password" in the text field yields:

MD5: 5f4dcc3b5aa765d61d8327deb882cf99

which is not the same. (if you google the latter, you get plenty of hits, as this is the md5 hash for "password" - if you google the former, you get nada, zip, nothing)

IOW, crypt() is not a simple md5 converted to base64. See also wikipedia:

First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.

note the "thousand iterations" part.

I think using rainbow tables on the md5 you suggest will be fruitless.

sandeen · May 2011

Re: Enphase Data Access

rahvin wrote: »

Has anyone looked at the user account to see what's available through it? Does is have sudo ability? Is it part of the admin group? I'm curious because it might be easier to crack the user account password.

The only other acct with a password is "energytracking" - it has no special rights, as it is specifically for the one kWh meter which can be associated with the envoy (see http://gsfn.us/t/27gos )

Oh, and fwiw that account is denied in the ssh config.

rahvin · May 2011

Re: Enphase Data Access

sandeen wrote: »

I don't think that what you've done is correct.

Regrettably I agree. I've done a lot more reading and it's clear that the version of crypt being used was made extremely difficult to crack. What I'm confused by is the vulnerability report on busybox regarding it not using salt. It discusses that by not using salt the system is susceptible to the use of rainbow tables.

What's curious is that in reading about all this is that there must be rainbow tables that can be used to crack the password because of the lack of salt. I'm confident at this point that I'm not using the right rainbow tables but the question is are there rainbow tables available that work against this version of crypt() and if so where do you get them? Backtrack has utilities to generate the rainbow tables but creating those tables would seem to be as CPU intensive as brute forcing.

I'm at a loss for how to proceed at this point. If I had an Envoy I would probably start by running some vulnerability scans against it. As I mentioned before, given the age of kernel I'm willing to bet most of the software on it has known vulnerabilities. Anyway, I'm stumped. I'm going to spend some time trying to brute force the passwords but I don't see a high probability for success.

sandeen · May 2011

Re: Enphase Data Access

rahvin wrote: »

Regrettably I agree. I've done a lot more reading and it's clear that the version of crypt being used was made extremely difficult to crack. What I'm confused by is the vulnerability report on busybox regarding it not using salt. It discusses that by not using salt the system is susceptible to the use of rainbow tables.

It would be, if they existed.

(sorry to everyone else for turning this into a crypto newsletter)

They don't exist, I think, because by and large crypted passwords are salted, and because even generating unsalted rainbow tables for crypt() would take thousands of time longer than the md5 tables out there. crypt() is intentionally computationally expensive. (but see http://darthnull.org/2010/12/22/nails-in-the-crypt/) And creating those rainbow tables for yourself is no cheaper than brute forcing.

Anyway. I've done some trivial looking for other security flaws and have found nothing obvious so far. The web input forms seem pretty sanitized, and while old software often has vulnerabilities, they aren't remote exploits all that often. But I'm no expert here.

sandeen · May 2011

Re: Enphase Data Access

Hm, I wonder what all this update might contain ...

http://gsfn.us/t/29ahm

The upcoming build for the Envoy has an updated network connectivity page.

I wonder how much of that updated build might possibly be in response to this thread ...

sandeen · May 2011

Re: Enphase Data Access

Not directly related, but Enphase has finally posted all source code for GPL software in the Envoy:

http://enphase.com/licenses/m2-2-1/

And the new manual says:

Other Information
For third-party license information, refer to www.enphaseenergy.com/licenses.

which leads to the page with the software downloads.

I think maybe the licenses should be in the manual proper, but this is enough of a good faith effort to satisfy me for now - not that I am the enforcer/lawyer in this case, of course. Persistence paid off

drees · May 2011

Re: Enphase Data Access

Hmm - but my software version is "M2.1.1 (dddef8)"... So may not be exactly the same as what I have. I wonder if they'll be updating the software on older units to the latest - and what those changes will include?

sandeen · May 2011

Re: Enphase Data Access

drees wrote: »

Hmm - but my software version is "M2.1.1 (dddef8)"... So may not be exactly the same as what I have. I wonder if they'll be updating the software on older units to the latest - and what those changes will include?

I also wonder how/when they get upgraded, and if any *cough* special features on existing envoys would get overwritten.

sandeen · May 2011

Re: Enphase Data Access

dgalbraith100 wrote: »

I was able to hack getting the data out of it with a different route I haven't seen discussed yet. I played with my hack for a couple weeks, and then quit since I decided that what enphase was charging for the access was cheap enough. And with my hack, you couldn't see your system on enphase site until the night... (you'll see why after you read how it works)

Here is the hack I did:
Change your dhcp so that it assignes out a DNS server to the unit that you have control over. Set (I'm going from memory now) reports.enphaseenergy.com to point to a web server you have control over... So that when the unit attempts to report home it goes to your webserver instead. (https enabled)
...
The only thing I couldn't figure out was how to get it to quit sending the data.. so once a night you change the DNS entry to the real reports.enphaseenergy.com and let it talk to there... that clears the buffer and the next morning you get your data again... (And sends all the data to enphase)

This actually seems like the simplest route, although they could break it easily by checking the certificate.

To get it to stop re-sending data, you just need to give it the right response, something like:

<?xml version="1.0" encoding="UTF-8"?>
<perf_report_response status="success">
  <intervals_processed>
    <interval id="479379"/>
    <interval id="479381"/>
...
  </intervals_processed>
  <events_processed>
    <event id="30227"/>
    <event id="30228"/>
...
  </events_processed>
</perf_report_response>

Seems like the simplest way to still see your enlighten data is just to forward on the data from the envoy. Just grab it, process it, and optionally send it up to reports.enphaseenergy.com if you have a subscription.

I'm in the same boat as you, though, for $22/year this is an interesting problem but not an imperative. Enlighten is still ok with me.

sandeen · May 2011

Upgrade notes

My envoy got upgraded on May 26, to M2.2.1 (f0b764). A few notes:

rsync is gone (and the old binary won't execute)
my modified production screen got overwritten
changes to /root/.ssh are intact
I didn't request the upgrade; it just got pushed.

rsync's removal makes it harder to get files off to compare to the old root, but we'll get there.

drees · May 2011

Re: Enphase Data Access

Mine updated to the same version this morning. In the logs it indicates "Envoy Reboot" and "SOFTWARE RESET" around 6am Pacific...

dgsloan · June 2011

Re: Enphase Data Access

Does Enphase not include generation of an API key which would allow access? Looks like their web access is now free for life for those that do not need more data for retrieval.

sandeen · June 2011

Re: Enphase Data Access

dgsloan wrote: »

Does Enphase not include generation of an API key which would allow access? Looks like their web access is now free for life for those that do not need more data for retrieval.

My paid-up subscription does have (beta) API access and I've done some fun things with it. Here's a screenshot of my OSX dashboard widget:

I assume the API will be available with this lifetime access as well.

This certainly makes reverse-engineering or hacking the Envoy a little less interesting, other than for the hack value.

With API access to most of the relevant data, I can do the things I wanted to do, which were unavailable to me early on in my subscription period...

fixer · July 2011

Re: Upgrade notes

sandeen wrote: »

My envoy got upgraded on May 26, to M2.2.1 (f0b764). A few notes:
rsync is gone (and the old binary won't execute)

my modified production screen got overwritten

changes to /root/.ssh are intact

I didn't request the upgrade; it just got pushed.

rsync's removal makes it harder to get files off to compare to the old root, but we'll get there.

Reminds me of when Apple tried this, every time the iPhone got "unlocked" they would send out a new version. Then that got broken.

As some point those companies learn to let the OWNERS of their products enjoy them any way they wish.

I'm amazed they haven't learned from all the other companies that have done this. Do they not have net access and google or something? Maybe they can't read, or maybe they live in their own little world.

Like Linksys has sold a lot more wireless routers due to the hobby market of people who put their own version of Linux on them. If you can customize your own way then it sells big.

ag4wake · July 2011

Re: Enphase Data Access

Sorry it's been a while since I last posted. Here's some more info about the EC2 password crack setup:

I used oclHashCat+ to do a bruteforce crack using (i recall) the full character set and let it run to 5 characters in length. I then switched and used the rockyou list of passwords and let it run on that for a while. In each case I didn't get anywhere and going past 5 characters substantially slows down the cracking. The EC2 instance was blazing through the passwords, so you probably could run it for a week and get something. At $50 a day thats $350 dollars to crack a password. I might as well pay enphase for a bunch of years for that money. I don't have a godo GPU on my server here to think I could run it here with much success.

Like was mentioned, i looked into the password and then found it wasn't salted and in that case tried to use a password lookup table (rockyou) and also tried to brute force the attack. I would suspect though that the password would be common words or something based on the serial number. I just didn't get enough time to run through a bunch of scenarios. For whatever the case, I couldn't crack the password much further (in the time I allotted) than 5 characters using the full character set. I didn't want to start with the small character sets and possibly have to restart a couple of times.

If you want to try running oclHashcat on the EC2 farm, google it and you'll find the AMI needed to launch and the couple of binaries you need to download to enable source compiling. I wish I could find the procedure I used since i usually write it down in a README file for myself in my working directory, but this time I didn't do it for some reason.

In terms of the some specifics on the EC2 costs, this was the rate as of Feb/Mar 2011. I didn't need to pay for incoming data charges (which it looks they again got rid of for US again)

Amazon EC2 running Linux/UNIX
$2.10 per Cluster GPU Quadruple Extra Large Instance (cg1.4xlarge) instance-hour (or partial hour)
26 Hrs = $54.60

Amazon EC2 EBS
$0.10 per GB-month of provisioned storage
0.744 GB-Mo = $0.07

$0.10 per 1 million I/O requests
99,558 IOs = $0.01

$0.01 per 10,000 gets (when loading a snapshot)
1,577 Requests = $0.01

Alan

rahvin wrote: »

Wait, someone else said the password isn't salted. We need to at least agree on that, Is the password salted or not? That salt value becomes crucial if it's salted, if it's not then it should have been cracked with the GPU EC2 attempt. The research I've read says a GPU instance like that can crack a hashed password in at most a couple hours so if it's not salted the password is definitely not 5 chars.

I'm a little curious about the EC2 attempt, was a dictionary used or just a random char attack and what was the parameters (ie upper/lower/numbers/special)?

ag4wake · July 2011

Re: Enphase Data Access

Bryan,

If you are still checking the forum, were you soldering a JTAG connector to the board. I thought I recall you had a board w/o that connector. If you are which connector did you buy?

Alan

brturn wrote: »

Speaking of which.. my JTAG just arrived.
--Bryan

sandeen · July 2011

Re: Enphase Data Access

ag4wake wrote: »

I might as well pay enphase for a bunch of years for that money.

You do know that Enlighten is free now, with a data API to boot? Kind of took the wind out of my sails on this one

(Also, from a quick look, it doesn't seem that oclHashcat even supports Unix passwd-file type encryption? Maybe I'm wrong ...)

brturn · July 2011

Re: Enphase Data Access

Alan,

Yes, my board had no connector on it. I scavenged a connector from other projects (an old graphics card), the pieces I used were standard parts. I pushed the pins as far as possible into their seats, and set them from 'behind' so the pins stuck out of the holes, pointing toward the soldier pads. A lot of trial soldiering later... I got all the pins connected and tested.

Had to sand down the JTAG connector since the soldier blobs were large enough to interrupt the connection. Everything checked out fine mechanically.

Was unable to get the debugger to connect to the unit, although it recognized the JTAG, it could not wrest control from the board. I tried a number of configurations, including one which worked for a member of this board, but no luck. I notice a new connection on mine (right next to the JTAG connector) which does not appear on the older boards, looks like a missing capacitor pad. A quick search suggests this capacitor is not needed for the mode I was using, but it would be the first thing to check if you go down this route.

Sadly, I ran out of time on this project and since it's not critical for getting the system to work, I've moved on. Would be happy to cooperate with others in getting the unpopulated boards under JTAG control, it is still valuable for my future system design.

--Bryan

ag4wake · July 2011

Re: Enphase Data Access

Actually just saw that today. I couldn't tell, is enlighten free to both existing customers and new ones? I would assume so from your response. Their website didn't go into much details on the change.

oclHashcat+ supports it. I used that cracker.

sandeen wrote: »

You do know that Enlighten is free now, with a data API to boot? Kind of took the wind out of my sails on this one

(Also, from a quick look, it doesn't seem that oclHashcat even supports Unix passwd-file type encryption? Maybe I'm wrong ...)

drees · July 2011

Re: Enphase Data Access

Yes, free now for both old and new customers.

Blackcherry04 · July 2011

Re: Enphase Data Access

It was a ridiculous situation in the first place. It cost 6-7 % of your yearly solar harvest dollars to look at your own data. I hope that the big gripe thread that some of us were part of opened their eyes.

sandeen · July 2011

Re: Enphase Data Access

ag4wake wrote: »

oclHashcat+ supports it. I used that cracker.

I see that now - sorry, was looking at the wrong one and missed the differences.

System2 · October 2011

Re: Enphase Data Access

Earlier in the thread there was mention of Ariane Controls. Enphase uses Ariane components for the PLC (powerline communication) between the Envoy and inverters. Ariane offers a PLC developer kit, as mentioned in the thread, but it appears to be a special order part.

For any hackers still interested in this, I found some off-the-shelf kits that have the same Ariane PLM-1 chip in the Envoy. In theory, one of these kits could be connected to the solar power bus to monitor the data. Once the protocol is unraveled, the kit could act in place of the Envoy for those of us who want private or local access to the inverter data.

The PLC kits are manufactured by LinkSprite (http://www.linksprite.com):
-"Mamba" ($55, http://www.sparkfun.com/products/10918), a PLC shield that plugs into the Arduino Uno ($30, http://www.sparkfun.com/products/9950).
-"Spyder" ($55, http://www.electronics123.com/s.nl/it.A/id.3251/.f), a PLC transceiver that hosts modules fitting the XBee profile.

System2 · November 2011

Re: Enphase Data Access

Great thread! I stumbled across it while looking for the ssh username and password.

Like many others I am interested in getting access to the raw data collected from the micro-inverters. I'm curious to see if there is a way to get a shell on the envoy without needing to open the hardware. Has anyone made any progress toward this?

I'd guess the web server would be the likely service to look at. Does anyone know much about it?

le_bresilien · November 2015

Hi,

I own also an Enphase System M215 micro inverters & Envoy Energy Management Unit (EMU)

I have found this material to go ahead on this topic:
http://blog.oddbit.com/2012/02/13/enphase-envoy-xml-data-format/
http://blog.oddbit.com/2012/02/22/capturing-envoy-data/

Herafter information from Enphase documentation:
screenshot77png

For the last screenshot, to read UDP on last line (not FTP) as NTP is relayed on UDP not on TCP

Please let me know if you progress on this topic

Best regards

Tilendor · March 2017

Hi guys. Very good technical discussion here, though I'm rather late to the discussion. I just recently had an EnPhase microinverter + Envoy-S install done here. I think this model is a bit newer than most of the ones mentioned here.

First thing, my Envoy-S exposes a very limited unrestricted api, as is documented here: http://www2.enphase.com/global/files/Envoy-API-Technical-Brief.pdf
Basically you can hit http://<envoy_ip>/api/v1/production to get 4 values: { "wattHoursToday": 15116, "wattHoursSevenDays": 15499, "wattHoursLifetime": 15499, "wattsNow": 1566}

Enough to get some simple data. I made an Arduino with an Ethernet & TFT screen to access this and display my panel performance using it. Pretty fun.

I too am saddened by purchasing this and having limited access to it. I've found a couple of interesting work-arounds.
My installers finished up, but it they didn't have the login ready for me just yet. So I registered at the Enlighten website as a "Self-Installer".

Next, I downloaded the Enphase Installer's Toolkit app onto my Android phone. I saw the installers using it to configure my Envoy.

There are several ways to get the Envoy-S setup on your home network. Direct Ethernet connection or it built-in WiFi that can be configured to log on to your home network. My installers put in a pre-configured "micro-router" that just plugged into my network and setup an unbroadcasted SSID that the Envoy-S was preconfigured to join.

There is a button on the Envoy-S to turn on its built-in AP for 8 hours. I pressed this, and had my Android phone join that network.

I then logged into the Toolkit app using my "Self Install" Credentials. This let me access the Envoy-S directly, with full control to change settings and see all the micro-inverters, and their production. I setup the Envoy-S to connect to my home network, bypassing the micro-router.

I downloaded PacketCapture for Android, created a self-signed certificate, and connected again with the Toolkit app. I captured 48 requests, and it seems like the the toolkit app is mostly a wrapped browser, as it makes requests for HTML assets, in addition to many json requests.

(Side-note: When the installers granted me access to myEnlighten, I was able to grant my "Self-Installer" account access. This lets me see my system using the "Enlighten Manager" which has much more detail, including per-panel values and history.)

Here are the endpoints I found with the packet capture(not including the responses just yet as I am hand typing this, also omitting images, css, js, html, etc...):

/admin/lib/admin_pmu_display.json ------------------------(available and associated pmu IDS?)
/admin/lib/date_time_display.json?tzlist=1&locale=en -(Timezone list)
/admin/lib/dba.json ----------------------------------------------(one element, tunnel_open: true|false)
/admin/lib/network_display.json ------------------------------(network configuration)
/admin/lib/tariff.json ---------------------------------------------(currency, rate types and thresholds)
/admin/lib/wireless_display.json?site_info=0 -------------(basic config info)

/api/v1/production/inverters --- (has lastReportDate, lastReportWatts,maxReportWatts per inverter)

/info.xml --- (Envoy specific device info)

/installer/agf/index.json?simplified=true -( some profile information and package versions)
/installer/agf/inverters_status.json --------(more detailed inverter info)
/installer/pcu_comm_check -----------------(all inverters respond with a single code(in mine 4 or 5))

/inventory.json?deleted=1 --- (seems to list detailed micro-inverter info)

/ivp/mod -------------(another list of inverter info)
/ivp/peb/newscan -(maybe about automatic inverter discovery)

/production.json?details=1 --- (top level count of inverters, watts now and watts lifetime, also storage info (ie batteries))

/prov --- (more detailed inverter information)

/home.json --- (top level config for homepage)

At the very beginning of the packet stream, there are some 401s to /prov and ipv/mod. The Toolkit sends a second request with an Authorization Header: Digest username="installer", realm="enphaseengery.con", nonce="1489263331", response="494872dfeec358725f29589086cdf900", qop="auth", nc=00000001, cnonce="1IQm7hqVitpxif+oC8vZ"

Following requests don't have an Authorization Header, but do have a Cookie with a sessionId, and an envoy_<serial> entry. Its odd, I don't see a request where the cookie it set. Maybe through javascript.

I have not tried to make requests with this information yet, but I'm hoping I can use the information gleaned from the packet stream to make requests for the more detailed inverter information. If I can access the /api/v1/production/inverters endpoint, I can update my monitor to show the performance of all my panels.

Hope this information is helpful to those who want more control of their own data.

Tilendor · March 2017

I discovered some very interesting things:

1) The cookie does have an expiration, so it can't be used indefinitely.
2) Requests are replayable. Duplicating the Authorization header yields a successful response. Since this is Digest Authentication the header is url specfic, which means you can't use it for other urls. It either doesn't have an expiration, or it is longer than several days.
3) The manual talks about using the built in website to change settings. It has a home page that doesn't require any credentials, but needs a username and password to modify them. The manual states that the username is envoy, and the password is the last 6 digits of the serial number. These credentials also work for the following urls:

/admin/lib/dba.json ----------------------------------------------(one element, tunnel_open: true|false)
/admin/lib/network_display.json ------------------------------(network configuration)
/admin/lib/wireless_display.json?site_info=0 -------------(basic config info)

/api/v1/production/inverters --- (has lastReportDate, lastReportWatts,maxReportWatts per inverter)

/info.xml --- (Envoy specific device info)

/inventory.json?deleted=1 --- (seems to list detailed micro-inverter info)

/production.json?details=1 --- (top level count of inverters, watts now and watts lifetime, also storage info (ie batteries))

/home.json --- (top level config for homepage)

I'm pretty excited about his, as I have access to the endpoint I wanted. Hope this helps others.

djr114 · March 2017

Thank you SO much for this Tilendor, this finally gave me what I've wanted for years now, namely the ability to easily see individual panel data.

Specifically I mean (most of your post removed for brevity but nothing changed otherwise):

Tilendor said:
My installers finished up, but it they didn't have the login ready for me just yet. So I registered at the Enlighten website as a "Self-Installer".

(Side-note: When the installers granted me access to myEnlighten, I was able to grant my "Self-Installer" account access. This lets me see my system using the "Enlighten Manager" which has much more detail, including per-panel values and history.)

Just to give a little bit more detail in case anyone else wants to be able to see their individual panel data on the enlighten website, do the following:

Make sure you already have access to https://enlighten.enphaseenergy.com as a normal user (you should see your system and history and such). Sorry, I can'r remember the steps for this, it was something my installer helped me with and it was couple of years ago. (Once you log on here, you should see "MyEnlighten" at the very top left of the web page")
Go to https://enlighten.enphaseenergy.com, log out if you're already logged in, and click the "Sign up for Enlighten" link on the logon page.
Select the "I am a do-it-yourselfer installing Enphase products on my own home or business" and complete the new user registration form with a different email address than you use for your main Enlighten account (note if you use gmail you can add something like "+enlighten" after your username and it will count as a different ID but you'll still receive the emails. Like username+enlighten@gmail.com where username@gmail.com is your normal gmail address).
Go to your email inbox and click the Activate Your Account now link in the new Welcome to Enphase Energy's Enlighten email you received.
Log on to your "do-it-yourselfer" account on Enlighten and make sure that works (no data here yet). Note that this account should show "EnlightenManager" at the top left of the web page instead of "MyEnlighten" like your normal account shows. When done logoff.
Log on to your original account on Enlighten (top left should say :MyEnlighten") and on the right side of the menu bar click the drowp-down for the menu ("Signed in as...") and choose settings. Sroll down to the "User Access Settings" section and click the "Give another user access" link. Enter the email you used for your "do-it-yourselfer" account and click send invitation. For me I immediately got a message that the other user was added. Log off.
Log on to Enlighten with your "do-it-yourselfer" account. You should now see your system there with PER PANNEL information going all the way back to the install date of the system. You can see per panel energy (watt hours) over any date range and you can even see animated power (watt) for each panel over a given day or week.

Thanks again to Tilendor, I had been wanting to get per panel information ever since my system was installed more than 2 years ago and now I can do so for free and very simply.

Enphase Data Access

Comments

Categories