jbuehl / solaredge Goto Github PK

Some inverters send a timestamp on the serial interface like this:

XX1XXXXX FFFFFFFC 036A unkown INV => 03 03 0A 00 4F 29 06 58 20 1C 00 00 02 00

"58 06 29 4F" is the current utc timestamp

The command is currently not defines in the software.

Hey all,

I want to add new defines that are missing. The obvious one that comes to mind is of course 0x003d for the encrypted message (which is just a wrapper around 0x0500 messages, I know).
Which btw, if it where up to me, I'd probably name it something along the lines of:
PROT_CMD_MISC_PAYLOAD_ENC
or something.
But I want to stay in sync as much as possible with the 'source dumps' of the apps (which makes things just so much easier in the future potentially).
I know that these initial defines/enums come from the ver2 'control' application. ver3 isn't that popular but may contain these descriptions? I haven't found a working link to ver3 however ... (anybody?)

The other one I've found missing so far is 0x0503 which obviously is the command that gets the encryption key? (The pubkey is with SE?, each machine holds the PRIVKEY in 16 bytes at parameters 0x0239 - 0x023c)
PROT_CMD_INVERTER_GET_PRIVKEY
comes to mind, but these seem to sandwiched in between the VENUSMNGR commands? I guess they ran out of ... something? (I think it is save to assume they are keeping commands unique across products)

I'll be reading comment #8 again (boy it is long, though I did read all of it 3 months ago)

Otherwise I'll create the PR with the suggested values here.

I decided that ethernet was too much trouble.
I have the Solaredge rs485 adapter board installed.
If I execute python /home/pi/solaredge/semonitor.py -o /mnt/nfs/test.json -s [inverter_sn] -t 4 /dev/ttyUSB0 it just sits there, no output.
If i execute python /home/pi/solaredge/semonitor.py -c 322 -s [inverter_sn] -vvvv -t 4 /dev/ttyUSB0 I get the usual
{"data": {"Emon": 32784.90234375, "Etot": 40462.0, "Eyear": 39798.01953125, "Eday": 80.69844818115234, "Time1": "Mon Jul 11 10:00:00 2016"}, "command": 802, "response": 909, "sequence": 10}
The adapter board is set to sunspec, slave and device (non Se Logger.)
My best guess is I am doing something very wrong here.

I got my Solaredge connected to the grid some days ago and I am now collecting and analyzing the data, and I was wondering why the ID's of some of my optimizers showed up wrong.

I was seeing 1030a179 instead of 10a0a179 and so on.

Looking at he code I found in seData.py
# remove the extra bit that is sometimes set in a device ID and upcase the letters def parseId(seId): return ("%x" % (seId & 0xff7fffff)).upper()
changing the 7 in the mask to f and the ID's are right but this would probably be to simple. There is defineatly a reason for masking one bit out that I do ignore.

Since noon today it seems messaged are no longer processed. I'm seeing the following:

Sep 23 15:29:37 /data/data/20170923152732.dat --> message: 1913 length: 551
Sep 23 15:29:37 dataLen: 0211
Sep 23 15:29:37 dataLenInv: fdee
Sep 23 15:29:37 sequence: 01c8
Sep 23 15:29:37 source: 731281f7
Sep 23 15:29:37 dest: fffffffe
Sep 23 15:29:37 function: 003d
Sep 23 15:29:37 Decrypting message
Sep 23 15:29:37 dataLen: 839e
Sep 23 15:29:37 dataLenInv: 6db5
Sep 23 15:29:37 sequence: e5d6
Sep 23 15:29:37 source: 2d538355
Sep 23 15:29:37 dest: 2af559a5
Sep 23 15:29:37 function: e600
Sep 23 15:29:37 Data length is too big for the message
Sep 23 15:29:37 data: 9e 83 b5 6d d6 e5 55 83 53 2d a5 59 f5 2a 00 e6
Sep 23 15:29:37 data: a7 ab 2f 7d 44 bf 48 ca ac 00 b6 dd 42 de d9 e2
Sep 23 15:29:37 data: 1d 05 31 37 da 0e a9 82 31 69 55 09 f3 9f f8 90
Sep 23 15:29:37 data: 24 92 cf 73 dc bf e3 0a ec 6a 7c bd dc f9 4b 46
Sep 23 15:29:37 data: 68 b7 70 9a f8 4a e8 ae 31 4a 08 c4 26 e6 ee 31
Sep 23 15:29:37 data: cb f3 bb e1 7e 8f b0 4d 6f e4 63 e1 8a ea 80 66
Sep 23 15:29:37 data: 44 45 21 f3 bc c4 bc f4 59 a5 c3 d6 29 df 7a 8d
Sep 23 15:29:37 data: e3 98 b3 da 06 a7 1d 59 22 42 08 81 e9 9a f8 4a
Sep 23 15:29:37 data: f0 14 eb 59 5f 2f 20 14 74 e3 d7 45 4e a8 c6 fb
Sep 23 15:29:37 data: 55 c8 39 ba 06 92 f7 27 e3 d3 3a e6 08 fb e9 33
Sep 23 15:29:37 data: ed a0 48 3d 43 16 2e 71 8f d9 3a 0b 79 b3 ba 72
Sep 23 15:29:37 data: f9 45 3c 74 b2 05 98 75 47 6c 42 d8 6e be de 2b
Sep 23 15:29:37 data: 8e ec b8 e7 46 82 00 98 3e 34 fe 08 0f 5c 74 b7
Sep 23 15:29:37 data: bc e1 59 5e 78 92 1a 56 1a ee 38 d7 59 24 60 53
Sep 23 15:29:37 data: e6 03 79 9c af 5c 3b f6 9b 5c 86 e4 66 61 ae a2
Sep 23 15:29:37 data: 8e 97 6f a3 0c 17 2e 98 f4 b8 c8 0f 53 9b d4 ee
Sep 23 15:29:37 data: 11 a6 d9 92 7a 40 bf 52 7a b9 ac 0f ec 90 fe 18
Sep 23 15:29:37 data: 21 8e 78 79 88 53 34 be 62 ab 31 21 2c 3b 20 e1
Sep 23 15:29:37 data: c8 05 b2 83 e9 15 92 ff 65 f8 8b 01 e6 7c ff 8c
Sep 23 15:29:37 data: ff 35 92 f9 54 78 a5 dd 5a 85 d2 39 eb 24 f2 6d
Sep 23 15:29:37 data: 30 e1 a4 35 e8 53 c8 7b f8 b8 4b 4c 62 2d cc a3
Sep 23 15:29:37 data: 17 ba 1f 15 70 50 ae 10 13 f2 f3 3b de 6b cf 90
Sep 23 15:29:37 data: 38 fd 90 36 f8 4e a6 04 0b c9 7c f0 3b 24 e0 23
Sep 23 15:29:37 data: c9 59 af 10 d0 ad 07 7e 0e 0f 6b 68 8c 1c cc 03
Sep 23 15:29:37 data: 7d fb 89 a0 38 44 92 3d 4b bd 80 1f d5 a3 4d f5
Sep 23 15:29:37 data: fe 64 70 ed 64 2e fb f1 e1 5c f9 49 21 12 41 a7
Sep 23 15:29:37 data: ba 9a ed 53 58 c7 7d 21 e9 f4 f4 84 c6 84 b0 6b
Sep 23 15:29:37 data: 9c fb dc f3 72 e8 e6 75 64 32 a2 59 2d 0e 41 b4
Sep 23 15:29:37 data: 17 f7 7f e1 d9 df 00 a9 4d 2f b4 0d 3d 0f 00 a3
Sep 23 15:29:37 data: c6 c4 54 23 ac 0a 2d d7 b3 2d 3c b6 ec 8f fe b8
Sep 23 15:29:37 data: 65 07 62 05 55 de 97 d7 4b a1 ad 57 76 68 c0 09
Sep 23 15:29:37 data: 1c 56 f9 8a 3f 02 24
Sep 23 15:29:37 Ignoring this message
Sep 23 15:29:37

I am having trouble to get semonitor working. My inverter is connected via ethernet, and I want to let my router do the IP address spoofing stuff (because it runs dnsmasq anyway), so I thought I should use the -tn option. But when I do
sudo python semonitor.py -d stdout -tn
I only get

Input file cannot be specified for network mode

and the script returns immediately. What does this mean? I expected the script to go into a state where it accepts connections from the inverter, similar to the -n option.
My testing platform is a standard Ubuntu laptop where I killed dnsmasq and installed some missing python modules.

Hi jbuehl,

First of all: Great scripts! They allow me to read out my solaredge inverters without having to connect me to the internet and do local logging.
I have 2 inverters setup to collect data over RS485.

My cabling (I use around 9 meters of cat6-STP-cable) is currently only terminated at the inverter-side. This usually works fine for a few hours in a row, but sometimes I get data corruption or wrong checksums. This is no problem, as the protocol recovers from it by itself.

However every now and then the communication just completely stops. Nothing seems to happen anymore.

Analyzing your code I think I understand what's going on: The master-thread grants bus-access to the inverter and will then wait for the read-thread to return bus-access. This will work, except in 2 cases where either the 0x0302 (grant) or the 0x039a (resp-grant) are corrupted/lost.
In the first case the inverter just sits there and waits for the 0x302 before it is allowed to transmit data, while the master-thread waits for the 0x039a to return.
In the second case, the inverter considers the access returned to the master after sending the 0x039a, but the master-thread keeps waiting for the 0x039a.
Both cases result in a deadlock, that will only be fixed by restarting the whole script.

Obviously I need to fix the termination on the bus, but even then an occasional error may occur (my data-cable follows the same physical path as my AC-cabling, so there may be some interferences occurring, even though I use a shielded cable).

As the master-thread is intended to keep running 24/7, may I suggest to add some kind of recovery-mechanism?
What I see in the communication is that the inverter usually responds within a few seconds after the 0x302 was sent.
Considering this, it seems like a fair assumption that if the 0x039a was not received after 1-5 minutes that either the 0x302 or the 0x039a was lost. In that case the master-thread could also consider the bus-access to be unlocked and continu polling the inverters. This will keep the data flow running without the need for a manual restart.

Although I have done a fair bit of coding in the past, it's been a while and I never coded in Python, so I do not have a code-proposal for you. I hope you can add this in a future update to improve the robustness in the RS485-communication.

Thanks!

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).

sedata.zip

Hi,

I'm seeing a lot of messages like the one below and it seems not all data is captured because of it.
Does anybody have an idea what could be wrong? :)

Sep 21 14:10:29 icarus semonitor.py: dataLen: 0211
Sep 21 14:10:29 icarus semonitor.py: dataLenInv: fdee
Sep 21 14:10:29 icarus semonitor.py: sequence: 0058
Sep 21 14:10:29 icarus semonitor.py: source: 731281f7
Sep 21 14:10:29 icarus semonitor.py: dest: fffffffe
Sep 21 14:10:29 icarus semonitor.py: function: 003d
Sep 21 14:10:29 icarus semonitor.py: Discarding 12 extra bytes
Sep 21 14:10:29 icarus semonitor.py: data: 9e 89 09 bb 2b 82 00 00 20 20 20 20
Sep 21 14:10:29 icarus semonitor.py: Checksum error. Expected 0x4f65, got 0x1a93
Sep 21 14:10:29 icarus semonitor.py: data: 11 02 ee fd 58 00 f7 81 12 73 fe ff ff ff 3d 00
Sep 21 14:10:29 icarus semonitor.py: data: ba 27 0c 91 78 11 b6 90 1f f1 83 0e 94 af 8c ea
Sep 21 14:10:29 icarus semonitor.py: data: 01 e8 c4 4a 79 d7 9d 4a 58 3e 92 26 8e b4 df 71
Sep 21 14:10:29 icarus semonitor.py: data: 01 ec c7 09 e5 61 bc b7 b0 9c 32 1e f9 df 0a c9
Sep 21 14:10:29 icarus semonitor.py: data: 83 29 fc b9 98 00 ba f9 70 46 fc a3 6e 3e fb d1
Sep 21 14:10:29 icarus semonitor.py: data: a3 93 c1 e1 44 7c 89 c3 2c 49 34 66 7a 33 d9 67
Sep 21 14:10:29 icarus semonitor.py: data: 70 b2 2d 9b 56 11 e5 7f 86 8a 11 bc 93 1a 2c 24
Sep 21 14:10:29 icarus semonitor.py: data: eb 19 48 22 29 bf bd 50 dc a7 5d 53 3e b0 d9 17
Sep 21 14:10:29 icarus semonitor.py: data: 09 05 da 8b 84 61 ba 3b 12 43 17 02 34 ee 83 66
Sep 21 14:10:29 icarus semonitor.py: data: 4e f6 f6 d8 c1 f0 f2 a8 ca e4 78 2e cc a1 75 09
Sep 21 14:10:29 icarus semonitor.py: data: 41 5e 52 05 ef b6 14 0d 35 d6 85 fd d5 dc 82 96
Sep 21 14:10:29 icarus semonitor.py: data: d2 01 31 47 bc b6 b8 8e 88 55 36 9b 32 7a aa 01
Sep 21 14:10:29 icarus semonitor.py: data: 3b c4 42 5f 74 94 6f d9 f3 47 f6 b8 15 61 1d 81
Sep 21 14:10:29 icarus semonitor.py: data: 37 0b e0 02 46 c9 ec 19 ed 44 dd 14 65 ae d2 39
Sep 21 14:10:29 icarus semonitor.py: data: 69 40 53 c3 3e cb cb 99 96 b6 18 73 eb b8 80 ec
Sep 21 14:10:29 icarus semonitor.py: data: 77 a1 73 a0 c2 e2 58 59 fc b5 46 1e c6 b1 ab fd
Sep 21 14:10:29 icarus semonitor.py: data: 8e 7e 6a 29 8a 92 ed 60 30 f1 fe a1 2b a6 14 a3
Sep 21 14:10:29 icarus semonitor.py: data: 48 63 d9 ee ee 1c a7 ae 25 aa 62 59 55 9e f5 e5
Sep 21 14:10:29 icarus semonitor.py: data: 7d 2b 3b e7 25 bb 9d 83 4d 2a e7 e2 17 cf 7b 17
Sep 21 14:10:29 icarus semonitor.py: data: 63 de 8c 24 e6 66 2e ea 57 32 21 dd 52 e0 ee 5c
Sep 21 14:10:29 icarus semonitor.py: data: eb ca f8 33 67 b2 c8 fc 80 16 04 f6 8f 5e 8e 5f
Sep 21 14:10:29 icarus semonitor.py: data: 17 c2 90 d7 7e 4e 5f fa 83 5b d9 2b bc a6 d8 e1
Sep 21 14:10:29 icarus semonitor.py: data: ea fb cf cd 2a 26 a0 8a e3 af cb f1 e4 01 ee 48
Sep 21 14:10:29 icarus semonitor.py: data: 00 8d a8 e5 a5 1b 67 68 a2 45 6b 0c 74 09 e6 75
Sep 21 14:10:29 icarus semonitor.py: data: 68 9d 0f 01 80 a6 3b 17 18 c3 a7 23 e0 8b dc 5b
Sep 21 14:10:29 icarus semonitor.py: data: 6a 52 23 86 01 b2 86 0b dc 57 bd 5e 3d 0e 85 36
Sep 21 14:10:29 icarus semonitor.py: data: b9 64 6f bd 9d 38 d9 f9 f7 b2 95 af 54 6d b2 60
Sep 21 14:10:29 icarus semonitor.py: data: 55 0d 34 56 b5 1f 9a 04 f7 d9 10 58 7f 47 04 34
Sep 21 14:10:29 icarus semonitor.py: data: 20 81 66 2f 0b 1c 29 23 c7 6c 9e 37 ad 25 27 28
Sep 21 14:10:29 icarus semonitor.py: data: 22 e7 d9 02 7d 78 ca 63 d7 04 32 7d 58 58 f1 a2
Sep 21 14:10:29 icarus semonitor.py: data: d2 3b ee d6 83 47 78 b5 64 8e 43 b0 2f 26 58 48
Sep 21 14:10:29 icarus semonitor.py: data: e0 ac 18 4d df ee 2d 08 b5 40 ac 94 78 eb 76 6b
Sep 21 14:10:29 icarus semonitor.py: data: c0 e4 94 af b2 80 b8 71 66 f6 ca ac 5c ab 33 98
Sep 21 14:10:29 icarus semonitor.py: data: 75 d1 47 f6 31 90 00 00 20 20 20 20 67 88 a6 69
Sep 21 14:10:29 icarus semonitor.py: data: a6 65 4f 9e 89 09 bb 2b 82 00 00 20 20 20 20
Sep 21 14:10:29 icarus semonitor.py: Ignoring this message

