pyMATE is a python library that can be used to emulate an Outback MATE unit, and talk to any supported Outback Power Inc. device such as an MX charge controller (eg. FLEXmax 60/80), an FX inverter, a FlexNET DC monitor, or a hub with multiple devices attached to it.

NOTE: Not all devices are tested yet. I have only been able to test with devices I actually have!

The MATE by itself provides some pretty basic data through its RS232 port, but you can get much better data from the binary "MateNET" link, plus you bypass the MATE from your system altogether piping the data directly into a Raspberry Pi!

All you need is a simple adapter (described below) and a standard serial port. The python library will work on any OS! (I have tested it on Linux and Windows)

KEEP IN MIND that this is a replacement for the MATE's RS232 output - with this library and adapter you do not even need the MATE unit!

Motivation

I dislike closed proprietary protocols that hide the data away! I believe data should be open - it allows for much more innovation and opens a lot of possibilities.

In this case, I found that the RS232 interface that the MATE provides is vastly inferior to the data I could obtain on the LCD, so I decided that it would be worthwhile to extract the data directly from the solar charge controller.

I also wanted to integrate data collection into my own home-automation network, and removing the need for a MATE unit and going directly to a Raspberry Pi is a plus.

Adapter

The proprietary link between the MATE and the unit (what I will now call "MateNET") needs some voltage conversion before you can connect it to your PC or Pi, but it's just UART (9600 baud, 9 data bits, 1 stop bit)

The serial signals are 0 to VBAT (which in my case is 0-24V), with logic high being anything greater than 50% of VBAT (the MATE's circuitry uses a schmitt-trigger comparator with its reference set to 50% of VBAT)

To interface with it, you'll need to build a simple adapter, which just needs to convert TTL serial to the correct voltages. I chose to use opto-isolators to ensure my Raspberry Pi stays isolated from the charging system, but this isn't strictly required (provided you know what ground is!)

The only other thing you'll need is a TTL (not RS232!) serial interface, which may be a UART<>USB adapter. Both 3.3V and 5V adapters should work, but you may need to tweak the resistor values to make sure your logic levels are good.

Pin-Out

The MATE connection uses a standard RJ45 connector, and is as follows:

1: +V (Battery Voltage)  (Green/White)
2: GND                   (Green)
3: (TX:MATE -> RX:MX/FX) (Orange)
6: (RX:MATE <- TX:MX/FX) (Orange/White)

To connect the opto-isolator to an MX/FX unit:

Opto-Isolator <> MX/FX
 +V : Pin 1 (Green/White)
GND : Pin 2 (Green)
 TX : Pin 3 (Orange/White)
 RX : Pin 6 (Orange)

To connect the opto-isolator to a MATE (For testing!):

Opto-Isolator <> MATE
 +V : Pin 1 (Green/White)
GND : Pin 2 (Green)
 TX : Pin 6 (Orange)
 RX : Pin 3 (Orange/White)

(Note the swapped RX/TX!)

For more details on the reverse-engineering process, see my Hackaday.IO Page

Python Library

[ GitHub Repo ] [ Download ]

To use, you will need to install Python 2.7 and PySerial. The code includes some samples on how to use the library.

I intended this library to be integrated into your own application - it does not provide a complete user interface! I'm hoping that someone else will come along and write a nice webpage or GUI or cloud interface :)

If you need any help, feel free to leave a comment below or send me an e-mail.

Implementation Details

Because PC serial ports only support 8-bit serial data, I had to do a sort of hacky implementation that exploits the parity bit. This introduces some delay between the first byte in the packet and the rest, but none of the devices seem to mind.

The raw protocol itself is pretty tricky - the packets are highly packed and data is scattered all over the place! (Trust me, it was an absolute nightmare to figure out which bytes mapped to the LCD display)

While I don't have access to all of Outback's devices, I was able to guess with fairly good accuracy what you need to interpret packets from other units (such as the FX interter and FlexNET DC). These devices are currently untested.


comments powered by Disqus