Every day day production drops to 0 W on every optimizer

[jlai79]

Every day shortly after 6 p.m., data transmission stops. All optimizers then continuously report 0 W. What could be the reason for this?

I haven't found any error message yet.

[al090187]

I have the same, but just after 5pm. Is there a rate limit we are reaching?

[kennyb03]

Seems like some kind of rate limit. For me, it goes to 0 for most of the day. So I think I'm using up most of my queries at night!

[markroyle]

I have the same problem in that at some time around 1800 everything drops to zero. I have 29 panels on different parts of the roof and all of them drop to zero at the same time. If I restart homeassistant after this time then the panels start registering power again for about 30 minutes then drop to zero again. UPDATE I am now finding that all panels drop to zero at around 1650 in the afternoon. I am in southern England if that potentially makes any difference.

[tnholden]

I have the same issue as above, around 16:50 everything will drop to zero.

[mjb1416]

I have the same issue around 16:30. Interesting to note this happened on the first day I set up the integration at 15:00 so unlikely to be due to running out of queries. Like markroyal I've found that restarting Home Assistant fixes the issue for a while.

[okpud]

Same for me. Reporting no power on all optimizers during the middle of the day, every day. Assumed it was a query limit w/ SolarEdge.

[tluschin]

Same also for me. I am located in SLO. It works good during winter time. Here an example from February where sunrise was before 8 o'clock

But during summer where sunrise was before 5:30 it stops recording some hours before sunset.

Maybe the offline detection of the integration does not work correctly which inserts a "0" if the value of the last measurement is older than 1 hour.

[FrodoVDR]

Same by me

[al090187]

Just had a thought...... Does the problem appear only when there are more than 12 hours of sunlight? I wonder if either the solaredge site, or the plugin, works in 12 hour clock, so when it scrapes the value and there is another 4 'o clock on the same day then it doesn't record the value?

For example, my first value today was 4:56 am, and the last value was 4:44pm, so exactly 12 hours, minus the 15 minute refresh period. The next value would have been at 4:56pm, so maybe caused an error somewhere. I think the original developer has gone AWOL, so we need to find someone that knows what it is doing really.

[lpersoons]

Same issue here. Around 17:20 all optimizers drop to 0. Any news on this issue?

[mjb1416]

I've spent the day looking at the code and working out where it obtains it's data. I now believe this issue is down to SolarEdge not the integration. If you login to https://monitoring.solaredge.com/ and go to the layout tab, right click on a panel and select Info you will see that the Last Measurement time is not up to date. This gets worse as the day goes on until it is more than an hour out of date. At this point the integration displays zero rather than showing old data.

[al090187]

Oh brilliant! Well spotted. Just checked mine and yes, it says last value was 7pm and it is 9:15 😮 Now do we get Solaredge to fix it their end, or can we tweak the code to not worry if the data is more than an hour old?

I guess first we need to know what's correct. If it sees a value at 7pm, but it says 6pm, is the value actually from 7pm with a dodgy update time, or 6pm delayed? And then does the integration save it as the value for 7pm when it retrieves the value, or 6pm, when it thinks it should have been reported?

[tronikos]

See #94

[jlai79]

I also had a deeper look and tried something:

Patch – keep sensors updating in the afternoon

Add the three snippets below to custom_components/solaredgeoptimizers/sensor.py. Nothing else in the file has to change.

---

1 · Imports (top of file)

# add right below the existing imports
from datetime import timezone
from homeassistant.util import dt as dt_util   # HA helper, tz-aware

---

2 · UTC “now” for the age check

Inside MyCoordinator._async_update_data replace

timetocheck = datetime.now() - CHECK_TIME_DELTA

with

timetocheck = dt_util.utcnow() - CHECK_TIME_DELTA    # tz-aware UTC

---

3 · Mark portal timestamps as UTC

Still in the same method, find the loop that iterates over the optimizers:

for optimizer in data:
    if optimizer.lastmeasurement > timetocheck:
        update = True
        break

Replace that block with

for optimizer in data:
    ts = optimizer.lastmeasurement

    # SolarEdge returns a *naive* UTC timestamp – tag it as UTC
    if ts.tzinfo is None:
        ts = ts.replace(tzinfo=timezone.utc)

    if ts > timetocheck:
        update = True
        break

---

Why it works

• datetime.now() is naive/local; SolarEdge timestamps are naive/UTC. After one hour of summer-time offset those values look “too old” and the coordinator returns None.
• Switching the comparison to tz-aware UTC (dt_util.utcnow()) and tagging the portal value as UTC makes the >1 h test accurate, so updates continue throughout the day.

I changed that and it seems to work:

[lpersoons]

I will try this fix at once. We will shortly see whether it's working or not. Normally the data stops around 17:20-17:30 which is in 15min from now. We'll see if the fix is also working for me. Thanks already for sorting this out @jlai79

[mjb1416]

I can see why this might fix the issue as the times coming back from SolarEdge are marked as GMT.

