Solaredge API problem

[jannl]

Can some admin merge the 3 solaredge api threads?

[waltervl]

Can some admin merge the 3 solaredge api threads?

I have merged 2 topics into 1 and moved some posts of another one in this thread too. So hopefully everyoen stays focusses on this thread....

[gbonny]

The "Solaredge API problem" seems to be on SolarEdge side. People using Home Assistant are reporting issues recently as well:
https://github.com/home-assistant/core/issues/159905
Only one device was working for me yesterday: "Inverter PV Power"

You can verify your API key is working, when the SolarEdge API is working off course, using a web browser via:

Code: Select all

https://monitoringapi.solaredge.com/sites/list.json?size=1&api_key=<your_key>

This shows information of your site. Extract your siteid and then try:

Code: Select all

https://monitoringapi.solaredge.com/equipment/<site_id>/list.json?api_key=<your_key>

This shows your equipement details.

Try to deactivate/activate "SolarEdge via Web API" from Hardware once, or reboot Domoticz once. Fingers crossed it will work from then on, when the sun shines. Wasn't there an SolarEdge API issue in december last year as well?!

Edit: deactivate/activate worked for me.


One side question: Is there anyone who has a SolarEdge Battery in his/her system, and it is working/visible in Domoticz?
@Gizmocuz, I might see an issue when fetching data in https://github.com/domoticz/domoticz/bl ... dgeAPI.cpp

Code: Select all

void SolarEdgeAPI::GetBatteryDetail
.. # expects JSON here:
ExtraHeaders.push_back("Accept: application/json");
.. # url returns XML in browser:
sURL << "https://monitoringapi.solaredge.com/site/" << m_SiteID << "/currentPowerFlow?api_key=" << m_APIK;

I cannot verify myself whether this works as I have no battery installed.

It appears that this doesn't show json output in my browser:

Code: Select all

https://monitoringapi.solaredge.com/site/<site id>/currentPowerFlow?api_key=<api_key>

but this does (mind the .json in the URL):

Code: Select all

https://monitoringapi.solaredge.com/site/<site id>/currentPowerFlow.json?api_key=<api_key>

Same works for, although those URLs are not used by Domoticz (mind the .json in the URL):

Code: Select all

https://monitoringapi.solaredge.com/site/<site id>/details.json?api_key=<api_key>
https://monitoringapi.solaredge.com/site/<site id>/dataPeriod.json?api_key=<api_key>
https://monitoringapi.solaredge.com/site/<site id>/overview.json?api_key=<api_key>

[jannl]

This: https://monitoringapi.solaredge.com/sit ... =<api_key> is what is used in de code.
Everry url in Domoticz Solaredge.cpp ends with .json, so that should be ok. Not changed in de the last year

[waltervl]

This: https://monitoringapi.solaredge.com/sit ... =<api_key> is what is used in de code.
Everry url in Domoticz Solaredge.cpp ends with .json, so that should be ok. Not changed in de the last year

That does not seems to be true, it currently is missing the .json for currentPowerflow:
https://github.com/domoticz/domoticz/bl ... I.cpp#L458

The rest uses .json indeed.

[jannl]

This: https://monitoringapi.solaredge.com/sit ... =<api_key> is what is used in de code.
Everry url in Domoticz Solaredge.cpp ends with .json, so that should be ok. Not changed in de the last year

That does not seems to be true, it currently is missing the .json for currentPowerflow:
https://github.com/domoticz/domoticz/bl ... I.cpp#L458

The rest uses .json indeed.

My Bad, you are right, didn't look good.

Should be a simple and easy fix if that is the problem. But since it mostly works I doubt that is the (only) problem.

Edit: both work, the one without .json delivers XML, the one with .json delivers json. So the fix is not that easy

And still, I do not think Domoticz is the problem

Edit2: hm, the strange thing is the code seems to parse json.....

[JaapB]

This: https://monitoringapi.solaredge.com/sit ... =<api_key> is what is used in de code.
Everry url in Domoticz Solaredge.cpp ends with .json, so that should be ok. Not changed in de the last year

