@jswim788 Looking at the enphase community post it doesn’t seem to be working (yet) with the new suggested url. Also to make changes to the binding it needs to be known what the suggested url would actually return (and what authentication is required). Without that information it’s unfortunately not possible to fix this.
Hello, since a few days my Envoy Thing is online with the following log message: Enphase Envoy (enphase:envoy:121842042748) hostname/ip address set to xxx.xxx.xxx.xxx
after touching the Thing and saving it, the Thing went offline with error message: Could not retrieve data: HTTP protocol violation: Authentication challenge without WWW-Authenticate header. From the tread it seems that this problem has already been addressed in May 23, but at the time I don’t think I was affected. I have no idea when the firmware of my envoy was updated, but I’m on D7.0.88 right now. I upgraded from 4.0.x to 4.1.1 last month. Binding has been working fine for me for more than 2 years.
After reading the docs for this binding and the hints in the Thing config it seems that I have to provide User+ PW and Site Name. However, with Auto JWT on all entries are automatically reset. switched off, the behavior changes: the values are not immediately overwritten anymore, but when I save, the values are reset anyway. The state of the Auto JWT does not actually matter anymore for this behavior.
The debuglog with/ without Auto JWT is identical:
2024-03-16 12:18:58.944 [DEBUG] [ternal.handler.EnvoyConnectorWrapper] - Set Envoy version found in the Envoy data: 5.0.62
2024-03-16 12:18:58.951 [DEBUG] [hase.internal.handler.EnvoyConnector] - ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
java.util.concurrent.ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
at org.eclipse.jetty.client.util.FutureResponseListener.getResult(FutureResponseListener.java:118) ~[?:?]
at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:101) ~[?:?]
at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:732) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.send(EnvoyConnector.java:247) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.retrieveData(EnvoyConnector.java:213) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.getProduction(EnvoyConnector.java:159) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.updateEnvoy(EnvoyBridgeHandler.java:332) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.updateData(EnvoyBridgeHandler.java:264) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.lambda$2(EnvoyBridgeHandler.java:161) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
at org.eclipse.jetty.client.AuthenticationProtocolHandler$AuthenticationListener.onComplete(AuthenticationProtocolHandler.java:164) ~[?:?]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:218) ~[?:?]
at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:210) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:481) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:461) ~[?:?]
at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:424) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:374) ~[?:?]
at org.eclipse.jetty.http.HttpParser.handleContentMessage(HttpParser.java:596) ~[?:?]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1723) ~[?:?]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1552) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:208) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:148) ~[?:?]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:80) ~[?:?]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:131) ~[?:?]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:172) ~[?:?]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:555) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:410) ~[?:?]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:164) ~[?:?]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) ~[?:?]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) ~[?:?]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) ~[?:?]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) ~[?:?]
... 1 more
What am I supposed to do?
Same here. March 18 Openhab stopped reporting solar energy production data from the Envoy. Seems to be an authentication issue. Previously I could get into the envoy using last 6 digits of the serial number. Now it requires an Enphase account, logging in with said account it somehow works but it reports errors in the interface and it still doesn’t report production data. May we should move to a Python script using a library like Enphase-API and post the results to MQTT.
If your issue is the same as mine, the authentication alone is insufficient to solve the problem. The latest Enphase binding handles the authentication. The issue is that the data is simply no longer available on the local endpoints after you authenticate. (Not completely true, I think you can still get the instantaneous power, but only that, not the cumulative data as we could get before.)
What Enphase software version do you have? I now have D7.3.130.
Hi John,
I’m still running Openhab 3.4 so I might still have older Enphase binding. The Enphase itself is at 7.6.175. As I mentioned when I log in via the browser I can’t get the production data (json records) either, so I tend to agree most likely a Enphase issue. If I have time I might move over next weekend to latest Openhab and Enphase binding. If that doesn’t help I most likely write a Python script either polling the local Gateway or the Enphase Cloud interface. I’ll keep you posted. Cheers, Rene
Yes, I’m curious to know if you can get the data from the local API now. It’s not available in the firmware I have. The values are 0’s. So python access to the local API won’t work for me.
I’m going to open a case with Enphase to see if they will correct this. Many people on their forum are complaining of this change.
It took more time than expected as I had problems with the OH upgrade to 4.1.2. In the end it was not an OH issue but related to the reverse proxy. After upgrade I needed to update the binding for the Envoy. With the new settings for the binding the connection errors are gone and I get the data as before. I have production data for total system (lifetime, week, today, actual, timestamp latest update) and for individual inverters (actual and max power and timestamp latest update). The sitename I couldn’t find anywhere but I guessed it based on URL at the Enphase site.
My current binding settings are:
Bridge enphase:envoy:Envoy "Envoy" @ "Hall"
[
serialNumber = "122133xxxxxx",
hostname = "192.168.xxx.xxx",
autoJwt = "True",
username = "email@address",
password = "secret",
siteName = magicnumber
]
{
Things:
inverter Inverter_01 "Micro Inverter 01" [ serialNumber="122148xxxxxx" ]
inverter Inverter_02 "Micro Inverter 02" [ serialNumber="122148xxxxxx" ]
inverter Inverter_03 "Micro Inverter 03" [ serialNumber="122148xxxxxx" ]
inverter Inverter_04 "Micro-Inverter 04" [ serialNumber="122148xxxxxx" ]
inverter Inverter_05 "Micro Inverter 05" [ serialNumber="122148xxxxxx" ]
inverter Inverter_06 "Micro Inverter 06" [ serialNumber="122148xxxxxx" ]
inverter Inverter_07 "Micro Inverter 07" [ serialNumber="122148xxxxxx" ]
inverter Inverter_08 "Micro Inverter 08" [ serialNumber="122148xxxxxx" ]
inverter Inverter_09 "Micro Inverter 09" [ serialNumber="122148xxxxxx" ]
inverter Inverter_10 "Micro Inverter 10" [ serialNumber="122148xxxxxx" ]
inverter Inverter_11 "Micro Inverter 11" [ serialNumber="122148xxxxxx" ]
inverter Inverter_12 "Micro Inverter 12" [ serialNumber="122148xxxxxx" ]
inverter Inverter_13 "Micro Inverter 13" [ serialNumber="122148xxxxxx" ]
inverter Inverter_14 "Micro Inverter 14" [ serialNumber="122148xxxxxx" ]
inverter Inverter_15 "Micro Inverter 15" [ serialNumber="122148xxxxxx" ]
inverter Inverter_16 "Micro Inverter 16" [ serialNumber="122148xxxxxx" ]
}
Hi all, I am running OH 4.1.3 with the enphase binding. My gateway is old, with firmware D3.18.10 (f0855e). I am having an issue with the log file getting lots of stack traces that look like this:
2024-06-16 22:21:59.612 [TRACE] [.internal.handler.EnvoyBridgeHandler] - refreshInverters connection problem
org.openhab.binding.enphase.internal.exception.EnvoyConnectionException: Could not retrieve data: HttpConnectionOverHTTP@451068f::SocketChannelEndPoint@4bc0919{l=/[IP of OpenHAB]:54448,r=/[IP of gateway]:80,ISHUT,fill=-,flush=-,to=0/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@451068f(l:/[IP of OpenHAB]:54448 <-> r:/[IP of gateway]:80,closed=false)=>HttpChannelOverHTTP@7cc4c967(exchange=HttpExchange@55ec670a{req=HttpRequest[GET /api/v1/production/inverters HTTP/1.1]@59056646[TERMINATED/null] res=HttpResponse[null 0 null]@3d9558be[PENDING/null]})[send=HttpSenderOverHTTP@67c0219a(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@51a2de5f{s=START}],recv=HttpReceiverOverHTTP@23e7b57b(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0 of -1}]]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.send(EnvoyConnector.java:256) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.retrieveData(EnvoyConnector.java:213) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyConnector.getInverters(EnvoyConnector.java:205) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.refreshInverters(EnvoyBridgeHandler.java:173) ~[?:?]
at org.openhab.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:101) ~[?:?]
at org.openhab.core.cache.ExpiringCache.getValue(ExpiringCache.java:72) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.getInvertersData(EnvoyBridgeHandler.java:230) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.updateInverters(EnvoyBridgeHandler.java:369) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.updateData(EnvoyBridgeHandler.java:265) ~[?:?]
at org.openhab.binding.enphase.internal.handler.EnvoyBridgeHandler.lambda$2(EnvoyBridgeHandler.java:161) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.io.EOFException: HttpConnectionOverHTTP@451068f::SocketChannelEndPoint@4bc0919{l=/[IP of OpenHAB]:54448,r=/[IP of gateway]:80,ISHUT,fill=-,flush=-,to=0/0}{io=0/0,kio=0,kro=1}->HttpConnectionOverHTTP@451068f(l:/[IP of OpenHAB]:54448 <-> r:/[IP of gateay],closed=false)=>HttpChannelOverHTTP@7cc4c967(exchange=HttpExchange@55ec670a{req=HttpRequest[GET /api/v1/production/inverters HTTP/1.1]@59056646[TERMINATED/null] res=HttpResponse[null 0 null]@3d9558be[PENDING/null]})[send=HttpSenderOverHTTP@67c0219a(req=QUEUED,snd=COMPLETED,failure=null)[HttpGenerator@51a2de5f{s=START}],recv=HttpReceiverOverHTTP@23e7b57b(rsp=IDLE,failure=null)[HttpParser{s=CLOSED,0 of -1}]]
Any help to clean this up would be appreciated. What other information would be helpful?
Hello,
Is it still required to use that “out of band” update with openHab 4.1 and/or 4.2?
I’m seeing some issues and before reporting them I’d like to avoid adding unnecessary noise
Hi @hilbrand, I now have the documented link for the Enphase production working. It required a push update from Enphase to my system, but now it works fine.
It’s “GET http://{IQ Gateway_ip}/ivp/pdm/energy” which is listed on page 18 of https://enphase.com/download/accessing-iq-gateway-local-apis-or-local-ui-token-based-authentication
The authentication is the same as before with the token - no change.
Can we get this added to the binding?
Here’s some sample output from my meter which matches what is listed in the above documentation:
{
production: {
pcu: {
wattHoursToday: 267,
wattHoursSevenDays: 138387,
wattHoursLifetime: 1307296,
wattsNow: 378
},
rgm: {
wattHoursToday: 0,
wattHoursSevenDays: 0,
wattHoursLifetime: 0,
wattsNow: 0
},
eim: {
wattHoursToday: 0,
wattHoursSevenDays: 0,
wattHoursLifetime: 0,
wattsNow: 0
}
},
consumption: {
eim: {
wattHoursToday: 0,
wattHoursSevenDays: 0,
wattHoursLifetime: 0,
wattsNow: 0
}
}
}
I’ve found that the Python script here: GitHub - greiginsydney/Get-EnphaseData-v7.py: A custom sensor for PRTG that queries your on-site Enphase solar controller, the Envoy. (v7 version) works quite well with the latest Enphase Envoy API, and I modified it to push the data I need into the OH rest API. Not quite as nice as the binding, but works well for me. I run it from cron every 10 minutes.
Note: if you have the new Enphase firmware and you store or use the lifetime energy, you’ll need to add an offset to the value coming from http://IP/ivp/pdm/generation. You can use the app to see the lifetime, then compare that to the value from new API. Subtract to get the offset. Apparently Enphase wiped out the lifetime energy when they switched the API, but their own servers remember the old value, so they can add that to the value shown in their app. You need to do the same if you want your true lifetime number.
Hello
I’m having an issue where the envoy gateway becomes unreachable but when I disable/enable the bridge I get this error message:
Could not login to Envoy with the access token. Envoy returned status:200
This is very strange, and the only workaround so far is to leave the bridge disabled for 10 minutes.
Do you have any idea what’s causing this?
same here , any news ?
Could someone reading here and using the binding please summarize the state of Enphase support in OH ?
So there’s an official binding in current OH release (4.3.4) Enphase - Bindings | openHAB right?
Is it the one this thread is about?
There’s posts in the thread to mention Enphase introduced breaking changes with some firmware.
So what’s the hardware required and what’s the firmware requirement to work with this binding?
Thanks.
I’m running openHAB 4.3.2 stable on windows and the binding as a standard add-on.
My Envoy gateway is currently running firmware D8.2.4264.
The binding is currently working but I don’t actively use the data as I have a Givenergy battery which Enphase doesn’t see. The Envoy hub will see solar production or grid import/export but doesn’t show current flow correctly when the battery is suppling the house loads.
I’m on D8.2.4345 (3f3de0) and the binding connects successfully, but the data I care about (power today, lifetime) are all 0. I believe this is because the binding has not been updated to the new documented endpoint. The python script above works well for me. I do not know if it is possible to determine which endpoint to use based on the software version. This stopped working for me back on D7.3.130, but others seem to have it working on similar or later versions with the original endpoint. The binding may need a setting to know which endpoint to use or need to try both and see which gives proper values.
I’m still getting all the values on my setup. I was also running separately the ‘http’ binding (Enphase - Envoy V7 local API to CURL-JSON on Windows) and using the live data every 10 seconds.
I now use data from the ‘myenergi’ binding as that can see solar production and battery or grid supply or consumption. It would be nice to get kWH from that binding but it’s not data I need, just nice to have.