After digging around some time with my new HD Wave Inverter SE5000H i managed to get some data over RS485 for the encryption key commands. Most times the answer was empty so i issued every command on its own multiple times until i got a response 144 with a valid data set. The 4 JSON sets i got are:

{"data": {"type": 0, "value": 2136429196}, "command": 18, "response": 144, "sequence": 612}
{"data": {"type": 0, "value": 119530X718}, "command": 18, "response": 144, "sequence": 624}
{"data": {"type": 0, "value": 67575110}, "command": 18, "response": 144, "sequence": 692}
{"data": {"type": 0, "value": 1654055058}, "command": 18, "response": 144, "sequence": 636}

(i did realise that the third one h23b is only 8 digit long but it was replicable)

Piping this data into sekey i got:

8c5X577f6ed73e47461d07049Xe09662

(the X being a valid digit)

But if i use the keyfile to decrypt my tcpdump with command

python solaredge/seextract.py capture.pcap | python solaredge/semonitor.py -k solaredge/73125Xa3.key -o monitor.json -d stdout -vvvv

I get the error as in the title:

Sep 23 17:22:13 --> message: 26 length: 66
Sep 23 17:22:13 data: 12 34 56 79 2c 00 d3 ff 5d 00 a3 57 12 73 fe ff
Sep 23 17:22:13 data: ff ff 3d 00 47 c2 15 62 94 5e f4 b4 84 6c 01 51
Sep 23 17:22:13 data: db a3 c7 37 8d 09 6f df 52 62 4d 22 a3 95 c4 3b
Sep 23 17:22:13 data: d3 63 0c ad c9 44 46 77 20 d3 04 e1 8c 16 24 df
Sep 23 17:22:13 data: 20 e2
Sep 23 17:22:13 dataLen: 002c
Sep 23 17:22:13 dataLenInv: ffd3
Sep 23 17:22:13 sequence: 005d
Sep 23 17:22:13 source: 73125Xa3
Sep 23 17:22:13 dest: fffffffe
Sep 23 17:22:13 function: 003d
Sep 23 17:22:13 Decryption key not yet available
Sep 23 17:22:13 Ignoring this message

Can anyone point where i made the mistake. Could the too short number on h23b be the problem? Has anyone else the new HD Wave inverter and successfully decoded the tcpdump?

Having the 'meters' accidentally in my results, I noticed some values where returned as NaN (not the string NaN, which would have been okay). NaN however is not valid json (on purpose), it is supposed to be set as 0/0 for example. So in favor of returning valid JSON, ensure output cannot ever be NaN.

Hi,

many thanks for all your fantastic work.

I started to log the data of my solaredge-4k inverter (3 phase) and 18 optimizers over RS485. semonitor.py works fine. Now I'd like to write the data in a mySQL database. Therefore I tried to use se2csv.py. The file solar.json contains one line of data:

{"inverters": {"7E180E50": {"Uptime": 75002, "Freq3": 49.9990234375, "Freq2": 49.9982795715332, "Freq1": 49.999778747558594, "data29": 78.0, "data21": 4286578687, "data22": 4286578687, "data23": 4286578687, "GndFrR": 6900.03125, "data31": 3169517568, "EdayDC": 4286578687, "Vac3": 232.9375, "Eac": 43.30878448486328, "Vac1": 232.53125, "ID": "7E180E50", "Date": "2017-04-22", "CosPhi3": 1.0, "CosPhi2": 1.0, "IoutDC": -0.03955078125, "Temp": 27.459383010864258, "Interval": 300, "Iac3": 0.5551663637161255, "CosPhi1": 1.0, "Iac1": 0.5501027703285217, "Time": "17:09:52", "Idc": 4286578687, "Edc": 4286578687, "Iac2": 0.561946451663971, "Eday": 4351.13818359375, "Etot": 9455554.0, "Vdc": 747.125, "Vac2": 234.03125, "mode": 5, "Irdc": 0.0026874998584389687}}, "optimizers": {"20050055": {"Uptime": 37295, "Temp": 14.0, "Vmod": 29.375, "Imod": 0.7250000000000001, "ID": "20050055", "Vopt": 40.625, "Time": "17:11:19", "Date": "2017-04-22", "Inverter": 0, "Eday": 268.75}, "20050893": {"Uptime": 37438, "Temp": 14.0, "Vmod": 26.75, "Imod": 1.09375, "ID": "20050893", "Vopt": 43.625, "Time": "17:08:30", "Date": "2017-04-22", "Inverter": 0, "Eday": 306.25}, "20050BED": {"Uptime": 37524, "Temp": 14.0, "Vmod": 27.625, "Imod": 1.05, "ID": "20050BED", "Vopt": 44.125, "Time": "17:08:14", "Date": "2017-04-22", "Inverter": 0, "Eday": 299.75}, "200506C0": {"Uptime": 37095, "Temp": 14.0, "Vmod": 31.375, "Imod": 1.56875, "ID": "200506C0", "Vopt": 43.125, "Time": "17:05:02", "Date": "2017-04-22", "Inverter": 0, "Eday": 288.25}, "20050D1B": {"Uptime": 37698, "Temp": 14.0, "Vmod": 26.75, "Imod": 1.25625, "ID": "20050D1B", "Vopt": 43.25, "Time": "17:07:05", "Date": "2017-04-22", "Inverter": 0, "Eday": 306.0}, "200507F9": {"Uptime": 37334, "Temp": 14.0, "Vmod": 30.375, "Imod": 1.4125, "ID": "200507F9", "Vopt": 41.875, "Time": "17:05:39", "Date": "2017-04-22", "Inverter": 0, "Eday": 282.5}, "2005089E": {"Uptime": 37388, "Temp": 14.0, "Vmod": 26.625, "Imod": 1.06875, "ID": "2005089E", "Vopt": 43.75, "Time": "17:07:53", "Date": "2017-04-22", "Inverter": 0, "Eday": 295.5}, "20050540": {"Uptime": 37458, "Temp": 14.0, "Vmod": 29.75, "Imod": 0.7875000000000001, "ID": "20050540", "Vopt": 40.875, "Time": "17:10:21", "Date": "2017-04-22", "Inverter": 0, "Eday": 272.0}, "20050D54": {"Uptime": 37529, "Temp": 14.0, "Vmod": 26.875, "Imod": 1.04375, "ID": "20050D54", "Vopt": 43.625, "Time": "17:08:33", "Date": "2017-04-22", "Inverter": 0, "Eday": 294.75}, "200507EC": {"Uptime": 37288, "Temp": 14.0, "Vmod": 29.625, "Imod": 1.16875, "ID": "200507EC", "Vopt": 42.375, "Time": "17:06:36", "Date": "2017-04-22", "Inverter": 0, "Eday": 281.75}, "200507DA": {"Uptime": 37697, "Temp": 14.0, "Vmod": 26.75, "Imod": 1.14375, "ID": "200507DA", "Vopt": 43.125, "Time": "17:07:26", "Date": "2017-04-22", "Inverter": 0, "Eday": 301.75}, "20050945": {"Uptime": 37606, "Temp": 14.0, "Vmod": 30.375, "Imod": 0.76875, "ID": "20050945", "Vopt": 41.5, "Time": "17:10:41", "Date": "2017-04-22", "Inverter": 0, "Eday": 283.75}, "20050467": {"Uptime": 37293, "Temp": 14.0, "Vmod": 31.0, "Imod": 0.84375, "ID": "20050467", "Vopt": 42.125, "Time": "17:08:49", "Date": "2017-04-22", "Inverter": 0, "Eday": 275.0}, "20050516": {"Uptime": 37757, "Temp": 14.0, "Vmod": 30.375, "Imod": 0.8500000000000001, "ID": "20050516", "Vopt": 41.75, "Time": "17:10:15", "Date": "2017-04-22", "Inverter": 0, "Eday": 296.5}, "20050525": {"Uptime": 37367, "Temp": 14.0, "Vmod": 31.125, "Imod": 1.3875000000000002, "ID": "20050525", "Vopt": 40.625, "Time": "17:05:17", "Date": "2017-04-22", "Inverter": 0, "Eday": 256.0}, "20050526": {"Uptime": 37255, "Temp": 14.0, "Vmod": 28.875, "Imod": 0.9375, "ID": "20050526", "Vopt": 41.0, "Time": "17:08:17", "Date": "2017-04-22", "Inverter": 0, "Eday": 281.0}, "200508CB": {"Uptime": 37161, "Temp": 14.0, "Vmod": 30.0, "Imod": 0.8187500000000001, "ID": "200508CB", "Vopt": 38.125, "Time": "17:09:01", "Date": "2017-04-22", "Inverter": 0, "Eday": 259.5}, "20050D48": {"Uptime": 37067, "Temp": 14.0, "Vmod": 30.5, "Imod": 0.875, "ID": "20050D48", "Vopt": 40.125, "Time": "17:07:40", "Date": "2017-04-22", "Inverter": 0, "Eday": 262.25}}}

But the commandline

solaredge/se2csv.py -i inverter.csv -o optimizer.csv solar.json

produces the errormessage:

Traceback (most recent call last):
  File "solaredge/se2csv.py", line 103, in <module>
    writeData(json.loads(jsonStr), invFile, optFile)
  File "solaredge/se2csv.py", line 64, in writeData
    invSeq = writeDevData(invFile, invOutFmt, msgDict["inverters"][seId], invItems, invSeq)
  File "solaredge/se2csv.py", line 74, in writeDevData
    outMsg = delim.join([(outFmt[i] % devDict[devItems[i]]) for i in range(len(devItems))])
KeyError: 'Vac'

If I remove -i inverter.csv from the commandline above, se2csv.py works well.

It seems, that se2csv.py doesn't notice, that I use a 3 phase inverter. Can anybody help me to convert my json-files into csv-files?

Many thanks, Jan

By the way: In seDataParams.py in line 95 it is assumed, that data29 means the power limit. I can confirm this, because my inverter is limited to 78%. This is exactly the value in solar.json above.

I'm trying to get this working on my synology NAS. I get an error 👍
debug: True
debugFiles: True
debugData: True
headers: True
delim: ,
dataBase:
dbHostName:
userName:
password:
append: a
inFileName: stdin
invFileName:
optFileName:
jsonFileName:
reading stdin
solaredge inputSeq 0 seDataLen 14951
solaredge inputSeq 1 seDataLen 0
solaredge inputSeq 2 seDataLen 0
solaredge inputSeq 3 seDataLen 342
solaredge seHdr a9 fe 03a9 7f190ff7 fffffffe 0500
solaredge seType 0010 seId 7F190FF7 seDeviceLen 124
Traceback (most recent call last):
File "/root/solaredge/seconvert2.py", line 454, in
seConvert()
File "/root/solaredge/seconvert2.py", line 197, in seConvert
seHeader(inRec+inFile.read(2))
File "/root/solaredge/seconvert2.py", line 238, in seHeader
seInvData = readData(inFile, invInFmt, seDeviceLen)
File "/root/solaredge/seconvert2.py", line 262, in readData
return list(struct.unpack(inFmt, inFile.read(seDeviceLen)))
struct.error: unpack requires a string argument of length 104

I have no idea why this goes wrong. My inverter is a SE3000 that sends it's data to domoticz on ip address 192,168.1.51 port 22222

please advise
wimsan

Hi all,
New to this forum but greatly appreciate all the work and sleuthing done.
I have an se10000 (CAN version for brutal cold) now connected via ethernet; was using wi-fi periodically to upload stored daily data. It used to hold 5-6 weeks but when I replaced the comm board the storage capacity went down to ~3 weeks. That may be the result of the switch to encryption. Plan is to download historic data and write to mysql db, then permanently snoop; will use tools here for that.
My question is regards to ports 22222 and 22221. Does anyone know if these are actually necessary? They appear to be the preferred ports for uploading data, with port 80 as a fallback. Looking at a live tcpdump of my installation it appears if they are open there is no traffic on port 80, but I got the impression from reading here that many are seeing the data go up on port 80. What I see is only data on 22222 and nothing on 22221 or 80. If I block 22222, I then see data only on 22221. It does a number of retries and delays including fresh dns lookups before switching. If I then reopen 22222 and block 22221 it does not switch back, but switches to 80. It looks like the preferred order is 22222, 22221, and then 80; but I'm wondering if either of 22222 or 22221 is actually required.

se2MQTT.py -c anon -u anon -p anon -s localhost -t /ha/value/solaredge /mnt/nfs/solar.json
[Errno 32] Broken pipe
[Errno 32] Broken pipe
[Errno 32] Broken pipe
[Errno 32] Broken pipe
[Errno 32] Broken pipe
[Errno 32] Broken pipe
[Errno 32] Broken pipe

My SolarEdge inverter has a Tesla powerwall attached and apparently also provides metering data. It looks like there is no support for these in this package, would it be possible add it (short of my hacking into in the code and submitting a PR)?

Here is what I'm seeing from my data collection script that can't be parsed:

ERROR: Unable to process batteries_0x0030 data! ({u'7F15397E': {u'T16H0013143\x00': {u'batteryId': u'T16H0013143\x00', u'seId': u'7F15397E', u'TotalEnergyOut': 12792, u'devLen': 86, u'EOut': 0, u'TotalEnergyIn': 11668, u'BattCapacityActual': 6376.0, u'AlwaysZero_66_float': 0.0, u'Date': u'2017-07-05', u'HexConst_56': u'ff ff 7f ff', u'AlwaysZero_48_float': 0.0, u'HexConst_52': u'ff ff 7f ff', u'EIn': 4, u'Temp': 23.0, u'Interval': 300, u'AlwaysZero_70_float': 0.0, u'seType': u'0x0030', u'Time': u'13:09:36', u'Idc': 0.0, u'BattCharge': 263.0, u'AlwaysZero_40_float': 0.0, u'BattChargingStatus': 6, u'BattCapacityNom': 6400.0, u'Vdc': 358.29998779296875, u'dateTime': 1499285376, u'devType': u'batteries_0x0030'}}})
ERROR: Unable to process meters_0x0022 data! ({u'7F15397E': {u'8_MostlyZeroes': {u'TotalE2Grid': 0, u'AlwaysZero_off34_int2': 0, u'seId': u'7F15397E', u'P2X': 0.0, u'Flag_off20_hex': u'00 80', u'devLen': 58, u'Flag_off28_hex': u'00 80', u'E2X': 0, u'PfromX': nan, u'TotalEfromGrid': 0, u'Date': u'2017-07-05', u'Totaloff22_int4': 0, u'Totaloff30_int4': 0, u'Interval': 300, u'EfromX': 0, u'seType': u'0x0022', u'Time': u'13:09:36', u'Flag_off12_hex': u'00 80', u'onlyIntervalData': 1, u'dateTime': 1499285376, u'AlwaysZero_off26_int2': 0, u'AlwaysZero_off10_int2': 0, u'devType': u'meters_0x0022', u'Flag_off36_hex': u'00 80', u'AlwaysZero_off18_int2': 0, u'recType': 8}, u'7_Battery': {u'TotalE2Grid': 0, u'AlwaysZero_off34_int2': 0, u'seId': u'7F15397E', u'P2X': 0.0, u'Flag_off20_hex': u'00 80', u'devLen': 58, u'Flag_off28_hex': u'00 80', u'E2X': 0, u'PfromX': nan, u'TotalEfromGrid': 0, u'Date': u'2017-07-05', u'Totaloff22_int4': 0, u'Totaloff30_int4': 0, u'Interval': 300, u'EfromX': 0, u'seType': u'0x0022', u'Time': u'13:09:36', u'Flag_off12_hex': u'00 80', u'onlyIntervalData': 1, u'dateTime': 1499285376, u'AlwaysZero_off26_int2': 0, u'AlwaysZero_off10_int2': 0, u'devType': u'meters_0x0022', u'Flag_off36_hex': u'00 80', u'AlwaysZero_off18_int2': 0, u'recType': 7}}})
ERROR: Unable to process meters_0x0022 data! ({u'7F15397E': {u'9_PVProduction': {u'TotalE2Grid': 0, u'AlwaysZero_off34_int2': 0, u'seId': u'7F15397E', u'P2X': 7061.0, u'Flag_off20_hex': u'00 80', u'devLen': 58, u'Flag_off28_hex': u'00 80', u'E2X': 591, u'PfromX': nan, u'TotalEfromGrid': 0, u'Date': u'2017-07-05', u'Totaloff22_int4': 0, u'Totaloff30_int4': 0, u'Interval': 300, u'EfromX': 0, u'seType': u'0x0022', u'Time': u'13:09:36', u'Flag_off12_hex': u'00 80', u'onlyIntervalData': 1, u'dateTime': 1499285376, u'AlwaysZero_off26_int2': 0, u'AlwaysZero_off10_int2': 0, u'devType': u'meters_0x0022', u'Flag_off36_hex': u'00 80', u'AlwaysZero_off18_int2': 0, u'recType': 9}}})

Not an issue but a question. From what I have read in my documentation my inverter does not have a RS232 interface.

Any chance that I can get the encryption keys withouth it?

Regards
Hagen

seconvert does not detect when an inverter shuts down for the night so the current values never go to zero. This is a matter of finding out what the message is.

Hello again,