That does not seems to be true, it currently is missing the .json for currentPowerflow:
https://github.com/domoticz/domoticz/bl ... I.cpp#L458

The rest uses .json indeed.

My Bad, you are right, didn't look good.

Should be a simple and easy fix if that is the problem. But since it mostly works I doubt that is the (only) problem.

Edit: both work, the one without .json delivers XML, the one with .json delivers json. So the fix is not that easy

And still, I do not think Domoticz is the problem

Edit2: hm, the strange thing is the code seems to parse json.....

Problem is that you need a restart of domoticz to get the connection re-establised and that only works when solaredge is producing. I guess that is what has changed at the solaredge part of the connection.

[jannl]

No you (I) don't. Connection always comes back automatically after some time. The app and web interface also have issues with displaying anything besides the live data.

[JaapB]

No you (I) don't. Connection always comes back automatically after some time. The app and web interface also have issues with displaying anything besides the live data.

I've been monitoring it for a few days now but connection does not automatically come back and there are no issues with the app and web-interface.

Mayb it's a combination of things that are at the base of these problems, most of the times a restart of domoticz fixes things but not alle of the time.

[robkoel]

for me, (on linux) changing the ipv6 / ipv4 priority to ipv4 first "solved" the issue.

to check the current priority (you will see the ipv6 address first in the list):
$ getent ahosts monitoringapi.solaredge.com
2606:4700::6812:1dbb STREAM monitoringapi.solaredge.com.cdn.cloudflare.net
2606:4700::6812:1dbb DGRAM
2606:4700::6812:1dbb RAW
2606:4700::6812:1cbb STREAM
2606:4700::6812:1cbb DGRAM
2606:4700::6812:1cbb RAW
104.18.29.187 STREAM
104.18.29.187 DGRAM
104.18.29.187 RAW
104.18.28.187 STREAM
104.18.28.187 DGRAM
104.18.28.187 RAW

after uncommenting the following line in /etc/gai.conf:
precedence ::ffff:-:0/96 100
the priority is set to ipv4, then ipv6

to verify:
$ getent ahosts monitoringapi.solaredge.com
104.18.28.187 STREAM monitoringapi.solaredge.com.cdn.cloudflare.net
104.18.28.187 DGRAM
104.18.28.187 RAW
104.18.29.187 STREAM
104.18.29.187 DGRAM
104.18.29.187 RAW
2606:4700::6812:1dbb STREAM
2606:4700::6812:1dbb DGRAM
2606:4700::6812:1dbb RAW
2606:4700::6812:1cbb STREAM
2606:4700::6812:1cbb DGRAM
2606:4700::6812:1cbb RAW

the last couple of days i didn't have any issues...

short-time happiness : today the same errors as before.

[JaapB]

for me, (on linux) changing the ipv6 / ipv4 priority to ipv4 first "solved" the issue.

to check the current priority (you will see the ipv6 address first in the list):
$ getent ahosts monitoringapi.solaredge.com
2606:4700::6812:1dbb STREAM monitoringapi.solaredge.com.cdn.cloudflare.net
2606:4700::6812:1dbb DGRAM
2606:4700::6812:1dbb RAW
2606:4700::6812:1cbb STREAM
2606:4700::6812:1cbb DGRAM
2606:4700::6812:1cbb RAW
104.18.29.187 STREAM
104.18.29.187 DGRAM
104.18.29.187 RAW
104.18.28.187 STREAM
104.18.28.187 DGRAM
104.18.28.187 RAW

after uncommenting the following line in /etc/gai.conf:
precedence ::ffff:-:0/96 100
the priority is set to ipv4, then ipv6

to verify:
$ getent ahosts monitoringapi.solaredge.com
104.18.28.187 STREAM monitoringapi.solaredge.com.cdn.cloudflare.net
104.18.28.187 DGRAM
104.18.28.187 RAW
104.18.29.187 STREAM
104.18.29.187 DGRAM
104.18.29.187 RAW
2606:4700::6812:1dbb STREAM
2606:4700::6812:1dbb DGRAM
2606:4700::6812:1dbb RAW
2606:4700::6812:1cbb STREAM
2606:4700::6812:1cbb DGRAM
2606:4700::6812:1cbb RAW

