diy solar

diy solar

"Splitting" RS485 - Two monitoring solutions for one inverter?

Joined
Aug 1, 2020
Messages
88
Location
Mansfield, TX
I like solar-assistant for my pair of Megarevo inverters, however I keep having to change back to the original monitoring sticks for Megarevo to login and mess with stuff. Is it possible to run a splitter and have both running at the same time? Would it be as simple as just connecting all the communications wires together? rs485+ from the inverter connects to both solar assistant and the OEM logger stick? I'm a dummy when it comes to canbus/rs485.
 
Nope, it won't work.
Basically SA or your Monitoring stick are the RS485 Master. There can be only one master in a Modbus (RS485) network.
But I have fiddled around with running two masters, but you need additional hardware and some programming skills:
What I did is implement a "proxy" using a microcontroller (RPI2040) and a two channel RS485 "hat"/shield.
Basically this proxy handles requests from two sources and sends them to one destination. It does this in a first-come-first-serve manner. Meaning that one will wait for the other's request to complete before receiving a response. This is all time sensitive and depends on the interval of requests being received and the ability of the inverter to reply fast enough.

It works nicely when I tested my MUST inverter with both Solar Assistant and the MUST software being connected.

I could share the code and hardware list if you are interested, but I haven't done thorough testing yet. I pretty much abandoned this little project as after initial setting of my inverter, I just plan on using SA for monitoring.
 
That's a bummer but I suspected something like that would be the case. I appreciate your offer, I'm not ambitious enough to make it work at this point though with the proxy I think.
 
It depends on the protocols; Modbus as stated above cannot have two masters, but some of the communications devices use a separate protocol for their device to get around limitations of Modbus. Some also have CANBUS communications. The one Megarevo manual I could find online showed support for multiple interfaces, but it was a larger unit. I don't know what SolarAssistant is using in terms of protocol.
 
I think there are off the shelf ModBus proxies to support controls people implementing industrial etc equipment. It can probably be made to work decently with a single writer/multiple reader situation. Which I assume is happening in your case with SolarAssistant used for monitoring.

You could also consider using a DPDT (or however many poles) relay to automate the switching at a mechanical level.
 
I think there are off the shelf ModBus proxies to support controls people implementing industrial etc equipment. It can probably be made to work decently with a single writer/multiple reader situation. Which I assume is happening in your case with SolarAssistant used for monitoring.

You could also consider using a DPDT (or however many poles) relay to automate the switching at a mechanical level.
I don't think you could use a generic proxy since it would not allow setting values. A custom proxy would be prohibitively expensive and you can get into issues switching masters quickly FWIW.

Since SA says it can't be done I would default to trusting them.
 
I don't think you could use a generic proxy since it would not allow setting values. A custom proxy would be prohibitively expensive and you can get into issues switching masters quickly FWIW.

Since SA says it can't be done I would default to trusting them.
What do you think would break with a standard proxy? My understanding is that the proxy acts as the one and only real master, and it mediated all access with the targets on the RS485 bus. There are either three separate RS485 segments, or the proxy exposes ModBus TCP (not ideal in this case where the masters are ModBus). So there cannot be crosstalk between the two masters talking through the proxy.

Now if you try to do any workflow that involves modifies the state on the targets from both masters, that just will not end well from a theoretical angle, and you deserve whatever you get in undefined behavior for trying it.
 
You could also consider using a DPDT
This is what I plan to do to provide access to the Bluetooth BMS dongle or SA I'm going to make a small box with connectors to receive from the dongle and SA through a switch to the output on the BMS
 
This is what I plan to do to provide access to the Bluetooth BMS dongle or SA I'm going to make a small box with connectors to receive from the dongle and SA through a switch to the output on the BMS

Can you explain a little bit on the workflow? When does the BMS need to be connected, and when does SA?

I don’t imagine either of those are mission critical to safe/reliable functioning
 