This has been working perfectly for over a month now, but last Monday (7th) it suddenly stopped logging data :-(

I'm not sure why, nothing has changed with the config at all. Restarting the scripts / rebooting etc doesn't help.

The solaredge web portal is still receiving data and updating correctly.

The pcap files are still getting created.

I enabled debugging and took a look at the log output - there seemed to be a lot of "solaredge unknown seType", more than I remember from previously watching the logs when I first got up and running.

Could you take a look at one of the pcap files and see if it seems "normal" and produces expected data for you?

solaredge-20151212230003.zip

Thanks for your help!

Martyn

First, a big "thank you" for all of the work done to get this project to where it is. As far as monitoring my own SolarEdge install, I'm sitting on the shoulders of giants because of you.

Background: My SolarEdge site has three inverters, each with three strings of solar panels and optimizers (124 total between the three SE10000 inverters). Because the inverters have revenue grade meters built into them, the installers report they could not chain them together via the RS-485 bus and, instead, each has its own Ethernet connection to a dedicated subnet. There is a Linux-based router connecting that subnet to the Internet and that's where I have tcpdump capturing all tcp traffic to/from the solar energy subnet.

I captured the three key files via RS-232 and process the pcap with seextract.py before feeding it to semonitor.py three times, once per inverter with the appropriate key file as an argument each time.

My problems may be related (hence one Github issue) or might be two independent issues.

1. I have incomplete data in the JSON files created by semonitor.py. Looking at the pcap file in Wireshark, I see data regularly since midnight. And I see updates every 15 minutes on the SolarEdge monitoring portal. But the data in the JSON files is irregular at best.

2. The JSON created by semonitor.py appears to be invalid, according to both the Perl JSON modules and to Firefox's built-in ability to display JSON data. It looks like semonitor.py is producing each line in a JSON-ish format but the file itself is not standard JSON. To fix this, I have to

• Add quote marks around NaN values
• Add a comma at the end of each line (except the last)
• Add a [ at the beginning of the file and a ] at the end of the file.

3JSONs+pcap.zip

While trying to solve the network connection issues in #11, I have now connected to my SE5k inverter by RS485. Sadly, I am not getting any output. I have terminated the cable at the inverter side by moving up the switch in the inverter. At the computer side, the cable is currently unterminated because I do not really know what resistance my cable has (2x2 twisted wires phone cable, 1.5 m long).
Here is the debug.log I get by running sudo python semonitor.py -m -s 7E1A0823 -d ../debug.log -vvvv -t 4 /dev/ttyUSB0:

Aug 10 17:44:57 debugEnable: True 
Aug 10 17:44:57 debugFiles: True 
Aug 10 17:44:57 debugMsgs: True 
Aug 10 17:44:57 debugData: True 
Aug 10 17:44:57 debugRaw: True 
Aug 10 17:44:57 debugFileName: ../debug.log 
Aug 10 17:44:57 haltOnException: False 
Aug 10 17:44:57 inFileName: /dev/ttyUSB0 
Aug 10 17:44:57 inputType: 4 
Aug 10 17:44:57 serialDevice: True 
Aug 10 17:44:57     baudRate: 115200 
Aug 10 17:44:57 networkDevice: False 
Aug 10 17:44:57 networkSvcs: False 
Aug 10 17:44:57 following: True 
Aug 10 17:44:57 passiveMode: False 
Aug 10 17:44:57 commandAction: False 
Aug 10 17:44:57 masterMode: True 
Aug 10 17:44:57 slaveAddrs: 7E1A0823 
Aug 10 17:44:57 outFileName: stdout 
Aug 10 17:44:57 append: w 
Aug 10 17:44:57 opening /dev/ttyUSB0 
Aug 10 17:44:57 starting read thread 
Aug 10 17:44:57 starting master thread 
Aug 10 17:44:57 dataLen:    0000 
Aug 10 17:44:57 dataLenInv: ffff 
Aug 10 17:44:57 sequence:   0001 
Aug 10 17:44:57 source:     fffffffe 
Aug 10 17:44:57 dest:       7e1a0823 
Aug 10 17:44:57 function:   0302 
Aug 10 17:44:57 /dev/ttyUSB0 <-- message: 1 length: 22 
Aug 10 17:44:57 data:       12 34 56 79 00 00 ff ff 01 00 fe ff ff ff 23 08 
Aug 10 17:44:57 data:       1a 7e 02 03 fd 76 
Aug 10 17:44:57   
Aug 10 17:44:57   
Aug 10 17:44:57 /dev/ttyUSB0 --> message: 1 length: 22 
Aug 10 17:44:57 data:       12 34 56 79 00 00 ff ff 01 00 23 08 1a 7e fe ff 
Aug 10 17:44:57 data:       ff ff 9a 03 ee 43 
Aug 10 17:44:57 dataLen:    0000 
Aug 10 17:44:57 dataLenInv: ffff 
Aug 10 17:44:57 sequence:   0001 
Aug 10 17:44:57 source:     7e1a0823 
Aug 10 17:44:57 dest:       fffffffe 
Aug 10 17:44:57 function:   039a 
Aug 10 17:45:02 dataLen:    0000 
Aug 10 17:45:02 dataLenInv: ffff 
Aug 10 17:45:02 sequence:   0002 
Aug 10 17:45:02 source:     fffffffe 
Aug 10 17:45:02 dest:       7e1a0823 
Aug 10 17:45:02 function:   0302 
Aug 10 17:45:02 /dev/ttyUSB0 <-- message: 2 length: 22 
Aug 10 17:45:02 data:       12 34 56 79 00 00 ff ff 02 00 fe ff ff ff 23 08 
Aug 10 17:45:02 data:       1a 7e 02 03 f2 32 
Aug 10 17:45:02   
Aug 10 17:45:02   
Aug 10 17:45:02 /dev/ttyUSB0 --> message: 2 length: 22 
Aug 10 17:45:02 data:       12 34 56 79 00 00 ff ff 02 00 23 08 1a 7e fe ff 
Aug 10 17:45:02 data:       ff ff 9a 03 e1 07 
Aug 10 17:45:02 dataLen:    0000 
Aug 10 17:45:02 dataLenInv: ffff 
Aug 10 17:45:02 sequence:   0002 
Aug 10 17:45:02 source:     7e1a0823 
Aug 10 17:45:02 dest:       fffffffe 
Aug 10 17:45:02 function:   039a 
Aug 10 17:45:07 dataLen:    0000 
Aug 10 17:45:07 dataLenInv: ffff 
Aug 10 17:45:07 sequence:   0003 
Aug 10 17:45:07 source:     fffffffe 
Aug 10 17:45:07 dest:       7e1a0823 
Aug 10 17:45:07 function:   0302 
Aug 10 17:45:07 /dev/ttyUSB0 <-- message: 3 length: 22 
Aug 10 17:45:07 data:       12 34 56 79 00 00 ff ff 03 00 fe ff ff ff 23 08 
Aug 10 17:45:07 data:       1a 7e 02 03 f6 ce 
Aug 10 17:45:07   
Aug 10 17:45:07   
Aug 10 17:45:07 /dev/ttyUSB0 --> message: 3 length: 22 
Aug 10 17:45:07 data:       12 34 56 79 00 00 ff ff 03 00 23 08 1a 7e fe ff 
Aug 10 17:45:07 data:       ff ff 9a 03 e5 fb 
Aug 10 17:45:07 dataLen:    0000 
Aug 10 17:45:07 dataLenInv: ffff 
Aug 10 17:45:07 sequence:   0003 
Aug 10 17:45:07 source:     7e1a0823 
Aug 10 17:45:07 dest:       fffffffe 
Aug 10 17:45:07 function:   039a 
Aug 10 17:45:12 dataLen:    0000 
Aug 10 17:45:12 dataLenInv: ffff 
Aug 10 17:45:12 sequence:   0004 
Aug 10 17:45:12 source:     fffffffe 
Aug 10 17:45:12 dest:       7e1a0823 
Aug 10 17:45:12 function:   0302 
Aug 10 17:45:12 /dev/ttyUSB0 <-- message: 4 length: 22 
Aug 10 17:45:12 data:       12 34 56 79 00 00 ff ff 04 00 fe ff ff ff 23 08 
Aug 10 17:45:12 data:       1a 7e 02 03 ec ba 
Aug 10 17:45:12   
Aug 10 17:45:12   
Aug 10 17:45:12 /dev/ttyUSB0 --> message: 4 length: 22 
Aug 10 17:45:12 data:       12 34 56 79 00 00 ff ff 04 00 23 08 1a 7e fe ff 
Aug 10 17:45:12 data:       ff ff 9a 03 ff 8f 
Aug 10 17:45:12 dataLen:    0000 
Aug 10 17:45:12 dataLenInv: ffff 
Aug 10 17:45:12 sequence:   0004 
Aug 10 17:45:12 source:     7e1a0823 
Aug 10 17:45:12 dest:       fffffffe 
Aug 10 17:45:12 function:   039a 
Aug 10 17:45:17 dataLen:    0000 
Aug 10 17:45:17 dataLenInv: ffff 
Aug 10 17:45:17 sequence:   0005 
Aug 10 17:45:17 source:     fffffffe 
Aug 10 17:45:17 dest:       7e1a0823 
Aug 10 17:45:17 function:   0302 
Aug 10 17:45:17 /dev/ttyUSB0 <-- message: 5 length: 22 
Aug 10 17:45:17 data:       12 34 56 79 00 00 ff ff 05 00 fe ff ff ff 23 08 
Aug 10 17:45:17 data:       1a 7e 02 03 e8 46 
Aug 10 17:45:17   
Aug 10 17:45:17   
Aug 10 17:45:17 /dev/ttyUSB0 --> message: 5 length: 22 
Aug 10 17:45:17 data:       12 34 56 79 00 00 ff ff 05 00 23 08 1a 7e fe ff 
Aug 10 17:45:17 data:       ff ff 9a 03 fb 73 
Aug 10 17:45:17 dataLen:    0000 
Aug 10 17:45:17 dataLenInv: ffff 
Aug 10 17:45:17 sequence:   0005 
Aug 10 17:45:17 source:     7e1a0823 
Aug 10 17:45:17 dest:       fffffffe 
Aug 10 17:45:17 function:   039a 
Aug 10 17:45:22 dataLen:    0000 
Aug 10 17:45:22 dataLenInv: ffff 
Aug 10 17:45:22 sequence:   0006 
Aug 10 17:45:22 source:     fffffffe 
Aug 10 17:45:22 dest:       7e1a0823 
Aug 10 17:45:22 function:   0302 
Aug 10 17:45:22 /dev/ttyUSB0 <-- message: 6 length: 22 
Aug 10 17:45:22 data:       12 34 56 79 00 00 ff ff 06 00 fe ff ff ff 23 08 
Aug 10 17:45:22 data:       1a 7e 02 03 e7 02 
Aug 10 17:45:22   
Aug 10 17:45:22   
Aug 10 17:45:22 /dev/ttyUSB0 --> message: 6 length: 22 
Aug 10 17:45:22 data:       12 34 56 79 00 00 ff ff 06 00 23 08 1a 7e fe ff 
Aug 10 17:45:22 data:       ff ff 9a 03 f4 37 
Aug 10 17:45:22 dataLen:    0000 
Aug 10 17:45:22 dataLenInv: ffff 
Aug 10 17:45:22 sequence:   0006 
Aug 10 17:45:22 source:     7e1a0823 
Aug 10 17:45:22 dest:       fffffffe 
Aug 10 17:45:22 function:   039a 
Aug 10 17:45:27 dataLen:    0000 
Aug 10 17:45:27 dataLenInv: ffff 
Aug 10 17:45:27 sequence:   0007 
Aug 10 17:45:27 source:     fffffffe 
Aug 10 17:45:27 dest:       7e1a0823 
Aug 10 17:45:27 function:   0302 
Aug 10 17:45:27 /dev/ttyUSB0 <-- message: 7 length: 22 
Aug 10 17:45:27 data:       12 34 56 79 00 00 ff ff 07 00 fe ff ff ff 23 08 
Aug 10 17:45:27 data:       1a 7e 02 03 e3 fe 
Aug 10 17:45:27   
Aug 10 17:45:27   
Aug 10 17:45:27 /dev/ttyUSB0 --> message: 7 length: 22 
Aug 10 17:45:27 data:       12 34 56 79 00 00 ff ff 07 00 23 08 1a 7e fe ff 
Aug 10 17:45:27 data:       ff ff 9a 03 f0 cb 
Aug 10 17:45:27 dataLen:    0000 
Aug 10 17:45:27 dataLenInv: ffff 
Aug 10 17:45:27 sequence:   0007 
Aug 10 17:45:27 source:     7e1a0823 
Aug 10 17:45:27 dest:       fffffffe 
Aug 10 17:45:27 function:   039a 
Aug 10 17:45:32 dataLen:    0000 
Aug 10 17:45:32 dataLenInv: ffff 
Aug 10 17:45:32 sequence:   0008 
Aug 10 17:45:32 source:     fffffffe 
Aug 10 17:45:32 dest:       7e1a0823 
Aug 10 17:45:32 function:   0302 
Aug 10 17:45:32 /dev/ttyUSB0 <-- message: 8 length: 22 
Aug 10 17:45:32 data:       12 34 56 79 00 00 ff ff 08 00 fe ff ff ff 23 08 
Aug 10 17:45:32 data:       1a 7e 02 03 d3 ea 
Aug 10 17:45:32   
Aug 10 17:45:32   
Aug 10 17:45:32 /dev/ttyUSB0 --> message: 8 length: 22 
Aug 10 17:45:32 data:       12 34 56 79 00 00 ff ff 08 00 23 08 1a 7e fe ff 
Aug 10 17:45:32 data:       ff ff 9a 03 c0 df 
Aug 10 17:45:32 dataLen:    0000 
Aug 10 17:45:32 dataLenInv: ffff 
Aug 10 17:45:32 sequence:   0008 
Aug 10 17:45:32 source:     7e1a0823 
Aug 10 17:45:32 dest:       fffffffe 
Aug 10 17:45:32 function:   039a 
Aug 10 17:45:37 dataLen:    0000 
Aug 10 17:45:37 dataLenInv: ffff 
Aug 10 17:45:37 sequence:   0009 
Aug 10 17:45:37 source:     fffffffe 
Aug 10 17:45:37 dest:       7e1a0823 
Aug 10 17:45:37 function:   0302 
Aug 10 17:45:37 /dev/ttyUSB0 <-- message: 9 length: 22 
Aug 10 17:45:37 data:       12 34 56 79 00 00 ff ff 09 00 fe ff ff ff 23 08 
Aug 10 17:45:37 data:       1a 7e 02 03 d7 16 
Aug 10 17:45:37   
Aug 10 17:45:37   
Aug 10 17:45:37 /dev/ttyUSB0 --> message: 9 length: 22 
Aug 10 17:45:37 data:       12 34 56 79 00 00 ff ff 09 00 23 08 1a 7e fe ff 
Aug 10 17:45:37 data:       ff ff 9a 03 c4 23 
Aug 10 17:45:37 dataLen:    0000 
Aug 10 17:45:37 dataLenInv: ffff 
Aug 10 17:45:37 sequence:   0009 
Aug 10 17:45:37 source:     7e1a0823 
Aug 10 17:45:37 dest:       fffffffe 
Aug 10 17:45:37 function:   039a 
Aug 10 17:45:42 dataLen:    0000 
Aug 10 17:45:42 dataLenInv: ffff 
Aug 10 17:45:42 sequence:   000a 
Aug 10 17:45:42 source:     fffffffe 
Aug 10 17:45:42 dest:       7e1a0823 
Aug 10 17:45:42 function:   0302 
Aug 10 17:45:42 /dev/ttyUSB0 <-- message: 10 length: 22 
Aug 10 17:45:42 data:       12 34 56 79 00 00 ff ff 0a 00 fe ff ff ff 23 08 
Aug 10 17:45:42 data:       1a 7e 02 03 d8 52 
Aug 10 17:45:42   
Aug 10 17:45:42   
Aug 10 17:45:42 /dev/ttyUSB0 --> message: 10 length: 22 
Aug 10 17:45:42 data:       12 34 56 79 00 00 ff ff 0a 00 23 08 1a 7e fe ff 
Aug 10 17:45:42 data:       ff ff 9a 03 cb 67 
Aug 10 17:45:42 dataLen:    0000 
Aug 10 17:45:42 dataLenInv: ffff 
Aug 10 17:45:42 sequence:   000a 
Aug 10 17:45:42 source:     7e1a0823 
Aug 10 17:45:42 dest:       fffffffe 
Aug 10 17:45:42 function:   039a 
Aug 10 17:45:48 dataLen:    0000 
Aug 10 17:45:48 dataLenInv: ffff 
Aug 10 17:45:48 sequence:   000b 
Aug 10 17:45:48 source:     fffffffe 
Aug 10 17:45:48 dest:       7e1a0823 
Aug 10 17:45:48 function:   0302 
Aug 10 17:45:48 /dev/ttyUSB0 <-- message: 11 length: 22 
Aug 10 17:45:48 data:       12 34 56 79 00 00 ff ff 0b 00 fe ff ff ff 23 08 
Aug 10 17:45:48 data:       1a 7e 02 03 dc ae 
Aug 10 17:45:48   
Aug 10 17:45:48   
Aug 10 17:45:48 /dev/ttyUSB0 --> message: 11 length: 22 
Aug 10 17:45:48 data:       12 34 56 79 00 00 ff ff 0b 00 23 08 1a 7e fe ff 
Aug 10 17:45:48 data:       ff ff 9a 03 cf 9b 
Aug 10 17:45:48 dataLen:    0000 
Aug 10 17:45:48 dataLenInv: ffff 
Aug 10 17:45:48 sequence:   000b 
Aug 10 17:45:48 source:     7e1a0823 
Aug 10 17:45:48 dest:       fffffffe 
Aug 10 17:45:48 function:   039a 
Aug 10 17:45:53 dataLen:    0000 
Aug 10 17:45:53 dataLenInv: ffff 
Aug 10 17:45:53 sequence:   000c 
Aug 10 17:45:53 source:     fffffffe 
Aug 10 17:45:53 dest:       7e1a0823 
Aug 10 17:45:53 function:   0302 
Aug 10 17:45:53 /dev/ttyUSB0 <-- message: 12 length: 22 
Aug 10 17:45:53 data:       12 34 56 79 00 00 ff ff 0c 00 fe ff ff ff 23 08 
Aug 10 17:45:53 data:       1a 7e 02 03 c6 da 
Aug 10 17:45:53   
Aug 10 17:45:53   
Aug 10 17:45:53 /dev/ttyUSB0 --> message: 12 length: 22 
Aug 10 17:45:53 data:       12 34 56 79 00 00 ff ff 0c 00 23 08 1a 7e fe ff 
Aug 10 17:45:53 data:       ff ff 9a 03 d5 ef 
Aug 10 17:45:53 dataLen:    0000 
Aug 10 17:45:53 dataLenInv: ffff 
Aug 10 17:45:53 sequence:   000c 
Aug 10 17:45:53 source:     7e1a0823 
Aug 10 17:45:53 dest:       fffffffe 
Aug 10 17:45:53 function:   039a 
Aug 10 17:45:58 dataLen:    0000 
Aug 10 17:45:58 dataLenInv: ffff 
Aug 10 17:45:58 sequence:   000d 
Aug 10 17:45:58 source:     fffffffe 
Aug 10 17:45:58 dest:       7e1a0823 
Aug 10 17:45:58 function:   0302 
Aug 10 17:45:58 /dev/ttyUSB0 <-- message: 13 length: 22 
Aug 10 17:45:58 data:       12 34 56 79 00 00 ff ff 0d 00 fe ff ff ff 23 08 
Aug 10 17:45:58 data:       1a 7e 02 03 c2 26 
Aug 10 17:45:58   
Aug 10 17:45:58   
Aug 10 17:45:58 /dev/ttyUSB0 --> message: 13 length: 22 
Aug 10 17:45:58 data:       12 34 56 79 00 00 ff ff 0d 00 23 08 1a 7e fe ff 
Aug 10 17:45:58 data:       ff ff 9a 03 d1 13 
Aug 10 17:45:58 dataLen:    0000 
Aug 10 17:45:58 dataLenInv: ffff 
Aug 10 17:45:58 sequence:   000d 
Aug 10 17:45:58 source:     7e1a0823 
Aug 10 17:45:58 dest:       fffffffe 
Aug 10 17:45:58 function:   039a 
Aug 10 17:46:03 dataLen:    0000 
Aug 10 17:46:03 dataLenInv: ffff 
Aug 10 17:46:03 sequence:   000e 
Aug 10 17:46:03 source:     fffffffe 
Aug 10 17:46:03 dest:       7e1a0823 
Aug 10 17:46:03 function:   0302 
Aug 10 17:46:03 /dev/ttyUSB0 <-- message: 14 length: 22 
Aug 10 17:46:03 data:       12 34 56 79 00 00 ff ff 0e 00 fe ff ff ff 23 08 
Aug 10 17:46:03 data:       1a 7e 02 03 cd 62 
Aug 10 17:46:03   
Aug 10 17:46:03   
Aug 10 17:46:03 /dev/ttyUSB0 --> message: 14 length: 22 
Aug 10 17:46:03 data:       12 34 56 79 00 00 ff ff 0e 00 23 08 1a 7e fe ff 
Aug 10 17:46:03 data:       ff ff 9a 03 de 57 
Aug 10 17:46:03 dataLen:    0000 
Aug 10 17:46:03 dataLenInv: ffff 
Aug 10 17:46:03 sequence:   000e 
Aug 10 17:46:03 source:     7e1a0823 
Aug 10 17:46:03 dest:       fffffffe 
Aug 10 17:46:03 function:   039a 
Aug 10 17:46:08 dataLen:    0000 
Aug 10 17:46:08 dataLenInv: ffff 
Aug 10 17:46:08 sequence:   000f 
Aug 10 17:46:08 source:     fffffffe 
Aug 10 17:46:08 dest:       7e1a0823 
Aug 10 17:46:08 function:   0302 
Aug 10 17:46:08 /dev/ttyUSB0 <-- message: 15 length: 22 
Aug 10 17:46:08 data:       12 34 56 79 00 00 ff ff 0f 00 fe ff ff ff 23 08 
Aug 10 17:46:08 data:       1a 7e 02 03 c9 9e 
Aug 10 17:46:08   
Aug 10 17:46:08   
Aug 10 17:46:08 /dev/ttyUSB0 --> message: 15 length: 22 
Aug 10 17:46:08 data:       12 34 56 79 00 00 ff ff 0f 00 23 08 1a 7e fe ff 
Aug 10 17:46:08 data:       ff ff 9a 03 da ab 
Aug 10 17:46:08 dataLen:    0000 
Aug 10 17:46:08 dataLenInv: ffff 
Aug 10 17:46:08 sequence:   000f 
Aug 10 17:46:08 source:     7e1a0823 
Aug 10 17:46:08 dest:       fffffffe 
Aug 10 17:46:08 function:   039a 
Aug 10 17:46:13 dataLen:    0000 
Aug 10 17:46:13 dataLenInv: ffff 
Aug 10 17:46:13 sequence:   0010 
Aug 10 17:46:13 source:     fffffffe 
Aug 10 17:46:13 dest:       7e1a0823 
Aug 10 17:46:13 function:   0302 
Aug 10 17:46:13 /dev/ttyUSB0 <-- message: 16 length: 22 
Aug 10 17:46:13 data:       12 34 56 79 00 00 ff ff 10 00 fe ff ff ff 23 08 
Aug 10 17:46:13 data:       1a 7e 02 03 ad 4a 
Aug 10 17:46:13   
Aug 10 17:46:13   
Aug 10 17:46:13 /dev/ttyUSB0 --> message: 16 length: 22 
Aug 10 17:46:13 data:       12 34 56 79 00 00 ff ff 10 00 23 08 1a 7e fe ff 
Aug 10 17:46:13 data:       ff ff 9a 03 be 7f 
Aug 10 17:46:13 dataLen:    0000 
Aug 10 17:46:13 dataLenInv: ffff 
Aug 10 17:46:13 sequence:   0010 
Aug 10 17:46:13 source:     7e1a0823 
Aug 10 17:46:13 dest:       fffffffe 
Aug 10 17:46:13 function:   039a 
Aug 10 17:46:18 dataLen:    0000 
Aug 10 17:46:18 dataLenInv: ffff 
Aug 10 17:46:18 sequence:   0011 
Aug 10 17:46:18 source:     fffffffe 
Aug 10 17:46:18 dest:       7e1a0823 
Aug 10 17:46:18 function:   0302 
Aug 10 17:46:18 /dev/ttyUSB0 <-- message: 17 length: 22 
Aug 10 17:46:18 data:       12 34 56 79 00 00 ff ff 11 00 fe ff ff ff 23 08 
Aug 10 17:46:18 data:       1a 7e 02 03 a9 b6 
Aug 10 17:46:18   
Aug 10 17:46:18   
Aug 10 17:46:18 /dev/ttyUSB0 --> message: 17 length: 22 
Aug 10 17:46:18 data:       12 34 56 79 00 00 ff ff 11 00 23 08 1a 7e fe ff 
Aug 10 17:46:18 data:       ff ff 9a 03 ba 83 
Aug 10 17:46:18 dataLen:    0000 
Aug 10 17:46:18 dataLenInv: ffff 
Aug 10 17:46:18 sequence:   0011 
Aug 10 17:46:18 source:     7e1a0823 
Aug 10 17:46:18 dest:       fffffffe 
Aug 10 17:46:18 function:   039a 
Aug 10 17:46:23 dataLen:    0000 
Aug 10 17:46:23 dataLenInv: ffff 
Aug 10 17:46:23 sequence:   0012 
Aug 10 17:46:23 source:     fffffffe 
Aug 10 17:46:23 dest:       7e1a0823 
Aug 10 17:46:23 function:   0302 
Aug 10 17:46:23 /dev/ttyUSB0 <-- message: 18 length: 22 
Aug 10 17:46:23 data:       12 34 56 79 00 00 ff ff 12 00 fe ff ff ff 23 08 
Aug 10 17:46:23 data:       1a 7e 02 03 a6 f2 
Aug 10 17:46:23   
Aug 10 17:46:23   
Aug 10 17:46:23 /dev/ttyUSB0 --> message: 18 length: 22 
Aug 10 17:46:23 data:       12 34 56 79 00 00 ff ff 12 00 23 08 1a 7e fe ff 
Aug 10 17:46:23 data:       ff ff 9a 03 b5 c7 
Aug 10 17:46:23 dataLen:    0000 
Aug 10 17:46:23 dataLenInv: ffff 
Aug 10 17:46:23 sequence:   0012 
Aug 10 17:46:23 source:     7e1a0823 
Aug 10 17:46:23 dest:       fffffffe 
Aug 10 17:46:23 function:   039a 
Aug 10 17:46:28 dataLen:    0000 
Aug 10 17:46:28 dataLenInv: ffff 
Aug 10 17:46:28 sequence:   0013 
Aug 10 17:46:28 source:     fffffffe 
Aug 10 17:46:28 dest:       7e1a0823 
Aug 10 17:46:28 function:   0302 
Aug 10 17:46:28 /dev/ttyUSB0 <-- message: 19 length: 22 
Aug 10 17:46:28 data:       12 34 56 79 00 00 ff ff 13 00 fe ff ff ff 23 08 
Aug 10 17:46:28 data:       1a 7e 02 03 a2 0e 
Aug 10 17:46:28   
Aug 10 17:46:28   
Aug 10 17:46:28 /dev/ttyUSB0 --> message: 19 length: 22 
Aug 10 17:46:28 data:       12 34 56 79 00 00 ff ff 13 00 23 08 1a 7e fe ff 
Aug 10 17:46:28 data:       ff ff 9a 03 b1 3b 
Aug 10 17:46:28 dataLen:    0000 
Aug 10 17:46:28 dataLenInv: ffff 
Aug 10 17:46:28 sequence:   0013 
Aug 10 17:46:28 source:     7e1a0823 
Aug 10 17:46:28 dest:       fffffffe 
Aug 10 17:46:28 function:   039a 
Aug 10 17:46:33 dataLen:    0000 
Aug 10 17:46:33 dataLenInv: ffff 
Aug 10 17:46:33 sequence:   0014 
Aug 10 17:46:33 source:     fffffffe 
Aug 10 17:46:33 dest:       7e1a0823 
Aug 10 17:46:33 function:   0302 
Aug 10 17:46:33 /dev/ttyUSB0 <-- message: 20 length: 22 
Aug 10 17:46:33 data:       12 34 56 79 00 00 ff ff 14 00 fe ff ff ff 23 08 
Aug 10 17:46:33 data:       1a 7e 02 03 b8 7a 
Aug 10 17:46:33   
Aug 10 17:46:33   
Aug 10 17:46:33 /dev/ttyUSB0 --> message: 20 length: 22 
Aug 10 17:46:33 data:       12 34 56 79 00 00 ff ff 14 00 23 08 1a 7e fe ff 
Aug 10 17:46:33 data:       ff ff 9a 03 ab 4f 
Aug 10 17:46:33 dataLen:    0000 
Aug 10 17:46:33 dataLenInv: ffff 
Aug 10 17:46:33 sequence:   0014 
Aug 10 17:46:33 source:     7e1a0823 
Aug 10 17:46:33 dest:       fffffffe 
Aug 10 17:46:33 function:   039a 
Aug 10 17:46:38 dataLen:    0000 
Aug 10 17:46:38 dataLenInv: ffff 
Aug 10 17:46:38 sequence:   0015 
Aug 10 17:46:38 source:     fffffffe 
Aug 10 17:46:38 dest:       7e1a0823 
Aug 10 17:46:38 function:   0302 
Aug 10 17:46:38 /dev/ttyUSB0 <-- message: 21 length: 22 
Aug 10 17:46:38 data:       12 34 56 79 00 00 ff ff 15 00 fe ff ff ff 23 08 
Aug 10 17:46:38 data:       1a 7e 02 03 bc 86 
Aug 10 17:46:38   
Aug 10 17:46:38   
Aug 10 17:46:38 /dev/ttyUSB0 --> message: 21 length: 22 
Aug 10 17:46:38 data:       12 34 56 79 00 00 ff ff 15 00 23 08 1a 7e fe ff 
Aug 10 17:46:38 data:       ff ff 9a 03 af b3 
Aug 10 17:46:38 dataLen:    0000 
Aug 10 17:46:38 dataLenInv: ffff 
Aug 10 17:46:38 sequence:   0015 
Aug 10 17:46:38 source:     7e1a0823 
Aug 10 17:46:38 dest:       fffffffe 
Aug 10 17:46:38 function:   039a 
Aug 10 17:46:43 dataLen:    0000 
Aug 10 17:46:43 dataLenInv: ffff 
Aug 10 17:46:43 sequence:   0016 
Aug 10 17:46:43 source:     fffffffe 
Aug 10 17:46:43 dest:       7e1a0823 
Aug 10 17:46:43 function:   0302 
Aug 10 17:46:43 /dev/ttyUSB0 <-- message: 22 length: 22 
Aug 10 17:46:43 data:       12 34 56 79 00 00 ff ff 16 00 fe ff ff ff 23 08 
Aug 10 17:46:43 data:       1a 7e 02 03 b3 c2 
Aug 10 17:46:43   
Aug 10 17:46:43   
Aug 10 17:46:43 /dev/ttyUSB0 --> message: 22 length: 22 
Aug 10 17:46:43 data:       12 34 56 79 00 00 ff ff 16 00 23 08 1a 7e fe ff 
Aug 10 17:46:43 data:       ff ff 9a 03 a0 f7 
Aug 10 17:46:43 dataLen:    0000 
Aug 10 17:46:43 dataLenInv: ffff 
Aug 10 17:46:43 sequence:   0016 
Aug 10 17:46:43 source:     7e1a0823 
Aug 10 17:46:43 dest:       fffffffe 
Aug 10 17:46:43 function:   039a 
Aug 10 17:46:48 dataLen:    0000 
Aug 10 17:46:48 dataLenInv: ffff 
Aug 10 17:46:48 sequence:   0017 
Aug 10 17:46:48 source:     fffffffe 
Aug 10 17:46:48 dest:       7e1a0823 
Aug 10 17:46:48 function:   0302 
Aug 10 17:46:48 /dev/ttyUSB0 <-- message: 23 length: 22 
Aug 10 17:46:48 data:       12 34 56 79 00 00 ff ff 17 00 fe ff ff ff 23 08 
Aug 10 17:46:48 data:       1a 7e 02 03 b7 3e 
Aug 10 17:46:48   
Aug 10 17:46:48   
Aug 10 17:46:48 /dev/ttyUSB0 --> message: 23 length: 22 
Aug 10 17:46:48 data:       12 34 56 79 00 00 ff ff 17 00 23 08 1a 7e fe ff 
Aug 10 17:46:48 data:       ff ff 9a 03 a4 0b 
Aug 10 17:46:48 dataLen:    0000 
Aug 10 17:46:48 dataLenInv: ffff 
Aug 10 17:46:48 sequence:   0017 
Aug 10 17:46:48 source:     7e1a0823 
Aug 10 17:46:48 dest:       fffffffe 
Aug 10 17:46:48 function:   039a 
Aug 10 17:46:53 dataLen:    0000 
Aug 10 17:46:53 dataLenInv: ffff 
Aug 10 17:46:53 sequence:   0018 
Aug 10 17:46:53 source:     fffffffe 
Aug 10 17:46:53 dest:       7e1a0823 
Aug 10 17:46:53 function:   0302 
Aug 10 17:46:53 /dev/ttyUSB0 <-- message: 24 length: 22 
Aug 10 17:46:53 data:       12 34 56 79 00 00 ff ff 18 00 fe ff ff ff 23 08 
Aug 10 17:46:53 data:       1a 7e 02 03 87 2a 
Aug 10 17:46:53   
Aug 10 17:46:53   
Aug 10 17:46:53 /dev/ttyUSB0 --> message: 24 length: 22 
Aug 10 17:46:53 data:       12 34 56 79 00 00 ff ff 18 00 23 08 1a 7e fe ff 
Aug 10 17:46:53 data:       ff ff 9a 03 94 1f 
Aug 10 17:46:53 dataLen:    0000 
Aug 10 17:46:53 dataLenInv: ffff 
Aug 10 17:46:53 sequence:   0018 
Aug 10 17:46:53 source:     7e1a0823 
Aug 10 17:46:53 dest:       fffffffe 
Aug 10 17:46:53 function:   039a 
Aug 10 17:46:58 dataLen:    0000 
Aug 10 17:46:58 dataLenInv: ffff 
Aug 10 17:46:58 sequence:   0019 
Aug 10 17:46:58 source:     fffffffe 
Aug 10 17:46:58 dest:       7e1a0823 
Aug 10 17:46:58 function:   0302 
Aug 10 17:46:58 /dev/ttyUSB0 <-- message: 25 length: 22 
Aug 10 17:46:58 data:       12 34 56 79 00 00 ff ff 19 00 fe ff ff ff 23 08 
Aug 10 17:46:58 data:       1a 7e 02 03 83 d6 
Aug 10 17:46:58   
Aug 10 17:46:58   
Aug 10 17:46:58 /dev/ttyUSB0 --> message: 25 length: 22 
Aug 10 17:46:58 data:       12 34 56 79 00 00 ff ff 19 00 23 08 1a 7e fe ff 
Aug 10 17:46:58 data:       ff ff 9a 03 90 e3 
Aug 10 17:46:58 dataLen:    0000 
Aug 10 17:46:58 dataLenInv: ffff 
Aug 10 17:46:58 sequence:   0019 
Aug 10 17:46:58 source:     7e1a0823 
Aug 10 17:46:58 dest:       fffffffe 
Aug 10 17:46:58 function:   039a 
Aug 10 17:47:03 dataLen:    0000 
Aug 10 17:47:03 dataLenInv: ffff 
Aug 10 17:47:03 sequence:   001a 
Aug 10 17:47:03 source:     fffffffe 
Aug 10 17:47:03 dest:       7e1a0823 
Aug 10 17:47:03 function:   0302 
Aug 10 17:47:03 /dev/ttyUSB0 <-- message: 26 length: 22 
Aug 10 17:47:03 data:       12 34 56 79 00 00 ff ff 1a 00 fe ff ff ff 23 08 
Aug 10 17:47:03 data:       1a 7e 02 03 8c 92 
Aug 10 17:47:03   
Aug 10 17:47:03   
Aug 10 17:47:03 /dev/ttyUSB0 --> message: 26 length: 22 
Aug 10 17:47:03 data:       12 34 56 79 00 00 ff ff 1a 00 23 08 1a 7e fe ff 
Aug 10 17:47:03 data:       ff ff 9a 03 9f a7 
Aug 10 17:47:03 dataLen:    0000 
Aug 10 17:47:03 dataLenInv: ffff 
Aug 10 17:47:03 sequence:   001a 
Aug 10 17:47:03 source:     7e1a0823 
Aug 10 17:47:03 dest:       fffffffe 
Aug 10 17:47:03 function:   039a 
Aug 10 17:47:08 dataLen:    0000 
Aug 10 17:47:08 dataLenInv: ffff 
Aug 10 17:47:08 sequence:   001b 
Aug 10 17:47:08 source:     fffffffe 
Aug 10 17:47:08 dest:       7e1a0823 
Aug 10 17:47:08 function:   0302 
Aug 10 17:47:08 /dev/ttyUSB0 <-- message: 27 length: 22 
Aug 10 17:47:08 data:       12 34 56 79 00 00 ff ff 1b 00 fe ff ff ff 23 08 
Aug 10 17:47:08 data:       1a 7e 02 03 88 6e 
Aug 10 17:47:08   
Aug 10 17:47:08   
Aug 10 17:47:08 /dev/ttyUSB0 --> message: 27 length: 22 
Aug 10 17:47:08 data:       12 34 56 79 00 00 ff ff 1b 00 23 08 1a 7e fe ff 
Aug 10 17:47:08 data:       ff ff 9a 03 9b 5b 
Aug 10 17:47:08 dataLen:    0000 
Aug 10 17:47:08 dataLenInv: ffff 
Aug 10 17:47:08 sequence:   001b 
Aug 10 17:47:08 source:     7e1a0823 
Aug 10 17:47:08 dest:       fffffffe 
Aug 10 17:47:08 function:   039a 
Aug 10 17:47:13 dataLen:    0000 
Aug 10 17:47:13 dataLenInv: ffff 
Aug 10 17:47:13 sequence:   001c 
Aug 10 17:47:13 source:     fffffffe 
Aug 10 17:47:13 dest:       7e1a0823 
Aug 10 17:47:13 function:   0302 
Aug 10 17:47:13 /dev/ttyUSB0 <-- message: 28 length: 22 
Aug 10 17:47:13 data:       12 34 56 79 00 00 ff ff 1c 00 fe ff ff ff 23 08 
Aug 10 17:47:13 data:       1a 7e 02 03 92 1a 
Aug 10 17:47:13   

No other output with production data whatsoever. Anybody knows what functions 039a or 0302 mean? Where may this information be found?
Also, the transmission stalls after some time, however not reproducibly. Could this be due to the missing termination and the stability issue named in #18 ?

Hey all. It seems that for this cool little tool, most of the communication is happening via issues (as can be seen in #8), as if they where a forum.

Is there however a small community/forum somewhere where findings here are discussed a bit more in depth? If not, and this is the place to be, great :)

I just got a new PV setup with a new HD Wave SE5000H. It has not ever been connected to the internet yet, I have connected it via network to a local semonitor on a dedicated network interface. But since I just received my USB 485 dongle today, I started to actually pull data off the unit.

From this data set, I'm getting a lot of 'unknown...' and 'undeciphered_data' and 'meters_...' which seem to be little documented. My question is, is the json dump to any interest, specifically the deciphered data? Or is there only any true value in pcap files/full dumps?

P.S. making note of the meters_0x0022 that I mentioned above, I see this one spamming the whole night, even while the unit is in night mode. Is that expected/new/curious info (it is being decoded reasonably, but I have no meter connected at all). Turns out, this was caused by me configuring my 'Server' as RS485. I set it to 'none' now as I don't use the SE servers anyway. Which disables reporting all together, so the spamming is normal.

semonitor.py sometimes has issues with losing message synchronization after getting a corrupted message from a serial device. There is a workaround currently in place for this but it has other side effects. The low level message reading routine needs to be rewritten to be able to detect and discard a corrupted message, and then read the next message in the stream.

Can you give me more info on your project with the solar edge inverter like on witch hardware its running and so on ?

Greetings Jan,

Hi,

It would be great if this can be converted to a home assistant component. It seems like a great automation project to integrate with. It is also a python project so that surely helps.

The se2mqtt script can be used currently via MQTT -> HA, but it isn't as nice.

Just a suggestion!

https://home-assistant.io/
https://home-assistant.io/developers/creating_components/

Hello,

i have found the commands and the format of the data structures to get real time measurement data from a single phase inverter. The commands are appended. Maybe someone can find the meaning of the unknown fields.

Regards.

PROT_CMD_VENUSMNGR_READ_ISE_MEAS1

• Data format (for python struct)
  • "<ffffffffffL"
• Field description
  • 'Vdc','Vac','Unk0','Vac2','Fac','Cac','Unk1','Unk2','Unk3','Pac','Status'

PROT_CMD_VENUSMNGR_READ_ISE_MEAS2

• Data format (for python struct)
  • "<fffffffL"
• Field description
  • 'Vac','Pac','Unk0','Unk1','Unk2','Unk3','Riso','Status'

PROT_CMD_VENUSMNGR_READ_SE_MEAS

• Data format (for python struct)
  • "<ffffffffff"
• Field description
  • 'Vdc','Vac','Unk0','Unk1','Vac2','Unk2','Fac','Unk3','Unk4','Unk5'

Originally, this project was only concerned with 2 device types within the 0500 performance data message - the 0000 optimizer and the 0010 inverter. As more and more people have begun to use it, new device types have emerged and some individuals have contributed code to the project to handle their devices. More and more device types will continue to emerge. Additionally, only a small subset of messages within the SE protocol are interpreted. It isn't practical for someone who doesn't have a particular device to do the necessary detective work of figuring out the format of the data fields within the message and what they represent and not everyone using the project is comfortable with coding in python.

This issue proposes a feature in semonitor.py that allows for table driven parsing of messages and device data within the 0500 message. This would be a complete rewrite of seData.py. Data tables would contain an entry for each message type or device type, each with a list of fields containing the length, data type, and name of the field.

Exact syntax is TBD, but an example might look something like this:

{messages:
   {0x0012, PROT_CMD_PARAMS_GET_SINGLE:
     {2, H, param},
   },
   {0x0011, PROT_RESP_PARAMS_SINGLE:
     {4, L, value},
     {2, H, param},
   },
   {0x0090, PROT_CMD_PARAMS_SET_SINGLE:
     {2, H, param},
     {4, L, value},
   },
     ...
   }
 0500data:
   {0x0000, optimizer:
     {4, L, Inverter}, 
     {4, L, Uptime},
     {4, f, Vmod},
     {4, f, Vopt}, 
     {4, f, Imod}, 
     {4, f, Eday}, 
     {4, f, Temp},
   },
   {0x0010, inverter:
     {4, L, Uptime}, 
     {4, L, Interval},
     {4, f, Temp},
     {4, f, Eday}, 
     {4, f, Eac}, 
     {4, f, Vac}, 
     {4, f, Iac},
     {4, f, freq},
     {4, x, unknown},
     {4, x, unknown},
     {4, f, Vdc},
       ...
   },
}

