Solar Freaks

JinbaIttai wrote:I used to work for a dial-up ISP so I keep thinking about multi-port serial interfaces A 64-port "Stallion panel" is probably overkill...

Matt, my setup is quite unique.
I have 5 x USB-RS232 converters, plugged into 2 x USB Hubs, as i only have 2 USB ports spare .

Have yet to experiment with the RS485. Maybe that will solve my issues.

Hi JinbaIttai, biink,TonyB and Inspector,

I was also working on reverse engineering the protocol when I stumbled upon this forum.
I have a Schneider SunEzy 600E (in Europe), which seems to be based on the PhoenixTec/Sunville 4600. It allows the connection of up to 3 panel arrays.

I think the protocol is a bit more complicated than what is assumed here:

This is what (I think) I have figured out:

The protocol is probably designed for multi-drop RS-485 (one controller, multiple inverters in daisy chain)

By analysing the sequence attached (see attachment SunEzy.xls), I believe the data words have the following structure:
---------------------------------------------------------------
Bytes 0 and 1: AAAA is a leader (10101010 in binary)
Byte 2-3: Source address (0100 for the controller)
Byte 4-5: Destination address (with 0000 for broadcast and 00XX for the inverters)
Byte 6: Mode (Network management (00) and communication mode (01))
Byte 7: Command/reply type byte with the following commands and their replies. Note that the high bit is set when a reply from an inverter is received and cleared when a command from the controller is sent.

In network management mode (see byte 6)
04: Reset network address for all devices/Initialize network (uses broadcast mode)

00: Query network
80: Report from network with serial (here 09359AL012)

01: Assign device with serial a network address (here 01, uses handshake mode. This is where you assumed that it was a trailing 01, wheras I suppose it is an assignment of an address, will become 02 when next inverter responds, I guess)
81: Confirm (reply 06 from assigned address, uses handshake mode)

In communication mode (see byte 6)
03: Query device for inverter type and software revision
83: Reply with inverter type and software revision (here Type 4600, firmware S1.00, brand SunEzy 600E, Manufacturer: PhoenixTec)

00/80, 01/81 and 04/84: Possibly query device capabilities (see e.g. unknown request 3)

02: Query device for readings
82: Reply with readings

Byte 8: Number of bytes to follow after the command sequence exclduing the checksum
Bytes 9 to (n-1): data (either in hex, double hex or ASCII)
Bytes (n-1) to n: simple checksum of all previous byte (addition with single byte carry over)
------------------------------------------------------------
Obviously I'm not sure about the whole thing, as verifying this requires protocol readings from a system that has multiple inverters installed, but my guess is that I'm not far off.

Can anyone confirm or correct?

Hi Ingmar

I never suggested the protocol wasn't complicated, far from! However in my short-sightedness (and desire to get it working) I did not reverse engineer the protocol beyond what I needed to make it work

Looks like you have done a great job of working it all out. I always wondered what the setup handshake was all about, and why it included the serial number but what you are saying makes perfect sense

Have you set your inverter to different network addresses and been able to communicate with it that way? I might have a play with this on the weekend.

At the moment my Perl program is a dodgy hack that actually works at least via RS-232 (now tested on multiple CMS-2000 inverters, and about to be tested on a CMS-10000) but I would love to have it work "properly" by calculating each command correctly rather than just sending pre-fabricated strings as it does now - with your insight into the protocol that job has become much easier.

I also skipped over the firmware/model query steps, but I will have a play with that too, to confirm your findings.

Haven't tried it yet, just figured out the protocol because I wanted to write my own software to log things. The software delivered by Schneider is the most crappy software I've ever seen. It's written "win95-style".

However, since this is a new system, I don't want to make any mistakes because there are also commands to set system parameters that I believe setting wrongly might damage the system.

Hence I was seeking some confirmation before attempting to play around with things.

The program I'll eventually write will be in Delphi, and probably also an embedded version (running on a PIC, TMS430DSP or whatever I have laying around).

I also want to implement a translator to SMA format, because there seems to be a lot of SMA compatible soft around.

JinbaIttai wrote:Hi Ingmar

I never suggested the protocol wasn't complicated, far from! However in my short-sightedness (and desire to get it working) I did not reverse engineer the protocol beyond what I needed to make it work

