jbuehl / solaredge

SolarEdge inverter logging data capture
GNU General Public License v3.0
288 stars 60 forks source link

Exception: timestamp out of range for platform time_t #162

Closed ocaj-nl closed 3 years ago

ocaj-nl commented 3 years ago

Hi jbuehl (and others),

I've been running your code for about 5 years now without any issues. I take the output from semonitor.py and store it in a MySQL-database. Suddenly 1 of my 2 inverters stopped reporting new date since 10 days. After a bit of searching I found that the code apparently stumbles on the reported data with an error "Exception: timestamp out of range for platform time_t ". Because this message is never confirmed to the inverter, this will always remain the next message to report, effectively blocking all further reports. My other inverter keeps working, so it is not a generic issue.

I attached the debug-output of semonitor with all raw data. semonitor_exception.txt

Do you have any suggestions how to fix this and make the flow of data continue?

I never updated to newer version of solaredge-master, so it is still running a mid-2016-version. As my inverters are non-connected, they still run the 2016-firmware. I never updated the raspberry pi this is running on either and therefore am still running python2.7. Seems like the current version of your software doesn't run on python2.7. I'm a bit reluctant to updating to newer python as this raspberry pi is doing a few more data-gathering jobs in my home, so I'd rather not mess too much with it (it's fully isolated anyway, so my update-policy is "don't touch a working system") On the other hand: I don't remember how much data is stored in the inverter, but I would like to fix it soon to prevent gaps in my long-term database.

jbuehl commented 3 years ago

I see in your debug output that the inverter is sending a message with performance data for the inverter and 8 optimizers. The data for the first 7 optimizers is good, but the last optimizer with ID 20251129 contains a timestamp that is invalid. Instead of something like 0x61190e38 which corresponds to Aug 15 2021, it contains the value 0x80000002 which I'm guessing may be some sort of status code that they are putting into the timestamp location in the data. It's possible that particular optimizer is having a problem.

You could modify semonitor.py to catch the exception so it can proceed with collecting your data. In the current version, a good place to do it would be in data.py in the function devDataDict(). For example:

# create a dictionary of device data items
def devDataDict(seId, itemNames, itemValues):
    devDict = {}
    try:
        devDict["Date"] = formatDateStamp(itemValues[0])
        devDict["Time"] = formatTimeStamp(itemValues[0])
    except OverflowError:
        devDict["Date"] = "error"
        devDict["Time"] = "error"
    devDict["ID"] = seId
    for i in range(3, len(itemNames)):
        devDict[itemNames[i]] = itemValues[i - 2]
    return devDict

This would not tell you what the error is, but at least it would get past the problem. I don't know if the program is structured the same way in the version of semonitor.py that you are using. This isn't going to be fixed by updating either this code or the SolarEdge firmware.

You could also try to remove that optimizer from the string if that isn't difficult to do.

ocaj-nl commented 3 years ago

Hi jbuehl,

Thanks for this quick analysis! The inverter reports on the display all 8/8 optimizers and seems to produce normal (I also have a separate kwh-meters measuring the inverter itself), so skipping this value and hoping it doesn't return seems the best approach. I will dive in to the code tonight after work (Europe time) and see if I can work it out (I don't speak python fluently, I'm more of a Perl guy), but should be able to figure it out. I'll post an update once I now more (and hopefully this magic timestamps isn't something that the optimizer wants to report every time, but just once...)

ocaj-nl commented 3 years ago

Followup:

I tried your suggested code and it seemed to be not an OverFlowException, but some other Exception (at least it still gave me the Exception error). Not knowing how to figure out which Exception it was I replaced except OverflowError: by except Exception: and that made the script skip over this weird report!

After acknowledging this data I reverted to the original script (because the catchall-exception could have side-effects I don't understand...). And now the script is happily catching up the data of the last 11 days.

Still not sure what happened and caused this. Could be a corrupt report originating from the optimizer, or a somehow corrupted entry in the storage of the inverter. Or a very special and very rare report from the optimizer that actually means something which only solaredge can tell. Quite surprised about this after 5 years of functioning properly, so it certainly is very rare. Today, I also watched the optimizer-screen in the display of the inverter. The optimizer that caused this issue was reporting normal data on the display, so it seems fine now. Also, the data that is coming in now from just after the weird report is all looking normal.

Thank you very much for the quick solution/workaround. Excellent support, great work!

ethpi commented 2 years ago

A few days ago I had exactly the same problem in a very similar setting.

Many thanks for this workaround. Using "except Exception:" instead of "except OverflowError:" works for me.

I use a version of semonitor.py from 2017 without any updates due to the same reasons as ocaj-nl. In my 2017-installation I couldn't find a file called data.py, but the file seData.py contains the function devDataDict().