E.G. "lastMeasurementDate":"Fri Jul 11 15:44:23 GMT 2025"

The code that converts this to a date ignores the GMT part.

rawdate = json_object["lastMeasurementDate"]

new_time = "{} {} {} {} {}".format( rawdate.split(' ')[0],rawdate.split(' ')[1],rawdate.split(' ')[2], rawdate.split(' ')[3],rawdate.split(' ')[5] ) self.lastmeasurement = datetime.strptime(new_time, "%a %b %d %H:%M:%S %Y")

But this does not explain why the code works in the mornings. If the old code assumed a reading a 09:00 GMT was really at 09:00 BST it would be over an hour old when read at 10:01 BST.

I need to check what SolarEdge returns tomorrow morning.

[markroyle]

I have implemented the fix from @jlai79 and things now appear to be working. The latest reading appears for 19:53 and I have not had any readings that late recently. Still a bit premature to say the issue is fixed but will report back in a couple of days.

[mjb1416]

Just checked the data for one of my panels and I'm getting the response

SE.systemData = {"countrySettings":{},"description":"Panel 1.1.1","lastMeasurementDate":"Sat Jul 12 07:03:46 GMT 2025","manufacturer":"Trina Solar Energy","measurements":{"Current [A]":"0.49","Optimizer Voltage [V]":"38.25","Power [W]":"20.11","Voltage [V]":"41.25"},"model":"Vertex S+ 445W N-Type Full Black Mono","phase1Measurements":{},"phase2Measurements":{},"phase3Measurements":{},"secondarySerialNumbers":{"serialNumber":"14F6CC26-FC"},"serialNumber":"14F6CC26-FC","softwareInformation":{},"status":"Active","type":"POWER_BOX"};

As it's currently 07:08 BST the lastMeasurementData cannot be in GMT as indicated as that would be in the future.

I'll try to raise a case with SolarEdge to see if they can fix the delay that occurs later in the day. If I look at the analysis graph for the panel it contains more up to date data late in the day.

[al090187]

The solution given by jlai79 works fine.... until the gap between the time and measurement time is over 1 hour. Happens for me at about 8pm at the moment.

I just used my file editor on HA to read the files it has in the config folder. We made a change to the time zones in the sensor.py file, and that kind of works, but I noticed it references a constant called CHECK_TIME_DELTA. In the folder there is the constants file, const.py. I just changed the CHECK_TIME_DELTA value to 2 hours, now to wait and see if that works...... Can anyone suggest a reason why it wouldn't, or would cause a problem?

EDIT: It just updated, and seems to have worked for the first value past the 1 hour mark.

[markroyle]

Apologies was going to give an update a few days ago. My North East facing array is first showing readings at about 0515. My South West facing array is showing readings up to about 2100 and then just drops. Yesterday for instance it was showing 1 kW at 2100 and then nothing. This may be due to the sun getting very low and dipping below the tree line. Things are a lot better since I implemented the fix by @jlai79.

[bf8392]

I have the same problem with the updates stopping in the evening. I will try this fix too...Will it officially be integrated at some point?

I also had a deeper look and tried something:

Patch – keep sensors updating in the afternoon

Add the three snippets below to custom_components/solaredgeoptimizers/sensor.py. Nothing else in the file has to change.

---

1 · Imports (top of file)

# add right below the existing imports
from datetime import timezone
from homeassistant.util import dt as dt_util   # HA helper, tz-aware

---

2 · UTC “now” for the age check

Inside MyCoordinator._async_update_data replace

timetocheck = datetime.now() - CHECK_TIME_DELTA

with

timetocheck = dt_util.utcnow() - CHECK_TIME_DELTA    # tz-aware UTC

---

3 · Mark portal timestamps as UTC

Still in the same method, find the loop that iterates over the optimizers:

for optimizer in data:
    if optimizer.lastmeasurement > timetocheck:
        update = True
        break

Replace that block with

for optimizer in data:
    ts = optimizer.lastmeasurement

    # SolarEdge returns a *naive* UTC timestamp – tag it as UTC
    if ts.tzinfo is None:
        ts = ts.replace(tzinfo=timezone.utc)

    if ts > timetocheck:
        update = True
        break

---

Why it works

• datetime.now() is naive/local; SolarEdge timestamps are naive/UTC. After one hour of summer-time offset those values look “too old” and the coordinator returns None.
• Switching the comparison to tz-aware UTC (dt_util.utcnow()) and tagging the portal value as UTC makes the >1 h test accurate, so updates continue throughout the day.

I changed that and it seems to work:

[bf8392]

@jlai79 can you make a pull request?

[jlai79]

@jlai79 can you make a pull request?

Done. But it looks like @ProudElm is inactive.

[bf8392]

Great great thanks :-) Oh okay I see...maybe one of the contributors can implement? I also just saw that you also forked it. Does your fok contain the fix? https://github.com/jlai79/solaredgeoptimizers