jbuehl / solaredge

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

New to SolarEdge #11

Closed BoHammil closed 6 years ago

BoHammil commented 8 years ago

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

jbuehl commented 8 years ago

Good to hear this has been useful for you.

jdwhite commented 8 years ago

I'd contacted Solar Edge last November or so when this thread was just getting started and we hadn't decoded the payload yet to ask them if they'd just tell me what the on-wire packet format was. I was very explicit about what I was asking.  My response was esentially "that data is on our servers and we won't give you access to our servers".  My response clarifying that I was not asking for access to their server, but to the on-wire packet format, went unanswered.

My presumption is that the level 1 tech answering the mail didn't understand what I was asking for.

This is just one of many examples of what I don't like about these IoT devices and only being able to access the data from some server via an API.  If that company goes under you're hosed.  I've got a thermostat, weather station, and an inverter that fall into this category.  No internet, no data -- even if I can access on my local network.  Anyone ever read the Terms of Service for the Solar Edge website?  Only get to use for free for 25 years. :)

-Jason

From: BoHammil notifications@github.com Reply: jbuehl/solaredge reply@reply.github.com Date: May 11, 2016 at 11:24:25 PM To: jbuehl/solaredge solaredge@noreply.github.com Subject:  [jbuehl/solaredge] New to SolarEdge (#11)

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 l ike 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

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

--  Jason White

d-tamm commented 8 years ago

Hi there. I am also excited about the possibility to have a "faked" SolarEdge monitoring server (semonitor.py) and collect the inverter data myself instead of in the cloud. However, I am having trouble to get it working. My inverter is connected via ethernet, 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 supposed the script would go into a state where it accepts connections from the inverter. When I instead try sudo python semonitor.py -d stdout -n wlp2s0 (wlp2s0 is my network interface), I get the following error:

Exception in thread dnsThread: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 801, in bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 754, in run self.__target(_self.args, _self.__kwargs) File "/home/eltern/ownCloud/Solarzellen/Monitoring/solaredge-master/seNetwork.py", line 266, in dns dnsSocket.bind(("", dnsPort)) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(args) error: [Errno 98] Address already in use

and the script hangs, cannot even be terminated by Ctrl+C. Any advice? Thank you!

jbuehl commented 8 years ago

The second command line is correct sudo python semonitor.py -d stdout -n wlp2s0 The error message is occurring because the dns port 53 is busy, possibly because there is another dns server running on the same machine that you are using. You can use the command fuser 53/udp to find out which process is using the port.

d-tamm commented 8 years ago

Thank you for your reply. It turned out that dnsmasq was running in my standard Ubuntu installation. Did not expect this. After deactivating dnsmasq, I get no error messages any more. Anyway, I rather would like not to have semonitor.py act as a DNS/DHCP server, but manage this by my router. That's why I initially tried with the -tn option, according to the readme file:

If there is no data source specified and -t n is specified, semonitor.py will listen on port 22222 for a connection from an inverter.

So why is the first command throwing the error "Input file cannot be specified for network mode"? How is the -tn option expected to be used?

jbuehl commented 8 years ago

If you want semonitor.py to play the role of the monitoring server then when the inverter sends messages to the hostname of the SolarEdge server must resolve to the IP address of the server running semonitor.py. If the -n option is specified then semonitor.py performs DHCP/DNS services for the specified network interface that resolves all requests to the IP address of itself. This isn't useful as a DHCP/DNS server for a LAN and isn't intended to replace the DHCP/DNS servers for your network so the semonitor.py server needs to have 2 network interfaces - one that is connected only to the inverter and the other connected to your LAN.

The error message that occurs when you specify -tn is probably a bug, however if you want to use a separate DHCP/DNS server it will need to implement the special functionality required to spoof the IP address.

d-tamm commented 8 years ago

Yes I know I need to spoof the IP address. This is quite easy in my dd-wrt router, and would enable me to capture the data on my home server (which has just one network interface). I open a separate ticket for the -tn option.

jbuehl commented 8 years ago

i already fixed the -tn bug.

fahimmac commented 8 years ago

Hi,

Firstly,Great work you have done here with your SolarEdge Software.Thanks a lot for sharing.

I a trying to use the software with my solar edge inverter SE7k. My setup is Raspberry Pi 2 + RS485 USB adapter connected to the inverter. I am trying to communicate with a single inverter over RS485.

I could get the energy information if i use the 0x0322 command as you suggested on your other post.

pi@logger ~/Desktop/sedge $ sudo python semonitor.py -c 322 -s [serial number] -d stdout -vvvv -t 4 /dev/ttyUSB0

Jun 15 16:24:23 debugEnable: True Jun 15 16:24:23 debugFiles: True Jun 15 16:24:23 debugMsgs: True Jun 15 16:24:23 debugData: True Jun 15 16:24:23 debugRaw: True Jun 15 16:24:23 debugFileName: stdout Jun 15 16:24:23 haltOnException: False Jun 15 16:24:23 inFileName: /dev/ttyUSB0 Jun 15 16:24:23 inputType: 4 Jun 15 16:24:23 serialDevice: True Jun 15 16:24:23 baudRate: 115200 Jun 15 16:24:23 networkDevice: False Jun 15 16:24:23 networkSvcs: False Jun 15 16:24:23 following: True Jun 15 16:24:23 passiveMode: False Jun 15 16:24:23 commandAction: True Jun 15 16:24:23 command: 322 Jun 15 16:24:23 masterMode: True Jun 15 16:24:23 slaveAddrs: 07e1a06db Jun 15 16:24:23 outFileName: sedge Jun 15 16:24:23 append: w Jun 15 16:24:23 opening /dev/ttyUSB0 Jun 15 16:24:23 dataLen: 0000 Jun 15 16:24:23 dataLenInv: ffff Jun 15 16:24:23 sequence: 03d5 Jun 15 16:24:23 source: fffffffe Jun 15 16:24:23 dest: 7e1a06db Jun 15 16:24:23 function: 0322 Jun 15 16:24:23 /dev/ttyUSB0 <-- message: 1 length: 22 Jun 15 16:24:23 data: 12 34 56 79 00 00 ff ff d5 03 fe ff ff ff db 06 Jun 15 16:24:23 data: 1a 7e 22 03 c6 40 Jun 15 16:24:23
Jun 15 16:24:23
Jun 15 16:24:23 /dev/ttyUSB0 --> message: 1 length: 126 Jun 15 16:24:23 data: 12 34 56 79 68 00 97 ff d5 03 db 06 1a 7e fe ff Jun 15 16:24:23 data: ff ff 8d 03 f4 11 fc 44 f4 11 fc 44 f4 11 fc 44 Jun 15 16:24:23 data: 40 dd 3a 49 aa dc 60 57 d4 ad 0b 00 00 00 00 00 Jun 15 16:24:23 data: f6 8a 61 57 00 00 00 00 00 00 00 00 00 00 00 00 Jun 15 16:24:23 data: d4 ad 0b 00 00 00 00 00 f6 8a 61 57 00 00 00 00 Jun 15 16:24:23 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 15 16:24:23 data: 00 00 00 00 96 ae 0b 00 00 00 00 00 3c 8b 61 57 Jun 15 16:24:23 data: 00 00 00 00 00 00 00 00 f6 8a 61 57 9d 1d Jun 15 16:24:23 dataLen: 0068 Jun 15 16:24:23 dataLenInv: ff97 Jun 15 16:24:23 sequence: 03d5 Jun 15 16:24:23 source: 7e1a06db Jun 15 16:24:23 dest: fffffffe Jun 15 16:24:23 function: 038d Jun 15 16:24:23 sedge <-- message: 1 length: 194 Jun 15 16:24:23 data: 7b 22 64 61 74 61 22 3a 20 7b 22 45 6d 6f 6e 22 Jun 15 16:24:23 data: 3a 20 32 30 31 36 2e 35 36 31 30 33 35 31 35 36 Jun 15 16:24:23 data: 32 35 2c 20 22 45 74 6f 74 22 3a 20 37 36 35 33 Jun 15 16:24:23 data: 39 36 2e 30 2c 20 22 45 79 65 61 72 22 3a 20 32 Jun 15 16:24:23 data: 30 31 36 2e 35 36 31 30 33 35 31 35 36 32 35 2c Jun 15 16:24:23 data: 20 22 45 64 61 79 22 3a 20 32 30 31 36 2e 35 36 Jun 15 16:24:23 data: 31 30 33 35 31 35 36 32 35 2c 20 22 54 69 6d 65 Jun 15 16:24:23 data: 31 22 3a 20 22 57 65 64 20 4a 75 6e 20 31 35 20 Jun 15 16:24:23 data: 30 36 3a 34 32 3a 31 38 20 32 30 31 36 22 7d 2c Jun 15 16:24:23 data: 20 22 63 6f 6d 6d 61 6e 64 22 3a 20 38 30 32 2c Jun 15 16:24:23 data: 20 22 72 65 73 70 6f 6e 73 65 22 3a 20 39 30 39 Jun 15 16:24:23 data: 2c 20 22 73 65 71 75 65 6e 63 65 22 3a 20 39 38 Jun 15 16:24:23 data: 31 7d Jun 15 16:24:23
Jun 15 16:24:23 {"data": {"Emon": 2016.56103515625, "Etot": 765396.0, "Eyear": 2016.56103515625, "Eday": 2016.56103515625, "Time1": "Wed Jun 15 06:42:18 2016"}, "command": 802, "response": 909, "sequence": 981} Jun 15 16:24:25 closing /dev/ttyUSB0 Jun 15 16:24:25 closing sedge

But for getting the Vac,Iac and Pac information if i use 0X0500 code i do not receiver anything back.The programme just waits for inverter input but does not get anything back. I also tried using 0x0347 command but had no luck.

sudo python semonitor.py -m -c 500 -s [serial number] -d stdout -vvvv -t 4 /dev/ttyUSB0 Jun 15 16:29:04 debugEnable: True Jun 15 16:29:04 debugFiles: True Jun 15 16:29:04 debugMsgs: True Jun 15 16:29:04 debugData: True Jun 15 16:29:04 debugRaw: True Jun 15 16:29:04 debugFileName: stdout Jun 15 16:29:04 haltOnException: False Jun 15 16:29:04 inFileName: /dev/ttyUSB0 Jun 15 16:29:04 inputType: 4 Jun 15 16:29:04 serialDevice: True Jun 15 16:29:04 baudRate: 115200 Jun 15 16:29:04 networkDevice: False Jun 15 16:29:04 networkSvcs: False Jun 15 16:29:04 following: True Jun 15 16:29:04 passiveMode: False Jun 15 16:29:04 commandAction: True Jun 15 16:29:04 command: 500 Jun 15 16:29:04 masterMode: True Jun 15 16:29:04 slaveAddrs: 07e1a06db Jun 15 16:29:04 outFileName: sedge Jun 15 16:29:04 append: w Jun 15 16:29:04 opening /dev/ttyUSB0 Jun 15 16:29:04 dataLen: 0000 Jun 15 16:29:04 dataLenInv: ffff Jun 15 16:29:04 sequence: 03d6 Jun 15 16:29:04 source: fffffffe Jun 15 16:29:04 dest: 7e1a06db Jun 15 16:29:04 function: 0500 Jun 15 16:29:04 /dev/ttyUSB0 <-- message: 1 length: 22 Jun 15 16:29:04 data: 12 34 56 79 00 00 ff ff d6 03 fe ff ff ff db 06 Jun 15 16:29:04 data: 1a 7e 00 05 4a bd Jun 15 16:29:04

I will really appreciate your suggestion in this situation. Am i missing something here ?

jbuehl commented 8 years ago

The 0500 command is sent by the inverter, not by semonitor.py. Remove the -c 500 from your command line. The program will then wait indefinitely for 0500 messages from the inverter.

fahimmac commented 8 years ago

Thank you for your quick reply. I am getting output from the inverter now.

But at this moment i am only getting the values from optimizer, not the inverter values itself . Inverter is always identified as '0' on top of 'ID'. My inverter is set up as Server:RS485-1; Rs-485-1 Config: Device Type: Solar Edge, Protocol: Slave

pi@logger ~/solaredge $ sudo python semonitor.py -m -s 7e1a06db -d stdout -vvvv -t 4 /dev/ttyUSB0>

Jun 15 17:54:28 /dev/ttyUSB0 --> message: 8 length: 519

Jun 15 17:54:28 data: 12 34 56 79 f1 01 0e fe 0b 04 db 06 1a 7e fe ff Jun 15 17:54:28 data: ff ff 00 05 80 00 5d 76 23 20 0d 00 ea 0c 58 57 Jun 15 17:54:28 data: 5e 7d d8 40 f4 4b 88 0e 16 80 00 b5 65 23 20 0d Jun 15 17:54:28 data: 00 f5 0c 58 57 2c 73 d6 3c c4 4c 9d 0e 14 80 00 Jun 15 17:54:28 data: 99 65 23 20 0d 00 0a 0d 58 57 00 73 d4 38 24 4e Jun 15 17:54:28 data: b5 0e 14 80 00 19 65 23 20 0d 00 17 0d 58 57 4a Jun 15 17:54:28 data: 73 d2 34 d4 4d bd 0e 14 80 00 5e 71 23 20 0d 00 Jun 15 17:54:28 data: 24 0d 58 57 58 73 d7 50 04 4e 09 0f 15 80 00 df Jun 15 17:54:28 data: 79 23 20 0d 00 39 0d 58 57 34 73 d7 38 54 4c 96 Jun 15 17:54:28 data: 0e 13 80 00 70 65 23 20 0d 00 53 0d 58 57 e4 73 Jun 15 17:54:28 data: d6 4c d4 4d 02 0f 14 80 00 da 74 23 20 0d 00 69 Jun 15 17:54:28 data: 0d 58 57 9f 7d d7 3c 94 4b 8c 0e 14 11 00 db 06 Jun 15 17:54:28 data: 9a 7e 02 01 70 0d 58 57 c6 2d 00 00 2c 01 00 00 Jun 15 17:54:28 data: f1 a6 2e 42 a8 30 9c 46 00 80 bb 43 00 f0 67 43 Jun 15 17:54:28 data: 00 e0 67 43 00 54 66 43 00 40 c8 40 00 40 c9 40 Jun 15 17:54:28 data: 00 40 c8 40 bd 04 48 42 66 07 48 42 08 05 48 42 Jun 15 17:54:28 data: ff ff 7f ff ff ff 7f ff 00 0c 3b 44 ff ff 7f ff Jun 15 17:54:28 data: b0 c5 12 49 8d 97 ee 3b ff ff 7f ff ff ff 7f ff Jun 15 17:54:28 data: ff ff 7f ff 00 00 80 3f 00 00 80 3f 00 00 80 3f Jun 15 17:54:28 data: 04 00 00 00 2c a0 d7 45 00 00 c8 42 00 00 0c 3c Jun 15 17:54:28 data: 00 00 0c bc 00 00 e0 3a 00 b4 c8 43 00 7c c8 43 Jun 15 17:54:28 data: 00 fc c7 43 00 a0 b4 44 00 a0 b4 44 00 a0 b4 44 Jun 15 17:54:28 data: 00 20 b5 44 00 00 b5 44 00 c0 b6 44 00 00 d8 c2 Jun 15 17:54:28 data: 00 00 05 c3 00 00 ba c2 00 00 c8 42 00 00 c8 42 Jun 15 17:54:28 data: 00 00 c8 42 5b 2c 09 00 00 00 00 00 00 00 00 00 Jun 15 17:54:28 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5b 2c Jun 15 17:54:28 data: 09 00 00 00 00 00 00 80 bb 43 00 00 00 00 00 00 Jun 15 17:54:28 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 15 17:54:28 data: 00 00 00 00 00 00 80 00 1e 72 23 20 0d 00 7e 0d Jun 15 17:54:28 data: 58 57 6c 73 d3 54 a4 4e 1f 0f 14 80 00 5d 76 23 Jun 15 17:54:28 data: 20 0d 00 9c 0d 58 57 0f 7e da 3c 04 4b b1 0e 16 Jun 15 17:54:28 data: 80 00 df 79 23 20 0d 00 a2 0d 58 57 9d 73 d3 38 Jun 15 17:54:28 data: 74 4d ad 0e 13 5d 49 Jun 15 17:54:28 dataLen: 01f1 Jun 15 17:54:28 dataLenInv: fe0e Jun 15 17:54:28 sequence: 040b Jun 15 17:54:28 source: 7e1a06db Jun 15 17:54:28 dest: fffffffe Jun 15 17:54:28 function: 0500 Jun 15 17:54:28 optimizer: 2023765D type: 0080 len: 000d Jun 15 17:54:28 Uptime : 32094 Jun 15 17:54:28 Temp : 44.0 Jun 15 17:54:28 Vmod : 27.0 Jun 15 17:54:28 Imod : 7.59375 Jun 15 17:54:28 Eday : 930.0 Jun 15 17:54:28 Vopt : 34.0 Jun 15 17:54:28 Time : 14:17:46 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 2023765D Jun 15 17:54:28 optimizer: 202365B5 type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29484 Jun 15 17:54:28 Temp : 40.0 Jun 15 17:54:28 Vmod : 26.75 Jun 15 17:54:28 Imod : 7.675 Jun 15 17:54:28 Eday : 935.25 Jun 15 17:54:28 Vopt : 33.875 Jun 15 17:54:28 Time : 14:17:57 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 202365B5 Jun 15 17:54:28 optimizer: 20236599 type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29440 Jun 15 17:54:28 Temp : 40.0 Jun 15 17:54:28 Vmod : 26.5 Jun 15 17:54:28 Imod : 7.8125 Jun 15 17:54:28 Eday : 941.25 Jun 15 17:54:28 Vopt : 33.75 Jun 15 17:54:28 Time : 14:18:18 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 20236599 Jun 15 17:54:28 optimizer: 20236519 type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29514 Jun 15 17:54:28 Temp : 40.0 Jun 15 17:54:28 Vmod : 26.25 Jun 15 17:54:28 Imod : 7.78125 Jun 15 17:54:28 Eday : 943.25 Jun 15 17:54:28 Vopt : 33.625 Jun 15 17:54:28 Time : 14:18:31 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 20236519 Jun 15 17:54:28 optimizer: 2023715E type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29528 Jun 15 17:54:28 Temp : 42.0 Jun 15 17:54:28 Vmod : 26.875 Jun 15 17:54:28 Imod : 7.8 Jun 15 17:54:28 Eday : 962.25 Jun 15 17:54:28 Vopt : 34.5 Jun 15 17:54:28 Time : 14:18:44 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 2023715E Jun 15 17:54:28 optimizer: 202379DF type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29492 Jun 15 17:54:28 Temp : 38.0 Jun 15 17:54:28 Vmod : 26.875 Jun 15 17:54:28 Imod : 7.63125 Jun 15 17:54:28 Eday : 933.5 Jun 15 17:54:28 Vopt : 33.75 Jun 15 17:54:28 Time : 14:19:05 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 202379DF Jun 15 17:54:28 optimizer: 20236570 type: 0080 len: 000d Jun 15 17:54:28 Uptime : 29668 Jun 15 17:54:28 Temp : 40.0 Jun 15 17:54:28 Vmod : 26.75 Jun 15 17:54:28 Imod : 7.78125 Jun 15 17:54:28 Eday : 960.5 Jun 15 17:54:28 Vopt : 34.375 Jun 15 17:54:28 Time : 14:19:31 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 20236570 Jun 15 17:54:28 optimizer: 202374DA type: 0080 len: 000d Jun 15 17:54:28 Uptime : 32159 Jun 15 17:54:28 Temp : 40.0 Jun 15 17:54:28 Vmod : 26.875 Jun 15 17:54:28 Imod : 7.55625 Jun 15 17:54:28 Eday : 931.0 Jun 15 17:54:28 Vopt : 33.875 Jun 15 17:54:28 Time : 14:19:53 Jun 15 17:54:28 Date : 2016-06-08 Jun 15 17:54:28 Inverter : 0 Jun 15 17:54:28 ID : 202374DA Jun 15 17:54:28 Unknown device 0x0011 Jun 15 17:54:28 data: 11 00 db 06 9a 7e 02 01 70 0d 58 57 c6 2d 00 00 Jun 15 17:54:28 data: 2c 01 00 00 f1 a6 2e 42 a8 30 9c 46 00 80 bb 43 Jun 15 17:54:28 data: 00 f0 67 43 00 e0 67 43 00 54 66 43 00 40 c8 40 Jun 15 17:54:28 data: 00 40 c9 40 00 40 c8 40 bd 04 48 42 66 07 48 42 Jun 15 17:54:28 data: 08 05 48 42 ff ff 7f ff ff ff 7f ff 00 0c 3b 44 Jun 15 17:54:28 data: ff ff 7f ff b0 c5 12 49 8d 97 ee 3b ff ff 7f ff Jun 15 17:54:28 data: ff ff 7f ff ff ff 7f ff 00 00 80 3f 00 00 80 3f Jun 15 17:54:28 data: 00 00 80 3f 04 00 00 00 2c a0 d7 45 00 00 c8 42 Jun 15 17:54:28 data: 00 00 0c 3c 00 00 0c bc 00 00 e0 3a 00 b4 c8 43 Jun 15 17:54:28 data: 00 7c c8 43 00 fc c7 43 00 a0 b4 44 00 a0 b4 44 Jun 15 17:54:28 data: 00 a0 b4 44 00 20 b5 44 00 00 b5 44 00 c0 b6 44 Jun 15 17:54:28 data: 00 00 d8 c2 00 00 05 c3 00 00 ba c2 00 00 c8 42 Jun 15 17:54:28 data: 00 00 c8 42 00 00 c8 42 5b 2c 09 00 00 00 00 00 Jun 15 17:54:29 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 15 17:54:29 data: 00 00 5b 2c 09 00 00 00 00 00 00 80 bb 43 00 00 Jun 15 17:54:29 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 15 17:54:29 data: 00 00 00 00 00 00 00 00 00 00 Jun 15 17:54:29 optimizer: 2023721E type: 0080 len: 000d Jun 15 17:54:29 Uptime : 29548 Jun 15 17:54:29 Temp : 40.0 Jun 15 17:54:29 Vmod : 26.375 Jun 15 17:54:29 Imod : 7.8625 Jun 15 17:54:29 Eday : 967.75 Jun 15 17:54:29 Vopt : 34.625 Jun 15 17:54:29 Time : 14:20:14 Jun 15 17:54:29 Date : 2016-06-08 Jun 15 17:54:29 Inverter : 0 Jun 15 17:54:29 ID : 2023721E Jun 15 17:54:29 optimizer: 2023765D type: 0080 len: 000d Jun 15 17:54:29 Uptime : 32271 Jun 15 17:54:29 Temp : 44.0 Jun 15 17:54:29 Vmod : 27.25 Jun 15 17:54:29 Imod : 7.5 Jun 15 17:54:29 Eday : 940.25 Jun 15 17:54:29 Vopt : 33.875 Jun 15 17:54:29 Time : 14:20:44 Jun 15 17:54:29 Date : 2016-06-08 Jun 15 17:54:29 Inverter : 0 Jun 15 17:54:29 ID : 2023765D Jun 15 17:54:29 optimizer: 202379DF type: 0080 len: 000d Jun 15 17:54:29 Uptime : 29597 Jun 15 17:54:29 Temp : 38.0 Jun 15 17:54:29 Vmod : 26.375 Jun 15 17:54:29 Imod : 7.74375 Jun 15 17:54:29 Eday : 939.25 Jun 15 17:54:29 Vopt : 33.75 Jun 15 17:54:29 Time : 14:20:50 Jun 15 17:54:29 Date : 2016-06-08 Jun 15 17:54:29 Inverter : 0 Jun 15 17:54:29 ID : 202379DF

 Do i need to change some setting to get the inverter value itself ?
jbuehl commented 8 years ago

The "unknown device 0x0011" may contain the inverter data. It looks like they have changed the format for the inverter data for your model of inverter. If you change line 134 of seData.py to

elif seType == 0x0011: # inverter data

it may give you some useful data. The 0011 data is 258 bytes and is larger than the 0001 data so there are some new data items that would have to be understood. The program should ignore them for now.

Jerrythafast commented 8 years ago

I believe the three phase inverters have an extended format to allow for the additional line measurement data. I can't check right now because I am not at home, but I wouldn't be surprised if 0x0011 would be 3 phase inverter data. If I remember correctly it generally has the same format, except for the fact that it has three Vac and Iac values instead of one.


Van: jbuehlmailto:notifications@github.com Verzonden: ‎16-‎6-‎2016 15:44 Aan: jbuehl/solaredgemailto:solaredge@noreply.github.com Onderwerp: Re: [jbuehl/solaredge] New to SolarEdge (#11)

The "unknown device 0x0011" may contain the inverter data. It looks like they have changed the format for the inverter data for your model of inverter. If you change line 134 of seData.py to

elif seType == 0x0011: # inverter data

it may give you some useful data. The 0011 data is 258 bytes and is larger than the 0001 data so there are some new data items that would have to be understood. The program should ignore them for now.


You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jbuehl/solaredge/issues/11#issuecomment-226489012

fahimmac commented 8 years ago

Yes, after updating 0x0011 data in seData.py i could get some values from the inverter.But as Jerrythefast suggested, it was no different format than your solaredge inverter. The inverter values contains some errors.

Jun 16 16:11:26 /dev/ttyUSB0 --> message: 2 length: 519 Jun 16 16:11:26 data: 12 34 56 79 f1 01 0e fe 6a 04 db 06 1a 7e fe ff Jun 16 16:11:26 data: ff ff 00 05 11 00 db 06 9a 7e 02 01 c0 53 58 57 Jun 16 16:11:26 data: 46 1f 00 00 2c 01 00 00 44 b2 1f 42 58 3b 39 45 Jun 16 16:11:26 data: 00 00 10 42 00 68 65 43 00 7c 65 43 00 6c 63 43 Jun 16 16:11:26 data: 00 00 5e 3f 00 00 62 3f 00 00 66 3f be 02 48 42 Jun 16 16:11:26 data: 94 00 48 42 8f 01 48 42 ff ff 7f ff ff ff 7f ff Jun 16 16:11:26 data: 00 2c 3b 44 ff ff 7f ff 10 f6 15 49 35 5e 3a 3b Jun 16 16:11:26 data: ff ff 7f ff ff ff 7f ff ff ff 7f ff 00 00 80 3f Jun 16 16:11:26 data: 00 00 80 3f 00 00 80 3f 04 00 00 00 61 a0 d7 45 Jun 16 16:11:26 data: 00 00 c8 42 00 00 04 bc 00 00 80 b9 00 00 40 bb Jun 16 16:11:26 data: 00 74 c6 43 00 1c c6 43 00 c4 c5 43 00 00 1d 43 Jun 16 16:11:26 data: 00 00 1d 43 00 00 18 43 00 00 46 43 00 00 4d 43 Jun 16 16:11:26 data: 00 00 4a 43 00 00 f0 c2 00 00 05 c3 00 00 09 c3 Jun 16 16:11:26 data: 00 00 c8 42 00 00 c8 42 00 00 c8 42 61 5f 09 00 Jun 16 16:11:26 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 16 16:11:26 data: 00 00 00 00 00 00 61 5f 09 00 00 00 00 00 00 00 Jun 16 16:11:26 data: 10 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 16 16:11:26 data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 Jun 16 16:11:26 data: be 67 23 20 0d 00 c2 53 58 57 91 20 f1 74 74 08 Jun 16 16:11:26 data: 25 02 0c 80 00 70 65 23 20 0d 00 c4 53 58 57 95 Jun 16 16:11:26 data: 20 e6 5c a4 08 58 02 0c 80 00 0d 65 23 20 0d 00 Jun 16 16:11:26 data: cf 53 58 57 9f 20 e9 14 04 08 53 02 0b 80 00 5e Jun 16 16:11:26 data: 71 23 20 0d 00 d1 53 58 57 9e 20 eb d0 43 07 15 Jun 16 16:11:26 data: 01 0b 80 00 bf 66 23 20 0d 00 e5 53 58 57 b5 20 Jun 16 16:11:26 data: ea 44 a4 08 6b 02 0b 80 00 99 65 23 20 0d 00 f3 Jun 16 16:11:26 data: 53 58 57 c2 20 ec 88 84 08 a2 02 0c 80 00 0d 65 Jun 16 16:11:26 data: 23 20 0d 00 f4 53 58 57 c4 20 eb 20 d4 07 54 02 Jun 16 16:11:26 data: 0b 80 00 df 79 23 20 0d 00 05 54 58 57 d2 20 eb Jun 16 16:11:26 data: 84 a4 08 8e 02 0c 80 00 5e 71 23 20 0d 00 08 54 Jun 16 16:11:26 data: 58 57 d5 20 f6 d8 a3 06 16 01 0b 80 00 db 77 23 Jun 16 16:11:26 data: 20 0d 00 0b 54 58 57 da 20 ed 1c b4 07 b6 01 0b Jun 16 16:11:26 data: 80 00 e0 64 23 20 0d 00 30 54 58 57 ff 20 ec 68 Jun 16 16:11:26 data: 54 08 93 02 0c 47 7b Jun 16 16:11:26 dataLen: 01f1 Jun 16 16:11:26 dataLenInv: fe0e Jun 16 16:11:26 sequence: 046a Jun 16 16:11:26 source: 7e1a06db Jun 16 16:11:26 dest: fffffffe Jun 16 16:11:26 function: 0500

**> Jun 16 16:11:26 inverter: 7E1A06DB type: 0011 len: 0102

Jun 16 16:11:26 Uptime : 8006 Jun 16 16:11:26 Temp : 39.9240875244 Jun 16 16:11:26 Vac : 229.40625 Jun 16 16:11:26 Eac : 36.0 Jun 16 16:11:26 Interval : 300 Jun 16 16:11:26 Iac : 229.484375 Jun 16 16:11:26 Eday : 2963.70898438 Jun 16 16:11:26 Etot : 50.0005645752 Jun 16 16:11:26 Vdc : 0.8984375 Jun 16 16:11:26 Pac : -3.40282346639e+38 Jun 16 16:11:26 Time : 19:20:00 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Freq : 227.421875 Jun 16 16:11:26 ID : 7E1A06DB Jun 16 16:11:26 Pmax : -3.40282346639e+38\

Jun 16 16:11:26 optimizer: 202367BE type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8337 Jun 16 16:11:26 Temp : 24.0 Jun 16 16:11:26 Vmod : 30.125 Jun 16 16:11:26 Imod : 0.84375 Jun 16 16:11:26 Eday : 137.25 Jun 16 16:11:26 Vopt : 35.625 Jun 16 16:11:26 Time : 19:20:02 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 202367BE Jun 16 16:11:26 optimizer: 20236570 type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8341 Jun 16 16:11:26 Temp : 24.0 Jun 16 16:11:26 Vmod : 28.75 Jun 16 16:11:26 Imod : 0.8625 Jun 16 16:11:26 Eday : 150.0 Jun 16 16:11:26 Vopt : 34.875 Jun 16 16:11:26 Time : 19:20:04 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 20236570 Jun 16 16:11:26 optimizer: 2023650D type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8351 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 29.125 Jun 16 16:11:26 Imod : 0.8 Jun 16 16:11:26 Eday : 148.75 Jun 16 16:11:26 Vopt : 32.625 Jun 16 16:11:26 Time : 19:20:15 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 2023650D Jun 16 16:11:26 optimizer: 2023715E type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8350 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 29.375 Jun 16 16:11:26 Imod : 0.725 Jun 16 16:11:26 Eday : 69.25 Jun 16 16:11:26 Vopt : 30.5 Jun 16 16:11:26 Time : 19:20:17 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 2023715E Jun 16 16:11:26 optimizer: 202366BF type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8373 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 29.25 Jun 16 16:11:26 Imod : 0.8625 Jun 16 16:11:26 Eday : 154.75 Jun 16 16:11:26 Vopt : 34.125 Jun 16 16:11:26 Time : 19:20:37 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 202366BF Jun 16 16:11:26 optimizer: 20236599 type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8386 Jun 16 16:11:26 Temp : 24.0 Jun 16 16:11:26 Vmod : 29.5 Jun 16 16:11:26 Imod : 0.85 Jun 16 16:11:26 Eday : 168.5 Jun 16 16:11:26 Vopt : 36.25 Jun 16 16:11:26 Time : 19:20:51 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 20236599 Jun 16 16:11:26 optimizer: 2023650D type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8388 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 29.375 Jun 16 16:11:26 Imod : 0.78125 Jun 16 16:11:26 Eday : 149.0 Jun 16 16:11:26 Vopt : 33.0 Jun 16 16:11:26 Time : 19:20:52 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 2023650D Jun 16 16:11:26 optimizer: 202379DF type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8402 Jun 16 16:11:26 Temp : 24.0 Jun 16 16:11:26 Vmod : 29.375 Jun 16 16:11:26 Imod : 0.8625 Jun 16 16:11:26 Eday : 163.5 Jun 16 16:11:26 Vopt : 36.125 Jun 16 16:11:26 Time : 19:21:09 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 202379DF Jun 16 16:11:26 optimizer: 2023715E type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8405 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 30.75 Jun 16 16:11:26 Imod : 0.6625 Jun 16 16:11:26 Eday : 69.5 Jun 16 16:11:26 Vopt : 30.75 Jun 16 16:11:26 Time : 19:21:12 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 2023715E Jun 16 16:11:26 optimizer: 202377DB type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8410 Jun 16 16:11:26 Temp : 22.0 Jun 16 16:11:26 Vmod : 29.625 Jun 16 16:11:26 Imod : 0.76875 Jun 16 16:11:26 Eday : 109.5 Jun 16 16:11:26 Vopt : 32.875 Jun 16 16:11:26 Time : 19:21:15 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 202377DB Jun 16 16:11:26 optimizer: 202364E0 type: 0080 len: 000d Jun 16 16:11:26 Uptime : 8447 Jun 16 16:11:26 Temp : 24.0 Jun 16 16:11:26 Vmod : 29.5 Jun 16 16:11:26 Imod : 0.83125 Jun 16 16:11:26 Eday : 164.75 Jun 16 16:11:26 Vopt : 35.25 Jun 16 16:11:26 Time : 19:21:52 Jun 16 16:11:26 Date : 2016-06-08 Jun 16 16:11:26 Inverter : 0 Jun 16 16:11:26 ID : 202364E0

I got two unknown values for Pac and Pmax ( -3.40282346639e+38) . Also my Etotal got completely changed (765396.0 to 50.0005645752).

I am not sure for which reason this error is happening. Suggestions will be really helpful.

jbuehl commented 8 years ago

Someone with one of these inverters will need to interpret what the values represent.

Jerrythafast commented 8 years ago

I already had this lying around. Here you go.

Record Types
0000    Panel
0001    String
0002    Cluster
0010    Inverter1Phase
0011    Inverter3Phase
0012    CombiString
0013    Combi
0014    UnifiedCombiString
0015    UnifiedCombi
0080    PanelPacked
0200    Venus
0300    Polestar
0400    Suntracer
0800    Jupiter
0A00    Vega
Telemetry Record Header         
0000    0001    UINT16  Type of record
0002    0005    UINT32  ID
0006    0007    UINT16  Length
0008    000B    UINT32  TimeStamp

0000 Panel Record           
000C    000F    UINT32  ReceiverID
0010    0013    UINT32  DstID
0014    0017    UINT32  Seconds
0018    001B    Single  Vin
001C    001F    Single  Vout
0020    0023    Single  Iin
0024    0027    Single  AccPower
0028    002B    Single  Temperature

0001 String Record          
000C    000F    UINT32  ReceiverID
0010    0013    UINT32  DstID
0014    0017    UINT32  Seconds
0018    001B    Single  Vin
001C    001F    Single  Vout
0020    0023    Single  Iin
0024    0027    Single  AccPower
0028    002B    Single  Temperature

0002 Cluster Record         
000C    000F    UINT32  ReceiverID
0010    0013    UINT32  Seconds
0014    0017    Single  Vin
0018    001B    Single  Vout
001C    001F    Single  Iin
0020    0023    Single  AccPower
0024    0027    Single  AccIIn
0028    002B    Single  Temperature

0010 Inverter1Phase Record          
000C    000F    UINT32  Secs
0010    0013    UINT32  SecsDelta
0014    0017    Single  Temperature
0018    001B    Single  AccPowerAC
001C    001F    Single  AccPowerDeltaAC
0020    0023    Single  VoltageAC
0024    0027    Single  CurrentAC
0028    002B    Single  FreqAC
002C    002F    Single  AccPowerDC
0030    0033    Single  AccPowerDeltaDC
0034    0037    Single  VoltageDC
0038    003B    Single  CurrentDC

0011 Inverter3Phase Record          
000C    000F    UINT32  Secs
0010    0013    UINT32  SecsDelta
0014    0017    Single  Temperature
0018    001B    Single  AccPowerAC
001C    001F    Single  AccPowerDeltaAC
0020    0023    Single  VoltageAC1
0024    0027    Single  VoltageAC2
0028    002B    Single  VoltageAC3
002C    002F    Single  CurrentAC1
0030    0033    Single  CurrentAC2
0034    0037    Single  CurrentAC3
0038    003B    Single  FreqAC1
003C    003F    Single  FreqAC2
0040    0043    Single  FreqAC3
0044    0047    Single  AccPowerDC
0048    004B    Single  AccPowerDeltaDC
004C    004F    Single  VoltageDC
0050    0053    Single  CurrentDC

0012 CombiString Record         
000C    000F    UINT32  Seconds
0010    0013    UINT32  SecondsDelta
0014    0017    UINT32  InitiatorID
0018    0019    UINT16  TrippedCode
001A    001B    UINT16  Status
001C    001D    UINT16  ErrorCode
001E    001F    UINT16  StringIndex
0020    0021    UINT16  StringIndexGemini
0022    0023    UINT16  SwitchesStatus
0024    0027    Single  ErrorMeasurement
0028    002B    Single  RCD_I
002C    002F    Single  String_I
0030    0033    Single  String_V
0034    0037    Single  HS_V
0038    003B    Single  LS_V
003C    003F    Single  EnergyDelta
0040    0043    Single  Energy

0013 Combi Record           
000C    000F    UINT32  Seconds
0010    0013    UINT32  SecondsDelta
0014    0017    UINT32  InitiatorID
0018    0019    UINT16  TrippedCode
001A    001B    UINT16  Status
001C    001D    UINT16  ErrorCode
001E    001F    UINT16  ActiveStrings
0020    0021    Single  InverterVoltage
0022    0023    Single  TotalSystemCurrent
0024    0027    Single  Temperature
0028    002B    Single  VSupply
002C    002F    Single  Common_5V
0030    0033    Single  V_Ref_1
0034    0037    Single  V_Ref_2
0038    003B    Single  EnergyDelta
003C    003F    Single  Energy

0014 UnifiedCombiString Record          
000C    000F    UINT32  Seconds
0010    0013    UINT32  SecondsDelta
0014    0017    UINT32  InitiatorID
0018    0019    UINT16  TrippedCode
001A    001B    UINT16  Status
001C    001D    UINT16  ErrorCode
001E    001F    UINT16  StringIndex
0020    0021    UINT16  StringIndexGemini
0022    0023    UINT16  SwitchesStatus
0024    0027    Single  ErrorMeasurement
0028    002B    Single  RCD_I
002C    002F    Single  String_I
0030    0033    Single  String_V
0034    0037    Single  HS_V
0038    003B    Single  LS_V
003C    003F    Single  EnergyDelta
0040    0043    Single  Energy

0015 UnifiedCombi Record            
000C    000F    UINT32  Seconds
0010    0013    UINT32  SecondsDelta
0014    0017    UINT32  InitiatorID
0018    0019    UINT16  TrippedCode
001A    001B    UINT16  Status
001C    001D    UINT16  ErrorCode
001E    001F    UINT16  ActiveStrings
0020    0021    Single  InverterVoltage
0022    0023    Single  TotalSystemCurrent
0024    0027    Single  Temperature
0028    002B    Single  VSupply
002C    002F    Single  Common_5V
0030    0033    Single  V_Ref_1
0034    0037    Single  V_Ref_2
0038    003B    Single  EnergyDelta
003C    003F    Single  Energy

PanelPacked is obviously a bit harder to sum up like this. But its format is already known anyway.

d-tamm commented 8 years ago

I am still trying to get semonitor running with the eth interface. When I connect my SE5k inverter via an eth cable to my laptop and issue sudo python semonitor.py -d stdout -n wlp2s0 the inverter's display shows eight "1" on the ethernet page, indicating that LAN connection should be fine on all levels including ping to Google and prod.solaredge.com (according to my installation guide). However, on the display's start page, the indicating connection to the monitoring server never shows up, and the script does not output anything (I have tested for more than 1 hour now). So I am wondering if 1) semonitor's eth option is known to be working with this inverter, and 2) what I can do for debugging? Would a tcpdump output help? Thank you for your help!

jbuehl commented 8 years ago

@d-tamm, probably you are not seeing any output because the performance data is encrypted. If you add the -vv option you should see some 003d and 0503 messages being sent by the inverter.

There are two ways you can decrypt the data. I have updated the examples in the README to describe them. Both involve temporarily connecting to the inverter via RS232 and sending some commands.

  1. Extract the encryption key from the inverter to a file using the RS232 interface as described in the example for sekey.py. Then you can monitor using ethernet if you reference this file with the -k option as shown in the last example for semonitor.py.
  2. Place the inverter in unencrypted mode as described in the second to last example for semonitor.py using the RS232 interface. The inverter will remain in unencrypted mode as long as it doesn't communicate with the SolarEdge server. If you let it communicate with SolarEdge again they will set it back to encrypted mode.
jbuehl commented 8 years ago

@Jerrythafast - I don't think that represents the actual format of the data in the 0500 record for the 0011 inverter. When I analyze the data that @fahimmac posted that his inverter reported, The first few fields have data that is reasonable according to your format, but it gets confusing after that.

11 00           Device type 
db 06 9a 7e     Device ID
02 01           Data length
70 0d 58 57     Timestamp
c6 2d 00 00     Uptime
2c 01 00 00     Interval
f1 a6 2e 42     Temp
a8 30 9c 46     Eday
00 80 bb 43     Eac
00 f0 67 43     Vac1
00 e0 67 43     Vac2
00 54 66 43     Vac3
00 40 c8 40     Iac1
00 40 c9 40     Iac2
00 40 c8 40     Iac3
bd 04 48 42     Freq1
66 07 48 42     Freq2
08 05 48 42     Freq3
ff ff 7f ff 
ff ff 7f ff 
00 0c 3b 44 
ff ff 7f ff 
b0 c5 12 49 
8d 97 ee 3b 
ff ff 7f ff 
ff ff 7f ff 
ff ff 7f ff 
00 00 80 3f 
00 00 80 3f 
00 00 80 3f 
04 00 00 00 
2c a0 d7 45 
00 00 c8 42 
00 00 0c 3c 
00 00 0c bc 
00 00 e0 3a 
00 b4 c8 43 
00 7c c8 43 
00 fc c7 43 
00 a0 b4 44 
00 a0 b4 44 
00 a0 b4 44 
00 20 b5 44 
00 00 b5 44 
00 c0 b6 44 
00 00 d8 c2 
00 00 05 c3 
00 00 ba c2 
00 00 c8 42 
00 00 c8 42 
00 00 c8 42 
5b 2c 09 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 5b 2c 
09 00 00 00 
00 00 00 80 
bb 43 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 
00 00 00 00 00 00 
fahimmac commented 8 years ago

@Jerrythafast @jbuehl Sorry, for my basic question but how should i interpret the hex values to actual inverter information (as the information in inverter screen )?

As an example,you told that the Eac output from the inverter was 00 80 bb 43 and for Eday was a8 30 9c 46.

Should i take 00,80,bb,43 hexadecimal values individually - Convert them to decimal - and add them up? (00 + 80 + bb + 43 )

Or should i take 0080 and bb43 - Convert them to decimal -and add them up ? (0080 + bb43 )

Is the same procedure should be used for getting other values ? (Temp,Vac ,Iac, Freq).

Thank you.

jbuehl commented 8 years ago

These are mostly little endian floating point values. 00,80,bb,43 is the representation of 375.0. Python code for decoding them is

>>> import struct
>>> x="\x00\x80\xbb\x43"
>>> struct.unpack("<f",x)
(375.0,)
jbuehl commented 8 years ago

Here's an online conversion tool http://www.scadacore.com/field-applications/programming-calculators/online-hex-converter/

d-tamm commented 8 years ago

I have done some additions in my seData.py and seDataParams.py files in order to adjust for my 3 phase inverter, according to the posts above. This leads to quite reasonable values for most of the values (but not all of them), see http://zuhause.tamm-tamm.de/pv/. I would like to contribute this change to this project and will try to do this via a fork and pull request (never done that before...).

fahimmac commented 8 years ago

@d-tamm Thats really nice. Were you successful to contribute the modified seData.py and seDataParams.py for 3 phase inverter ? I would like to see the modifications you made,if possible. Thanks.

d-tamm commented 8 years ago

I am doing my first steps with github now. You should find the 3 phase inverter additions in my fork of this repository. However, there are a few parameters where I do not know what they contain, and others which are obviously wrongly paired. E.g. Pmax and Pac are definitely wrongly mapped. I have added some comments to confirmed parameters in the code.

d-tamm commented 8 years ago

I am trying to get more light on the field mapping for 3 phase inverters, using the seDataParams.py and seData.py files in my fork, see also the link above. This is how long I have got by now:

data0   timeStamp   OK`
data1   Uptime  OK
data2   Interval    OK (normally 300 s)
data3   Temp    OK
data4   Eday    OK
data5   Eac seems OK (Wh within last interval)
data6   Vac1    OK
data7   Vac2    OK
data8   Vac3    OK
data9   Iac1    OK
data10  Iac2    OK
data11  Iac3    OK
data12  freq1   OK
data13  freq2   OK
data14  freq3   OK
data15  ??  (always 0xFF7FFFFF)
data16  ??  (always 0xFF7FFFFF)
data17  Vdc OK
data18  ??  (always 0xFF7FFFFF)
data19  Etot    OK
data20  ??  (always a value around 0.002-0,0035 if interpreted as float. Can this be FI current?)
data21  ??  (always 0xFF7FFFFF)
data22  ??  (always -3,40E+38 if interpreted as float, probably same as 0xFF7FFFFF according to @fahimmac s data)
data23  ??  (same as data22)
data24  ??  (always 0x0000803F)
data25  ??  (always 0x0000803F)
data26  ??  (always 0x0000803F)
data27  ??  (always 0x04000000)
data28  ??  (for me always 0x45D7A051=1171759185, which is different from @fahimmac s data)
data29  ?   may be Power limit [%] (always 100 for me if interpreted as float)
data30  ??  (if interpreted as float, always a small positive or negative number in the range -0,007...+0,009. Also a candidate for FI current?)
data31  ??  (here I get interesting hex values, e.g.: BBB80000, BB300000, 39800000, BB400000, BBD80000, BAA00000, BC140000. All of them end with 4 zeros.)

I have also compared with the data shown in SolarEdge's monitoring portal, but the only similarity I could find was the value 100 for the Power Limit, and the hint for the FI current.

Jerrythafast commented 8 years ago

@d-tamm, the values are all little-endian. You are putting the raw 0x.... values in the wrong byte order for data24-27. Also got some gaps I can fill for you.

data15  EdayDC  (Same as Eday, but measured at DC side. I suspect SE is hiding this value because it would directly reveal inverter efficiency.)
data16  Edc     (Same as Eac, but measured at DC side. Hidden just like EdayDC.)
data18  Idc     (I suspect SE is hiding this value for the same reasons.)
data20  Ircd
data24  CosPhi1
data25  CosPhi2
data26  CosPhi3
data27  Mode    (1=OFF, 2=SLEEPING, 3=STARTING, 4=MPPT, 6=SHUTTING_DOWN, 8=STANDBY)
data28  GndFtR  (Ground Fault Resistance, a float value)
data30  IoutDC  (This is what SolarEdge calls it, the name is cryptic to me as well.)
d-tamm commented 8 years ago

This is great, thank you for the completions @Jerrythafast

jbuehl commented 8 years ago

I merged your changes into the project @d-tamm. If anyone has any further changes, please let me know.

d-tamm commented 8 years ago

I am now operating semonitor as server where the inverter is set to unencrypted mode. Everything works fine for some time. But then (I think it is always after sleep time at night, but I need to verify that) the connection is broken, no more data is received by the script, and the inverter no longer shows S_OK. Only restarting the script does not change anything. After restarting the inverter, it connects to the script again and sends the missing data. Does anyone else see such a behavior in a similar setup? The inverter is an SE5k.

jbuehl commented 8 years ago

It sounds like the inverter is losing connectivity to the server and can't reconnect. The inverter should display the error on the Server Communication Status display. See page 66 of http://www.solaredge.com/sites/default/files/se-inverter-installation-guide.pdf.

d-tamm commented 8 years ago

That was also my first thought. But the communication status shows eight ones, so everything should be working. I came back after holiday yesterday and the communication had been broken for about 10 days. So after restarting the inverter, it resumed uploading data until late evening when it went to sleep (mode 2). At that time, uploading had not finished completely. But this morning, I had to restart again to force it to resume uploading the remaining data, despite eight ones in the comm status.

jbuehl commented 8 years ago

Maybe it isn't a comm problem. If the 8th status bit is 1 it means that it has a tcp connection to a server. I don't know what it means to have a good status but no S_OK. There could be a message that it is expecting from the server that it isn't getting. Running with debug option -vvv would be helpful.

d-tamm commented 8 years ago

OK, thank you @jbuehl. I will try further in 2 weeks after my holidays.

pejonp commented 8 years ago

Hi, The inverter is an SE5k. SlaveMod ID:3 Protokoll:SE RS485 -> TCPIP (USR-TCP232-T24&K1). /dev/ttyS0 by socat. socat pty,link=/dev/ttyS0,nonblock,b115200,raw,echo=0 TCP4:RS485_IP:20108

the output of : python semonitor.py -d stdout -vvvv -m -s 7e1820ea -t 4 /dev/ttyS0 raspberrypi:/opt/solaredge/solaredge# python semonitor.py -d stdout -vvvv -m -s 7e1820ea -t 4 /dev/ttyS0 Jul 17 23:35:34 debugEnable: True Jul 17 23:35:34 debugFiles: True Jul 17 23:35:34 debugMsgs: True Jul 17 23:35:34 debugData: True Jul 17 23:35:34 debugRaw: True Jul 17 23:35:34 debugFileName: stdout Jul 17 23:35:34 haltOnException: False Jul 17 23:35:34 inFileName: /dev/ttyS0 Jul 17 23:35:34 inputType: 4 Jul 17 23:35:34 serialDevice: True Jul 17 23:35:34 baudRate: 115200 Jul 17 23:35:34 networkDevice: False Jul 17 23:35:34 networkSvcs: False Jul 17 23:35:34 following: True Jul 17 23:35:34 passiveMode: False Jul 17 23:35:34 commandAction: False Jul 17 23:35:34 masterMode: True Jul 17 23:35:34 slaveAddrs: 7e1820ea Jul 17 23:35:34 outFileName: stdout Jul 17 23:35:34 append: w Jul 17 23:35:34 opening /dev/ttyS0 Jul 17 23:35:34 starting read thread Jul 17 23:35:34 starting master thread Jul 17 23:35:34 dataLen: 0000 Jul 17 23:35:34 dataLenInv: ffff Jul 17 23:35:34 sequence: 017e Jul 17 23:35:34 source: fffffffe Jul 17 23:35:34 dest: 7e1820ea Jul 17 23:35:34 function: 0302 Jul 17 23:35:34 /dev/ttyS0 <-- message: 1 length: 22 Jul 17 23:35:34 data: 12 34 56 79 00 00 ff ff 7e 01 fe ff ff ff ea 20 Jul 17 23:35:34 data: 18 7e 02 03 3a 3e Jul 17 23:35:34 Jul 17 23:35:34 Jul 17 23:35:34 /dev/ttyS0 --> message: 1 length: 30 Jul 17 23:35:34 data: 12 34 56 79 08 00 f7 ff 15 01 ea 20 18 7e fe ff Jul 17 23:35:34 data: ff ff 32 03 00 00 64 00 33 33 73 3f 4e 82 Jul 17 23:35:34 dataLen: 0008 Jul 17 23:35:34 dataLenInv: fff7 Jul 17 23:35:34 sequence: 0115 Jul 17 23:35:34 source: 7e1820ea Jul 17 23:35:34 dest: fffffffe Jul 17 23:35:34 function: 0332 Jul 17 23:35:34 Unknown function 0x0332 Jul 17 23:35:34 Jul 17 23:35:34 /dev/ttyS0 --> message: 2 length: 30 Jul 17 23:35:34 data: 12 34 56 79 08 00 f7 ff 16 01 ea 20 18 7e fe ff Jul 17 23:35:34 data: ff ff 32 03 00 00 64 00 33 33 73 3f 0a c6 Jul 17 23:35:34 dataLen: 0008 Jul 17 23:35:34 dataLenInv: fff7 Jul 17 23:35:34 sequence: 0116 Jul 17 23:35:34 source: 7e1820ea Jul 17 23:35:34 dest: fffffffe Jul 17 23:35:34 function: 0332 Jul 17 23:35:34 Unknown function 0x0332 Jul 17 23:35:34 Jul 17 23:35:34 /dev/ttyS0 --> message: 3 length: 30 Jul 17 23:35:34 data: 12 34 56 79 08 00 f7 ff 17 01 ea 20 18 7e fe ff Jul 17 23:35:34 data: ff ff 32 03 00 00 64 00 33 33 73 3f 37 3a Jul 17 23:35:34 dataLen: 0008 Jul 17 23:35:34 dataLenInv: fff7 Jul 17 23:35:34 sequence: 0117 Jul 17 23:35:34 source: 7e1820ea Jul 17 23:35:34 dest: fffffffe Jul 17 23:35:34 function: 0332 Jul 17 23:35:34 Unknown function 0x0332 Jul 17 23:35:34 Jul 17 23:35:34 /dev/ttyS0 --> message: 4 length: 30 Jul 17 23:35:34 data: 12 34 56 79 08 00 f7 ff 18 01 ea 20 18 7e fe ff Jul 17 23:35:34 data: ff ff 32 03 00 00 64 00 33 33 73 3f 60 2f Jul 17 23:35:34 dataLen: 0008 Jul 17 23:35:34 dataLenInv: fff7 Jul 17 23:35:34 sequence: 0118 Jul 17 23:35:34 source: 7e1820ea Jul 17 23:35:34 dest: fffffffe Jul 17 23:35:34 function: 0332 Jul 17 23:35:34 Unknown function 0x0332 Jul 17 23:35:34 Jul 17 23:35:34 /dev/ttyS0 --> message: 5 length: 30 Jul 17 23:35:34 data: 12 34 56 79 08 00 f7 ff 19 01 ea 20 18 7e fe ff Jul 17 23:35:34 data: ff ff 32 03 00 00 64 00 33 33 73 3f 5d d3 Jul 17 23:35:34 dataLen: 0008 Jul 17 23:35:34 dataLenInv: fff7 Jul 17 23:35:34 sequence: 0119 Jul 17 23:35:34 source: 7e1820ea Jul 17 23:35:34 dest: fffffffe Jul 17 23:35:34 function: 0332 Jul 17 23:35:34 Unknown function 0x0332

the problem: Unknown function 0x0332

thank you. sorry for my english.

jbuehl commented 8 years ago

I don't know what function 0332 is supposed to do. Someone trying to use RS485 posted a similar question in issue #16 who was seeing function 0333. Both functions seem to be related to power reduction, according to their function names that you can see in seCommands.py, but I don't know what is supposed to be done in response. If you let it run for a while and you start getting performance data sent in 0500 messages, you can probably ignore the 0332 messages.

d-tamm commented 8 years ago

Back from holidays :) - back to the inverter not resuming after the night:

Well, the last data packet yesterday was:

Aug 02 21:39:15 <socket> --> message: 649 length: 288 
Aug 02 21:39:15 dataLen:    010a 
Aug 02 21:39:15 dataLenInv: fef5 
Aug 02 21:39:15 sequence:   0176 
Aug 02 21:39:15 source:     7e1a0823 
Aug 02 21:39:15 dest:       fffffffe 
Aug 02 21:39:15 function:   0500 
Aug 02 21:39:15 inverter:      7E1A0823 type: 0011 len: 0102 
Aug 02 21:39:15     Eac : 0.0 
Aug 02 21:39:15     Interval : 300 
Aug 02 21:39:15     ID : 7E1A0823 
Aug 02 21:39:15     Etot : 975773.0 
Aug 02 21:39:15     Mode : 4 
Aug 02 21:39:15     Time : 21:35:00 
Aug 02 21:39:15     Date : 2016-08-02 
Aug 02 21:39:15     Eday : 88.5288085938 
Aug 02 21:39:15 /home/pi/Solaranlage/output.json <-- message: 632 length: 203 
Aug 02 21:39:15   
Aug 02 21:39:15 {"inverters": {"7E1A0823": {"Eac": 0.0, "Interval": 300, "ID": "7E1A0823", "Etot": 975773.0, "Mode": 4, "Time": "21:35:00", "Date": "2016-08-02", "Eday": 88.52880859375}}, "events": {}, "optimizers": {}} 
Aug 02 21:39:15 dataLen:    0000 
Aug 02 21:39:15 dataLenInv: ffff 
Aug 02 21:39:15 sequence:   0176 
Aug 02 21:39:15 source:     fffffffe 
Aug 02 21:39:15 dest:       7e1a0823 
Aug 02 21:39:15 function:   0080 
Aug 02 21:39:15 <socket> <-- message: 648 length: 22 

After this, several "empty" 0500 messages followed:

Aug 02 21:39:35 <socket> --> message: 650 length: 22 
Aug 02 21:39:35 dataLen:    0000 
Aug 02 21:39:35 dataLenInv: ffff 
Aug 02 21:39:35 sequence:   0177 
Aug 02 21:39:35 source:     7e1a0823 
Aug 02 21:39:35 dest:       fffffffe 
Aug 02 21:39:35 function:   0500 
Aug 02 21:39:35 dataLen:    0000 
Aug 02 21:39:35 dataLenInv: ffff 
Aug 02 21:39:35 sequence:   0177 
Aug 02 21:39:35 source:     fffffffe 
Aug 02 21:39:35 dest:       7e1a0823 
Aug 02 21:39:35 function:   0080 
Aug 02 21:39:35 <socket> <-- message: 649 length: 22 

Then this one 2 times:

Aug 02 21:42:35 <socket> --> message: 654 length: 58 
Aug 02 21:42:35 dataLen:    0024 
Aug 02 21:42:35 dataLenInv: ffdb 
Aug 02 21:42:35 sequence:   0179 
Aug 02 21:42:35 source:     7e1a0823 
Aug 02 21:42:35 dest:       fffffffe 
Aug 02 21:42:35 function:   0500 
Aug 02 21:42:35 Unknown device 0x0800 
Aug 02 21:42:35 data:       00 08 23 08 9a 7e 1c 00 03 f7 a0 57 0e 00 00 00 
Aug 02 21:42:35 data:       72 0b 95 41 00 00 80 bf 00 00 80 bf 00 00 00 00 
Aug 02 21:42:35 data:       00 00 00 00 
Aug 02 21:42:35 /home/pi/Solaranlage/output.json <-- message: 633 length: 49 
Aug 02 21:42:35   
Aug 02 21:42:35 {"inverters": {}, "events": {}, "optimizers": {}} 
Aug 02 21:42:35 dataLen:    0000 
Aug 02 21:42:35 dataLenInv: ffff 
Aug 02 21:42:35 sequence:   0179 
Aug 02 21:42:35 source:     fffffffe 
Aug 02 21:42:35 dest:       7e1a0823 
Aug 02 21:42:35 function:   0080 
Aug 02 21:42:35 <socket> <-- message: 653 length: 22 

again followed by empty 0500 messages all night long. I sent the debug to a file with the -d option, and that file is truncated at 5:30 am:

Aug 03 05:30:15 <socket> --> message: 1121 length: 22 
Aug 03 05:30:15 dataLen:    0000 
Aug 03 05:30:15 dataLenInv: ffff 
Aug 03 05:30:15 sequence:   0262 
Aug 03 05

This is the state now at 5 pm, so nothing has been transferred during the day, or the script is hanging since 5:30 am. Maybe this truncation has to do with some sort of buffering, but 5:30 is about the time where it gets light again here right now. The inverter did not show S_OK this morning. Putting it together: I can only see 0500 functions and 0080 replies, but at the end of the day, there is some unknown device 0x0800. Nothing other unnormal in the debug log. Maybe I have to get rid of the truncation/buffering to see the cause? How? Any idea?

jbuehl commented 8 years ago

The empty 0500 messages during the night are normal. The unknown device 0800 may be a message that is sent when your inverter goes into night mode, similar to the 0300 message.

The truncating log may indicate that semonitor.py is hanging. I just made a change to seConf.py to flush the debug file after every write. You could also try running with -vvvv and -x options to maximize the output.

d-tamm commented 8 years ago

Thank you for the adjustment in code. Now I have been running semonitor over night again, with -vvvv and -x parameters. Following are the last debug lines from tonight:

Aug 06 23:11:16 <socket> --> message: 1076 length: 22 
Aug 06 23:11:16 data:       12 34 56 79 00 00 ff ff dd 05 23 08 1a 7e fe ff 
Aug 06 23:11:16 data:       ff ff 00 05 f6 17 
Aug 06 23:11:16 dataLen:    0000 
Aug 06 23:11:16 dataLenInv: ffff 
Aug 06 23:11:16 sequence:   05dd 
Aug 06 23:11:16 source:     7e1a0823 
Aug 06 23:11:16 dest:       fffffffe 
Aug 06 23:11:16 function:   0500 
Aug 06 23:11:16 dataLen:    0000 
Aug 06 23:11:16 dataLenInv: ffff 
Aug 06 23:11:16 sequence:   05dd 
Aug 06 23:11:16 source:     fffffffe 
Aug 06 23:11:16 dest:       7e1a0823 
Aug 06 23:11:16 function:   0080 
Aug 06 23:11:16 <socket> <-- message: 1075 length: 22 
Aug 06 23:11:16 data:       12 34 56 79 00 00 ff ff dd 05 fe ff ff ff 23 08 
Aug 06 23:11:16 data:       1a 7e 80 00 e6 78 
Aug 06 23:11:16   
Aug 06 23:13:16 Exception: timed out 
Aug 06 23:13:16   
Aug 06 23:13:16 <socket> --> message: 1077 length: 22 
Aug 06 23:13:16 data:       12 34 56 79 00 00 ff ff dd 05 23 08 1a 7e fe ff 
Aug 06 23:13:16 data:       ff ff 00 05 f6 17 
Aug 06 23:13:16 dataLen:    0000 
Aug 06 23:13:16 dataLenInv: ffff 
Aug 06 23:13:16 sequence:   05dd 
Aug 06 23:13:16 source:     7e1a0823 
Aug 06 23:13:16 dest:       fffffffe 
Aug 06 23:13:16 function:   0500 
Aug 06 23:13:16 dataLen:    0000 
Aug 06 23:13:16 dataLenInv: ffff 
Aug 06 23:13:16 sequence:   05dd 
Aug 06 23:13:16 source:     fffffffe 
Aug 06 23:13:16 dest:       7e1a0823 
Aug 06 23:13:16 function:   0080 
Aug 06 23:13:16 <socket> <-- message: 1076 length: 22 
Aug 06 23:13:16 data:       12 34 56 79 00 00 ff ff dd 05 fe ff ff ff 23 08 
Aug 06 23:13:16 data:       1a 7e 80 00 e6 78 
Aug 06 23:13:16   
Aug 06 23:13:16 Exception: 104 
Aug 06 23:13:16 closing <socket> 
Aug 06 23:13:16 waiting for connection

Before, a lot of empty 0500 messages, the last non-empty 0500 message being at 21:36 where the inverter reported mode 4. What does exception 104 mean? May the timeout have anything to do with the communication problems?

jbuehl commented 8 years ago

It looks like the inverter is closing down the connection and not reconnecting. Exception 104 is "connection reset by peer" which means the inverter has abruptly disconnected. It should try to reconnect, but it doesn't seem to do that. If it is showing a good status on the display maybe it doesn't realize that the connection is broken.

You could try capturing the network traffic with tcpdump and see if there is something else going on. You could run this

tcpdump -U -w capture.pcap host xx.xx.xx.xx

where xx.xx.xx.xx is the IP address of the inverter.

I'm beginning to think there may be a problem with the hardware or firmware of your inverter.

d-tamm commented 8 years ago

When the connection is interrupted, the S_OK (indicating contact to the monitoring portal) on the display disappears. However, the network page still shows eight ones. Also, earlier before beginning to experiment with your scripts and when the inverter still sent data to SolarEdge, I think there already has been a situation when I had to restart the inverter to make it reconnect - which may confirm your suspicion of a firmware problem. I will try tcpdump now and report on it after the next interruption.

jbuehl commented 8 years ago

Another thing you could try is to disconnect the network cable for at least 2 minutes and see if that duplicates the problem. The debug output from semonitor.py should look like what you posted above, with the "timed out" message occurring after 2 minutes. When you reconnect the cable, I would expect that the inverter should try to reconnect, starting with the DHCP and DNS messages.

d-tamm commented 8 years ago

OK, will try that, too.

d-tamm commented 8 years ago

Well here is some output from tcpdump: Last non-empty messages:

21:25:16.840356 IP Inverter.1270 > PINGUIN.22222: Flags [.], seq 374281:374605, ack 40833, win 2144, length 324
21:25:16.876055 IP PINGUIN.22222 > Inverter.1270: Flags [.], ack 374605, win 65532, length 0
21:25:16.908233 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 40833:40855, ack 374605, win 65532, length 22
21:25:17.108340 IP Inverter.1270 > PINGUIN.22222: Flags [.], ack 40855, win 2144, length 0
21:26:56.837532 ARP, Request who-has PINGUIN (b8:27:eb:ee:04:cd (oui Unknown)) tell Inverter, length 46
21:26:56.837677 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
21:26:56.838131 IP Inverter.1270 > PINGUIN.22222: Flags [.], seq 374605:374627, ack 40855, win 2144, length 22
21:26:56.838278 IP PINGUIN.22222 > Inverter.1270: Flags [.], ack 374627, win 65532, length 0
21:26:56.910495 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 40855:40877, ack 374627, win 65532, length 22
21:26:57.104359 IP Inverter.1270 > PINGUIN.22222: Flags [.], ack 40877, win 2144, length 0

Then, the following is repeating for a while (suppose these are the empty messages):

21:27:01.845993 ARP, Request who-has Inverter tell PINGUIN, length 28
21:27:01.846399 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
21:27:16.837448 IP Inverter.1270 > PINGUIN.22222: Flags [.], seq 374627:374649, ack 40877, win 2144, length 22
21:27:16.837597 IP PINGUIN.22222 > Inverter.1270: Flags [.], ack 374649, win 65532, length 0
21:27:16.850114 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 40877:40899, ack 374649, win 65532, length 22
21:27:17.103550 IP Inverter.1270 > PINGUIN.22222: Flags [.], ack 40899, win 2144, length 0
21:28:56.835077 ARP, Request who-has PINGUIN (b8:27:eb:ee:04:cd (oui Unknown)) tell Inverter, length 46
21:28:56.835175 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
21:28:56.835657 IP Inverter.1270 > PINGUIN.22222: Flags [.], seq 374649:374671, ack 40899, win 2144, length 22
21:28:56.848452 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 40899:40921, ack 374671, win 65532, length 22
21:28:57.099545 IP Inverter.1270 > PINGUIN.22222: Flags [.], ack 40921, win 2144, length 0

Then at 23:03, when the communication breaks according to debug.log, this:

23:01:01.736364 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:01:16.716473 IP Inverter.1270 > PINGUIN.22222: Flags [.], seq 376695:376717, ack 42945, win 2144, length 22
23:01:16.728801 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 42945:42967, ack 376717, win 65532, length 22
23:01:16.971548 IP Inverter.1270 > PINGUIN.22222: Flags [.], ack 42967, win 2144, length 0
23:02:17.050408 ARP, Request who-has Inverter tell 0.0.0.0, length 46
23:02:28.047944 ARP, Request who-has router tell Inverter, length 46
23:02:28.050031 ARP, Request who-has PINGUIN tell Inverter, length 46
23:02:28.050111 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
23:02:28.050553 IP Inverter.3045 > PINGUIN.22222: Flags [S], seq 19500, win 2144, options [mss 536], length 0
23:02:28.050692 IP PINGUIN.22222 > Inverter.3045: Flags [R.], seq 0, ack 19501, win 0, length 0
23:02:30.047981 IP Inverter.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:27:02:1a:08:23 (oui Unknown), length 250
23:02:33.055986 ARP, Request who-has Inverter tell PINGUIN, length 28
23:02:33.752184 ARP, Request who-has Inverter tell 0.0.0.0, length 46
23:02:34.055986 ARP, Request who-has Inverter tell PINGUIN, length 28
23:02:35.055985 ARP, Request who-has Inverter tell PINGUIN, length 28
23:02:35.056364 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:02:44.749121 IP Inverter.3048 > PINGUIN.22221: Flags [S], seq 36200, win 2144, options [mss 536], length 0
23:02:44.749277 IP PINGUIN.22221 > Inverter.3048: Flags [R.], seq 0, ack 36201, win 0, length 0
23:02:46.747297 IP Inverter.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:27:02:1a:08:23 (oui Unknown), length 250
23:02:50.451483 ARP, Request who-has Inverter tell 0.0.0.0, length 46
23:03:01.447952 IP Inverter.3051 > PINGUIN.http: Flags [S], seq 52900, win 2144, options [mss 536], length 0
23:03:01.448137 IP PINGUIN.http > Inverter.3051: Flags [S.], seq 2073727195, ack 52901, win 29200, options [mss 1460], length 0
23:03:01.448560 IP Inverter.3051 > PINGUIN.http: Flags [.], ack 1, win 2144, length 0
23:03:11.673075 IP Inverter.3051 > PINGUIN.http: Flags [.], seq 1:23, ack 1, win 2144, length 22
23:03:11.673308 IP PINGUIN.http > Inverter.3051: Flags [.], ack 23, win 29200, length 0
23:03:16.844287 IP PINGUIN.22222 > Inverter.1270: Flags [P.], seq 42967:42989, ack 376717, win 65532, length 22
23:03:16.844770 IP Inverter.1270 > PINGUIN.22222: Flags [R.], seq 376717, ack 42989, win 65532, length 0

So here is an irregularity, even if I am not familiar with this stuff, so I don't really know what it may significate. But the "tell 0.0.0.0" is strange. The following minutes, the tcpdump log continues like this:

23:03:41.673503 IP Inverter.3051 > PINGUIN.http: Flags [.], seq 23:45, ack 1, win 2144, length 22
23:03:41.673627 IP PINGUIN.http > Inverter.3051: Flags [.], ack 45, win 29200, length 0
23:04:41.672663 IP Inverter.3051 > PINGUIN.http: Flags [.], seq 45:67, ack 1, win 2144, length 22
23:04:41.672787 IP PINGUIN.http > Inverter.3051: Flags [.], ack 67, win 29200, length 0
23:04:46.675982 ARP, Request who-has Inverter tell PINGUIN, length 28
23:04:46.676365 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:05:41.671176 IP Inverter.3051 > PINGUIN.http: Flags [.], seq 67:89, ack 1, win 2144, length 22
23:05:41.671299 IP PINGUIN.http > Inverter.3051: Flags [.], ack 89, win 29200, length 0
23:05:46.675975 ARP, Request who-has Inverter tell PINGUIN, length 28
23:05:46.676334 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:06:41.669319 IP Inverter.3051 > PINGUIN.http: Flags [.], seq 89:111, ack 1, win 2144, length 22
23:06:41.669450 IP PINGUIN.http > Inverter.3051: Flags [.], ack 111, win 29200, length 0
23:06:46.675977 ARP, Request who-has Inverter tell PINGUIN, length 28
23:06:46.676350 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:07:18.635911 IP Inverter.3051 > PINGUIN.http: Flags [F.], seq 111, ack 1, win 2144, length 0
23:07:18.636279 IP PINGUIN.http > Inverter.3051: Flags [F.], seq 1, ack 112, win 29200, length 0
23:07:18.636843 IP Inverter.3051 > PINGUIN.http: Flags [.], ack 2, win 2144, length 0
23:09:07.631507 ARP, Request who-has router (e0:46:9a:78:52:6a (oui Unknown)) tell Inverter, length 46
23:09:07.633234 ARP, Request who-has PINGUIN (b8:27:eb:ee:04:cd (oui Unknown)) tell Inverter, length 46
23:09:07.633316 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
23:09:07.633795 IP Inverter.3053 > PINGUIN.http: Flags [S], seq 419100, win 2144, options [mss 536], length 0
23:09:07.634003 IP PINGUIN.http > Inverter.3053: Flags [S.], seq 3606228624, ack 419101, win 29200, options [mss 1460], length 0
23:09:07.634432 IP Inverter.3053 > PINGUIN.http: Flags [.], ack 1, win 2144, length 0
23:09:12.635977 ARP, Request who-has Inverter tell PINGUIN, length 28
23:09:12.636344 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:09:38.626018 IP PINGUIN.http > Inverter.3053: Flags [S.], seq 3606228624, ack 419101, win 29200, options [mss 1460], length 0
23:09:38.626490 IP Inverter.3053 > PINGUIN.http: Flags [.], ack 1, win 2144, length 0
23:09:43.635993 ARP, Request who-has Inverter tell PINGUIN, length 28
23:09:43.636361 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:11:41.658373 ARP, Request who-has PINGUIN (b8:27:eb:ee:04:cd (oui Unknown)) tell Inverter, length 46
23:11:41.658479 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
23:11:41.658996 IP Inverter.3053 > PINGUIN.http: Flags [.], seq 1:23, ack 1, win 2144, length 22
23:11:41.659169 IP PINGUIN.http > Inverter.3053: Flags [.], ack 23, win 29200, length 0
23:11:46.665979 ARP, Request who-has Inverter tell PINGUIN, length 28
23:11:46.666345 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:12:11.657796 IP Inverter.3053 > PINGUIN.http: Flags [.], seq 23:45, ack 1, win 2144, length 22
23:12:11.657924 IP PINGUIN.http > Inverter.3053: Flags [.], ack 45, win 29200, length 0
23:12:16.665971 ARP, Request who-has Inverter tell PINGUIN, length 28
23:12:16.666332 ARP, Reply Inverter is-at 00:27:02:1a:08:23 (oui Unknown), length 50
23:12:18.623529 IP Inverter.3053 > PINGUIN.http: Flags [F.], seq 45, ack 1, win 2144, length 0
23:12:18.623875 IP PINGUIN.http > Inverter.3053: Flags [F.], seq 1, ack 46, win 29200, length 0
23:12:18.624400 IP Inverter.3053 > PINGUIN.http: Flags [.], ack 2, win 2144, length 0
23:14:09.619082 ARP, Request who-has router (e0:46:9a:78:52:6a (oui Unknown)) tell Inverter, length 46
23:14:09.620751 ARP, Request who-has PINGUIN tell Inverter, length 46
23:14:09.620833 ARP, Reply PINGUIN is-at b8:27:eb:ee:04:cd (oui Unknown), length 28
23:14:09.621271 IP Inverter.3055 > PINGUIN.http: Flags [S], seq 721100, win 2144, options [mss 536], length 0
23:14:09.621450 IP PINGUIN.http > Inverter.3055: Flags [S.], seq 1766412640, ack 721101, win 29200, options [mss 1460], length 0

Hope someone understands more of this stuff than me!

jbuehl commented 8 years ago

I was hoping you would capture the data into a file with the -w option and post it here. The messages you posted above are just a summary and don't include all the data.

There is some interesting information, however. At the time the inverter seems to close the connection to port 22222, it starts to send messages to port 80 (http) on your server which isn't being responded to. It is also making DHCP requests that aren't being responded to by your server. Are you running semonitor.py with the -n option so that it functions as the DHCP/DNS server? There should have been some messages in the debug output that you posted earlier.

The ARP messages are lower level communications used by network interfaces and ethernet switches to know how to route traffic. It's not relevant to this issue.

d-tamm commented 8 years ago

Thank you for all your help! I am sorry for not having posted the binary data. Yes, I have actually recorded with the -w option, but did not know what to do with the binary output. I have now attached the pcap file (which in the meantime has grown further). capture.pcap.zip I am running the command semonitor.py -vvvv -x -d debug.log -t n so no, not with DHCP/DNS server. The last messages in debug.log are:

Aug 08 23:01:16 <socket> --> message: 2080 length: 22 
Aug 08 23:01:16 data:       12 34 56 79 00 00 ff ff 7c 07 23 08 1a 7e fe ff 
Aug 08 23:01:16 data:       ff ff 00 05 09 2e 
Aug 08 23:01:16 dataLen:    0000 
Aug 08 23:01:16 dataLenInv: ffff 
Aug 08 23:01:16 sequence:   077c 
Aug 08 23:01:16 source:     7e1a0823 
Aug 08 23:01:16 dest:       fffffffe 
Aug 08 23:01:16 function:   0500 
Aug 08 23:01:16 dataLen:    0000 
Aug 08 23:01:16 dataLenInv: ffff 
Aug 08 23:01:16 sequence:   077c 
Aug 08 23:01:16 source:     fffffffe 
Aug 08 23:01:16 dest:       7e1a0823 
Aug 08 23:01:16 function:   0080 
Aug 08 23:01:16 <socket> <-- message: 2079 length: 22 
Aug 08 23:01:16 data:       12 34 56 79 00 00 ff ff 7c 07 fe ff ff ff 23 08 
Aug 08 23:01:16 data:       1a 7e 80 00 19 41 
Aug 08 23:01:16   
Aug 08 23:03:16 Exception: timed out 
Aug 08 23:03:16   
Aug 08 23:03:16 <socket> --> message: 2081 length: 22 
Aug 08 23:03:16 data:       12 34 56 79 00 00 ff ff 7c 07 23 08 1a 7e fe ff 
Aug 08 23:03:16 data:       ff ff 00 05 09 2e 
Aug 08 23:03:16 dataLen:    0000 
Aug 08 23:03:16 dataLenInv: ffff 
Aug 08 23:03:16 sequence:   077c 
Aug 08 23:03:16 source:     7e1a0823 
Aug 08 23:03:16 dest:       fffffffe 
Aug 08 23:03:16 function:   0500 
Aug 08 23:03:16 dataLen:    0000 
Aug 08 23:03:16 dataLenInv: ffff 
Aug 08 23:03:16 sequence:   077c 
Aug 08 23:03:16 source:     fffffffe 
Aug 08 23:03:16 dest:       7e1a0823 
Aug 08 23:03:16 function:   0080 
Aug 08 23:03:16 <socket> <-- message: 2080 length: 22 
Aug 08 23:03:16 data:       12 34 56 79 00 00 ff ff 7c 07 fe ff ff ff 23 08 
Aug 08 23:03:16 data:       1a 7e 80 00 19 41 
Aug 08 23:03:16   
Aug 08 23:03:16 Exception: 104 
Aug 08 23:03:16 closing <socket> 
Aug 08 23:03:16 waiting for connection
jbuehl commented 8 years ago

Looking at the pcap file with wireshark I can see that there a couple of DHCP messages at the time the socket is closed, but they are DHCP release requests. I don't think they are relevant since the inverter continues to use the IP address 192.168.17.17. There is one attempt to connect to port 22221 on the 192.168.17.103 server followed by numerous attempts to connect to port 80.

This is behavior that I don't remember seeing in the past between an inverter and SolarEdge, so maybe it's a new feature that was added in a later firmware release. There's no way to know what the messages are expected to be unless someone captures the exchange between an inverter and the SolarEdge server to see what is happening.

d-tamm commented 8 years ago

I am now setting up my Pi to be a bridge between inverter and the SE portal to gather some data from that communication. @jbuehl , do you have a good starting point for setting up a RPi with a recent distribution for this bridging? My first tries don't work.

jbuehl commented 8 years ago

I did bridging in the past using the Arch linux distribution on the RPi. The configuration for the bridging interface is br0 in the deprecated folder of this project:

Description="Example Bridge connection"
Interface=br0
Connection=bridge
BindsToInterfaces=(eth0 eth1)
IP=static
Address=('192.168.1.56/24')
Gateway='192.168.1.1'
DNS=('192.168.1.1')

If you are using a different linux distribution such as Raspbian, the network configuration may be different and I don't know the details of how to do it. I think the basic concept should be the same, though. You define a bridge type interface that has the IP address, and it refers to the physical interfaces that don't have IP addresses.

d-tamm commented 8 years ago

OK, thank you. This looks quite different to the descriptions for Raspbian I found. I will look at this more.