Stopped working!

[martynwendon]

Hello again,

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

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

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

The pcap files are still getting created.

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

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

solaredge-20151212230003.zip

Thanks for your help!

Martyn

[jbuehl]

It has stopped working for me and at least one other person as well. I hope to be able to look at it this week.

[martynwendon]

Ah ok, glad it's not just me then!

It sounds like the protocol has changed, but I don't understand how as I'd have thought that would involve a firmware update on the Inverter?

Anything I can help with please let me know.

Martyn

[jdwhite]

I wrote a Perl version of seconvert2.py, using your script for the templates to decode the packet. Was also working last week, but when I ran yesterday's packet capture through it I also can no longer decode the packet dumps. I spent just a couple minutes looking at the packet capture with wireshark and I can still see the magic sequence "12345679" and I can also see the identifier for my inverter in the clear, so it doesn't appear that they're encrypting the payload.

I have full daily packet dumps from 11/29/15 onward and will try and take a closer look at them later tonight to see if I can see what's changed. For what it's worth, I have an SE10000.

[jbuehl]

That's what I am seeing also. The messages seem to be smaller but more numerous than before, so the overall amount of the captured data for a day looks about the same. I don't see any instances of my optimizer identifiers in the data. There are instances of the last 2 bytes of the optimizer identifiers, but that could just be coincidence.

[jdwhite]

I spent about an hour looking over packet dumps tonight. I can tell you that with certainty that the change occurred after end of day on 12/7/15 CST US, the last day of dumps that I can decode. The dumps from 12/8 onward are a different animal. I also noticed that while I could find references to the ID for my inverter they were only in what I call heartbeat packets that are sent periodically 24/7 and that had not been previously decoded. I found no trace of optimizer IDs in the new format packet dumps, which is discouraging. The initial packet that the inverter sends in the morning that contains the model identifier is also still readable.

Looking at the LCD panel on my inverter, I compared the DSP1/2 and CPU fields currently displayed with how they looked a couple weeks prior when it was installed. The values were unchanged. If new firmware was somehow fetched and installed I can't tell from the display panel. It's not unreasonable to think that SolarEdge could have embedded a command in one of the response packets to control the inverter and make it perform some sort of update.

It's unfortunate that SolarEdge's API doesn't contain the optimizer data in the first place. I had no problem getting API access as a customer but it's kind of useless.

[jbuehl]

I just uploaded a new program seconvert3.py. This replaces seconvert2.py and hopefully will help us to figure out the new format. At this time it only dumps hex data to the log and doesn't do any output to files. It parses the output of seconvert1.py and locates the records that start with the magic number 0x12345679. The raw data is printed out and then the data after the magic number is printed again formatted as 16 bit numbers.

Example: /usr/bin/python /root/solaredge/seconvert1.py -f -v -s 217.68.144.150 pcap/solaredge-20151215000002.pcap | python /root/solaredge/seconvert3.py -l -vvvv

I haven't spent much time with it yet, but here are a few things I have noticed:

• The record length, including the magic number, always seems to be a multiple of 6.
• A valid inverter ID is in bytes 10:13 and doesn't appear anywhere else in the record.
• Records with relatively short lengths such as 12, 66, 72, and 84 bytes are sent all the time. When the inverters start producing power, larger records with lengths such as 234 and 468 bytes are sometimes sent. These are no doubt the ones containing the useful data.

[martynwendon]

Did you make any further progress on this?