Note - the 0080 optimizer would not be able to be parsed by this method because of the bit shifting required. The data table format would need to accomodate such a special case.

I've been getting the occasional traceback, I'm guessing it's caused by some sort of spurious data that the python code isn't expecting.

Traceback (most recent call last):
  File "/usr/src/solaredge/seconvert2.py", line 534, in <module>
    seConvert()
  File "/usr/src/solaredge/seconvert2.py", line 200, in seConvert
    seHeader(inRec+readBytes(2))
  File "/usr/src/solaredge/seconvert2.py", line 234, in seHeader
    seOptData = readData(inFile, optInFmt, seDeviceLen)
  File "/usr/src/solaredge/seconvert2.py", line 310, in readData
    return list(struct.unpack(inFmt, readBytes(seDeviceLen)[:(len(inFmt)-1)*4]))
struct.error: unpack requires a string argument of length 36
Traceback (most recent call last):
  File "/usr/src/solaredge/seconvert1.py", line 253, in <module>
    readPcapRec(pcapFile)
  File "/usr/src/solaredge/seconvert1.py", line 109, in readPcapRec
    sys.stdout.flush()
IOError: [Errno 32] Broken pipe

Traceback (most recent call last):
  File "/usr/src/solaredge/seconvert2.py", line 534, in <module>
    seConvert()
  File "/usr/src/solaredge/seconvert2.py", line 200, in seConvert
    seHeader(inRec+readBytes(2))
  File "/usr/src/solaredge/seconvert2.py", line 243, in seHeader
    seOptData = convertNewOptData(seData)
  File "/usr/src/solaredge/seconvert2.py", line 298, in convertNewOptData
    (timeStamp, uptime) = struct.unpack("<LH", seData[0:6])
