Living on mostly 12v and reducing power

As both RS-232 and RS-485 at the core are asynchronous serial communication methods, it does not make any difference to the GS inverter which one you pick.  At the end of the day, the actual communication protocol is what matters...MODBUS will be supported, and if there's any other industry standard that I should know about, I can add support for that as well.

6 hours ago, Sid Genetry Solar said:

As both RS-232 and RS-485 at the core are asynchronous serial communication methods, it does not make any difference to the GS inverter which one you pick.  At the end of the day, the actual communication protocol is what matters...MODBUS will be supported, and if there's any other industry standard that I should know about, I can add support for that as well.

My experience with RS232 on an embedded system, a standard terminal package can be used to gain access to a command line (ie Cisco router, UNIX console, TTY device, etc.), a character based menu system (ie UNIX FMLI), full raster based system based on escape sequences (ie Techtronix 401x emulation), of full graphical windowing based upon escape sequences (ie 5620 dmd, 630/730 mtg, etc.) Binaries or software updates often occur via a protocol (ie X Modem, Y Modem, Kermit, etc.)

When I was in college, I coded a cooperative multitasking debugger & firmware in assembler for a single board I designed & soldered together, which used dual RS232 ASCII ports which one could upload new code to the debugger as a command line option.)

Sun workstations & servers and most Open System servers had full command line debuggers using ASCII RS233 ports, with a FORTH interpreter for OpenFirmware ieee1275-1984. Systems are still shipped with this, today, used in projects ranging from the One Laptop per Child initiative to large UNIX systems.

In my job: we used FMLI on top of a UNIX shell, for decades, on servers & telco switching instruments; coded our own menu systems for human interactive work; even made quick performance graphs in an xterm Tek mode (those tools are now finally being discontinued Jan 2024 in commercial UNIX systems like Solaris 10.)

What you would need to implement, I am not sure. Having been the author, user, and automation builder [across thousands of units] of embedded systems on rs232 based systems and later ascii systems over telnet & ssh… my experiences are very different from yours.

From my perspective, I would expect to plug in a PuTTY RS232 terminal and get a login, prompt, menu, or graphical interface when the system interrogates the type of terminal emulation used… where I could request statistics through successive queries and automate such queries through the “expect” language.

My historical expectation from working with  rs232 ports on workstations, servers, communications equipment, laptops, single board computers, and entertainment consoles like CD-I is not the objective from embedded systems of automotive or scientific instrumentation… and likely not your perspective, which should be closer to equipment shipped by power vendors like Schneider Electric.

I guess at this point that I should just get the most common configuration from each of the vendors.

I think I beat this to death. LOL!

Have you dug into the communication documentation (if any!) on all of the other RS-485 units you mentioned?  That might be a good start, to see if they are even compatible to share the same bus.

or if you can provide more specific details on each of the other components you'd like to share on the bus, I can do some quick checks to see if they're compatible.

Notice that the RS-485 bus limit has to do with maximum drive current abilities...if you strategically added RS-485 buffers, the bus could be significantly extended.

On 7/30/2022 at 3:35 PM, Sid Genetry Solar said:

But simply because something uses RS-485 is no guarantee they all speak the same language on RS-485.  You would have to ensure that all of the devices on the RS-485 bus speak the same "language" (and run at the same baud rate) so they don't cause bus collisions.  If all of the devices support MODBUS, then that's perfect--as each of them could have a separate MODBUS device ID, and the "bus master" simply requests data from each one in turn (by ID).

Sid have you made decisions on what direction you are planning to go.  I am hoping for MODBUS RS485.  I have two existing MODBUS networks baud rate 38400 and 115200 just because that is what the devices are hard coded with.  Well hoping that you pick one of those or make it configurable with Baud and ID, but I am willing to adapt to whatever you end up doing.    Just hoping for some crumbs of the plans right now so I can start to make some tweaks to my code to prepare. 

5 minutes ago, AquaticsLive said:

