I have implemented a program for logging all messaging events in a Magnum Energy (Magnum) system using a Raspberry Pi Model B and a RaspiComm expansion board. This program logs all messages on the network for subsequent analysis and display. The solar system is off-grid at a summer cottage on an island, far from electricity and internet connectivity. The project started as I wanted to track all generator activity and Magnum had no supporting methodology. This logger will run unsupervised for 6-7 months of the year.
The Project
I have a Magnum MS4024PAE Inverter Charger, an ME-ARC Remote, a BMK Battery Monitor Kit and an AGS-N Automatic Generator Start module. There is also an 810 Watt solar array, a Morningstar Corporation TS-MPPT-60 charge controller and a Yamaha EF5200-DE remote start generator. The AGS detects a low State of Charge (SOC) and automatically starts the generator to top-up the batteries. The magnum units communicate with each other using a proprietary protocol on a RS-485 serial network. Mangum, at one time, published this protocol but withdrew it from public circulation a few years ago. I was able to persuade them to give me a copy with my assurances that I would NEVER contact them for support. I have lived up to that commitment. Mangum has asked me to not publish their copyrighted document.
My Approach
Magnum sells a Web Monitoring Kit that uses a continuously stay-alive internet connection to log information to their data server. The data displayed is essentially the same as the live data displayed on the ARC Remote and monthly logging just shows high – low values on a daily basis. I couldn’t use this for these reasons:
- I don’t have a continuous internet connection
- It didn’t provide any historic logging of generator events. (I have an electric refrigerator so keeping it alive is important and generator activity will tell me approximate fuel consumption and time left before service)
- I had just bought a Pi and was looking for a good project.
The connection from the Magnum network to the Pi is a simple phone splitter jack on the AGS unit, a 4-wire RJ-11 cable from the splitter to a standard RJ-11 wall jack beside the Pi and wiring from the jack to the RaspiComm RS-485 connector. I did not have to make any special changes to either the Magnum or the Pi configuration.
The first thing I needed to do was figure out what a “message” was. The Magnum protocol was a simple protocol of the inverter sending a status message and waiting, then the Remote would send a message with settings content pertinent to each of the other components and wait. These components would respond when there was a pause in the message traffic. The message content was a combination of facts, such as current voltage, settings (battery size) or request to alter a setting. Each unit in the network behaves autonomously. For example, the Remote will allow a user to configure the AGS to know when it will start, how long it will run, and when it can run (excluding quiet time). But the AGS makes its own decision about actually starting the generator. This means there are no command messages, just settings messages. These settings messages are sent repeatedly so the network is very resistant to missed messages and all units will do their tasks even when not connected to the network.
This message stream is continuous and there is no typical server/client request/respond behaviour. The data logger is continuously listening to a non-stop message stream and figuring out what is being said AND it can’t interrupt.
My solution was to determine the end of a message by detecting when the next message started. I was using serial blocking input so I read one character at a time. I check how long the last character took to read and if this exceeded 2 milliseconds, I assume that one message ended and a new was starting. So I would process the buffered characters, excluding the last one, as a message. This works well and I get a very high success rate of meaningful messages. To distinguish messages I rely on the documentation’s definitions and examine message length and some key character values, sometimes at the end of the message and sometimes at the head of the message. Occasionally I’ll get a garbled message that is the wrong size or has no meaningful identifying content. I discard these. My rational is that I’m logging data for later review and I am getting so much data that some losses are not important. I also ignore the first message as I have no idea when I joined the message stream so I start with my first compete message.
Here is an edited code fragment of the message read loop:
Code: Select all
long wait = 2;
char one;
while (getmore) {
long start_time = System.currentTimeMillis();
one = serial.read();
interval = System.currentTimeMillis() - start_time;
if (interval > wait || ix > 22) {
getmore = false;
} else {
buffer[ix++] = (byte) one;
}
}- Add a shutdown hook to enable an orderly logging of the last message and file close.
- Discard consecutive duplicate messages. As each unit transmits the same message over and over again, I discard any consecutive identical message on a message type basis. This reduces file size.
- I write the log to a Gzipped data stream – again for storage reduction.
- Create a new file every hour, on the hour. I am not sure I can defend this time span decision but it seemed like a good idea at the time. I may extend the span.
- Set the program to be started at system start-up by a crontab entry.
- Use separate program to read and format the logged messages. This reduces processing load on the Pi. I do my reporting on the laptop.
What’s Next
I have several things I plan to do in the next few months / years. A lot of the work can only be done on site as I need to interact directly with the live devices.
• Add logging of the MorningStar charge controller. This is relatively easy as it has completely documented MODBUS interface. I just have to decide what to log.
- Review and revise my logging criteria. I probably don’t need all the information I have. I may just do a data slurp every 60 seconds. This will reduce the load on the CPU which is currently running in a tight loop.
- Integrate the collected data in RRDTool for logging and reporting.
- Add a web server interface so I can see what’s happing from any device at my cottage. I have a local wireless network with mobile broadband access when I’m at the cottage.
- Add an email/ftp interface when/if I get more persistent internet access.
- Add weather statistics
- Add camera images
This is my first posting of a personal project so I have been unsure of what exactly to include / discard. I look to feedback to help.
- Should I post all the source?
- The full source is available on request as an Eclipse project.
- The Raspberry Pi and an Ethernet switch are running directly off the batteries using a set of LM2595 DC/DC buck converters. This allows logging to continue with the inverter shutdown.
- I cannot provide the Magnum Protocol Document
