Solar Controller Reverse Engineered In Both Directions

[Jared Sanson] has a solar power setup on his beach house, consisting of 6 panels and a 24V battery bank, supplied by Outback Inc. Their chargers and inverters pair over a seemingly proprietary connection with a controller known as the MATE. The MATE has a standard serial output which gives some details about the operation, but [Jared] wasn’t getting the detailed information they could get from the controller’s screen. This meant it was time to reverse engineer the proprietary connection instead, which [Jared] calls MateNET.

The controller interfaces with the chargers over a Cat5 cable. [Jared] initially suspected RS-485, but it turned out to be regular serial at 0-24V logic levels, at 9600 baud, 9n1. To figure out the pinout, [Jared] went through the MATE circuitry with a fine-toothed comb, discovering an ATMEGA32. Since both the MATE’s user output & its connection to the other equipment are both serial, a logic mux is used to split the ATMEGA32’s single UART between the two serial connections. With the physical layer sorted, it was time to figure out how the protocol worked.

The first step was to capture some packets from the running system, with the MATE connected to an MX charge controller. There was some difficulty in that the MateNET system uses the 9th bit to indicate the start of packets – [Jared]’s PC sniffing setup ignored this as a parity bit. By matching the contents of the captured packets with what was displayed on the screen, it was possible to determine fields containing status, battery voltage, and solar panel voltage. The rest of the packet wasn’t easily understood, however, and [Jared] decided to change tack.

Using Python to emulate the MX charge controller, packets were sent to the MATE with varying contents, and the screen monitored for changes. This spoofing approach made the contents of the packets much easier to determine. It was important to note the checksum used in the packets to make sure the MATE considered the data valid. [Jared] went further, trying to spoof other hardware with his Python code. The MATE helped out, indicating when packets from different hardware were shorter than expected, or otherwise malformed, helping them to guess the proper format. This work all got wrapped up into pymate, a Python emulator of a MATE controller.

With the protocol figured out, it was time to wrap the project up. Running pymate on a Carambola2 Linux board, the packets get processed and eventually stored in a PostgresSQL database on a remote server. Combining this with the stunning Grafana open-source graphing library allows [Jared] to view his system’s status with some very pretty graphical aids, by way of a Github fork that allows the library to grok SQL.

It’s a tidy project with a very professional-looking end product and allows [Jared] to easily monitor his solar setup remotely. Power monitoring hacks are very popular – we’ve even seen it done with webcams monitoring power meters with Python.

11 thoughts on “Solar Controller Reverse Engineered In Both Directions

  1. Another fuzzy title click-bait title from HaD. By reading it, one understands that the whole controller was reverse engineered. Alas, it´s deceiving: it´s just the communication protocol. Was it really too costly to add the word “protocol” to the title ?

    1. A good headline invites curiosity to get you to read the article. That’s not clickbait, that’s just being effective. If they tell you everything in the headline, why are you going to read it? Actual Clickbait is deplorable, however. But this headline was not clickbait at all.

  2. As someone who is an electronics Hobbyist. I have no idea why they use 0-24v logic on the uart instead of 5v or 3.3v depending on what the atmega32 is running at. Can any of you smart Electrical Engineers tell me why they would do that?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.