Sid have you made decisions on what direction you are planning to go.  I am hoping for MODBUS RS485.

Options, options 😉

When ordering a GS inverter, there *should* be an option to select what kind of hardware interface you want (RS-232 or RS-485).  Past the hardware layer, it's completely up to firmware...I definitely plan on supporting MODBUS (yes, with user customizable baud rate & ID number), but may also support other options as they come to mind.  A very simple one might be an automated (i.e. every 10 secs...or every minute) JSON stats dump...you never know.

Haven't started on the code for that yet, but hope to make some good progress on code before the inverters arrive.

1 minute ago, Sid Genetry Solar said:

When ordering a GS inverter, there *should* be an option to select what kind of hardware interface you want (RS-232 or RS-485).  Past the hardware layer, it's completely up to firmware...I definitely plan on supporting MODBUS (yes, with user customizable baud rate & ID number), but may also support other options as they come to mind.  A very simple one might be an automated (i.e. every 10 secs...or every minute) JSON stats dump...you never know.

Thanks Much.  Yeah that is the only bread crumb I needed to make my day.  Awesome.  Yep I picked RS485 on my order.  Can't wait man.  I prefer on demand data, but I am sure there may be others that would like a JSON stats dump.  Your always on top of it, please make it so I can turn the dumps off though if possible. 

1 minute ago, AquaticsLive said:

Your always on top of it, please make it so I can turn the dumps off though if possible. 

Settings, man...

That's my weak spot...maybe including too many 😉.

1 hour ago, Sid Genetry Solar said:

Settings, man...

That's my weak spot...maybe including too many

Yep, same here.  One trick I use is using a coil/register message to adjust some of the more detailed settings after communication is established.  So lets say you have a stats dump every minute, you have the master send the timed dump request it then knows when the response will come and the master are slave are in sync the master can even adjust its timing upon each received message.  If the master never sends this initial dump request then the automated data transmission never starts, it can also turn on and off any feature that way without making the interface screen cluttered with extra settings.

55 minutes ago, AquaticsLive said:

Yep, same here.  One trick I use is using a coil/register message to adjust some of the more detailed settings after communication is established.  So lets say you have a stats dump every minute, you have the master send the timed dump request it then knows when the response will come and the master are slave are in sync the master can even adjust its timing upon each received message.  If the master never sends this initial dump request then the automated data transmission never starts, it can also turn on and off any feature that way without making the interface screen cluttered with extra settings.

So I wasn't necessarily thinking of a MODBUS broadcast--that'd violate the MODBUS protocol specifications for a slave device 😉.

