Closed BoHammil closed 6 years ago
Good to hear this has been useful for you.
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
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!
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.
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?
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.
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.
i already fixed the -tn bug.
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 ?
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.
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 ?
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.
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
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.
Someone with one of these inverters will need to interpret what the values represent.
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.
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
@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.
@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
@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.
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,)
Here's an online conversion tool http://www.scadacore.com/field-applications/programming-calculators/online-hex-converter/
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...).
@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.
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.
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.
@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.)
This is great, thank you for the completions @Jerrythafast
I merged your changes into the project @d-tamm. If anyone has any further changes, please let me know.
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.
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.
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.
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.
OK, thank you @jbuehl. I will try further in 2 weeks after my holidays.
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.
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.
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?
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.
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?
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.
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.
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.
OK, will try that, too.
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!
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.
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
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.
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.
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.
OK, thank you. This looks quite different to the descriptions for Raspbian I found. I will look at this more.
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