struct.error: unpack requires a string argument of length 6
Traceback (most recent call last):
  File "/usr/src/solaredge/seconvert1.py", line 253, in <module>
    readPcapRec(pcapFile)
  File "/usr/src/solaredge/seconvert1.py", line 109, in readPcapRec
    sys.stdout.flush()
IOError: [Errno 32] Broken pipe

github won't let me upload a pcap file, so I've put it at https://dl.dropboxusercontent.com/u/52590317/solaredge-20151014000004.pcap - this produces the above errors for me consistently

Please let me know if there's anything else I can provide to track down the cause?

Hi,

This really isn't an issue with your software. I have had my system for 3 weeks now. I did see that solaredge sade they have a zigbee option. I have use zigbee in the past with other projects. Now, once installed, I found out that my company didn't install the zigbee unit and solar edge site is very limited about this unit. It seems that it reports back to there propitarty hub to route it out to the internet, just like if you had internet plugged directly into the inverter. I called solaredge today and just ask them the best way to read my data from my owned solaredge inverter. They stated that there was no way but via their portal. I mentioned to them that Sungevity(who installed my solaredge) isn't using their portal portal and they didnt say much. But then I said their where a couple of places on the internet who had done it. There was a quick response about there are hacking our solaredge. I felt like didn't I just spend 30k for my system, isnt it mine. But I felt like they really dont like owner of their products to have true intormation about what my system is doing without being in their cloud.

I have worked on a couple of items for people with home automation and thought this would be a good project for me to work on. But just realized today, even though I like the solaredge line for my power, they dont like people to know what your system is doing without using their data on there site.

I have worked with RasPis/Arduinos and Zigbees and thought this would be fun to monitor my own power. But I see these companies only like me to use their products.

I appreciate you guys in what you are doing. Keep it up. I want some day to try to get past the cloud and do my own reporting.

Just didnt know any other way to email you, so I opened up a ticket.

Thanks for the reading, I been doing alot since I found this forum/GitHub project.

Bo

This is just a nice-to-have enhancement.

The identifiers "inverters", "optimizers", "batteries", etc. that make their way into data are hard coded in multiple places. If it matters to someone that these are the north american english spellings and they would prefer "optimisers" or even a different language, having a single place to change them such as a config file might be useful.

This is a continuation of #11 and my questions with regard to LAN connections. I chose to open a new issue in order to keep discussions separated. I know that this is more a kind of forum usage and should not be under "issues", but I do not know a better place.
So I am trying to get data out of my SE5k inverter via LAN. After killing dnsmasq which was using my DNS port, and connecting my computer via ethernet cable and network interface enp0s25, I have tried with the following command:
sudo python semonitor.py -d stdout -n enp0s25
which puts the script in a waiting mode but nothing happens. According to @jbuehl this is due to encryption, see #11. Adding -vv option, I get the following output after restarting the inverter:

Jun 18 14:22:25 0.0.0.0:68 --> message: 40 length: 257
Jun 18 14:22:25 192.168.18.255:68 <-- message: 41 length: 300
Jun 18 14:22:25 waiting for dhcp message
Jun 18 14:22:26 0.0.0.0:68 --> message: 42 length: 269
Jun 18 14:22:26 192.168.18.255:68 <-- message: 43 length: 300
Jun 18 14:22:26 waiting for dhcp message
Jun 18 14:22:37 192.168.18.2:3111 --> message: 1 length: 37
Jun 18 14:22:37 192.168.18.2:3111 <-- message: 2 length: 72
Jun 18 14:22:37 waiting for dns message
Jun 18 14:22:37 connection from 192.168.18.2:3110
Jun 18 14:22:37 starting read thread
Jun 18 14:22:46 --> message: 1 length: 56
Jun 18 14:23:16 --> message: 2 length: 56
Jun 18 14:23:46 --> message: 3 length: 56
Jun 18 14:24:46 --> message: 4 length: 56
Jun 18 14:25:46 --> message: 5 length: 56
Jun 18 14:26:46 --> message: 6 length: 56
Jun 18 14:29:27 192.168.18.2:3113 --> message: 3 length: 37
Jun 18 14:29:27 192.168.18.2:3113 <-- message: 4 length: 72
Jun 18 14:29:27 waiting for dns message
Jun 18 14:30:00 192.168.18.2:3115 --> message: 5 length: 37
Jun 18 14:30:00 192.168.18.2:3115 <-- message: 6 length: 72
Jun 18 14:30:00 waiting for dns message
Jun 18 14:32:03 192.168.18.2:3117 --> message: 7 length: 37
Jun 18 14:32:03 192.168.18.2:3117 <-- message: 8 length: 72
Jun 18 14:32:03 waiting for dns message
Jun 18 14:32:05 192.168.18.2:68 --> message: 44 length: 250
Jun 18 14:32:05 waiting for dhcp message
Jun 18 14:32:07 0.0.0.0:68 --> message: 45 length: 257
Jun 18 14:32:07 192.168.18.255:68 <-- message: 46 length: 300
Jun 18 14:32:07 waiting for dhcp message
Jun 18 14:32:09 0.0.0.0:68 --> message: 47 length: 269
Jun 18 14:32:09 192.168.18.255:68 <-- message: 48 length: 300
Jun 18 14:32:09 waiting for dhcp message
Jun 18 14:32:20 192.168.18.2:3120 --> message: 9 length: 37
Jun 18 14:32:20 192.168.18.2:3120 <-- message: 10 length: 72
Jun 18 14:32:20 waiting for dns message
Jun 18 14:32:22 192.168.18.2:68 --> message: 49 length: 250

No 003d or 0503 messages as long as I can see.
@jbuehl you mentioned to extract the encryption key by RS232. My documentation does not mention RS232, only RS485. But when I open the cover, there is a 9-fold connector, with three contacts for RS485-1, three for RS485-2, and lastly three for RS232 (Rx, Tx, G). Can I suppose that this RS232 connector is active and can be used though it is not mentioned in the documentation? I ask because I would have to go and buy a serial cable.
Otherwise, is it also possible to extract the encryption keys via RS485? I see that common USB to RS485 connectors have 2 contacts, while the inverter has 3. Is it the ground contact that is unused then? In the documentation, only the connection between several inverters is described.
I begin feeling a bit stupid with all my questions. This is quite new for me and there seems to be very little documentation. I appreciate your help!

For debugging reasons, I want to submit data to the solaredge portal. I don't want to actually connect my inverter to the portal however. I wish to replay data to the portal (I'm extracting data via RS485 right now).

I'm expecting the answer to be no, this is not possible, so I'll likely build this feature myself, just wondering if anybody is aware of any gotcha's.

Hi jbuehl,

Though I haven't started to fetch the inverter key on our SE5000, let alone fetch data, I know I would like the data to store in a database, rather than in spreadsheet files. So I would like to write a python script that inserts the data in mysql-database.
I would like to ask you if I could 'hijjack' one of your programs to turn it into a database-insertion program.
If that is indeed OK with you, best candidate to use seems to me se2csv.py, but maybe you have a different opinion on this.

To temper expectations, it will take me some time, because I have a rather busy life, and no programming experience in python.

If, again, OK with you, would it be possible to send me a json-file containing some data I can use to experiment? I have a 1-phase inverter, but of course I would like it to be possible to use data from a 3-phase inverter.

Hi all,

I encountered this problem previously but it seems to be back again.

I was trying to use semonitor.py with my SolarEdge inverter. While using the -c 322 command with semonitor.py i can get energy values from the inverter.

But while trying to get the raw values from inverter, i came across a timestamp exception. The logging was working fine in last couple of days but now i am having this error.

sudo python semonitor.py -m -x -s 07e12a1d2 -d stdout -vvvv -t 4 /dev/ttyUSB1

Aug 29 08:49:04 debugEnable: True
Aug 29 08:49:04 debugFiles: True
Aug 29 08:49:04 debugMsgs: True
Aug 29 08:49:04 debugData: True
Aug 29 08:49:04 debugRaw: True
Aug 29 08:49:04 debugFileName: stdout
Aug 29 08:49:04 haltOnException: True
Aug 29 08:49:04 inFileName: /dev/ttyUSB1
Aug 29 08:49:04 inputType: 4
Aug 29 08:49:04 serialDevice: True
Aug 29 08:49:04 baudRate: 115200
Aug 29 08:49:04 networkDevice: False
Aug 29 08:49:04 sePort: 22222
Aug 29 08:49:04 networkSvcs: False
Aug 29 08:49:04 following: True
Aug 29 08:49:04 passiveMode: False
Aug 29 08:49:04 commandAction: False
Aug 29 08:49:04 masterMode: True
Aug 29 08:49:04 slaveAddrs: 07e12a1d2
Aug 29 08:49:04 outFileName: stdout
Aug 29 08:49:04 append: w
Aug 29 08:49:04 opening /dev/ttyUSB1
Aug 29 08:49:05 starting read thread
Aug 29 08:49:05 starting master thread
Aug 29 08:49:05 dataLen: 0000
Aug 29 08:49:05 dataLenInv: ffff
Aug 29 08:49:05 sequence: 017d
Aug 29 08:49:05 source: fffffffe
Aug 29 08:49:05 dest: 7e12a1d2
Aug 29 08:49:05 function: 0302
Aug 29 08:49:05 /dev/ttyUSB1 <-- message: 1 length: 22
Aug 29 08:49:05 data: 12 34 56 79 00 00 ff ff 7d 01 fe ff ff ff d2 a1
Aug 29 08:49:05 data: 12 7e 02 03 04 8a
Aug 29 08:49:05
Aug 29 08:49:15 RS485 master ack timeout
Aug 29 08:49:15 Exception: timestamp out of range for platform time_t
Aug 29 08:49:15 data: f8 01 07 fe 26 02 d2 a1 12 7e fe ff ff ff 00 05
Aug 29 08:49:15 data: 80 00 a9 66 3e 20 0d 00 ce d0 9f 59 75 23 13 82
Aug 29 08:49:15 data: e5 26 65 03 0e 80 00 40 5f 3e 20 0d 00 de d0 9f
Aug 29 08:49:15 data: 59 b1 23 3d d6 e2 0d b6 02 0e 80 00 23 63 3e 20
Aug 29 08:49:15 data: 0d 00 e2 d0 9f 59 98 23 02 56 65 26 1c 03 0f 80
Aug 29 08:49:15 data: 00 19 62 3e 20 0d 00 f1 d0 9f 59 e6 23 02 ba e6
Aug 29 08:49:15 data: 23 29 03 0d 80 00 a5 52 3f 20 0d 00 f2 d0 9f 59
Aug 29 08:49:15 data: e7 19 02 46 c5 26 cb 02 0f 80 00 65 59 3f 20 0d
Aug 29 08:49:15 data: 00 fa d0 9f 59 bb 23 07 3a 15 26 36 03 0f 80 00
Aug 29 08:49:15 data: f9 5e 3e 20 0d 00 fe d0 9f 59 3b 23 fe 75 e6 17
Aug 29 08:49:15 data: 21 02 0d 80 00 e4 5f 3e 20 0d 00 09 d1 9f 59 7b
Aug 29 08:49:15 data: 23 01 76 36 18 3c 02 0d 80 00 ed 60 3e 20 0d 00
Aug 29 08:49:15 data: 0c d1 9f 59 35 23 30 16 55 11 f0 01 0e 80 00 25
Aug 29 08:49:15 data: 61 3e 20 0d 00 10 d1 9f 59 ee 23 04 ba 75 2a b4
Aug 29 08:49:15 data: 03 0e 80 00 89 66 3e 20 0d 00 14 d1 9f 59 4f 19
Aug 29 08:49:15 data: ff b9 25 2a 64 03 0e 80 00 be 66 3e 20 0d 00 15
Aug 29 08:49:15 data: d1 9f 59 f7 23 0a a2 45 28 77 03 0e 80 00 29 62
Aug 29 08:49:15 data: 3e 20 0d 00 17 d1 9f 59 f0 23 46 1a 22 0a ca 02
Aug 29 08:49:15 data: 0e 80 00 f7 57 3f 20 0d 00 39 d1 9f 59 ed 23 10
Aug 29 08:49:15 data: 4e d5 25 0b 03 0f 80 00 db 64 3e 20 0d 00 47 d1
Aug 29 08:49:15 data: 9f 59 5c 23 f6 e9 25 17 10 02 0d 80 00 98 52 3f
Aug 29 08:49:15 data: 20 0d 00 4a d1 9f 59 15 24 03 42 65 26 fe 02 0f
Aug 29 08:49:15 data: 80 00 3f 5f 3e 20 0d 00 4b d1 9f 59 5a 23 39 6e
Aug 29 08:49:15 data: e2 07 c7 01 0f 80 00 83 66 3e 20 0d 00 4d d1 9f
Aug 29 08:49:15 data: 59 b8 15 fe e9 f5 16 e1 01 0d 80 00 1d 66 3e 20
Aug 29 08:49:15 data: 0d 00 4e d1 9f 59 46 24 aa 61 95 23 d3 02 0d 80
Aug 29 08:49:15 data: 00 2a 64 3e 20 0d 00 50 d1 9f 59 da 23 32 66 72
Aug 29 08:49:16 data: 08 ba 01 0d 80 00 66 64 3e 20 0d 00 53 d1 9f 59
Aug 29 08:49:16 data: b0 23 3c d6 e2 09 d2 01 0e 80 00 4f 62 3e 20 0d
Aug 29 08:49:16 data: 00 54 d1 9f 59 95 23 fa 51 a6 18 f9 01 0d 80 00
Aug 29 08:49:16 data: f8 5e 3e 20 0d 00 60 d1 9f 99 91 23 02 e2 85 16
Aug 29 08:49:16 data: f1 01 0d 80 00 4f 69 3e 20 0d 00 69 d1 9f 59 a8
Aug 29 08:49:16 data: 24 9e 39 a5 23 6f 03 0f ff 6c
Exception in thread read thread:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "semonitor.py", line 40, in readData
processMsg(msg, dataFile, recFile, outFile)
File "semonitor.py", line 56, in processMsg
msgData = parseData(function, data)
File "/home/pi/inverter/sedgenew/seData.py", line 22, in parseData
return parseDeviceData(data)
File "/home/pi/inverter/sedgenew/seData.py", line 138, in parseDeviceData
optDict[seId] = parseNewOptData(seId, optItems, data[dataPtr:dataPtr+devLen])
File "/home/pi/inverter/sedgenew/seData.py", line 204, in parseNewOptData
return devDataDict(seId, optItems, [timeStamp, 0, uptime, vpan, vopt, imod, eday, temp])
File "/home/pi/inverter/sedgenew/seData.py", line 209, in devDataDict
devDict["Date"] = formatDateStamp(itemValues[0])
File "/home/pi/inverter/sedgenew/seData.py", line 233, in formatDateStamp
return time.strftime("%Y-%m-%d", time.localtime(timeStamp))
ValueError: timestamp out of range for platform time_t

