Can you publish this into Hubitat Package Manager? This is awesome. Why monitoring went out a while back and I assumed it was hubigraph. I finally dug into the issue and found it's the new OATH type of mechanism required to sign into the combiner now. I search for this on HPM and could only find the one I already had. I am switching over to yours now.
Any update on the graphs?
Hi... the dashboard took a bit of a back seat for past two months. I can see about putting something on GitHub over the weekend.
Please know there are two parts and it is assumed you already have the enphase driver working with HE.
-
The installation of InfluxDB and Grafana - which I have working via docker-compose.yml. If InfluxDB and Grafana are already up and running, then you can move onto step 2. Otherwise, InfluxDB and Grafana will be needed before this can be used.
-
Influxdb Logger - from the HPM - is required to pull the enphase data from the panels, and put into InfluxDB.
I hope to report back soon.
Cheers!
Thank you. Yes I have both parts working. Looking forward to it.
Hi,
Thanks you for the feedback. I will try to publish this to the HPM.
Cheers,
Supun
Hi,
I can give it a try if Envoy knows about the SOC. I'll check it in the API documentation.
Since I don't have batteries with me, I can't test it before the release.
Hi folks, I have done what I can. Please understand grafana is not my for-tae.
The parts I have been playing with are on GitHub, HERE
For those within InfluxDB and Grafana there is also a docker-compose.yml that can help to get things up and running for you. For now you will have to manual add the dashboard into Grafana; however, the docker-compose does add in the weather data source. You will need to get your own OpenWeather API key though, else just turn off those plots.
I hope is works for you.
Cheers!
@vpsupun anyway to add an auto refresh when the token expires? Apparently my token expired back in July and didn't notice it until I was reviewing my logs for severe hub load tonight. I had to re-enter the same password and click save preferences for it to go out and retrieve a new token.
The driver validates the tocken each and every time it tries to pull the data.
If it's invalid, it should renew the token automatically.
After my last network migration, I forgotten to update the Envoy IP. So, it thought the token was invalid. I can see it was renewing the token each time without any issues.
Anyway, I need to fix this behaviour 
. But token renewal should work without any issues.
1 Like
New to Hubitat and attempting to integrate my Enphase Envoy system. This type of work and thread is what really got me interested and excited in Hubitat. If it matters, I'm located in the US, and am having issues getting a token. I've followed along the driver and identified the website to retrieve the token was incorrect based on some general google searches and should be "Enphase Authentication | Home" so I updated the driver accordingly. However the next issue I'm running into is that within a browser, after logging in I get the following screen.
Based on the Device Info inputs it doesn't seem like it is made for this type of token request. Can you confirm? I have to start typing my system name and then it will appear along with the gateway to select. I've been able to manually get a token. Here is some other info that may be useful.
Firmware: D8.3.5167
SKY: ENV2-IQ-AM1-240
Any help you can provide would be greatly appreciated!
Hello Luke,
Welcome to the Hubitat community. I'm based in Europe and the driver still works for me.
Could you please check if you can login in (using the browser) Enphase Energy - Enlighten | Sign in to Enlighten ? If yes, the driver should work as intended.
If you can login but the driver doesn't work, could you please enable debug logging and share the logs with me ?
Cheers,
Supun
That website does work and I am able to log in just fine. My logging shows an error when attempting to get a token. Here is a recent log. Thanks for the support!
Me too, I got an error when request token with enterez url
I was seeing the same "403 Forbidden" problem from generateToken(). After much debugging (and amazingly, lots of help from Perplexity!), I found that changing the http parameter set-up to this got me a token:
Map<String, Object> httpParams = [
"uri" : tokenUrl,
"requestContentType": "application/json", /* tell Groovy to encode output payload as JSON */
"headers" : ["Accept" : "application/json"], /* ask other end to respond in JSON */
"contentType" : "text/html", /* treat response as raw text (do not try to parse JSON) */
"body" : data
]
(The addition of the "Accept" header is new.)
I confirmed that the resulting token was good by using it in a "curl" request to the Envoy gateway. However, now the driver code is failing to validate, complaining about a request timeout to the Envoy. I'm continuing to debug...
1 Like
I think my timeout is an internal routing problem (Hubitat and Envoy are not on the same network), which will take me time to fix. Meanwhile, I'd love to know if adding the Accept header spec fixes the problem for other people.
Thanks, the header parameter fix the problem
Added the header and fixed some typos highlighted by @anne.hubitat (Thanks).
I'll refactor the code as suggested to provide better logs.
This fixed my use (America), works great!
Is there any way to pull data per panel?
I'm actually working on that! Assuming that you have microinverters reporting data to your Envoy gateway, you can get that information using the web interface locally with (for example):
curl --insecure --header 'Accept: application/json' \
--header "Authorization: Bearer `cat file_contianing_token`" \
--request GET https://yo.ur.ip.addr/api/v1/production/inverters
which means we could add it to the driver code. I think that the approach is going to be to query the data from the existing driver, and have it create/update child devices for each inverter (which means we also need to write a child device driver).
I'm just learning to code in Groovy, so this is taking me a while, plus I was diverted from this project by finding a bug in InfluxDB with respect to boolean variables, so I need to wrap up that issue first, then I'll get back to playing with this one, and I will most certainly submit my code for consideration if I get it working - unless someone else gets to it first.
1 Like
I have a first draft of code working, though it needs to be cleaned up. At the moment I'm pulling data into attributes named the same as the keys supplied by the Envoy IQ gateway, in particular: lastReportDate, devType, maxReportWatts, and lastReportWatts (this last one is the interesting one). However I've been wondering about the names, because if we use "nonstandard" attribute names, we're forced to use the Advanced Attribute Selection in InfluxDB-Logger, which is rather a pain, whereas I think if we used standard names, the devices could be added in the regular way.
I need to think about what to call the attributes, though - I don't want to misuse a standard name. For example, if "power" and "energy" are expected to always refer to consumption, then it might be a mistake to use them for production. Any opinions out there?
1 Like