the last couple of days i didn't have any issues...

short-time happiness : today the same errors as before.

Too bad this did not work.

I've been looking at some other possible sollutions and found it in editting the file domocookies.txt in the config directory of domoticz on my raspberry. I uncommented all the lines with solaredge in it and on my test-system this has resulted in automaticly receiving data from the portal when the solaredge is delevering power for two days in a row now.

On my main system I did not make this change and there the problem still exists.

I'll keep monitoring this and maybe it is a sollution.

[edwin1234]

Nice,
Let us know when your shure.

[JaapB]

Nice,
Let us know when your shure.

After editting the domocookie.txt file the test-system worked for 4 days, on day five it did not start logging in the morning.

Looking at the webportal and app of solaredge that keeps working so somehow it has something to do with how domoticz handels this data since the domocookie file is generated and changed bij domoticz.

[Kedi]

Uncommenting did not work for me, because the '#' are writen back to the 3 cookies.

[Bjornen]

Hi. I have the same problem reported in this thread.

2026-02-19 07:22:25.074 Error: Solpaneler: Error getting http data (Equipment details)!
2026-02-19 07:22:25.254 Error: Solpaneler: Error getting http data (currentPowerFlow details)!

Sometimes it just starts to work, sometimes I have to stop the worker and start again, sometimes I reboot and it can still be problems and suddenly it works again. And another thing is that (I reboot my Raspberry every night at 2AM) it starts polling Solaredge right away and continues through the night. Which is a new behaviour.
All this started on second or third of January.

Raspberry Pi 4 with Trixie and Docker. Up to date.
Domoticz Version: 2025.2 (build 16818)
Build Hash: 2f9016a8b
Compile Date: 2025-10-19 11:41:46
dzVents Version: 3.1.8
Python Version: 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]

Also have Zigbee2mqtt and Mosquitto installed.

Database problem?

Regards!

[Bjornen]

Some time ago I did manual calls to Solaredge monitoringapi while Domoticz did not work.

========================
# Get site info works OK
========================
{"sites":{"count":1,"site":[{"id":nn,"name":"Address","accountId":nnn,"status":"Active","peakPower":7.2,"lastUpdateTime":"2026-01-25","installationDate":"2022-06-15","ptoDate":null,"notes":"","type":"Optimizers & Inverters","location":{"country":"Sweden","city":"a town","address":"an address","address2":"","zip":"nnnnn","timeZone":"Europe/Stockholm","countryCode":"SE"},"uris":{"DETAILS":"/site/nnnn/details","DATA_PERIOD":"/site/nnnn/dataPeriod","OVERVIEW":"/site/nnnn/overview"},"publicSettings":{"isPublic":false}}]}}

========================
# And get device info
========================
{"reporters":{"count":1,"list":[{"name":"Inverter 1","manufacturer":"SolarEdge","model":"SE7K-RW0TEBEN4","serialNumber":"7XXXXXXX-YY","kWpDC":null}]}}

========================
# This is response when nothing is produced I guess.
========================

{"data":{"count":0,"telemetries":[]}}

========================
# And later suddenly this is when it works OK.
========================

{"data":{"count":1,"telemetries":[{"date":"2026-01-25 10:00:06","totalActivePower":0.0,"dcVoltage":30.4985,"powerLimit":100.0,"totalEnergy":2.30435E7,"temperature":6.74658,"inverterMode":"MPPT","operationMode":0,"vL1To2":392.332,"vL2To3":393.247,"vL3To1":393.392,"L1Data":{"acCurrent":0.0,"acVoltage":226.617,"acFrequency":50.0031,"apparentPower":0.0,"activePower":0.0,"reactivePower":0.0,"cosPhi":0.0},"L2Data":{"acCurrent":0.0,"acVoltage":227.458,"acFrequency":50.002,"apparentPower":0.0,"activePower":0.0,"reactivePower":0.0,"cosPhi":0.0},"L3Data":{"acCurrent":0.0,"acVoltage":226.594,"acFrequency":50.0024,"apparentPower":0.0,"activePower":0.0,"reactivePower":0.0,"cosPhi":0.0}}]}}