The current implementation updates every 15 minutes due to a 300 request/day limit. However, I feel like this could be done ‘smarter’ (in true Home Assistant style haha). For example, at night the solar panels are producing no energy; 1 retrieval per e.g. 1 hour would be fine with me. During the daytime, and especially around 12:00, the panels are producing a lot of energy and 1 call per e.g. 5 minutes would be nice to have.
Would it be possible to make the retrieval schedule more dynamic? I’m not sure about specific implementation details (I’m very new to home assistant), but maybe implement a high/medium/low frequency and bind them to custom time intervals or maybe even entities (sun up/down)? Though the latter is of course maybe a bit more/too ‘dangerous’ as you’re not sure if you’re going over the 300 limit.
For example, for my solar panels I’d put something like this:
High frequency: 10:00-14:00 every 5 minutes
Medium frequency: 6:00-10:00 / 14:00-20:00 every 15 minutes
Low frequency: 20:00-6:00 every 1 hour
Total requests:
4*12*3= 144
10*4*3=120
10*1*3=30
total = 144 + 120 + 30 + 4 = 298
Now, I don’t know if this is worth the extra hassle, but I think it’s an interesting idea to think about at least.
Nice idea! I think it would also work with sunrise/sunset. Would just have to be calculated once per day (eg midnight) how long the high frequency time is and divide it by remaining requests after low frequency time to get the target interval.
Maybe leave some room if eg. the phone app shares a limit pool.
Doesn’t SolarEdge provide any local API like Modbus?
PS: don’t forget to vote for your own feature request
The issue with the sun up/down thing is that I’m afraid it would run into quite a complicated calculation. Because I believe (not 100% sure) based on a quick look at the Github code, that the solaredge integration (currently) fires 3 requests every 15 minutes. So if you take the entire sun-up interval as high-frequency you’re gonna run out of requests real fast or you have to calculate some kind of frequency graph to stay within the 300 limit
Nevertheless, I’m sure someone could figure something out that makes at least a little better use of the 300 request limit, especially considering like 50% of the time the panels are barely producing anything anyway haha. Plus, in my calculations I assumed 3 requests every x minutes as it currently does, but maybe not all 3 calls have to be increased anyway? Someone with more knowledge about the SolarEdge API could answer that.
And yes, there’s supposedly a SolarEdge Local API integration too. But according to the docs it seems to be actively removed by SolarEdge and it also doesn’t show up in the integration list for me so maybe it’s discontinued? And there’s indeed a community Modbus integration too, but I haven’t looked into that yet, nor do I know if my setup is even compatible anyway. But I sure will take a a better look soon.
Oh, and I indeed didn’t know I could vote for my own suggestion haha. Thanks for the tip
I’ve started making some modifications to the SolarEdge component that calculates new update intervals every sunrise/sunset event. The daily limit will be distributed based on a ratio, currently set to 0.95 for the daylight period. So in this case 95% of the daily limit will be used during daylight for the 3 API calls that needs frequent update.
Please note that the changes currently includes test code (no actualy API calls are made) and is thus not really usable, yet.
I wanted to add that my SolarEdge setup includes a power/energy monitor that monitors not only PV, but also the grid (both from the SolarEdge cloud API) and the grid of course needs monitoring both day and night. If the SolarEdge Integration is to be changed to have a dynamic polling interval, please make this a configurable option (to disable it) as I need the monitoring interval to be the same for both day and night.
For a more frequent update of the production (SolarEdge) I would still recommend the usage of the SolarEdge Modbus integration.
This integration would allow you to get production related data in a very high frequency - and also get the current inverter status (running, sleep mode, and so on)
It should also be a more stable solution in terms of “network connection issues” which I have seen more often when using the monitoring api.
The SolarEdge Integration which is used for getting monitoring information is still usefull - since it does provide some infomration the modbus integration can’t - but for these information, the current cycle is pretty much ok…
This screenshot is showing my SolarEdge Dashboard… blue are the data I am getting from the Modbus Integration, purple comes from the Monitoring integration (some of them are provided by the integration, some of them are provided by a node red integration which does also poll the monitoring api).
I would rather request the possibility to get the environmental benefits and the lifetime revenue also by the SolarEdge Integration (which would make my nodered call obsolete)
Note even with the current 3 API calls per 15 minutes SolarEdge is intermittently throwing 429’s (Too Many Connections).
That means even redistributing the calls to mostly be used during the daytime (which is a great idea) will not be a panacea.
I’ve raised a ticket with them, will feed back if I get any useful response.
As far as I got, the Integration does different API calls related to the corresponding Data (Overview, EnergyDetails, Inventory, etc.)
As I could see from the dashboard, each of them does have its own Delay-Timer… and the important requests, such as Energy Details, Overview and some others have the same 15min timer.
That means, these requests will be triggered nearly at the same time - and the integration does probably run into another limitation of the API:
“The monitoring server API allows up to 3 concurrent API calls from the same source IP. Any additional concurrent calls will return HTTP 429 error – too many requests.”
Tbh, since I am seeing these 429s intermittently rather than structurally, my gut feeling is that
Either there is something else also consuming from the same limited connection pool (app, installer’s system?)
Or, more likely, the solaredge server has load issues and the connectivity limit is configured based the server load rather than on a limit per day / maximum concurrent amount, but that is just a guideline.
@JelleKoster I would also suspect server load issues. I’ve changed my solaredge component to only call the “overview” api call during the day (ie. only 1 of the 3 frequently called api endpoints), and still see some 429s once in awhile. This should rule out potential issues with the concurrent limit. Also the 429s occur randomly during the day, so it’s most likely not related to the daily limit either.
I found this GitHub issue, let’s continue the 429 investigation there and return this thread to it’s OP subject of dynamically calling the APIs on a smarter schedule.
I packed all this into a cron job and now the data comes every 5 seconds.
The setup has been running for 10 days now - the session cookie is still valid. Let’s see when that expires!
Intermediate status: The session cookie is still valid. Perhaps there is also the possibility of extending the SolarEdge integration with the “Session Cookie” option?