I hate to be that guy, but I’m looking for an rs485 proxy and can’t find it. I’d be willing to spend a few bucks and see if it works. Even if solar assistant wasn’t able to modify, just read. Does someone have a link to one they think might work? A switch to go between the two if of course an option, but one of the things I love about monitoring is having historical graphs and that doesn’t work if I’m not using it most of the time :(.
 
Can you explain a little bit on the workflow? When does the BMS need to be connected, and when does SA?

I don’t imagine either of those are mission critical to safe/reliable functioning
Yesterday was a perfect example. I was doing maintenance on two batteries and it would have been convenient to not have to unplug the converter box from the BMS and plug in the Bluetooth dongle so that I can see the BMS and then unplug that and replug the converter box for solar Assistant. More work than it will probably be worth for the convenience. But a little build project I'd like to do.

And actually a 4p2t switch..
 
Yesterday was a perfect example. I was doing maintenance on two batteries and it would have been convenient to not have to unplug the converter box from the BMS and plug in the Bluetooth dongle so that I can see the BMS and then unplug that and replug the converter box for solar Assistant. More work than it will probably be worth for the convenience. But a little build project I'd like to do.

And actually a 4p2t switch..
OK, so the BMS is for manual maintenance while the SA is for steady state use?

Yeah I wasn’t sure how many pairs there were in RS485 ?
 
I hate to be that guy, but I’m looking for an rs485 proxy and can’t find it. I’d be willing to spend a few bucks and see if it works. Even if solar assistant wasn’t able to modify, just read. Does someone have a link to one they think might work? A switch to go between the two if of course an option, but one of the things I love about monitoring is having historical graphs and that doesn’t work if I’m not using it most of the time :(.
Graphs are great.

Disclaimer: I haven't worked with any of this hardware or software for solar, but I have professional training in networking and the relevant operating systems stuff.

First of all, before we waste time going down a rabbit hole, what is the protocol running on top of RS485? (RS485 is just a electrical/physical interface, there are additional network layers sitting on top)

https://diysolarforum.com/threads/megarevo-rxlna-discussion.36290/post-473747
Here it says: GOODWE EMS PROTOCOL (MODBUS RTU)

OK, that would be my standard guess (registers built on top of Modbus RTU). So I think what we want to do is find a ModBus RTU proxy that gives you one port to point at the Megarevo 8K, and another two ports that point at your SolarAssistant and Megarevo stick.

This is part of the answer: https://github.com/3cky/mbusd (or hardware like this https://www.sstautomation.com/Products/Modbus_TCP/Modbus_to_Modbus_TCP/GT200-MT-RS485.html https://www.sstautomation.com/DownloadData/Datasheet/GT200MTRS_Datasheet_V14_RevB.pdf).

For that mbusd it looks like it assumes you have TCP masters connecting. You would need to combine this with a utility program that takes a UART device and mashes its output onto Modbus TCP. If the software is available (there's no rocket science here, it's a matter of what people have implemented) all that can run on the same RPi, IE one RPi with three (3) RS485 ports added onto it.

Note:
  • you probably want galvanically isolated RS485 adapters
  • in theory SolarAssistant RPi could probably host a proxy on it with an additional USB RS485 UART
 
What do you think would break with a standard proxy? My understanding is that the proxy acts as the one and only real master, and it mediated all access with the targets on the RS485 bus. There are either three separate RS485 segments, or the proxy exposes ModBus TCP (not ideal in this case where the masters are ModBus). So there cannot be crosstalk between the two masters talking through the proxy.

Now if you try to do any workflow that involves modifies the state on the targets from both masters, that just will not end well from a theoretical angle, and you deserve whatever you get in undefined behavior for trying it.
I haven't really been involved with Modbus proxies in a decade, but what they used to do is read all of the read-only registers at some set refresh interval, store current values, and then act as a slave for the other master segments to read the values. If this is all the functionality required then it generally works. (There are some issues with not doing inteligent scanning intervals and just brute-forcing it with a full refresh, but those are relatively minor.)

The problem really comes that both SolarAssistant and Megarevo's dongle assume they are full masters to the system, so their functionality is going to be restricted if behind a proxy-- if it doesn't end up crashing their system.

If Megarevo doesn't actually use Modbus for their communications (a proprietary protocol is pretty common to overcome some of the limitations of Modbus) then you have a different set of problems...
 
Back
Top