Basically, the hardware comm menu will have a list of "protocols."  At the moment, I just have MODBUS and maybe JSON dump (as the MQTT and local server pass data in JSON format for ease of JS consumption, so it's already generated).  Obviously, a baud rate setting will always apply (as all methodologies will be asynchronous serial, regardless of the actual output drive method [i.e. RS-485 / RS-232, etc]).  If MODBUS is selected, it'll have an ID number option.  And if "JSON Dump" is selected, it'll have an "interval" option.

Ahh I get it.  Makes more sense now.   A different comm method entirely.  Hmm I had taken that wrong completely.  Okay so thinking about it so sort of a raw serial dump.  So in the code you just do something like Serial.println("{JSON DATA HERE}") basically a super raw output.  That would let someone with very little knowledge of the system read the data.

Hey I like that, I know the myself and others wished other vendors would give you some basic com methods.

And if a little string was sent back, it could be interpreted/processed as a command.  Very, very basic.  Easy to connect to a rPI, computer, etc., etc.

Hi Sid,

I asked for info regarding the jk BMS rs485 interface, they said it was point to point only and provided some code. My question & their response:

“3. what is the url for the protocol used over rs485, so I can write code to integrate inverters to your JK balancer or BMS?”
Instructions： https://github.com/NEEY-electronic/JK/tree/JK-BMS

BMS protocol to connect to other devices： https://github.com/syssi/esphome-jk-bms

VenusOS driver： https://github.com/Louisvdw/dbus-serialbattery

I don’t know if you can interface to this via GS 12k

Reading that info looks like its RS485 ready, but doesn't have an actual RS485 chip on it so you would need to use an adapter on the output to take the serial output and convert it with a MAX RS485 adapter to get the A and B output. 

Then on the other end you would use another MAX RS485 adapter board to convert it back to serial data.  They are using a protocol that is similar to Modbus, but really not true Modbus, it will work though just takes a bit more effort.

The doc https://github.com/NEEY-electronic/JK/blob/JK-BMS/BMS-RS485Communication protocol.pdf

Has the info on how to interface with it.  Handy.  One issue is how do you set the ID of the board the doc says its a 4 byte ID I am wondering if there is are some solder pads to set the ID. 

So low dollar way would be to use an Arduino to interface with the inverter and the BMS then once you have figured out how to read the data from both of them you can output the data combined to a web page served up by the Arduino or send the data to a MQTT server like their serial example.

Sounds like a fun integration to write though, I don't have a JK BMS so don't know for sure how well the comm works.  There is a display I believe that plugs into the BMS you could get one of those and then monitor the communication to use as a reference.

On 8/21/2022 at 12:37 AM, AquaticsLive said:

Reading that info looks like its RS485 ready, but doesn't have an actual RS485 chip on it so you would need to use an adapter on the output to take the serial output and convert it with a MAX RS485 adapter to get the A and B output. 

Mostly.  Looks like it's got a regular MCU output on it ("rs232ttl serial port").  Can go to an RS-232, RS-485, or even a CANbus converter.  Note that to use RS-485, you will have to use a significantly more expensive RS-485 chip/module with auto-direction control.  (You can't use just any generic RS-485 module.)

On 8/21/2022 at 12:37 AM, AquaticsLive said:

Then on the other end you would use another MAX RS485 adapter board to convert it back to serial data.

If the goal is a direct connection to an Arduino or something close by, you don't need any converters at all.  For longer distances (or for connecting to a GS inverter), I'd actually recommend using an RS-232 level shifter on the JK BMS.  Lot cheaper and easier to work with than needlessly fighting with RS-485.  (Only place where RS-485 would come in handy was if you wanted to have multiple BMS units on the same wire pair; RS-232 does not support direct paralleling.)

Looked back up the GitHub tree, and noticed that the project description makes numerous references to "RS-485" when talking about TTL-level RS-232 data.  Seems that it's very easy to get confused about these protocols...I have not seen anything about the JK BMS that mentions RS-485.  Like the official PDF says, it uses TTL-level RS-232 as the comm protocol.

In short:

• RX / TX = RS-232
• A / B = RS-485 or CANbus

On 8/21/2022 at 12:37 AM, AquaticsLive said:

They are using a protocol that is similar to Modbus, but really not true Modbus, it will work though just takes a bit more effort.

Agreed, it ain't MODBUS.  (Actually not anything remotely compatible to MODBUS.)  Like the PDF says, "content custom communication format".

On 8/21/2022 at 12:37 AM, AquaticsLive said:

One issue is how do you set the ID of the board the doc says its a 4 byte ID I am wondering if there is are some solder pads to set the ID. 

4-byte ID, or is it?  Got a laugh out of this one...

<img class="ipsImage ipsImage_thumbnailed" data-fileid="1599" data-ratio="30.27" width="958" alt="image.png.4b8f85bf9f477ca551a74f191b0912fd.png" data-src="/monthly_2022_08/image.png.4b8f85bf9f477ca551a74f191b0912fd.png" src="/applications/core/interface/js/spacer.png" />

I don't know about how counting works in Chinese, but that looks awfully a lot like 5 bytes to me......!

As far as the ID number, I seriously doubt it'd be solder jumpers.  Many devices that use a MODBUS protocol (which the JK BMS does not) allow you to run a "write register" command to change the ID number.  I don't see where that is listed in the PDF file...but something of the sort likely is.