Solaredge API problem

[jannl]

I see that to. Looks like a problem at Solaredge.

[jannl]

The plugin map in- and outside the container is the same map.

Don't forget to stop and start the container after changing something in 1 of the plugin maps.

And remember to install the modbus library INSIDE the container.

Customstart.sh basically resides in the container, but also reachable from outside the container. See the Wiki.

[jjnh]

Same issue here. Not getting any SolarEdge data anymore.

I also use PVOutput with the same API and there data from SolarEdge is coming in.

So it looks like something related to the plugin in Domoticz.

[jjnh]

I'm also experiencing issues with the SolarEdge API connector throwing error "Error getting HTTP Data" since the upgrade to 2025.2 (from 2023.1).

I'm using the same API key in PVOutput.org and there it is working fine.

So this definitely looks like something related to the Domoticz plugin, not to SolarEdge.

[jannl]

The Solaredge website frequently does not look good. (no charger, no smarthome, no battery) The app mostly works fine.
It is just Domoticz can not retrieve data every now and then.
I still think Solaredge is the problem and not Domoticz. I would think if it was Domoticz the problem would occur always.

[jannl]

No errors today and everything seems to work fine.

Pi 3b running 2025.2 16990 in Docker

[jjnh]

Yesterday I received some data. Today only errors.

I'm running version 16818 in Docker.

[jjnh]

You triggered me with your question.
I also have a slave Domoticz running on my Synology.

What I did:
1. Installed the SolarEdge API on the slave --> it seems to pull data just fine.
2. Installed a second SolarEdge API in my primary Domoticz --> to my surprise that pulls data just fine.

So there seems to be something wrong with the old API connection in Domoticz.

I will keep monitoring the situation. If needed I can move the devices to the new API connection and remove the old one.

[jjnh]

Hi,

It could all be a coincidence, but I just installed a second API interface (under hardware) with the same API key and that is returning data now. The old API connection is still there but shows no data.

Let's see how this develops in the upcoming days.

PVoutput still going strong without issues.

[jjnh]

Apologies it took a few days (and tries) and I found the following:

- the slave installation of Domoticz has the same issue after a day
- the 2 connectors on my primary Domoticz are both throwing errors
- the errors start appearing around 16:00 when the sun goes down
- the errors will keep going in the morning unless I disable and reenable the hardware
- once the hardware is reenabled data starts flowing in
- the data PVOutput keeps on going without issues

Maybe a workaround could be to stop the SolarEdge hardware in Domoticz once the sun goes down and restart it when the sun comes back up.

I've created a switch in my Slave installation that controls the enable/disable of the SolarEdge API.
Scheduled it to go off at sunset and turn back on 15 minutes after sunrise.

The switching is done by a JSON command. This command is specific to your hardware and can be found by:

- open the hardware page
- hit F12 in your browser (mine is chrome) to open the developer window
- switch to the "network" tab in the developer window
- disable or enable the hardware
- look at the JSON commands it shows in the network tab

There are better explanations on how to do this in the forum

[jannl]

The error 'getting http data' occurs randomly'. Mostly during the night, but also during the day. It also disappears after 1 or more errors.

So I am still not sure this is (solely) a Domoticz issue.

Edit: I read de Solaredge API sometimes has different response times from a fewe hundreds of ms to 5-10seconds.

[JaapB]

The error 'getting http data' occurs randomly'. Mostly during the night, but also during the day. It also disappears after 1 or more errors.

So I am still not sure this is (solely) a Domoticz issue.

Edit: I read de Solaredge API sometimes has different response times from a fewe hundreds of ms to 5-10seconds.

I do have the same issues with Solaredge through the API and it needst restarting domoticz to get fixed, got the same issue on my main system as on my shadow sytem. Restarting solaredge hardware doesn't help.

[BartSr]

I started all over with fresh linux image and domoticz in docker. Followed all instructions and got the plugin do what expected. But..... it appears that my inverter doesnot sent data once the plugin asks for.
Than I had a closer look in the inverter's settings and couldnot find anything about modbus. I've been told no setting should be required. I own the solaredge inverter type SE3000 installed june 2018. According info from the webportel. It's the one with the display on it.
Any advices?

[BartSr]

Hi!
Since a few weeks the solaredge api fails to provide data. I know more members here faced same trouble.
Here in Rotterdam area still problems. What experience do you have?
I tried swapping to modbus tcp but it appears my inverter SE3000 does not provide modbus tcp data.

Edit Waltervl: moved this question to other already running discussion.

[BartSr]

@Walter
Not happy you moved this post. Allthough I started complaining about the api most posts regarded the modbustcp solution.
My lasf post is more general about solaredge api status.

[jvdz]

I have a se5000 with display and for me the modbus works fine. Did you open the menu on the inverter and check for the modbus settings?

Ps .. your last post does belongs here, as this is were the whole discussion has been done regarding the api error. unless you intent to make a bug report .
I have disabled the api a while ago when domoticz was regularly giving problems due tob this api hardware.

[BartSr]

I checked all settings of the inverter and did not find any about modbus. Just RS485. As there's also something to select about batteries I'm assuming the software might have been updated as in 2018 batteries where not yet common practise. Also this inverter does not has an opportunity to go into AP mode and get more items to set.

[jvdz]

It shows in the network settings as it is modbus over tcpip. These are the steps according the internet:

Enabling Modbus TCP on SolarEdge Inverter
Long hold "OK" (the rightmost button)
Enter the password as "Up Down OK, Up Down OK, Up Down". ( The screen will display 12312312)
Use the down arrow to scroll down to Communication.
Select LAN and press OK.
Enable ModBus TCP.

[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:
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.

[jannl]

For now it always has resolved itself by just waiting. Most of the time the data in the app also is not completely correct. Only the live data(which is not up to date in the api because of the 300l api calls limit a day) is correct.