Any help would be really great.

Thanks a lot in advance.

Hi!

This is not the description of a problem. It rather provides some insight on an alternative way to retrieve the performance data passively using the LAN.

My SolarEdge inverter is connected with an Ethernet cable directly to the router (I have it on an isolated VLAN that goes directly to the internet, but this is not a requirement for employing this method). My router has the ability to mirror traffic using iptables -j ROUTE -j tee. Many linux enabled routers, such as those using "DD-WRT v24-sp2" have an iptables version new enough (from 2012?) to support this (dd-wrt is not a requirement, iptables is). The idea is to configure the router to make a duplicate of the traffic between the inverter and solaredge and send this to the server where I do the monitoring (Note some router/switches have (ethernet) port mirroring built in, this is another different option, mine has not). So the setup (I hope it renders correctly):

SolarEdge Inverter (192.168.120.100) ==== ROUTER ==== SolarEdge Website
..........Monitoring server (192.168.100.120) ===||

Configuring the router to duplicate traffic

These are the iptables rules enabling duplication of traffic (to be added to the firewall):

iptables -A PREROUTING -t mangle -d 192.168.120.100 -p tcp -j ROUTE --gw 192.168.100.120 --tee
iptables -A PREROUTING -t mangle -s 192.168.120.100 -p tcp -j ROUTE --gw 192.168.100.120 --tee
iptables -A POSTROUTING -t mangle -d 192.168.120.100 -p tcp -j ROUTE --gw 192.168.100.120 --tee
iptables -A POSTROUTING -t mangle -s 192.168.120.100 -p tcp -j ROUTE --gw 192.168.100.120 --tee

Basically says everything that before or after routing has a destination or source from the inverter, make a copy and send the copy to the monitoring server (leave the original unaffected). The trick is that the router changes the destination MAC address to that of the monitoring server (OSI level 2), without changing higher levels, so the IP addresses are unaffected by the duplication of the traffic.

Feeding the result into seamonitor

On the monitoring server, you can do:
sudo tcpdump -i eth0 -s 65535 -w - 'tcp and host 192.168.120.100' | python /root/solaredge/semonitor.py -vv | tee output.json | python /root/solaredge/se2state.py -o solar.json

Basically tcpdump captures all the data from the Ethernet interface, filters out so that only tcp traffic to/from the inverter is passed to semonitor, and writes in binary format to the pipe (to semonitor). Semonitor converts the TCP traffic into JSON, and se2state maintains the latest performance data.

For some reason I did not need to indicate the encryption key I recovered yesterday. I do not know if the traffic is currently unencrypted, or if simply semonitor takes it automatically as it is in the same directory. It may be necessary to pass -k with the key to semonitor.

That's all, I just wanted to share with you this way. Someone may find it useful/interesting...

Regards and thanks again for making this tool available.

EDIT: I added a tcp filter to rules.

Hello,

i'm new to the solaredge inverters and have some questions about the rs485 protocol.

In my understanding it is possible to get the inverter data over the rs485. Is it also possible to get the optimizer data over the rs485 interface?

Is there a way to set the power reduction over rs485?

Thanks!

Hi:

I am working with a group of students at Kansas State University on a research project. We are trying to grab data from a Solar Edge Inverter at 15 minute intervals to store and display on our own website. From what I have read so far it appears that we need to use semonitor.py to grab the data from the inverter and then use seextract.py to take that data and convert it into a readable file. Could you please explain in detail how this is done and how to set something like this up? Thank you very much for your time.

Is it at all possible to passively monitor the inverter via Ethernet and not having the inverter connected directly to a raspberry pi. Strangely wireshark does not detect any traffic from the inverter either. The monitoring site is collecting data so I know the connection works.
My setup consists of a se5000, a tesla battery and some solaredge meters connect to CT's. The se5000 is connected via Ethernet to an un-managed switch. The RS-485 connector in the se5000 is connected to the solaredge meters as well as a unit that connects to the tesla battery.
If I can avoid using the RS-485 that would be desirable, otherwise any suggestions about connecting the pi via RS-485 and not changing the inverter settings would also be welcome.

M

While I do not have pcap files to offer, I do see 'odd' parsing off the Events on my HD Wave inverter.
For example:
"events": { "xxxxxxx": { "Type": 7, "Event3": "Tue Aug 22 18:40:25 2017", "Time": "18:44:17", "Date": "2017-08-22", "Event2": 1, "ID": "xxxxxx", "Event1": "Thu Jan 1 01:00:00 1970" }
First, in my short list of dumps, I see a lot of different type's here, unlike the described 0 or 1. I've seen 118, 114, 7 and 0.

Secondly, The very first Event3 I pulled from the device (which has never connected to a SE server yet) was at epoch + 1, with a time/date close to the above (e.g. an accurate timestamp). Some random timestamp later (about 2 hours) Event3 then was jan 9th, 10:20:57 1970, e.g. some larger number. A few hours after that, the timestamp was epoch + 3. I even saw it at 0 once.
The same happens to Event1, jumps around a lot during history. Event2 I've often seen at epoch + 1, 2 or 3. But sometimes also as an actual timestamp.

So maybe if the description in

Type 118, Event1, 2 and 3 are near epoch, e.g. very low int's
Type 114, Event3 is a low-ish number (jan 9th 1970), Event2 was 502133 and Event1 Jan 3rd 1970.
Type 7, Event3 holds a timestamp - almost 4 minutes. Event1 and 2 are low ints.
Type 0, Event3 = 0, Event1 and 2 exact timestamp match.

An inverter will try to connect to port 22221 or 22222 (and possibly others) and may switch from one port to another. semonitor.py needs to be able to listen on multiple port numbers and accept a connection to any of them.

Hi Everyone,

First off, thanks to everyone for your efforts in getting this up and running.

I seem to be having trouble decoding packets sent from my inverter to the SolarEdge monitoring portal. My inverter is setup to send data via the SolarEdge ZigBee adapter, which then forwards it via Ethernet to my router and out to the Internet.

I captured the packet stream using this command,

/usr/sbin/tcpdump -i eth2 -U -w - tcp and host 192.168.0.23 | tee capture.pcap | python solaredge/seextract.py | python solaredge/semonitor.py -k ~/7f13ae9d.key -d stdout -vvv

192.168.0.23 is the IP address of the SolarEdge ZigBee adapter. At first, this resulted in a lot of messages about the decryption key not being available, i.e.,

Sep 27 19:53:02 debugEnable: True
Sep 27 19:53:02 debugFiles: True
Sep 27 19:53:02 debugMsgs: True
Sep 27 19:53:02 debugData: True
Sep 27 19:53:02 debugRaw: False
Sep 27 19:53:02 debugFileName: stdout
Sep 27 19:53:02 haltOnException: False
Sep 27 19:53:02 inFileName: stdin
Sep 27 19:53:02 serialDevice: False
Sep 27 19:53:02 networkDevice: False
Sep 27 19:53:02 sePort: 22222
Sep 27 19:53:02 networkSvcs: False
Sep 27 19:53:02 following: True
Sep 27 19:53:02 passiveMode: True
Sep 27 19:53:02 commandAction: False
Sep 27 19:53:02 masterMode: False
Sep 27 19:53:02 outFileName: stdout
Sep 27 19:53:02 append: w
Sep 27 19:53:02 keyFileName: /home/matt/7f13ae9d.key
Sep 27 19:53:02 key: 10de3256af65bb46a7c0853f7f38e06e
Sep 27 19:53:02 opening stdin
Sep 27 19:53:02
Sep 27 19:53:02 --> message: 2 length: 66
Sep 27 19:53:02 dataLen: 002c
Sep 27 19:53:02 dataLenInv: ffd3
Sep 27 19:53:02 sequence: 010e
Sep 27 19:53:02 source: 6710fcd2
Sep 27 19:53:02 dest: fffffffe
Sep 27 19:53:02 function: 003d
Sep 27 19:53:02 Decryption key not yet available
Sep 27 19:53:02 Ignoring this message

Note that the timestamps are all the same because I ran the captured packets through semonitor.py just now. Eventually, the decryption key was obtained,

Sep 27 19:53:02 --> message: 489 length: 56
Sep 27 19:53:02 dataLen: 0022
Sep 27 19:53:02 dataLenInv: ffdd
Sep 27 19:53:02 sequence: 00d2
Sep 27 19:53:02 source: 6710fcd2
Sep 27 19:53:02 dest: fffffffe
Sep 27 19:53:02 function: 0503
Sep 27 19:53:02 Creating decryption object with key 10de3256af65bb46a7c0853f7f38e06e

However, no packets can be decrypted. I always get this same error,

Sep 27 19:53:02 --> message: 502 length: 66
Sep 27 19:53:02 dataLen: 002c
Sep 27 19:53:02 dataLenInv: ffd3
Sep 27 19:53:02 sequence: 01c2
Sep 27 19:53:02 source: fffffffd
Sep 27 19:53:02 dest: ffffffff
Sep 27 19:53:02 function: 003d
Sep 27 19:53:02 Decrypting message
Sep 27 19:53:02 dataLen: 46f4
Sep 27 19:53:02 dataLenInv: e5b2
Sep 27 19:53:02 sequence: 31b2
Sep 27 19:53:02 source: 532ec11d
Sep 27 19:53:02 dest: 03fb24c7
Sep 27 19:53:02 function: 956e
Sep 27 19:53:02 Data length is too big for the message
Sep 27 19:53:02 data: f4 46 b2 e5 b2 31 1d c1 2e 53 c7 24 fb 03 6e 95
Sep 27 19:53:02 data: 1c 21
Sep 27 19:53:02 Ignoring this message

I obtained the inverter's encryption key using the USB method detailed in another issue (thanks for that tip!), so I think that's good. Does anyone have any idea about where I went wrong? In case it's helpful, please find attached the packet capture.

Edit: Here is the encryption key.

Hi,

I've read somewhere that there is a way to change the interval the solaredge pushes data over serial? Is this true and does somebody know how to do this? Or/and is there a way to pull the inverter and/or optimizer data via rs485?

Regards,
Joris

Hello,

As long as the messages were sent unencrypted everything went well, I got an awful lot of data :-)
Now since the data is encoded I am able to decode the data but the granularity of the data went down.
digging deeper into this I see now a lot of Checksum errors.

I tried a bit around to find the cause but with no luck.

Is someone seeing the same thing?