Kinda miss my nice graphs of individual optimizer performance :-(

I did manage to get confirmation from my installer (via solaredge support) that they can remotely update firmware, although as jdwhite mentioned the versions shown on the front LCD panel don't seem to have changed.

My installer also mentioned that when he logs into the solaredge portal with his installer credentials he can "remotely control" my Inverter!

Not sure I like the fact that solaredge (or my installer) can remotely access the system whenever they want, I don't "rent" this equipment I bought it outright and had it installed, so as far as I'm concerned I own it and don't want anybody to access it unless I say so!

[carlo-strata]

Hi Everyone!

... but do you know the SolareEdge inverter protocol (RS-485, RS-232, wired and wireless ethernet, ...) is already opened (free, open source, royalty free, free as in freedom)?

SolarEdge is a Member of SunSpec Alliance!!! Here are all contributing members: http://sunspec.org/portfolio-type/contributing-members/

You can download the specs here ("/All SunSpec specifications are free to download and use/", you have olny to register to the site, it's free too, obviously): http://sunspec.org/download-sunspec-specifications/

Here about the SunSpec Alliance: http://sunspec.org/sunspec-about/

So why you do not integrate your work in an Arduino/Genuino - for example - project based on official Alliance Specifications and to to the reverse engineered ones???!!!

Have all a sunny day!

Carlo

Il 22/01/2016 10:53, martynwendon ha scritto:

Did you make any further progress on this?

Kinda miss my nice graphs of individual optimizer performance :-(

I did manage to get confirmation from my installer (via solaredge support) that they /can/ remotely update firmware, although as jdwhite mentioned the versions shown on the front LCD panel don't seem to have changed.

My installer also mentioned that when he logs into the solaredge portal with his installer credentials he can "remotely control" my Inverter!

Not sure I like the fact that solaredge (or my installer) can remotely access the system whenever they want, I don't "rent" this equipment I bought it outright and had it installed, so as far as I'm concerned I own it and don't want anybody to access it unless I say so!

— Reply to this email directly or view it on GitHub https://github.com/jbuehl/solaredge/issues/8#issuecomment-173864768.

[carlo-strata]

I fix my last phrase: "So why do you not integrate your work in an Arduino/Genuino project - for example - based on official Alliance Specifications and not to the reverse engineered ones???!!!"

Sorry for the fix.

Carlo

Il 22/01/2016 11:41, Carlo Strata, Google ha scritto:

Hi Everyone!

... but do you know the SolareEdge inverter protocol (RS-485, RS-232, wired and wireless ethernet, ...) is already opened (free, open source, royalty free, free as in freedom)?

SolarEdge is a Member of SunSpec Alliance!!! Here are all contributing members: http://sunspec.org/portfolio-type/contributing-members/

You can download the specs here ("/All SunSpec specifications are free to download and use/", you have olny to register to the site, it's free too, obviously): http://sunspec.org/download-sunspec-specifications/

Here about the SunSpec Alliance: http://sunspec.org/sunspec-about/

So why you do not integrate your work in an Arduino/Genuino - for example - project based on official Alliance Specifications and to to the reverse engineered ones???!!!

Have all a sunny day!

Carlo

Il 22/01/2016 10:53, martynwendon ha scritto:

Did you make any further progress on this?

Kinda miss my nice graphs of individual optimizer performance :-(

I did manage to get confirmation from my installer (via solaredge support) that they /can/ remotely update firmware, although as jdwhite mentioned the versions shown on the front LCD panel don't seem to have changed.

My installer also mentioned that when he logs into the solaredge portal with his installer credentials he can "remotely control" my Inverter!

Not sure I like the fact that solaredge (or my installer) can remotely access the system whenever they want, I don't "rent" this equipment I bought it outright and had it installed, so as far as I'm concerned I own it and don't want anybody to access it unless I say so!

— Reply to this email directly or view it on GitHub https://github.com/jbuehl/solaredge/issues/8#issuecomment-173864768.

[martynwendon]

Hi Carlo,

As far as we're aware the solaredge implementation of the SunSpec protocol is only available via the RS-485 connection and doesn't include data from the Optimisers - the "module level data" that is referred to in the readme at https://github.com/jbuehl/solaredge

If the module level data was available "officially" then there would be no need for this project :-)

[jbuehl]

I have not had any luck decoding this new format. As martynwendon said, the only reason I created this project was because the optimizer data wasn't available in the Sunspec data, and because that data isn't available over ethernet.

[ergouser]

I'm thinking of getting a SolarEdge for a new install. I'm not sure if the installer routinely installs Ethernet for monitoring, but I think I'll at least try to get the RS485 link. Individual panel performance might be interesting (especially for long-term diagnostics).

Two quick thoughts.

1) Especially if anyone can "remotely control" the inverter, the data to the network should be encrypted. It's possible that they have just started using SSH encryption, but if some data is still in the clear in all the packets, this is unlikely. If it's SSH you could probably use the Pi to perform a man-in-the-middle attack on the protocol.

2) Has anyone tried reading registers beyond 40109 on the RS485 interface to see if they respond and if anything interesting might be there. Is port 502 open on Ethernet? That is, does the module support Modbus/TCP?

[hube3443]

If it is encrypted traffic, it should be easily identifiable with Wireshark. I have just started implementing this code when the change was made and have not had an opportunity to do any packet tracing as of yet. Will take a look hopefully this weekend.

[jbuehl]

I have looked at it with Wireshark and it doesn't appear to be encrypted at the transport layer, which is how ssh does it. It looks like only part of the payload may be encrypted. I agree that if inverters can be remotely controlled, I want the communication to be secure. I just wish that SolarEdge would make the optimizer data accessible through their API.

[ergouser]

There should still be some sort of key negotiation. If that's not there, then both the server and the inverter hold a private key which is a fairly horrible security hole. On the other hand, it's likely that if you can fake the server protocol the inverter would still respond to the unencrypted commands which is even worse - unless there was an update that didn't change the version for Jason White.

[jbuehl]

This sort of uncertainty is why I am considering disconnecting my inverters from the internet and using the RS485 interface for monitoring. I would want to make it accessible remotely using my own cloud server. If I do that I will publish whatever I develop on github. If anyone is interested, your participation is welcome.

[ergouser]

Have you tried reading any of the Mobdus registers outside the defined range? It's possible that they put the optimizer data into registers even if no one documented it. You could read them one at a time and see if any come back as valid/with a value. I might start at 40001 and go to 41000 - the system shouldn't have a problem with invalid registers.

Do you have the (old?) Ethernet protocol well enough documented to fake the server-side? If the unencrypted protocol still works and you can poke the inverter sufficiently to start sending you data you could just disconnect from the Internet and grab the optimizer values. First trick would be to reconfigure DNS so that the server name resolves to one of your local system and then listen on the right port and see what happens. I would expect that the inverter reconnects after a disconnect or restart. It's possible that the host starts that communication, but that would be a little clunky.

If you can figure out the probably-encrypted-protocol you might consider the same disconnected approach, which removes any uncertainty associated with future updates or security.

[ergouser]

If the diagram on page 8 of this brochure is to be believe, the optimizer data should be available (somehow) on RS485: http://www.solaredge.com/files/pdfs/se_application_zigbee_gateway.pdf

[jbuehl]

It just occurred to me that the optimizer data is definitely accessible via RS485. I have 2 inverters and only one is connected to ethernet. It is connected to the other inverter with RS485 and it reports the data including optimizer data for both of them. I can try monitoring that interface and see what is being sent.

I had also thought of spoofing the server as you suggested. I haven't reverse engineered the server side, however I have 2-1/2 years of captured network data to work with.

[TeraHz]

Just got my solaredge inverter installed, so count me in on figuring out the protocol. I think Domoticz also implements a MITM capturing of SolarEdge data and, as far as I can tell from their forums, their implementation still works.

I will have my rpi2 in the next couple of days and will start contributing.

[ergouser]

Domoticz (which BTW looks quite interesting, as does OpenHAB) talks mostly about using the SolarEdge API - https://www.domoticz.com/wiki/SolarEdge - although it does suggest that you can change the forwarding of the converter. The API doesn't seem to be secure. Sniffing RS485 lines would seem to be the best approach. The default configuration per our installer is Zigbee - not sure how I feel about that, although I do have a smart meter that (I'm pretty sure) is Zigbee enabled.

[martynwendon]

Nice to see some fresh eyes on this, hopefully we will get somewhere after all!

Just to clarify a couple of things -

The solaredge API is limited in the data it can provide (no optimisers for example) and is also limited to a quota on the amount of times you can query it per day. The API isn't secure, it's a simple HTTP / JSON / XML.

Domoticz implements a similar approach to this project by becoming the "gateway" that you point your solaredge inverter at, which then forwards on the packets to the solaredge server. Domoticz only implemented enough of the protocol to get the inverter totals if I remember correctly and also stopped working early December too. They have reverted to the API approach instead.

The above mentioned API is entirely different to the what the solaredge inverter transmits to itself, this wasn't secure prior to early December, but isn't an open / known protocol but jbuehl did a cracking job in reverse engineering just enough of it to be able to get at all the lovely raw data for both inverters and optimisers :-)

Around the first week of December there was a firmware update that completely changed the protocol being used and so far we've not had any luck in identifying it.

I spent a fair bit of time at the weekend trying to spot any patterns (beyond what jbuehl had already worked out) but had no success either. IF encryption is being used then it's not for ALL of the transmission as some is still sent plain text (inverter serial for example).

In half a day or so of examining transmission I couldn't spot any patterns at all, which is strange as even if encrypted you would still expect to see some repetition of data (for example optimiser identifiers, date stamps, etc) or some other repeating pattern. But as far as I could tell every message was completely different, there didn't seem to be any similar byte patterns.

My suspicion would be that the data is being randomised in some form or is being encoded on a per transmission basis with a seed value that is also included in the transmission. Or some other method of making every transmission look different "over the wire" but still be decoded at the other end.

The RS485 approach could be interesting, we were under the impression that this didn't contain the optimiser data (as per the Sunspec implementation) but it would be a welcome surprise if it did!

I also noticed that the solaredge configuration software (Windows PC) that connects over RS232 has the ability to monitor the optimiser / inverter in realtime too, so that's possibly another angle to approach from.

[jdwhite]

http://www.domoticz.com/forum/viewtopic.php?f=17&t=1839&start=100

Cording to this thread it stop working around the same time that I and others noticed it.

On Jan 28, 2016, at 3:09 PM, Georgi Todorov notifications@github.com wrote:

Just got my solaredge inverter installed, so count me in on figuring out the protocol. I think Domoticz also implements a MITM capturing of SolarEdge data and, as far as I can tell from their forums, their implementation still works.

I will have my rpi2 in the next couple of days and will start contributing.

— Reply to this email directly or view it on GitHub.

[ergouser]

It seems somewhat strange to me that part of a packet would be encrypted. If you're going to encrypt, encrypt the whole stream and move on. Did the packet size decrease? Is it possible that it's just compression rather than encryption?

[rippiedoos]

Has anyone examined the packets to be actual modbus traffic? I could imagine that they first encapsulated modbus over tcp and now are actually using modbus rtu or modbus TCP/IP. With the magic header being the master id and the serial number of the inverter being the slave? Just a thought.

Op 29 jan. 2016 om 01:22 heeft ergouser notifications@github.com het volgende geschreven:

It seems somewhat strange to me that part of a packet would be encrypted. If you're going to encrypt, encrypt the whole stream and move on. Did the packet size decrease? Is it possible that it's just compression rather than encryption?

— Reply to this email directly or view it on GitHub.

[TeraHz]

I got my RPi online and saving traffic. However, the nightly traffic is not very interesting - I think only heartbeats. Hopefully today I will have some more interesting data.

@ergouser I'm using OpenHAB at home. My goal is to feed the data from the optimizers to my OpenHAB DB.

@jdwhite It does appear that Domoticz stopped working, you're correct. For some reason I missed that thread...

@rippiedoos Straight Modbus/TCP interpretation doesn't work on the data (according to Wireshark).

[jbuehl]

I connected to the RS485 interface between my 2 inverters and I am seeing data that is mostly readable by seconvert2.py being reported from the slave inverter, including optimizer data. I think it should be possible to put both inverters in slave mode and have a local server play the role of the master and request data from the inverters. Of course this would eliminate the ethernet connection to the SolarEdge monitoring server, but that seems like an improvement at this point.

To do this I connected the RS485 bus to a RaspberryPi using a serial USB dongle. I made a change to seconvert2.py to allow the serial port to be specified as the input.

# python solaredge/seconvert2.py -l -vv -o opt.dat -i inv.dat /dev/ttyUSB0 
debug: True 
debugFiles: True 
debugData: False 
headers: False 
delim: , 
dataBase:  
dbHostName:  
userName:  
password:  
append: w 
inFileName: /dev/ttyUSB0 
invFileName: inv.dat 
optFileName: opt.dat 
jsonFileName:  
logSysout: True 
writing inv.dat 
writing opt.dat 
reading /dev/ttyUSB0 
writing 2016-01-29,08:47:44,100F746C,7F104A16,4779,42.000000,27.625000,1.175000,18.250000,18.000000 
writing 2016-01-29,08:48:17,100E3326,7F104A16,4823,37.375000,7.375000,0.418750,12.000000,18.000000 
writing 2016-01-29,08:48:57,400E3520,7F104A16,4865,36.750000,7.875000,0.487500,13.750000,18.000000 
writing 2016-01-29,08:49:14,100F7401,7F104A16,4873,34.875000,55.875000,3.418750,61.750000,24.000000 
writing 2016-01-29,08:49:23,100F721E,7F104A16,4890,38.000000,6.250000,0.393750,13.750000,16.000000 
writing 2016-01-29,08:49:47,100F74A0,7F104A16,4911,36.500004,8.750000,0.531250,11.500000,16.000000 
writing 2016-01-29,08:49:56,7F104A16,7201,300,14.690000,410.496033,48.545162,239.699997,3.100300,60.009998,343.199982,9967339.000000,5000.000000,723.000000 
writing 2016-01-29,08:50:08,100E32F9,7F104A16,4928,36.750000,6.875000,0.468750,12.500000,16.000000 
writing 2016-01-29,08:50:29,1016AB88,7F104A16,4955,40.125000,7.375000,0.493750,38.000000,26.000000 
writing 2016-01-29,08:47:44,100F74DB,7F104A16,4779,42.000000,27.625000,1.175000,18.250000,18.000000 
writing 2016-01-29,08:48:17,100E3326,7F104A16,4823,37.250000,7.375000,0.211328,12.000000,18.000000 
writing 2016-01-29,08:48:57,100E3520,7F104A16,4865,36.750000,7.875000,0.487500,13.750000,18.000000 
writing 2016-01-29,08:49:14,100F7401,7F104A16,4873,34.875000,55.875000,3.418750,61.750000,24.000000 
writing 2016-01-29,08:49:23,100F721E,7F104A16,4890,38.000000,6.250000,0.393750,13.750000,16.000000 
writing 2016-01-29,08:49:47,100F7480,7F104A16,4911,36.500000,8.750000,0.531250,28.000000,16.000000 
writing 2016-01-29,08:49:56,7F032816,7201,300,14.690000,410.496033,48.545162,239.699997,3.100300,60.009998,343.199982,17575382.000000,5000.000000,723.000000 
writing 2016-01-29,04:51:12,100E32F9,7F104A16,4928,36.750000,6.875000,0.468750,12.500000,16.000000 
writing 2016-01-29,08:50:29,1016AB88,7F104A16,4955,40.125000,7.375000,0.493750,56.000000,26.000000 
writing 2016-01-29,08:47:44,100F74DB,7F104A16,4779,42.000000,27.625000,1.175000,18.250000,18.000000 
solaredge unknown seType 1309 seId 80000000 seDeviceLen 16907 
writing 2016-01-29,08:47:44,100F74DB,7F104A16,4779,0.000000,27.625006,1.175000,18.250000,18.000000 
solaredge unknown seType 0100 seId 100E3326 seDeviceLen 36 
writing 2016-01-29,08:48:57,100E3520,7F104A16,19457,36.750000,7.875000,0.487500,13.750000,18.000000 
writing 2016-01-29,08:49:14,100F7401,7F104A16,4873,34.875000,55.875000,3.418750,61.750000,24.000000 
writing 2016-01-29,08:49:23,100F721E,7F104A16,4890,38.000000,6.250000,0.393750,13.750000,16.000000 

[ergouser]

Is the communication Modbus or is there a proprietary protocol involved? Do you have the raw data for the whole converstation?

[jbuehl]

SolarEdge proprietary. It is whatever they were using to report data to the monitoring portal until December when they changed it.

Here is a hex dump of some data.

00000000  12 34 56 79 00 00 ff ff  0c c9 20 49 10 7f 16 4a  |.4Vy...... I...J|
00000010  10 7f 02 03 f8 73 ff 12  34 56 79 00 00 ff ff 6e  |.....s..4Vy....n|
00000020  73 20 49 10 7f 16 4a 10  7f 47 03 40 c2 12 34 56  |s I...J..G.@..4V|
00000030  79 00 00 ff ff 0d c9 20  49 10 7f 16 4a 10 7f 02  |y...... I...J...|
00000040  03 e8 93 03 12 34 56 79  00 00 ff ff 0e c9 20 49  |.....4Vy...... I|
00000050  10 7f 16 4a 10 7f 02 03  75 16 80 12 34 56 79 00  |...J....u...4Vy.|
00000060  00 ff ff 0e c9 16 4a 10  7f 20 49 40 7f 9a 03 82  |......J.. I@....|
00000070  e0 12 34 56 79 00 00 ff  ff 6f 73 20 49 10 7f 16  |..4Vy....os I...|
00000080  4a 10 7f 47 03 50 3e 80  12 34 56 79 00 00 ff ff  |J..G.P>..4Vy....|
00000090  0f c9 20 49 10 7f 16 4a  10 7f 02 03 c0 53 12 34  |.. I...J.....S.4|
000000a0  56 79 00 00 ff ff 10 c9  20 49 10 7f 16 4a 10 7f  |Vy...... I...J..|
000000b0  02 03 54 3e 80 12 34 56  79 00 00 ff ff 70 73 20  |..T>..4Vy....ps |
000000c0  49 10 7f 16 4a 10 7f 47  03 c0 53 12 34 56 79 00  |I...J..G..S.4Vy.|
000000d0  00 ff ff 11 c9 20 49 10  7f 16 4a 10 7f 02 03 44  |..... I...J....D|
000000e0  c2 12 34 56 79 00 00 ff  ff 12 c9 20 49 10 7f 16  |..4Vy...... I...|
000000f0  4a 10 7f 02 03 78 86 12  34 56 79 00 00 ff ff 71  |J....x..4Vy....q|
00000100  73 20 49 10 7f 16 4a 10  7f 47 03 c0 b3 80 12 34  |s I...J..G.....4|
00000110  56 79 00 00 ff ff 13 c9  20 49 40 7f 16 4a 10 7f  |Vy...... I@..J..|
00000120  02 03 68 7a c0 12 34 56  79 00 00 ff ff 14 c9 20  |..hz..4Vy...... |
00000130  49 10 7f 16 4a 10 7f 02  03 00 0e 80 12 34 56 79  |I...J........4Vy|
00000140  00 00 ff ff 14 c9 16 4a  10 7f 20 49 10 7f 9a 03  |.......J.. I....|
00000150  f7 f8 12 34 56 79 00 00  ff ff 15 c9 20 49 10 7f  |...4Vy...... I..|
00000160  16 4a 10 7f 02 03 10 f2  12 34 56 79 00 00 ff ff  |.J.......4Vy....|
00000170  72 73 20 49 10 7f 16 4a  10 7f 47 0c ec 93 03 12  |rs I...J..G.....|
00000180  34 56 79 00 00 ff ff 16  c9 20 49 10 7f 16 4a 40  |4Vy...... I...J@|
00000190  7f 02 03 0b b6 12 34 56  79 00 00 ff ff 17 c9 20  |......4Vy...... |
000001a0  49 10 7f 16 4a 10 7f 02  03 3c 4a 80 12 34 56 79  |I...J....<J..4Vy|
000001b0  00 00 ff ff 73 73 20 49  10 7f 16 4a 10 7f 47 03  |....ss I...J..G.|
000001c0  7f ae 12 34 56 79 00 00  ff ff 18 c9 20 49 10 7f  |...4Vy...... I..|
000001d0  16 4a 10 7f 02 03 fc 5e  c0 12 34 56 79 00 00 ff  |.J.....^..4Vy...|
000001e0  ff 19 c9 20 49 10 7f 16  4a 40 7f 02 03 ec a2 12  |... I...J@......|
000001f0  34 56 79 00 00 ff ff 74  73 20 49 10 7f 16 4a 10  |4Vy....ts I...J.|
00000200  7f 47 03 94 d3 12 34 56  79 00 00 ff ff 1a c9 20  |.G....4Vy...... |
00000210  49 10 7f 16 4a 10 7f 02  03 d0 e6 12 34 56 79 00  |I...J.......4Vy.|
00000220  00 ff ff 1b c9 20 49 10  7f 16 4a 10 7f 02 03 c0  |..... I...J.....|
00000230  1a 80 12 34 56 79 00 00  ff ff 75 73 20 49 10 7f  |...4Vy....us I..|
00000240  16 4a 10 7f 47 03 84 33  02 12 34 56 79 00 00 fc  |.J..G..3..4Vy...|
00000250  ff 1c c9 20 49 10 7f 16  28 83 7f 02 03 a8 6e c0  |... I...(.....n.|
00000260  12 34 56 79 00 00 ff ff  1d c9 20 49 10 7f 16 4a  |.4Vy...... I...J|
00000270  10 7f 02 03 b8 92 12 34  56 79 00 00 ff ff 76 73  |.......4Vy....vs|
00000280  20 49 10 7f 16 4a 10 7f  47 03 6e 62 c0 12 34 56  | I...J..G.nb..4V|
00000290  79 00 00 ff ff 1e c9 20  49 10 7f 16 4a 10 7f 02  |y...... I...J...|
000002a0  03 84 d6 12 34 56 79 00  00 ff ff 1f c9 20 49 10  |....4Vy...... I.|
000002b0  7f 16 4a 10 7f 02 03 2b  a2 06 12 34 56 79 0e 00  |..J....+...4Vy..|
000002c0  f1 ff 73 73 16 94 10 7f  20 49 10 7f 9f 03 00 00  |..ss.... I......|
000002d0  01 00 01 00 01 00 58 01  01 3f ff ff 7a f2 12 34  |......X..?..z..4|
000002e0  56 79 0e 00 f1 ff 76 73  16 4a 10 7f 20 49 10 7f  |Vy....vs.J.. I..|
000002f0  9f 03 00 00 01 00 01 00  01 00 58 01 04 3f ff ff  |..........X..?..|
00000300  7b 2e 12 34 56 79 00 00  ff ff 1f c9 16 4a 10 7f  |{..4Vy.......J..|
00000310  20 49 10 7f 9a 03 d2 dc  12 34 56 79 00 00 ff ff  | I.......4Vy....|
00000320  20 c9 20 49 10 7f 16 4a  10 7f 02 03 a8 3e 80 12  | . I...J.....>..|
00000330  34 56 79 00 00 ff ff 77  73 20 49 10 7f 16 4a 10  |4Vy....ws I...J.|
00000340  7f 47 03 a8 f3 12 34 56  79 00 00 ff ff 21 c9 20  |.G....4Vy....!. |
00000350  49 10 7f 16 4a 10 7f 02  03 b8 c2 12 34 56 79 00  |I...J.......4Vy.|
00000360  00 ff ff 22 c9 20 49 10  7f 16 4a 10 7f 02 03 84  |...". I...J.....|
00000370  86 12 34 56 79 00 00 ff  ff 78 73 20 49 10 7f 16  |..4Vy....xs I...|
00000380  4a 10 7f 47 03 68 53 12  34 56 79 00 00 ff ff 23  |J..G.hS.4Vy....#|
00000390  c9 20 49 10 7f 16 4a 10  7f 02 03 94 7a c0 12 34  |. I...J.....z..4|
000003a0  56 79 00 00 ff ff 24 c9  20 49 10 7f 16 4a 10 7f  |Vy....$. I...J..|
000003b0  02 03 fc 0e 80 12 34 56  79 00 00 ff ff 79 73 20  |......4Vy....ys |
000003c0  49 10 7f 16 4a 10 7f 47  03 78 b3 03 12 34 56 79  |I...J..G.x...4Vy|
000003d0  00 00 ff ff 25 c9 20 49  10 7f 16 4a 10 7f 02 03  |....%. I...J....|
000003e0  ec f2 12 34 56 79 00 00  ff ff 26 c9 20 49 10 7f  |...4Vy....&. I..|
000003f0  16 4a 10 7f 02 03 e8 b6  12 34 56 79 00 00 ff ff  |.J.......4Vy....|

[ergouser]

Can you post a sample PCAP from when the protocol was working?

[jbuehl]

martynwendon posted this one a few months ago https://dl.dropboxusercontent.com/u/52590317/solaredge-20151014000004.pcap

[ergouser]

So, as your system exists, you can snoop the data going from one inverter to the "main"/Ethernet connected inverter - half the data?

The data may be proprietary, but I doubt that they invented the protocol. You've already done a great job of reverse engineering the data, but to simulate the server it might be handy to have more info. I'd guess (wild guess) that it's one of the smart grid protocols. It might be DNP3 - not a protocol with which I'm intimately familiar.

I get the impression that the gateway supports RS485 as well as Ethernet, Zigbee, etc.? Is this correct, so you could run RS485 all the way to the gateway box and so snoop all the data?

[jbuehl]

ergouser, I just made the RS485 connection this morning as a test. Yes, it only shows me half the data, but it demonstrates that it is still possible to get at the optimizer data, which I didn't know yesterday. I am thinking that all that should be necessary to emulate the master inverter is to send the message that queries the slave inverter for data, which should be easy to find. I haven't had a chance to look for it yet.

I just looked at DNP3 and it is not that. DNP3 is a level 2 protocol like ethernet. The SolarEdge messages are application layer.

[ergouser]

DNP3 is a lot more than transport. Those models always become a mess when you start running them over an already reliable protocol (like TCP/IP) but they also have to support unreliable networks (like RS485). Amongst other things, apparently, DNP3 supports encryption using pre-shared keys and PKI.

That said, I'm not convinced. The 12345679 bothers me. If it was reversed in the response then I'd accept it as an address, but it's not - four seemingly useless bytes. Wireshark should also pick up DNP although packing any protocol inside a different structure would be enough to break that.

It looks too complex for a home-grown protocol. It's not a simple request/response, like Modbus, so I would expect some sort of event definition/configuration when the protocol starts ("send me these values"). There are also a bunch of different packet types and sizes - including the empty, except for overhead 22 byte packets. Any idea what the last 16 byte represent?

[martynwendon]

Hey jbuehl,

I did a bit more digging around and found that there's actually two protocols on the RS485 side, which I hadn't realised before.

These can be selected in the menu on the Inverter, there's the Sunspec one (which according to the docs on the Solaredge site is for "connecting to third party data loggers" and as we know only implements a subset of data), then there's a "Solaredge" one which as you've found looks like it is still using the older protocol. The latter is the default for inter-Inverter communication in a master -> slave(s) setup like you have.

By default all Inverters are configured as slaves on the RS485 side, you only need to make one a master if you want one to act as a gateway for onward ethernet connection to the Solaredge portal.

So as you mentioned, it sounds like all you'd need to do is change your master back to a slave, emulate the master commands yourself and you should be good to go!

I guess at that point your upload to Solaredge portal will only then include partial data from whichever Inverter is still connected to your network by ethernet. So you could probably directly connect your slave Inverter(s) to your network too if you wanted, although this probably doesn't matter if you intend to disconnect from the Solaredge portal completely. I am in two minds about that myself at the moment.

It sounds to me now like the RS485 side may well be a cleaner solution in the end.

[jbuehl]

You have described exactly what I am thinking of doing, martynwendon. I was thinking of configuring both inverters as RS485 slaves controlled by my RPi as a master, and having neither connected to ethernet, but I suppose it may not preclude also connecting both of them to the network and letting them both communicate to SolarEdge. I am unsure if I want to continue doing that as well.

[ergouser]

What configurations do people have?

Our installer is talking of Zigbee, which I assume means the "SolarEdge Home Gateway Kit". It seems that if I get the "SolarEdge Control and Communication Gateway" instead, then I can get RS485 to the gateway (so snoopable) and still maintain the option of communications to SolarEdge.

[TeraHz]

I've been looking at the web interface, and it seems like if your installer gives you access to the Charts tab, it is fairly straight forward to get the data in CSV using simple get requests. EG:

https://monitoring.solaredge.com/solaredge-web/p/charts/204282/chartExport?st=&et=&fid=204282&timeUnit=0&pn0=&id0=<ID of module/optimizer>

Where start and end time are just epoc times, eg 1454025600000 data field name is one of: Energy Current Voltage Power PowerBox%20Voltage

and ID of module is the unique ID of the optimizer/module entry in the charts.

Doing the above call with the right session cookie and ID gives you a nice CSV, and it seems that if you do a single day request, some of the data points are as little as 2 minutes apart.

It also seems like you can request multiple values at the same time using pn0,id0,pn1,id1

Just sharing it here that it might be another way to get the data daily. I'll probably try to write a web client that logs in to get the session headers and then grabs the CSV data for all modules.

here is a sample output from a curl command:

Time,OP1.1.3 V (V),P1.1.3 V (V) 01/29/2016 07:41,"30","26.875" 01/29/2016 07:51,"28.5","32.5" 01/29/2016 07:55,"30.5","29.875" 01/29/2016 08:02,"30.125","31.375" 01/29/2016 08:06,"30.5","31.75" 01/29/2016 08:10,"28.5","31.375" 01/29/2016 08:14,"27.75","33.125" 01/29/2016 08:18,"25.625","32.125" 01/29/2016 08:25,"31.125","36" ...

[jbuehl]

I know that you can do that to get inverter level data, but have you been able to get individual optimizer level data that way?

[TeraHz]

This is the individual module data, notice the 'OP1.1.3' - this is Inverter 1, String 1, Module 3

It took me a couple of minutes to export a chart from each module to gather all my 24 module IDs, but that should be a one time deal.

I'm thinking that to fully integrate into a script, we would need to setup a login session, fetch the module IDs somehow, and then make a few requests per module to fetch all the data.

It will end up being roughly 3*N requests (N=number of modules) per day - they only allow you 2 data points per request, it seems, and there are 5 data points available. That might be low key enough to not trigger any alarms on their end :)

The only downside is that it is delayed by a day, but I can live with that.

On the other hand, you can go and fetch all your historical data this way as well :)

[martynwendon]

ergouser, I think all current Solaredge inverters have ethernet network interface as standard, I don't see the point in going for Zigbee unless there's some installation issues that make Zigbee appropriate? You can also get a WiFi interface for the inverter if a cabled network connection isn't present.

I don't see the need for the CCG either, it seems quite expensive for what it is! Simultaneous RS485 & ethernet access on the inverter itself seems to be a supported configuration ( shown at the bottom of page 14 on http://www.solaredge.com/files/pdfs/solaredge-communication_options_application_note_v2_250_and_above.pdf ).

The only thing I am not sure about is the menu configuration being able to set the RS485 to device type Solaredge & protocol as Slave AND configure the ethernet side as well .... I'll find that out in a few days when I try it myself!

I guess with the CCG though you'd just be able to snoop on the data on the RS485 side as opposed to need to spoof a "master", because the CCG is the master.

TeraHz, that's an interesting method but the lack of realtime data would be a killer for me unfortunately :-(

Probably a bit sad but I like to see what the panels are doing in real time, plus you can do things like use the temperature readings for alerts or to trigger additional inverter cooling or panel cooling.

[TeraHz]

@martynwendon - Yes, I agree it is best to get the data real time. I mentioned the daily request just as a archival method that has low impact on their servers, but you can just as easily request have the et value in the future, and it returns the most current data as well (I just made a request at 1:58pm with end date of tomorrow and the last entry was from 1:54pm).

Again, it is just an alternative. I'd much rather have the data directly from the inverter and ideally have the inverter as RS485 slave + ethernet as you describe.

[ergouser]

@martynwendon

I guess with the CCG though you'd just be able to snoop on the data on the RS485 side as opposed to need to spoof a "master", because the CCG is the master.

That was exactly my thought, especially since I'm hoping that the gateway will keep the 485 link alive (and so snoopable) even if I disconnect the remote logging. I'm not really happy about having (undefined) entities having the ability to connect to and control my inverter. Especially since there seems to have been unobfuscated data up until the end of 2015.

[jbuehl]

Here's what I have learned about the SolarEdge protocol over RS485 so far. I'm posting this now to see if anyone has any suggestions. Hopefully someone will try it with their system. I wrote a program semonitor.py that I added to the repository that interpret the data and eventually may function as a RS485 master.

Messages are in this format: 4 bytes - magic number 0x12345679 2 bytes - length of data 2 bytes - always 0xffff 2 bytes - sometimes a sequence number 4 bytes - id of the inverter sending the message 4 bytes - id of the inverter the message is intended for 2 bytes - probably contains a function code 0..n bytes - data 2 bytes - maybe a checksum

Here is some output from semonitor. The master inverter 0x7f104920 continually sends messages to the slave inverter 0x7f104a16. The function bytes alternate between 0x0347 and 0x0302 and there is no data. The 0x0347 records have a monotonically increasing sequence number. The last 2 bytes don't seem to match a CRC16 checksum, but I would expect this type of protocol to have one.

semonitor rawdata: 12 34 56 79 00 00 ff ff f0 c4 20 49 10 7f 16 4a 
semonitor rawdata: 10 7f 47 03 b8 eb 
semonitor record: 4 length: 22 
semonitor magic:     12345679 
semonitor dataLen:   0000 
semonitor filler:    ffff 
semonitor sequence:  c4f0 
semonitor source:    7f104920 
semonitor dest:      7f104a16 
semonitor function:  0347 
semonitor checksum:  ebb8 

semonitor rawdata: 12 34 56 79 00 00 ff ff 3b 7f 20 49 10 7f 16 4a 
semonitor rawdata: 10 7f 02 03 44 ec 
semonitor record: 5 length: 22 
semonitor magic:     12345679 
semonitor dataLen:   0000 
semonitor filler:    ffff 
semonitor sequence:  7f3b 
semonitor source:    7f104920 
semonitor dest:      7f104a16 
semonitor function:  0302 
semonitor checksum:  ec44 

Every once in a while, the slave inverter sends a message with function code 0x0500 containing inverter and optimizer data. It is in the same format as previously sent to the SolarEdge monitoring server over ethernet. This message has 0xfffffffe as the destination id, which seems like a broadcast address.

semonitor rawdata: 12 34 56 79 d0 01 2f fe b6 01 16 4a 10 7f fe ff 
semonitor rawdata: ff ff 00 05 10 00 16 4a 40 7f 68 00 d5 dd ac 56 
semonitor rawdata: ec ca 00 00 2c 01 00 00 f5 28 20 0b 3b 55 58 43 
semonitor rawdata: d7 69 c6 41 66 e6 6e 43 bc e3 9c 3f 7a 14 70 42 
semonitor rawdata: ff ff 7f ff ff ff 7f ff 66 e6 aa 43 ff ff 7f ff 
semonitor rawdata: 10 35 86 4b a2 23 39 3c ff ff 7f ff 00 00 00 00 
semonitor rawdata: 04 00 00 00 00 40 9c 45 00 00 00 00 00 00 00 00 
semonitor rawdata: ff ff 7f ff ff ff 7f ff 00 80 8e 43 00 80 92 43 
semonitor rawdata: ff ff 7f ff 00 00 88 ab 16 10 24 00 ea dd ac 56 
semonitor rawdata: 16 4a 90 7f 16 4a 90 7f d7 0d 00 00 00 80 12 42 
semonitor rawdata: 00 00 ae 41 cd cc 14 3f 00 00 60 41 00 00 80 41 
semonitor rawdata: 00 00 35 73 0f 10 24 00 f2 dd ac 56 16 4a 90 7f 
semonitor rawdata: 16 4a 90 7f 57 0d 00 00 00 80 12 42 00 00 ae 41 
semonitor rawdata: 33 33 13 3f 00 00 64 41 00 00 60 41 00 00 20 72 
semonitor rawdata: 3c 10 24 00 41 de ac 56 16 4a 90 7f 16 4a 90 7f 
semonitor rawdata: c9 0d 00 00 00 80 14 42 00 00 f5 41 cd cc 7c 3f 
semonitor rawdata: 00 00 a6 41 00 00 60 41 00 00 95 71 0f 10 24 00 
semonitor rawdata: 5a de ac 56 16 4a 90 7f 16 4a 90 7f be 0d 00 00 
semonitor rawdata: 00 00 0b 42 00 00 70 41 cd cc fc 3e 00 00 4c 41 
semonitor rawdata: 00 00 60 41 00 00 bb b2 16 10 24 00 63 de ac 56 
semonitor rawdata: 16 4a 90 7f 58 4a 90 7f 2c 0e 00 00 00 80 0d 42 
semonitor rawdata: 00 00 a8 41 00 00 30 3f 00 00 5c 41 00 00 80 41 
semonitor rawdata: 00 00 a0 74 0f 10 24 00 b0 f3 ac 56 16 4a 90 7f 
semonitor rawdata: 16 4a 90 7f c9 0d 00 00 00 00 0f 42 00 00 6a 41 
semonitor rawdata: 00 00 00 3f 00 00 44 41 00 00 60 41 00 00 f9 32 
semonitor rawdata: 0e 10 24 00 8b de ac 56 16 4a 90 7f 16 4a 90 7f 
semonitor rawdata: e9 0d 00 00 00 00 15 42 00 00 5a 41 00 00 08 3f 
semonitor rawdata: 00 00 5c 41 00 00 60 41 00 00 4e 71 0f 10 24 00 
semonitor rawdata: 92 de ac 56 16 4a 90 7f 16 4a 90 7f c8 0d 00 00 
semonitor rawdata: 00 00 0f 42 00 00 58 41 00 00 10 3f 00 00 54 41 
semonitor rawdata: 00 00 60 41 46 cd 
semonitor record: 55 length: 486 
semonitor magic:     12345679 
semonitor dataLen:   01d0 
semonitor filler:    fe2f 
semonitor sequence:  01b6 
semonitor source:    7f104a16 
semonitor dest:      fffffffe 
semonitor function:  0500 
semonitor inverter:      
semonitor     type:      0010 
semonitor     id:        7f404a16 
semonitor     len:       0068 
semonitor     Uptime : 51948 
semonitor     Temp : 0.000000 
semonitor     Vac : 238.899994 
semonitor     Interval : 300 
semonitor     Iac : 1.225700 
semonitor     Vdc : 341.799988 
semonitor     Pac : 285.000000 
semonitor     Time : 07:59:17 
semonitor     Eday : 216.332932 
semonitor     Pmax : 5000.000000 
semonitor     Eac : 24.801680 
semonitor     Date : 2016-01-30 
semonitor     Freq : 60.019997 
semonitor     Etot : 17590816.000000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        1016ab88 
semonitor     len:       0024 
semonitor     Temp : 16.000000 
semonitor     Uptime : 3543 
semonitor     Vopt : 21.750000 
semonitor     Vmod : 36.625000 
semonitor     Time : 07:59:38 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.581250 
semonitor     Eday : 14.000000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        100f7335 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3415 
semonitor     Vopt : 21.750000 
semonitor     Vmod : 36.625000 
semonitor     Time : 07:59:46 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.575000 
semonitor     Eday : 14.250000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        103c7220 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3529 
semonitor     Vopt : 30.625000 
semonitor     Vmod : 37.125000 
semonitor     Time : 08:01:05 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.987500 
semonitor     Eday : 20.750000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        100f7195 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3518 
semonitor     Vopt : 15.000000 
semonitor     Vmod : 34.750000 
semonitor     Time : 08:01:30 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.493750 
semonitor     Eday : 12.750000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        1016b2bb 
semonitor     len:       0024 
semonitor     Temp : 16.000000 
semonitor     Uptime : 3628 
semonitor     Vopt : 21.000000 
semonitor     Vmod : 35.375000 
semonitor     Time : 08:01:39 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.687500 
semonitor     Eday : 13.750000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        100f74a0 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3529 
semonitor     Vopt : 14.625000 
semonitor     Vmod : 35.750000 
semonitor     Time : 09:32:32 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.500000 
semonitor     Eday : 12.250000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        100e32f9 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3561 
semonitor     Vopt : 13.625000 
semonitor     Vmod : 37.250000 
semonitor     Time : 08:02:19 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.531250 
semonitor     Eday : 13.750000 
semonitor optimizer:      
semonitor     type:      0000 
semonitor     id:        100f714e 
semonitor     len:       0024 
semonitor     Temp : 14.000000 
semonitor     Uptime : 3528 
semonitor     Vopt : 13.500000 
semonitor     Vmod : 35.750000 
semonitor     Time : 08:02:26 
semonitor     Date : 2016-01-30 
semonitor     Inverter : 7F104A16 
semonitor     Imod : 0.562500 
semonitor     Eday : 13.250000 
semonitor checksum:  cd46 

The slave inverter also sends this message addressed to the master inverter.

semonitor rawdata: 12 34 56 79 00 00 ff ff 5c 7f 16 4a 10 7f 20 49 
semonitor rawdata: 10 7f 9a 03 c2 6f c0 
semonitor record: 56 length: 23 
semonitor magic:     12345679 
semonitor dataLen:   0000 
semonitor filler:    ffff 
semonitor sequence:  7f5c 
semonitor source:    7f104a16 
semonitor dest:      7f104920 
semonitor function:  039a 
semonitor checksum:  c06f 

I know that I am getting some data corruption, probably as a result of not having the RS485 terminators set properly. I'll need to correct that before I can go much further.

[martynwendon]

Great work so far!

Does the salve respond to the 0347 and 0302 messages from the master? If not, it sounds like these may just be heartbeat "I'm alive, keep broadcasting" messages?

How often is the "broadcast" type transmission sent? Is that the only message with meaningful data sent from the slave?

What happens if you disconnect the master temporarily, does everything from the slave stop?

I'm intending on taking a look at the RS485 stuff in the next couple of days, so will update here with what I find.

[jbuehl]

The 0x0347 and 0x0302 messages are sent often, maybe once per second. The 0x0500 is the only one I have seen from the slave with meaningful data. I would not expect the slave to send anything unless it is polled by the master, but I haven't tried disconnecting the master yet.

As I mentioned above, I am seeing what I think is data corruption from time to time. When I have my monitor connected, the master stops reporting data from the slave to the SolarEdge server and when I disconnect it the data starts again, which tells me that I have a hardware issue which I need to fix. I neglected to change the termination switch in the inverter when I hooked it up so that's an obvious suspect. I'm waiting for it to stop raining so I can do that.

[TeraHz]

Another datapoint for the group here. I noticed that the solaredge android app has the Layout view with individual panel data so did some packet capturing there as well. Looks like it is doing POST to api.solaredge.com/solaredge-web/p/layoutGraph_Solaredge and gets a huge json dump of a lot of data, including optimizers, strings, inverters, model numbers, serial numbers and optimizer energy. I can't see the current/voltage going through yet, but I'll keep looking.

[mwhiemstra]

I have some data point from my SE3000 to be added:

1. Solaredge has remotely upgraded my software a few month ago in an attemp to fix my modbus functions
2. Two weeks ago they went into my system to restart two optimizers which went down and could not be paired locally
3. My system still sends the data format as in this forum initially I will follow the guidance and see if I can use the rs485 interface in stead of sniffing packets By the way the iPhone app has the panel layout as well now

[jbuehl]

I fixed my hardware issue, which was a problem with my RS485 adapter, and now I am getting clean, consistent data. Here's what I have learned:

The master constantly sends messages at a rate of about 10 per second. The slave responds at a similar rate, so there is a lot of traffic that constantly occurs, even when the inverters are in night mode.

The master sends a 0347 and 0302 message, each with a different sequence number. The slave responds with a 039F message that contains the same sequence number that was in the 0347 message, and a 039A message with the sequence number of the 0302 message. Every few minutes, the slave will send a 0500 message after the master sends the 0302 message, followed by a 039A with the sequence of the 0302. The sequence number in the 0500 message contains yet another sequence number that is incremented for each 0500 message. I haven't seen a message from the master with this sequence. The 0500 message may have performance data for the inverter and several optimizers, or it may have zero data. If there is data, bytes 6:7 of the message have the value FE2F, but if there is no data these bytes contain FFFF. In other messages, these bytes are usually FFFF, except for the 039F message where they are FFF1.

There are messages with other function codes such as 0080, 027F, 0012, 0090 that occur very infrequently. I have not investigated these yet. I am certain that the last 2 bytes of the message should be a checksum, however it doesn't seem to be a CRC16, an IP checksum, or a modulo 16 sum of the bytes.

Here is a sample:

rec#  dir  flgs seq  func data
----- ---- ---- ---- ---- ----------------------------
35350 M->S FFFF 8C84 0347
35351 M->S FFFF 9C9A 0302
35352 M<-S FFF1 8C84 039F 00000100010001005601013EFFFF
35353 M<-S FFFF 9C9A 039A
35354 M->S FFFF 9C9B 0302
35355 M<-S FE2F 0472 0500 inverter data + 8 optimizers
35356 M<-S FFFF 9C9B 039A
35357 M->S FFFF 8C85 0347
35358 M->S FFFF 9C9C 0302

If someone has a CCG and wanted to monitor the RS485 data, I think semonitor.py should be sufficient to get the data. I still want to use my server as the master, so I am going to keep working towards that goal. Before I can start sending messages, I first need to determine what the checksum algorithm is because the inverter will probably ignore messages that don't have a valid checksum. Suggestions are welcome.

[jbuehl]

I just found this http://gathering.tweakers.net/forum/list_messages/1489893 which has some posts relevant to SolarEdge. I didn't see anything new there, but I am relying on google to translate it so maybe I missed something.