Setting up StecaGrid communication

So, this StecaGrid 3600 was a fair bit cheaper than normal, and as always cheapness comes at a price. It turns out that there exist different revisions of the inverter and I received an older version of it. And from what I understand the newer models have an ethernet interface which connects directly to your LAN, allowing you to navigate to a nice little dashboard or read raw xml data.

That was not the case with my model. I had already verified that it came with two RJ45 connections at the bottom, but unfortunately both are used for a funky RS485 serial connection. So the only way forward was to figure out how this serial connection works, and I started research before I even got my solar panels.

The manufacterer Steca Elektronik nicely provided me with the technical documentation of their RS485 interface and this looked really promising; it contained various commands to retrieve almost all metrics that were available via the inverter display itself... among which the daily and total yield values!

So after this inverter had been installed I couldn't wait to get started. But before even thinking about the data and documentation I first had to to get the serial connection to work, and by that I mean the actual physical wire that connects the inverter to a computer.


I sacrificed this old 20-meter UTP patch cable and cut off one of the RJ45 connectors, so I could connect the relevant wires to an RS485-USB adapter. I then plugged it into the computer which detected the USB serial port...

And at that point I got stuck.

I found several serial communication software tools, and tried sending some bytes to see if the inverter would send any response, which it did not. I also had the tools listen on the serial port for several days and log every single byte they received, and although there seemed to be spontaneous activity now and then, it mostly consisted of 0x00 bytes and a handful of other random bytes, garbage in proper programmer's terminology.

The technical documentation from Steca was at a higher protocol level than the serial protocol I was currently struggling with. They described command bytes that led to certain response values... perfect... but that command had to be wrapped with all kinds of control and checksum bytes; get one wrong and your command would simply be ignored.

On top of that, there were still more variables in play:

• Did I attach the correct wires to the A (485+) and B (485-) pins of the adapter?
• Which of the two RJ45 sockets on the inverter should I use?
• In what position should I put the tiny line-termination switch at the bottom of the inverter?
• Did I use the correct serial connection parameters?

I must admit I almost gave up here. Almost even resorted to pulse-counting on the S0 port of the kWh-meter, which turned out to be a trivial arduino sketch and circuit, but at the same time felt so dirty and disappointing.

And then... two weeks after I had connected the cable... on this german forum Photovoltaik I found a mention of the Steca User Software that also used this RS485 connection. After installation, it started its inverter detection on the serial port, and hallelujah, within 3 seconds it reported a "StecaGrid 3600". Communication established, arduino back in the box, the mission was back on track.


This program could update the inverter's firmware (more on that later), but also retrieve the actual panel power, voltage and frequency measurements, visualize the day curves from the past 30 days, and the yield totals from the past months and years.

Whatever this program could do, I wanted to do it myself and tightly focused on what I really needed, and prepared for automated readouts.


It was time to take the next tools from my toolbox: a serial traffic monitor which could capture all bytes on the serial port, and a decompiler for Steca's .NET assemblies. Time to reverse engineer all these data commands.


A final note on the variables that lead to successful communication with the StecaGrid:

• It doesn't matter which of the two sockets you use since they're internally connected to each other; RS485 was designed to connect multiple devices in series over long distances.
• The line-termination switch can be in either position, but I found that I get more 0x00 padding with the switch in ON (right-most) position, so I put to OFF.
• UTP wire 1 (orange/white) is connected to data A (485+)
  UTP wire 2 (orange) is connected to data B (485-)
  UTP wire 8 (brown) is connected to ground

• Connection parameters:

  Baud rate:	38400
  Parity:	none
  Data bits:	8
  Stop bits:	1