Pac and Vdc sometimes -3.4028234663852886e+38
Opened this issue · 2 comments
At night, when the voltage/power drop to 0, I see in my json output values recorded as -3.4028234663852886e+38. I'm not sure whether the solaredge data actually holds this data, or that some python conversion is going slightly off.
Here's an example json output:
{"inverters": {"73124CBA": {"Uptime": 29147, "Temp": 33.76922607421875, "Vac": 231.74009704589844, "Eac": 0.0, "Interval": 300, "Iac": 0.0, "Eday": 0.0022689334582537413, "Etot": 114682.0, "Vdc": 250.82830810546875, "Pac": 0.0, "Time": "06:49:42", "Date": "2017-08-28", "Freq": 50.00763702392578, "ID": "73124CBA", "Pmax": -3.4028234663852886e+38}}, "meters_0x0022": {"73124CBA": {"9_PVProduction": {"TotalE2Grid": 0, "AlwaysZero_off34_int2": 0, "seId": "73124CBA", "TotalEfromGrid": 0, "Flag_off20_hex": "00 80", "devLen": 58, "Flag_off28_hex": "00 80", "E2X": 0, "PfromX": NaN, "P2X": 0.0, "Date": "2017-08-28", "AlwaysZero_off18_int2": 0, "Totaloff22_int4": 0, "Totaloff30_int4": 0, "Interval": 300, "EfromX": 0, "seType": "0x0022", "Time": "06:49:42", "onlyIntervalData": 1, "dateTime": 1503895782, "AlwaysZero_off26_int2": 0, "AlwaysZero_off10_int2": 0, "devType": "meters_0x0022", "Flag_off36_hex": "00 80", "Flag_off12_hex": "00 80", "recType": 9}}}, "events": {}, "optimizers": {"20427FFE": {"Uptime": 1, "Temp": 20.0, "Vmod": 36.875, "Imod": 0.0, "Eday": 0.0, "Vopt": 0.125, "Time": "06:51:43", "Date": "2017-08-28", "Inverter": 0, "ID": "20427FFE"}, "20430ADD": {"Uptime": 13, "Temp": 20.0, "Vmod": 37.0, "Imod": 0.0, "Eday": 0.0, "Vopt": 21.5, "Time": "06:51:46", "Date": "2017-08-28", "Inverter": 0, "ID": "20430ADD"}, "2042DBE2": {"Uptime": 4, "Temp": 20.0, "Vmod": 37.375, "Imod": 0.125, "Eday": 0.0, "Vopt": 4.5, "Time": "06:51:32", "Date": "2017-08-28", "Inverter": 0, "ID": "2042DBE2"}}}
Attached is the 'rec' file that should also hold this data (which i haven't figured out how to get semonitor to re-parse it).
SolarEdge uses that value, which is 0xffff7fff in little endian format, to signify "not reported".
Ah, well right now, semonitor converts/reports it as a float. Maybe report convert it to NaN or something? Outputting it as -3.4e38 seems a little wrong, as we are not getting that value, we are getting 'not reported'.
I guess it is fair to claim, that this is something a frontend would have to solve, e.g. 'anything negative is 0' or even 'anything smaller then 0, do not submit data at all. Yeah for my logger the latter sounds like the best.
I'm more interested at a generic solution however. So whenever 0xfff7ffff is received, what shall be done, as treating anything negative is wrong really, (as the sign symbol for 'a' field could be to indicate power direction flow ...)