Looks like you have done a great job of working it all out. I always wondered what the setup handshake was all about, and why it included the serial number but what you are saying makes perfect sense

Have you set your inverter to different network addresses and been able to communicate with it that way? I might have a play with this on the weekend.

At the moment my Perl program is a dodgy hack that actually works at least via RS-232 (now tested on multiple CMS-2000 inverters, and about to be tested on a CMS-10000) but I would love to have it work "properly" by calculating each command correctly rather than just sending pre-fabricated strings as it does now - with your insight into the protocol that job has become much easier.

I also skipped over the firmware/model query steps, but I will have a play with that too, to confirm your findings.

JinbaIttai and others,

could you reply and attach a protocol reading from the first 2 minutes of your system? I would like to compare them against my readings to try and figure out the 00, 01 and 04 command (the unknown ones).

Hi Ingmar,

I haven't done any low-level programming such as Jinbal; I've merely got my inverter working with readily-available ProControl software.

Good luck with your progress.

Inspector wrote:Hi Ingmar,

I haven't done any low-level programming such as Jinbal; I've merely got my inverter working with readily-available ProControl software.

Good luck with your progress.

Hi Inspector,

tried the ProControl on my system, but the readings were completely of. Not even close. Probably because of different system settings. Do you use it with a system for which it wasn't designed? If yes, could you send me the modelparameter text file of the original system software (based on PhoenixTec soft)

What system are you referring to - inverter or PC? I assume you set your PC's COM port correctly?

The Pro Control Software was designed for SEA Orion inverters. My understanding is Inspector is using it with the CMS2000 inverter, which is a re-badged Orion.

Ingmar, the inverter your using will most likely have different firmware to what the CMS2000 has as it a European inverter. Although the comms are the same, you could have different scaling on your data.

