Can you share the code extension? No clue where the token must be entered. Or do you have it on github?
I changed the code itself to put in the token and then created the binding with my token included. Best wait until @dfad1469 finishes his change and creates a snapshot version.
I am almost done. I am testing a feature where it will go get the JWT automatically. Will push today.
This is code of the official binding and works for the Envoy version that supports the local api. It seems newer version of the Envoy software either require a login or don’t support the local api anymore (I’m not sure what is the case). The official binding doesn’t support Enphase cloud access. The updated binding by @dfad1469 seems to add cloud access. (I would suggest to create a separate cloud bridge in the xml definitions, technically it can use the same code, with some detection of cloud/local. This would make it clearer for users what connection they use). Any change to this binding should still keep the current way of connecting working, as that is still a working way to read data.
You are correct…the way you login to your local port changed when they upgraded to their software version 7. If you local Enphase connector upgrades it’s software to version 7, you can no longer login with a default login/password. It now requires you to go onto a separate website in the cloud, login with your Enphase account, enter information about your system (System Name and serial number) and then get a JWT that you then use to login in locally. This JWT will expire in either 1 hour, 12 hours or 1 year depending on your account type.
I have put a flag into the parameters so that you can switch between version 7 and earlier. I have also put a feature into the code to automatically go out and get that JWT if you would like. Testing now.
Alright, I have this working, although there are still changes I would like to make. For example, I have a battery system and will be adding support for that.
To be clear, this will not connect to the Enlighten Cloud Service. It only updates this binding to support Version 7 of the Gateway software.
Here is the git repo: GitHub - dfad1469/openhab-addons: Add-ons for openHAB
And here is the branch: enphase
I will try to post a jar later.
I had the Envoy installed last week and it’s on version
D7.0.88 (5580b1). On this version, the local endpoint
/production.json works and it gives me expected values for production and consumption.
The cloud API is not a good option because it has a low rate limit on the free plan. See discussions here:
I have said many times, I am not trying to connect to the cloud API. In newer versions of the local gateway software, you can’t simply login using basic authentication. You now require a JWT supplied to you from a website. It’s a well documented issue:
This happened to me. So, I put some fixes in the code that bypasses the issue. I even attempted to put a switch in so that it would work with older software versions.
I did this for my own use, but thought I would share it in case others wanted to use it. If these changes aren’t wanted, then I won’t do a pull request after I am done testing. It’s up to the binding owner, but I don’t mind either way.
Did some more testing and found some more bugs. Just pushed the latest.
Hi Joe, I didn’t want to imply that you want to implement the cloud API and just wanted to state the situation there. Many thanks for your valuable work, it already helped me a lot.
Hi @dfad1469, I got the newest version from you branch and compiled it but when I install it in OpenHAB I’m getting
Unresolved requirement: Import-Package: javax.annotation.meta
which additional jar-files are you using?
I am not using any. I am building locally and dropping into my addons folder.
Is it possible your build version is different than your installed version?
Mmm… I’m using a clean installation of
openhab-3.4.0.M5 and your branch
enphase of the openhab-addons repo. When I do
mvn clean and
mvn package and then drop it into the
addons directory, it fails. When I uncomment the
json dependency in the bom file, it works.
I am a novice in Java compiles, I managed a successful build of the Enphase branch with: the following command:
mvn clean install -DskipChecks -DskipTests -pl :org.openhab.binding.enphase
Thanks for the efforts! Appreciated. Could you drop a jar file on git or send it via a link? Steep curve for a novice to compile Java and have the correct build setup
Weird stuff. Let’s see if it works for @JustDude.
@dfad1469 Having support for jwt access token would be a useful improvement. So having it added to the official binding would be a good idea. However there is still some work to do to make the change work correctly, and I have some questions about it. One thing I’d like to suggest is to make a different bridge for this instead of making it a option of the current bridge, because the required properties are different. My suggestions is for me to make changes and create a pull request against your branch, and then create a new pull request to the main repo. Wdyt?
No luck, the JAR compile of the single add-on fails on this pom.xml related error:
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-enphase; type=karaf.feature; version=3.4.0.SNAPSHOT; filter:=“(&(osgi.identity=openhab-binding-enphase)(type=karaf.feature)(version>=3.4.0.SNAPSHOT))” [caused by: Unable to resolve openhab-binding-enphase/3.4.0.SNAPSHOT: missing requirement [openhab-binding-enphase/3.4.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.enphase; type=osgi.bundle; version=“[220.127.116.11211302037,18.104.22.168211302037]”; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.enphase/22.214.171.124211302037: missing requirement [org.openhab.binding.enphase/126.96.36.199211302037] osgi.wiring.package; filter:=“(osgi.wiring.package=javax.annotation.meta)”]]
If you add
,javax.annotation.meta;resolution:=optional to the
bnd.importpackage line in the Enphase binding pom.xml it should compile.
It works! Thanks
The username / password / JWT and the correct site name is relevant.
Configuring the Thing now
After some try outs:
I had to rename the labels for Latest Power and others, they were not populated with the Consumed prefix as I would thought they would be. So they were listed double initially