New binding available: SolarEdge binding

@AlexF - Thanks Alex :+1:

Latest 2.4-SNAPSHOT version includes the fix and works for me.

Just installed the new version and can confirm it is also working for me again.
Thanks Alex!

Bad news: Solaredge ha implemented a Captcha mechanism in their login. This makes it hard to login automatically. In the past it was possible to use an existing session cookie from the browser in openhab as it is valid for nearly 80 years and only gets invalidated on password change.
I do not like this way but I do not want to make the binding even more complex because of the captcha stuff.

Anything that can be done? I would hate loosing the functionality your binding gave us :slight_smile:

The binding will probably have to use the regular SolarEdge API instead, with the result that the binding will have to be programmed from scratch? :scream:

Guess I encounter the login/chaptcha login?
Just restarted my openHAB server, and Solaredge data is no longer coming in… :cry:

We are sorry, but due to an internal error, we cannot fulfill your request. Please try again. If the problem persists, please contact SolarEdge support for assistance.

I have already fixed this at least temporary until Solaredge changes the behaviour once again.
The user login is now done manually and the session cookie is instead used. It is a bit like a hack but it works. The readme gives at least a short hint how to configure the binding. You could try it already.

A long term solution can only be to use the official API which means only 300 updates per day -> one update per 10 minutes. Thats better than nothing but still not 100% satisfying.

BR
Alex

1 Like

Thanks for the fix, unfortunately, I’m not sure what to do to get it to work. I am also getting the above error messages (“We are sorry, but due to an internal error…”).

I am using the latest 2.4.0 snapshot version from 04-Jun-2018 16:08. Not sure what to look for in the readme, I can’t seem to find anything to change. Could you clarify? Thanks in advance :slight_smile:

Hello Mario :wink:
You need to Change the Thing configuration. Just add the the parameter:

token (required)
can be retrieved from browser’s cookie store when logged into the solaredge website. It is called ‘SPRING_SECURITY_REMEMBER_ME_COOKIE’

Just open the Solaredge Page in Firefox, Login, and press F12, then go to the TabPage “Web-Speicher”.
Then just copy the value of ‘SPRING_SECURITY_REMEMBER_ME_COOKIE’ into your Thing configuration :slight_smile:

Hope it helps :wink: If not, just contact me :wink:

Best regards
Tobias

Had to search a bit in firefox, the tabbapage “Web-Speicher” is in my language ‘opslag’ (=storage). :wink:
For me, the token is expering on 2086. So still some time?

I’ve added this into my thing file, but it seems that i’m still be missing something. Still gotting the “We’re sorry” error.

What I’ve tried:

solaredge:generic:se15000     [ username="MYLOGIN", password="MYPASSW", solarId="MYID", token="MYVERYLONGTOKEN" ]

The same with the

solaredge:generic:se15000     [ username="MYLOGIN", password="MYPASSW", solarId="MYID", token="MYVERYLONGTOKEN", LegacyMode="True" ]

Any hint what I’m doing wrong?

Thanks Tobias! Unfortunately, I seem to be having the same problem Ben / brononius has. I added the token, but it’s still not working.

Please remove username and password, otherwise the binding will most likely not start at all because the expected parameters do not match the actual ones.
In addition it might help to reconnect to your ISP to get a new IP because the “We are sorry” error is Solaredge’s coded message for “your IP is banned because you are a bot”.

BR
Alex

I now have the following thing config:

Thing solaredge:generic:se3000 [ solarId="123456", token="MYLONGTOKEN", pollingInterval=30 ]

Error message now says:

solaredge:generic:se3000 (Type=Thing, Status=UNINITIALIZED (HANDLER_CONFIGURATION_PENDING), Label=SolarEdge, Bridge=null)

I should have gotten a new IP afterwards, and after that, I restarted openHAB.

Is there any hint in the logs?
Could you check in the karaf console that the new version of the binding is installed and being used?
Sometimes multiple versions of a binding are active at the same time.

I can’t seem to find anything in the logs.

I have version 2.4.0.201806041603 installed, which is the one I found here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.solaredge/2.4.0-SNAPSHOT/

Ok that’s the problem. I have first fixed the latest DEV version which can be downloaded here:
http://friese-de.eu/openhab2/

Your version does not include the fix up to now.

1 Like

Indeed!
This version works (even with username/password still in the thing file)…

Thanks a lot!!!

Yea, that one works! Thanks! :slight_smile:

Damned, guess I spoke to soon.
I’m getting following error now:

2018-06-11 18:29:43.569 [INFO ] [clipse.jetty.client.ResponseNotifier] - Exception while notifying listener org.openhab.binding.solaredge.internal.command.LiveDataUpdate@7c0c510e
java.lang.NullPointerException: null
        at org.openhab.binding.solaredge.internal.model.LiveDataResponse.getValues(LiveDataResponse.java:108) [241:org.openhab.binding.solaredge:2.4.0.201806111309]
        at org.openhab.binding.solaredge.internal.command.LiveDataUpdate.onComplete(LiveDataUpdate.java:68) [241:org.openhab.binding.solaredge:2.4.0.201806111309]
        at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:458) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:405) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:277) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1617) [75:org.eclipse.jetty.http:9.3.21.v20170918]
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1350) [75:org.eclipse.jetty.http:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:159) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:120) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:70) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:90) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:115) [72:org.eclipse.jetty.client:9.3.21.v20170918]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [76:org.eclipse.jetty.io:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [87:org.eclipse.jetty.util:9.3.21.v20170918]
        at java.lang.Thread.run(Thread.java:748) [?:?]

This is really weird.

    public Map<String, String> getValues() {
...
        if (siteCurrentPowerFlow != null) {
...
            // next line is "108"
            for (Connection con : siteCurrentPowerFlow.connections) {
...

Basically it is possible that the variable “siteCurrentPowerFlow” is set to null by another Thread just after the null check. But this should never happen as this is a one-time-use data object which is never shared between threads. So I do not have any idea.