Sorry you had to find out the hard way, but thanks for the heads up. I’ve “paused” internet access on my Envoy (using eero), until hopefully Enphase sorts this out. The Homebridge page did seem to imply Enphase is working on something at least.
When I try to go to that page and sign in using my Enlighten account, I get a banner at the top saying I am not authorised to view the page and I see a standard Overview. Any tips?
Would this new firmware also stop the Envoy integration working too, so the whole Energy integration you’ve worked so hard on would stop working?
EDIT: While blocking Internet access stops the firmware update, it’s a real shame my lifetime stats on Enlighten will no longer be updated, with the ability to see the history of individual inverters. HA is more important to me, but still.
Thanks for that - his last comment was in August re Enphase modifying the firmware - lets hope its done soon
Yeh - I wonder where he gets his information…
I’m making a bit of progress.
The first time I go to envoy.local via chrome on the Linix box that’s running HA as a virtual machine, it redirects to https and says the page is untrusted as it’s a self signed certificate. If I then click to “Proceed anyway”, it then displays a message saying I need to authenticate and redirects me. If you click at the top where it says logon with Enphase account it redirects again and you’re presented with a login for your enphase account.
This is the (redacted) url for the page thats asking for authorisation with my enphase details:
https://entrez.enphaseenergy.com/authorize?code_challenge=redacted&client_id=envoy-ui-client&redirect_uri=https://envoy.local/auth/callback&scope=redacted&response_type=code&code_challenge_method=S256
When you insert your Enphase username/password, it redirects to:
https://envoy.local/auth/callback?code='secret-big-long-code'
It than sits at that page for a few seconds with a message that its finishing the authentication process - after a minute it then displays any envoy.local page you wish to display.
If I then get tricky and paste the above into terminal using curl - I get this:
curl https://envoy.local/auth/callback?code='secret-big-long-code'
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
[1]- Done curl https://entrez.enphaseenergy.com/authorize?code_challenge=redacted
[5]+ Done response_type=code
So I need to work out from terminal how to trust the self signed certificate and “hopefully” I’ll get access via terminal.
One potential issue I say is that the output from https://envoy.local/stream/meter updates really slowly - at least 30 seconds or longer between burst of updates. The authorisation also doesn’t appear to be sticky - I lost it after a while of idle and had to re-authorise.
I’m hoping Enphase are working on a fix for this, per the above github thread …
1 Like
Found this in another topic
Not happy Jan!!!
I’m a bit confused by the Enphase thread https://community.enphase.com/s/question/0D53m00006ySLuR/unimpressed-with-loss-of-local-api-connectivity-to-envoys that discusses all this. It is said that local API access is still available, but via a cloud-generated token. I have no idea if this is true, or if it’s available yet.
EDIT: There’s also this little worry:
re your concern of the Envoy eventually failing when cut off from Enlighten due to its internal database overflowing, I can report that power-cycling the Envoy (by flipping the 10A breaker in a Combiner 3 box like mine, waiting a minute, and turning it back on) empties the database. I did this 2.5 months after disconnecting the Envoy from the internet when I noticed longer and longer periods of time during which the Home Assistant Envoy integration reported that the Envoy was unavailable. Power-cycling the Envoy fixed this, presumably because the database was wiped
Yes, that API access via a cloud-generated token is what I’m talking about a few replies higher. I can access the data I need but I need to generate a token which only lasts a certain period of time, and I then need to create a new one. The output data from the stream is also very slow, it used to update once a second but now maybe once every 340-40 seconds which is useless for my real-time monitoring requirements.
The part about needing to power off/on the envoy when the database is full isn’t an issue - If you wanted to keep the original 5.x.x and not have Enphase force update you to 7.x.x then block internet access to the envoy. The two downsides are that you then lose visibility of your system in their cloud, and the database keeps filling up - it seems Enphase must generate a command to clear the database and when you block internet access then the database keeps filling up. The easy solution is to power it off/on when the database is full - you could create an automation using a Shelly to do this.
1 Like
Oh, so you’ve generated a token using their system? There is some talk of long-lived tokens on their forum, but I don’t know if they’re available. There is also at least one user who successfully badgered them into downgrading his firmware!
1 Like
I went to https://entrez.enphaseenergy.com/
And got these choices. I have no idea what to put there though.
I chose “for uncommissioned envoys” and pressed “Create access token”
I then pasted the token into this JWT debugger
https://jwt.io/
This token appears to last 7 days.
exp: 1637885749 =
| GMT | Fri Nov 26 2021 00:15:49 GMT+0000 |
|---|---|
| Your Time Zone | Fri Nov 26 2021 11:15:49 GMT+1100 (Australian Eastern Daylight Time) |
iat: 1637280949 =
| GMT | Fri Nov 19 2021 00:15:49 GMT+0000 |
|---|---|
| Your Time Zone | Fri Nov 19 2021 11:15:49 GMT+1100 (Australian Eastern Daylight Time) |
1 Like
Interesting - I did the same yesterday - I created a token in the same way - however this morning when I tried to reuse it, it said it was invalid and I had to recreate it … maybe you could check if yours works for a the 7 days?
I thought this would be easy. Either a Shelley/Sonoff or make up a lead with a normal AC plug on the end that goes to a smart wifi plug/switch. However, I just spoke to my installer, and he said it’s not that easy. My system is 3-phase. He said I’d need a contactor that is activated by normal AC. He might be able to come in a week or so to take a look. Hopefully, my database won’t fill up before then!
If it fills, just power off at main switch - inconvenient but it will work.
If you type in the name of your system (Exactly how its recorded on the Enphase Cloud) it will show your envoy in the drop down box.
If I paste the token into the JWT debugger - it shows my Envoy instead of un-commissioned
1 Like
A Github user immesys just left a comment in my Github repo regrading this - he has worked out a way to get it to work from terminal!!.
But per my response to him in my Github repo - steam doesn’t update every second - it’s dumping a page at a time every 30 - 40 seconds so useless for real-time monitoring … onwards and upwards!
The envoy now expects you to authenticate using a JWT. You can technically authenticate on the envoy home page using your enphase username/password but it's just a wrapper around the JWT. Here is my code for obtaining the JWT (in go)
// The EPScraper struct just has some config data in it, it should be pretty
// evident from the variable names what the data is
func (ep *EPSCraper) getJWT() (string, error) {
// Error handling stripped for brevity
// We need to have an HTTP client that stores cookies, for reasons that
// will become apparent
jar, _ := cookiejar.New(nil)
client := &http.Client{
Jar: jar,
}
// First, login using your username and password
client.PostForm("https://entrez.enphaseenergy.com/login",
url.Values{"username":{ep.EnphaseUser}, "password":{ep.EnphasePassword}})
// Response error checking omitted, but what we needed was the cookie, which is now in the jar
// Second give system parameters
resp2, _ := client.PostForm("https://entrez.enphaseenergy.com/entrez_tokens",
url.Values{"Site":{ep.EnphaseSite}, "serialNum":{ep.EnphaseEnvoySerial}})
// htmlquery is like an xpath library
doc, _ := htmlquery.Parse(resp2.Body)
textareas := htmlquery.Find(doc, "//textarea[@id=\"JWTToken\"]")
// The first and only textarea with the JWTToken id is the JWT
return htmlquery.InnerText(textareas[0]), nil
}
Now, in most systems the JWT can be used as a bearer token, so you'd expect that once you have the JWT you can drop in an Authentication: Bearer <JWT> header and hit the same envoy API endpoints but unfortunately that doesn't seem to be the case here. What you need to do is make a call to /auth/check_jwt which will set a cookie if the JWT is valid and unexpired
func (ep *EPSCraper) loadJWTIntoCookie(jwt string) error {
// You need to empty the cookie jar before trying to load a new JWT in.
// If you have an old cookie from a previous JWT auth, it gets confused and you don't end
// up "refreshing" your auth. Then your system breaks when you hit the expiry time
jar, err := cookiejar.New(nil)
if err != nil {
panic(err)
}
// Erase the cookies in the scraper's client bc the envoy doesn't seem to overwrite the
// jwt if there is one in the session already
ep.client.Jar = jar
req, _ := http.NewRequest("GET", fmt.Sprintf("%s/auth/check_jwt",ep.EnvoyHost), nil)
req.Header.Set("Authorization", fmt.Sprintf("Bearer %s", jwt))
ep.client.Do(req)
// again, all error handling stripped. You'd normally check that response
// All we needed was the cookie, which is now in ep.client.Jar
return nil
}
Once you have that, you can hit the API endpoints. I'm not sure if these have changed since before or not, I've only used the new firmware. I personally use <envoy>/production.json?details=1
BUT. They also added mandatory https. So you have to hit the all the endpoints on HTPS not on HTTP (e.g. ep.EnvoyHost in the code above is "https://192.168.1.43" for me). They use a self-signed cert so you will need to make sure your HTTP client is ok with ignoring cert errors (security amirite)
1 Like
Yes, sure. I guess that kills the whole solar system too? Not that that matters for a short period of time. But, ideally, I’d like to automate a reboot say, every week.
The full database won’t stop your system from generating solar, but master switch off/on will interrupt solar generation - this is true if you power off/on the Envoy or the whole house, so your automation would be better doing at night. Similarly, when your database is full and before the Shelly is installed, it would be ideal to power off/on the master switch at night. I believe it takes weeks though or longer to fill the database
Ok, thank you. I didn’t realise power cycling just the Envoy would stop solar production too.