May 31 09:54:01 <stdin> --> message: 1352 length: 582
May 31 09:54:01 data:       12 34 56 79 24 02 db fd 8b 02 f4 21 1a 7e fe ff
May 31 09:54:01 data:       ff ff 3d 00 5b fb 96 06 43 67 cb f7 4b 67 14 99
May 31 09:54:01 data:       3b 65 10 86 1f 26 c2 09 37 c7 99 34 eb 58 b2 d6
May 31 09:54:01 data:       69 7d 89 87 ce 82 bc 0c 5d 73 7a f9 ea 3e 07 10
May 31 09:54:01 data:       97 6e c4 db bd 62 7c b0 ce d3 4a 93 4f 6a 15 1a
May 31 09:54:01 data:       01 0c 95 d8 83 d6 79 42 8d b9 46 5f 66 5c d6 b8
May 31 09:54:01 data:       a4 84 fb 79 67 e4 b6 91 e3 38 cd f9 74 6c 51 a8
May 31 09:54:01 data:       70 83 44 42 11 6d b2 69 4b 40 9d 8b ca 5d 48 07
May 31 09:54:01 data:       71 42 1a 0d 66 fa 20 c9 a8 07 d7 1c 15 b6 e0 28
May 31 09:54:01 data:       73 a1 bf a4 b2 17 67 c0 46 11 bc 72 de 3e 8f ec
May 31 09:54:01 data:       57 fe 04 d2 c0 0c ac 23 58 95 9b d7 b9 db 4c 0c
May 31 09:54:01 data:       49 3b 57 2e ab 64 87 ee ed b4 e7 52 74 d7 d4 59
May 31 09:54:01 data:       d0 ca c9 7e 27 ca 55 0e fe 2d 8d 3c 6e a5 52 05
May 31 09:54:01 data:       3c 0d 43 cc 33 2d b3 9e f8 ee 00 9b a3 cd 75 b9
May 31 09:54:01 data:       7c d6 79 78 c6 94 ae 4a 56 54 57 a4 d3 2f 48 46
May 31 09:54:01 data:       e8 98 a0 5e bb 11 63 dc 2a 2f 3f 50 1d 72 a6 a9
May 31 09:54:01 data:       3f f9 fe e2 8b de 6d 85 87 df af d7 8f 00 37 7d
May 31 09:54:01 data:       75 c2 e9 79 a8 ba 96 aa de 3e 80 e0 f0 bc 84 87
May 31 09:54:01 data:       19 16 75 0d e0 4e 5e 9b 0f 30 1d 18 1e 22 7d e8
May 31 09:54:01 data:       e7 31 bf 82 c6 8a c3 00 fe 0b b2 9d a6 fb 47 6c
May 31 09:54:01 data:       a2 f7 a4 c6 fa 5c 3b fe 49 5d 15 68 aa 2b c0 77
May 31 09:54:01 data:       5e ff b8 ac cd 2e b4 49 4b 6f cf a9 5e 02 4c d6
May 31 09:54:01 data:       a1 b9 3d ac 6b f3 dc 25 8f 14 06 6f 18 58 07 5e
May 31 09:54:01 data:       d2 4a 62 a8 63 75 74 c1 41 9b de 21 3f 0a 8c 3e
May 31 09:54:01 data:       81 1b ad 9b 3c 7b ba 64 78 64 58 e0 48 ad 2d c7
May 31 09:54:01 data:       62 3f 16 4d c4 31 b0 34 8f 23 ea 76 0c c3 0a 40
May 31 09:54:01 data:       f8 9d 01 f0 82 ed e2 41 93 c8 5a f6 b5 03 6f be
May 31 09:54:01 data:       81 75 a9 d9 93 0f 5d 16 b3 40 48 83 fb 5c 69 00
May 31 09:54:01 data:       fa ba 53 b5 42 51 1f bd b0 af 2c ea 3a d2 81 f9
May 31 09:54:01 data:       b8 7a 13 cc 6e 9a 4e 04 28 72 e7 3b f3 48 4e 82
May 31 09:54:01 data:       2d ba d2 c4 b9 ba 20 bf c4 1b 54 31 9b f7 95 ed
May 31 09:54:01 data:       f7 00 84 65 a1 30 93 2a a9 b0 ce 44 44 ab a4 09
May 31 09:54:01 data:       ca 7b f5 c4 18 79 8c 90 35 84 32 ae 32 ad 64 6e
May 31 09:54:01 data:       8a 7d 03 6a 71 5f f0 c5 b4 ed 00 00 d1 8a ba 14
May 31 09:54:01 data:       44 10 66 40 0a b0 35 4b b6 91 aa 73 0f 61 2b 0f
May 31 09:54:01 data:       f4 31 f3 d1 8b 25 9d e0 31 28 3a b9 26 55 c8 e5
May 31 09:54:01 data:       00 00 d4 47 2f 3b
May 31 09:54:01 dataLen:    0224
May 31 09:54:01 dataLenInv: fddb
May 31 09:54:01 sequence:   028b
May 31 09:54:01 source:     7e1a21f4
May 31 09:54:01 dest:       fffffffe
May 31 09:54:01 function:   003d
May 31 09:54:01 Discarding 12 extra bytes
May 31 09:54:01 data:       3a b9 26 55 c8 e5 00 00 d4 47 2f 3b
May 31 09:54:01 Checksum error. Expected 0x2831, got 0x2edc
May 31 09:54:01 data:       24 02 db fd 8b 02 f4 21 1a 7e fe ff ff ff 3d 00
May 31 09:54:01 data:       5b fb 96 06 43 67 cb f7 4b 67 14 99 3b 65 10 86
May 31 09:54:01 data:       1f 26 c2 09 37 c7 99 34 eb 58 b2 d6 69 7d 89 87
May 31 09:54:01 data:       ce 82 bc 0c 5d 73 7a f9 ea 3e 07 10 97 6e c4 db
May 31 09:54:01 data:       bd 62 7c b0 ce d3 4a 93 4f 6a 15 1a 01 0c 95 d8
May 31 09:54:01 data:       83 d6 79 42 8d b9 46 5f 66 5c d6 b8 a4 84 fb 79
May 31 09:54:01 data:       67 e4 b6 91 e3 38 cd f9 74 6c 51 a8 70 83 44 42
May 31 09:54:01 data:       11 6d b2 69 4b 40 9d 8b ca 5d 48 07 71 42 1a 0d
May 31 09:54:01 data:       66 fa 20 c9 a8 07 d7 1c 15 b6 e0 28 73 a1 bf a4
May 31 09:54:01 data:       b2 17 67 c0 46 11 bc 72 de 3e 8f ec 57 fe 04 d2
May 31 09:54:01 data:       c0 0c ac 23 58 95 9b d7 b9 db 4c 0c 49 3b 57 2e
May 31 09:54:01 data:       ab 64 87 ee ed b4 e7 52 74 d7 d4 59 d0 ca c9 7e
May 31 09:54:01 data:       27 ca 55 0e fe 2d 8d 3c 6e a5 52 05 3c 0d 43 cc
May 31 09:54:01 data:       33 2d b3 9e f8 ee 00 9b a3 cd 75 b9 7c d6 79 78
May 31 09:54:01 data:       c6 94 ae 4a 56 54 57 a4 d3 2f 48 46 e8 98 a0 5e
May 31 09:54:01 data:       bb 11 63 dc 2a 2f 3f 50 1d 72 a6 a9 3f f9 fe e2
May 31 09:54:01 data:       8b de 6d 85 87 df af d7 8f 00 37 7d 75 c2 e9 79
May 31 09:54:01 data:       a8 ba 96 aa de 3e 80 e0 f0 bc 84 87 19 16 75 0d
May 31 09:54:01 data:       e0 4e 5e 9b 0f 30 1d 18 1e 22 7d e8 e7 31 bf 82
May 31 09:54:01 data:       c6 8a c3 00 fe 0b b2 9d a6 fb 47 6c a2 f7 a4 c6
May 31 09:54:01 data:       fa 5c 3b fe 49 5d 15 68 aa 2b c0 77 5e ff b8 ac
May 31 09:54:01 data:       cd 2e b4 49 4b 6f cf a9 5e 02 4c d6 a1 b9 3d ac
May 31 09:54:01 data:       6b f3 dc 25 8f 14 06 6f 18 58 07 5e d2 4a 62 a8
May 31 09:54:01 data:       63 75 74 c1 41 9b de 21 3f 0a 8c 3e 81 1b ad 9b
May 31 09:54:01 data:       3c 7b ba 64 78 64 58 e0 48 ad 2d c7 62 3f 16 4d
May 31 09:54:01 data:       c4 31 b0 34 8f 23 ea 76 0c c3 0a 40 f8 9d 01 f0
May 31 09:54:01 data:       82 ed e2 41 93 c8 5a f6 b5 03 6f be 81 75 a9 d9
May 31 09:54:01 data:       93 0f 5d 16 b3 40 48 83 fb 5c 69 00 fa ba 53 b5
May 31 09:54:01 data:       42 51 1f bd b0 af 2c ea 3a d2 81 f9 b8 7a 13 cc
May 31 09:54:01 data:       6e 9a 4e 04 28 72 e7 3b f3 48 4e 82 2d ba d2 c4
May 31 09:54:01 data:       b9 ba 20 bf c4 1b 54 31 9b f7 95 ed f7 00 84 65
May 31 09:54:01 data:       a1 30 93 2a a9 b0 ce 44 44 ab a4 09 ca 7b f5 c4
May 31 09:54:01 data:       18 79 8c 90 35 84 32 ae 32 ad 64 6e 8a 7d 03 6a
May 31 09:54:01 data:       71 5f f0 c5 b4 ed 00 00 d1 8a ba 14 44 10 66 40
May 31 09:54:01 data:       0a b0 35 4b b6 91 aa 73 0f 61 2b 0f f4 31 f3 d1
May 31 09:54:01 data:       8b 25 9d e0 31 28 3a b9 26 55 c8 e5 00 00 d4 47
May 31 09:54:01 data:       2f 3b
May 31 09:54:01 Ignoring this message
May 31 09:54:01
May 31 09:54:01 <stdin> --> message: 1353 length: 66
May 31 09:54:01 data:       12 34 56 79 2c 00 d3 ff de 0c fd ff ff ff ff ff
May 31 09:54:01 data:       ff ff 3d 00 cd e8 e9 79 1f 48 41 d9 c5 06 5a b1
May 31 09:54:01 data:       36 82 85 1d 3c 46 93 cf c5 35 5b 14 97 71 c9 9c
May 31 09:54:01 data:       20 fc d0 94 45 7b 42 32 19 7b 67 a5 fc f9 6d 1e
May 31 09:54:01 data:       b6 60
May 31 09:54:01 dataLen:    002c
May 31 09:54:01 dataLenInv: ffd3
May 31 09:54:01 sequence:   0cde
May 31 09:54:01 source:     fffffffd
May 31 09:54:01 dest:       ffffffff
May 31 09:54:01 function:   003d
May 31 09:54:01 Decrypting message
May 31 09:54:01 dataLen:    0000
May 31 09:54:01 dataLenInv: ffff
May 31 09:54:01 sequence:   033c
May 31 09:54:01 source:     fffffffe
May 31 09:54:01 dest:       7e1a21f4
May 31 09:54:01 function:   0080
May 31 09:54:01
May 31 09:54:01 <stdin> --> message: 1354 length: 6
May 31 09:54:01 data:       12 34 56 79 2c 00
May 31 09:54:01 Ignoring this message
May 31 09:54:01
May 31 09:54:01 <stdin> --> message: 1355 length: 118
May 31 09:54:01 data:       12 34 56 79 60 00 9f ff 8c 02 f4 21 1a 7e fe ff
May 31 09:54:01 data:       ff ff 3d 00 cb a2 97 d4 43 a4 c1 e6 10 1c 0f a5
May 31 09:54:01 data:       42 69 e1 b3 8e c0 3d 0f e1 1c de fd 93 9e 3c 73
May 31 09:54:01 data:       76 fa 28 ae 1b e3 75 06 77 69 16 e0 fa ce 73 6e
May 31 09:54:01 data:       29 b7 7f 58 2b a6 67 c9 ef 3e f7 d7 9f 78 52 06
May 31 09:54:01 data:       af 46 fa 60 19 c1 e1 3a 12 a0 e3 39 85 33 5a 94
May 31 09:54:01 data:       d5 81 b3 33 81 fa 23 2b 4a e6 5c 84 86 05 0c f5
May 31 09:54:01 data:       37 a5 fc 29 23 5b
May 31 09:54:01 dataLen:    0060
May 31 09:54:01 dataLenInv: ff9f
May 31 09:54:01 sequence:   028c
May 31 09:54:01 source:     7e1a21f4
May 31 09:54:01 dest:       fffffffe
May 31 09:54:01 function:   003d
May 31 09:54:01 Decrypting message
May 31 09:54:01 dataLen:    0034
May 31 09:54:01 dataLenInv: ffcb
May 31 09:54:01 sequence:   ffff
May 31 09:54:01 source:     7e1a21f4
May 31 09:54:01 dest:       fffffffe
May 31 09:54:01 function:   03c2
May 31 09:54:01 Unknown function 0x03c2
May 31 09:54:01

https://www.solarpaneltalk.com/forum/solar-panels-for-home/solar-panel-system-equipment/19587-mirroring-intercepting-sunpower-monitoring-traffic/page3
mentions that someone wrote a script to watch sunpower traffic, partly based on this project.
(He's happy to help others who want to do the same thing, but is not willing/able to upload his script.)

Maybe this project could be generalized to support sunpower, too?

Filing this bug mostly just as a way to make it easier for sunpower users to follow breadcrumbs.

seconvert1.py should be able to reliably identify messages sent from the inverter to the SolarEdge server. If the server being communicated with is prod.solaredge.com (217.68.152.66) this can easily be done, however the IP address has been known to change without notice to another SolarEdge server. One alternative might be to filter messages whose source IP is on the local network (192.x.x.x).

Hi,

After running for a while my communication over RS485 as master suddenly stopped.
The error message:

Exception in thread master thread:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/pi/se/solaredge-master/semonitor.py", line 96, in masterCommands
    sendMsg(dataFile, formatMsg(nextSeq(), masterAddr, int(slaveAddr, 16), PROT_CMD_POLESTAR_MASTER_GRANT), recFile)
  File "/home/pi/se/solaredge-master/seMsg.py", line 174, in formatMsg
    checksum = calcCrc(struct.pack(">HLLH", msgSeq, fromAddr, toAddr, function) + data)
error: 'H' format requires 0 <= number <= 65535

Looking at the seseq.txt-file I can see that it has reached the maximum value for 16 bits and semonitor does not seem to deal with that situation?

Is it supposed to wrap around?

Can I safely remove the file? As it stores the sequence number on disk I always assumed that the sequence number should survive communication sessions?

Let me start by saying I'm a huge fan of this project! It has enabled me to pull a lot of info from my SolarEdge installation that I'm currently using in my Splunk and Homeseer dashboards.

I have a RasPi model B setup in bridge mode and am reading the traffic in passive ethernet mode. I've managed to get the encryption key through usb.

I'm running the python scripts in a chain as follows:

tcpdump -i br0 host x.x.x.x -U -w - | python seextract.py | python semonitor.py -k xxxxxxxx.key -o values.json

About once per day the seextract.py fails and this breaks the running script. I have managed to work around this by creating a monitoring script that checks values.json for updates and then kills and restarts the command if I don't see an update for 10 minutes. However, I then end up with a lot of missing data, since semonitor will have to wait for another set of session encryption keys (the 0503 message) before resuming logging.

It would be nice to somehow have the previous instance of semonitor store its session decryption keys somewhere, so that in case of an error and termination in tcpdump or seextract (so earlier in the script chain) a restart of semonitor can then start decrypting right away using the stored keys. There also should be a check if the keys work and if not it should be ignored (because they are too old e.g)

I haven't spend any time yet looking at the code so that I can actually make a proposal. My scripting / coding knowledge is rusty and my python knowledge non-existing but I'll spend some time on this in the next days hopefully.

I haven't figured out why seextract.py breaks, I have some debug logging and such, but that is another issue. I also have an issue with the se2csv script since it will only parse my optimizer data from the json and nothing on the inverter. For now I'm parsing the json through Splunk and can then use extracted csv files in HomeSeer. The inverter is a SE7k 3 phase. I can run separate issue reports for those issues and I can provide logging on both if needed.

This may be nothing new to all the contributors who have diligently created and updated this repository. However, I ended up creating this query as I cannot find a way to send PM to some of the dontributors.
I just got my SE7600 installed and in production. I'm reading a lot on this one and other forums so I can ask my installer to give me access I need to see what I want. BTW, I paid for my system outright.
On reading this for over a month I am getting this as a starting point.

• Only one interface out of LAN, RS, Zigbee, Cellular can be active at a time. My install has cellular so there is no way I know to snoop data.
• I want to use RPi3 and connect RS485 to collect data however the server is showing cellular so how will I get the data while still letting the portal updates to go thru? What type of connection must I make; any schematics will help immensely
• @abdullatahiroyo has all 3 connection per one of his post RS485, RS232 & LAN - how does he get data out of three simultaneously if first statement is true
• what are my options with cellular in the mix

Once I'm set I plan on writing a how to guide for someone new to this project. my first hurdle is to get this off the ground.

Hi All,

I was trying to use semonitor.py with my SolarEdge inverter. While using the -c 322 command with semonitor.py i can get energy values from the inverter.

But while trying to get the raw values from inverter, i came across a timestamp exception. The logging was working fine in last couple of days but now i am having this error.

Also i tried omitting the timestamp function in order to get only the inverter data. But had no luck.

pi@logger` ~/inverter/sedgenew $ sudo python semonitor.py -m -s 07e1a409e -d stdout -vvv -t 4 /dev/ttyUSB0
Jun 15 14:03:06 debugEnable: True
Jun 15 14:03:06 debugFiles: True
Jun 15 14:03:06 debugMsgs: True
Jun 15 14:03:06 debugData: True
Jun 15 14:03:06 debugRaw: False
Jun 15 14:03:06 debugFileName: stdout
Jun 15 14:03:06 haltOnException: False
Jun 15 14:03:06 inFileName: /dev/ttyUSB0
Jun 15 14:03:06 inputType: 4
Jun 15 14:03:06 serialDevice: True
Jun 15 14:03:06 baudRate: 115200
Jun 15 14:03:06 networkDevice: False
Jun 15 14:03:06 networkSvcs: False
Jun 15 14:03:06 following: True
Jun 15 14:03:06 passiveMode: False
Jun 15 14:03:06 commandAction: False
Jun 15 14:03:06 masterMode: True
Jun 15 14:03:06 slaveAddrs: 07e1a409e
Jun 15 14:03:06 outFileName: stdout
Jun 15 14:03:06 append: w
Jun 15 14:03:06 opening /dev/ttyUSB0
Jun 15 14:03:06 starting read thread
Jun 15 14:03:06 starting master thread
Jun 15 14:03:06 dataLen: 0000
Jun 15 14:03:06 dataLenInv: ffff
Jun 15 14:03:06 sequence: 00e7
Jun 15 14:03:06 source: fffffffe
Jun 15 14:03:06 dest: 7e1a409e
Jun 15 14:03:06 function: 0302
Jun 15 14:03:06 /dev/ttyUSB0 <-- message: 1 length: 22
Jun 15 14:03:06
Jun 15 14:03:43
Jun 15 14:03:43 /dev/ttyUSB0 --> message: 1 length: 520
Jun 15 14:03:43 dataLen: 01f2
Jun 15 14:03:43 dataLenInv: fe0d
Jun 15 14:03:43 sequence: 024d
Jun 15 14:03:43 source: 7e1a409e
Jun 15 14:03:43 dest: fffffffe
Jun 15 14:03:43 function: 0500
Jun 15 14:03:43 Exception: timestamp out of range for platform time_t

Any help would be really great.

Thanks a lot in advance.