Ingmar wrote:[tried the ProControl on my system, but the readings were completely of. Not even close. Probably because of different system settings.

Hello Ingmar

I have had a closer look at your spreadsheet, and have discovered the difference between the data packets the Orion and CMS-2000 send (which works with Pro Control) and the data packets your inverter sends.

Your inverter sends a whole bunch of parameters ours don't - Vpv2, Vpv3, Vpv4, Ipv1, Ipv2, Ipv3, Counter and Vpv1(R)

Our inverter goes from Vpv1 straight to Iac, skipping all those values - which is why Pro Control will be confused.

I don't know if ModelParameter.txt will be able to help you with that, as it appears to set min/max values of each parameter, not the parameter order.

It should be easy enough to modify my software to work with your inverter though. Are you interested in running my software or have you written something of your own?

JinbaIttai,

(btw: is your name Jinba? That's shorter)

Yes, indeed.
The Schneider is based on the 4600 PhoenixTec, which is a 3 panel array inverter. Hence the PV1, PV2 and PV3 V and I readings.
However, I assume the software to be intelligent enough to read the type (with the appropriate command), then look up the model in the modelparameter.txt file and accordingly read the correct items. Could also be that the ProControl software is a slimmed down version, and doesn't actually take into account the parameter file.

The parameter file inside Procontrol actually has an entry for SE600E (SunEzy 600E), but has at the end a few parameters more and different from my control program. Might be explained by firmware. Unfortunately, SEA only has one system. So no-one else to compare with.

SunEzy Control:
[Para] SE600E 1400 5000 20 300 1800 2510 1980 3000 4800 5200 4800 5200 5900 6100 5900 6100 100 20000 100 2000 1500 20 1980 2510 4981 5019 2500 1000

ProControl:
[Para] SE600E 1400 5000 20 300 1800 2510 1980 3000 4800 5200 4800 5200 5900 6100 5900 6100 100 20000 100 2000 1500 20 1980 2510 4981 5019 5925 6055 2500 750

I was actually going to start this WE with writing some software to do the testing of the addressing, just to see if that actually works as I suspect. And if it does, I'll probably go all the way to produce a full program. You know, once you start programming, it will continue into the night .
Web interface for remote reading should follow a bit later (or maybe also this WE, if things move fast enough). I know, I'm a

I'm not an expert in Perl, but I am able to read your program.

Could you attach a protocol reading from your system for the first two minutes?

Hi Ingmar

my name is Matt, which is even shorter again! "Jinba Ittai" is what I use on various forums. It refers to my other passion (cars)

So this "SunEzy control" is similar to Pro Control, but works with your inverter?

To be honest I haven't spent a huge amount of time playing with Pro Control (other than using it to figure out the protocol) as it would not let me do what I want - draw graphs and html on the fly.

And I know all about staying up all night writing code - the only thing that prevented too many late nights writing code for the inverter is that as soon as the sun goes down the inverter stops responding, however the graphing aspects did involve a few late ones

what do you mean by "protocol reading"?

I don't send the 00, 01, or 04 commands from my program, however this weekend I can modify my code to send them, and see the response my get. Is that what you are looking for?

Bear in mind that I don't have a computer with more than 1 serial port, so I can not put myself between Pro Control and the inverted and log all traffic. I had to reverse engineer this the hard way which is why I apparently missed a few commands

Hi Matt ,

I was looking for the communication log.
There is a free program from HHD software that runs in parallel with the ProControl (or SunEzy Control). You can download it from
http://www.serial-port-monitor.com/.

You need to start the program first, then the Control software, log some stuff, then close the Control program and finally the monitor software. It leaves the port open. The window you need is the Request view. Self explaining when you run the program.

The output is like attached to this post.

Hi Ingmar

right, this software would have saved me some trouble when I first started playing with this...

I reverse engineered the protocol by using two laptops, one running Pro Control, the other a serial sniffer, seeing what Pro Control was sending me - then swapping cables and sending that to the inverter and see what it replies with...

I will try this serial monitor on Saturday, with both Pro Control and my software, and let you know what I see

I got a chance to play with the CMS-10000 today (10kW, 3 array inverter) and the data packets are different again!

byte 8 (number of bytes) is 5a hex (90 decimal) - it looks like I'm going to have fun working which bytes are what again...

- Matt

Hello Ingmar (and others)

I have figured out most of the data from the CMS-10000

It's connected to 3-phase AC, and it outputs data for Voltage, Current and Frequency for each phase (plus a combined "Power" (kW) output) and it also has 3 panel arrays, so it has Voltage, Current and Power for each array.

Also, in addition to the "total production" E-total (kWh) counter, it has an E-today with the current day's production.

There's 3 values that it outputs which I haven't yet figured out the meaning of. They appear to be counters of some sort, but no idea of what - they were all "644" on Wednesday, and this morning I watched them all change from "750" to "751" at the same time.

Anyway, I have added sample inverter data for the CMS-2000 and CMS-10000 to your spreadsheet, for comparison purposes. Who knows, it may help someone else in the future

- Matt

Why do you have a CS10000?
Have you got a 10KW system?

Hi Tony

I don't have a 10kW system (I wish!) but I have been asked to help monitor one that was installed a few weeks ago.

Ingmar: my protocol reading is attached

It appears to me the first "unknown query" is how the inverter tells the reader which parameters it will be sending, and in what order - just like I am missing 7 byte-pairs in the data stream (Vpv1 -> Counter) response 1 is also missing 7 bytes in the same spot.

Therefore I would assume that 00 = Temp, 01 = Vpv1, 02 = Vpv2 etc, then 40 = Vpv, 41 = Iac, 42 = Vac etc.

"unknown query 3" gives the configuration parameters Vpv-Start, T-Start, Vac-Min, Vac-Max, Fac-Min, Fac-Max - the values I get correspond to those values as displayed in Pro Control.

"unknown query 2" is still a mystery to me. Once again you get two bytes that I don't (but at the end of the stream) but the responses are otherwise identical. Some kind of inverter status response maybe?

There's an "Error Message" value in Pro Control, perhaps these bytes are used to say "error in Pv array 2 / array 3" ?

- Matt

Matt, could the "644" and "751" be hours or minutes of inverter uptime?

Hello Inspector

I thought that's what they were, but there already is a parameter for that. Also, since there are 3 values, I would assume they either pertain to the 3 solar arrays, or to the three AC phases.

The values are very close to the inverter uptime though - when they were 644, inverter uptime was 62 hours. When they were 750/751 inverter uptime was 75 hours, although I suspect they are unrelated.

- Matt