Does Rosie support 3rd party BMS yet?

[HIT99]

Does the latest Release of Rosie (24.12.16) and MNGP2 (24.12.10) support 3rd party BMSs which use the pylontech protocol?

I was able to get Solar-Assistant talking to a RUiXU battery and Rosie (one at a time) using the same CAN cable. I only connected the CAN Bus pair to the RJ45 (pin 4/5) connector as per other threads on the forum.
When I connected Rosie to the battery I got garbage voltage values and alarms etc. I did not have CAN Bus errors.

I didn't try very hard and abandoned the experiment for now.

[aaapilot]

Does the latest Release of Rosie (24.12.16) and MNGP2 (24.12.10) support 3rd party BMSs which use the pylontech protocol?

I was able to get Solar-Assistant talking to a RUiXU battery and Rosie (one at a time) using the same CAN cable. I only connected the CAN Bus pair to the RJ45 (pin 4/5) connector as per other threads on the forum.
When I connected Rosie to the battery I got garbage voltage values and alarms etc. I did not have CAN Bus errors.

I didn't try very hard and abandoned the experiment for now.

These are not the latest PRODUCTION firmware releases for Rosie or MNGP2.  Rosie is on 25.02.13.00 and MNGP2 is 25.03.27.00. You might want to update both pieces of hardware and try again.  My Pytes V5 battery BMS uses Pylontech and works fine w/Rosie and Solar Assistant Open Loop. Haven't used closed loop.  Good luck w/your install and let us know if the RUiXU battery works.  Are you using the rack mount 5kw or the larger floor mount version?

Dave

[HIT99]

Thank you. I was monitoring the "Firmware update versions" thread above - and didnt notice anything.

I have the server rack style battery. The wall/floor mount style are too heavy to get to my site as there is a small boat involved.

Anyway I updated the FW and briefly tested. No real change. I do see a BMS page appear on the MNGP2 - so some pylontech message must have been recognized. The data is garbage eg Temp -26C.
Time to double check the cabling. Crossover or one leg floating or something.  Although I would have expected CAN bus errors in the MNGP2 stats. The line is terminated using the Midnite supplied terminator at one end and the CAN-USB adapter on the other end.

I did capture CAN Bus messages from the battery and Midnite before trying to connect them. Initially just checking messages were flowing at the same bitrate (500kbps) and no obvious low level CAN Bus errors.
I tried to capture the session between the Midnite and RUiXU. I am not sure if I was successful as there was a lot of messages and i didnt have filters set. I disconnected quickly - i didn't want to mess around too much when the system is in "distress".
I didnt see CAN Bus errors in the MNGP2 stats or on the capture program.

I manually decoded (partially) the pylontech messages captured from the RUiXU battery. Seemed to make sense. So there is hope despite the fact  exercise is a little futile in my case. My Solar Charge controller is open-loop only - a new one is on my Wishlist. I don't use the generator very often and only on the rare occasion will i use it to fully charge the battery - and it's probably to sync the whizbang.
It would be nice to see the SoC from the battery on the MNGP2.
Being able to sync the whizbang SoC to the BMS would be a "nice to have" feature.

I will double check the cables this weekend.At the moment I do not have the ground wire connected on the Midnite side. I only have the CAN pair wired (theoretically) to pins 4/5.

Sample of "decoded" pylontech messages from a RUiXU battery

Battery Voltage/Current Limits
0x00000351          8                   2c 02 68 10 70 17 e0 01
                                        55.6V 420A  600A  48

SOC/SOH
0x00000355          8                   58 00 64 00 60 22 00 00
                                        88%   100%

Voltage/Current/Temp
0x00000356          8                   c0 14 ed ff e4 00 00 00
                                        53.12V -1.9A  22.8C

Protection/Alarm
0x00000359          8                   00 00 00 00 06 00 00 00

Battery Charge/Request
0x0000035c          8                   c0 00 00 00 00 00 00 00

Batt Mfg/Model
0x0000035e          8                   52 58 34 38 31 30 30 48
                                         R  X   4  8  1  0  0 H

[ClassicCrazy]

I had trouble getting my pace bms to communicate properly with the Hawkes Bay. But then instead of Pylontec protocol I tried Luxpower and everything filled in perfectly on the Hawkes Bay. That is probably due to something on the pace bms side. But it wouldn't hurt to experiment with trying different bms inverter output protocols if you can change them with a program on your bms.

[HIT99]

Well I was happy and excited for a little while.

I changed the protocol to Luxpower on the RUiXU Battery. I just powered up the first battery - I got tired of powering the whole rack up and down.

I turned on the battery breaker on Rosie and it worked. BMS Battery Status and BMS Battery State of Health pages populated and made sense.

I shut everything down and closed up the Rosie Front Panel. Started everything up - didn't work- garbage on the BMS pages and Rosie and battery indicating a fault. So I shut everything down.

Turns out it only works with one battery whether Pylontech or Luxpower protocol was selected on the battery.

I captured the startup with the system working with one battery (Luxpower) and with it not working with two batteries.
I will look at it sometime- for what it's worth.

I have really just scratched the surface of this BMS protocol stuff - based on snippets on the internet - so I don't know much. But as a former telecom/datacom engineer I find what I have seen is a little sketchy. There doesn't seem to be much in the way of data integrity checks beyond what CAN provides. It doesn't look like it is easy for piece of equipment to easily validate the data (garbage,stale, which protocol, which version etc) before acting on it.
Hopefully I am wrong- there is hundreds of pounds of volatile material at the end of the wire!

[aaapilot]

If it works with one battery, then it doesn't sound like a protocol issue.  Perhaps the cabling from one battery to the next is the issue.  On my Pytes, the interconnecting cables must connect to a certain input port and output port.  Also, the interconnecting cables between batteries, did you make those yourself or were they supplied by the manufacturer?

Dave

[HIT99]

The inter battery cables came from the mfg.
They have an in and out ports - the same as your batteries.
Mine one above the other. A bit harder to mess up.

For my experiment today I had the Midnite connected to the top port of the top (master) battery and the sniffer on the bottom port of the last battery.

The sniffer sees the packet stream through all the batteries whether they are on or off. Solar assistant also works if connected where I have the sniffer.

I am thinking there is something different about when the first battery is a master. This is only if there are more than one battery. The master is supposed to talk on everyone's behalf. The message that contains the max charge current does go up by 70Amps per battery which is correct.

Things go wrong only after the MNGP2 finishes booting and transitions to the status screen.

There are some (extended) CAN frames which I don't know what they mean. I think there are more of them if there are more batteries. Maybe something like that is upsetting Rosie/MNGP2.

I am still trying to compare the working "one battery" vs broken "two battery" message captures.

Hopefully not a slave battery talking when it shouldn't.

I didn't try all the available protocols- I got too carried away when Lux appeared to work.

I did capture the battery output of most the protocols without Midnite attached. They all seem to have a lot in common.

Thanks for the suggestions. It has helped.

[Brucey]

The line is terminated using the Midnite supplied terminator at one end and the CAN-USB adapter on the other end.

My understanding is the battery will terminate the canbus chain on its end, not sure if your connection method is allowing that.

Try going from your usb to can adaptor to the mngp2, then to rosie, then out to battery. No terminators.

[ClassicCrazy]

I tried to understand how all the Canbus bms to inverter communications worked. It was difficult to impossible since nothing anywhere seems to be documented. And every device out there seems to work differently in their approach to which parts of the communicated data they use.
I ended up giving up on closed loop. One my system I have different controller going to the same batteries. I have an EG4 6000XP which really sucks for off grid with little way to set the pv charging. You look at the other inputs from grid or generator they have all kinds of parameters to set , but for closed loop you are at the mercy of whatever the bms is communicating to it. It would charge up , then drop down to a float level, and an hour or two later charge back up to again , etc. And they say you can use Lead Acid mode but that does not have an Absorb time so it sometimes does the same sort of thing. I only got that EG4 because at the time it was a good bang for the buck to get a 240v inverter ( plus the two mppt inputs I thought ).
The Hawkes Bay sort of works okay in regular charge mode but shuts down charging much earlier in day than the other controllers. It always seemed problematic in closed loop but that seemed to be with the bms inverter protocol ( until I figured out the Luxpower mode worked best ). But I gave up on it due to no monitoring software and I didn't want to get the Solar Assistant. I have been using Home Assistant more and more and it works good. I had everything talking with the Home Assistant , the eg4  and my old Classic too. I ended up putting a victron smart shunt on my system because it worked independently and super easy to integrate into Home Assistant via bluetooth. It seems very accurate. I ended up getting a Victron 450v 100 amp charge controller , and that also integrated into Home Assistant easily via bluetooth. It works perfectly in the lead acid mode because you can set up the absorb time and float and the other controllers don't affect how it works at all. So my two best controllers for being spot on doing what I want are the Classic and the Victron . The Hawkes Bay has always been too frustrating to me because of the lack of a monitoring software.
I never tried to closed loop to the Victron because I think another $200 victron box might be needed to do that and not worth it to me at this point. Winter project to see if there is some other way to get bms to talk to it directly.
Off Grid Garage on Youtube has the most information on  how those bms work in closed loop but there are so many videos he has produced that it would take some time to find the one that gives the info on that.
I think the way the bms is supposed to work is send info to the controller or inverter such as voltage, highest and lowest cells voltages, and some of the bms setpoints, battery capacity, etc. But which info and how each controller uses that info is a bit of a mystery.
I think it is all just at the mercy of what ever someone programmed into the controller brains and if they knew what they were doing or ever tested it out .
Larry

[Brucey]

Yeah I just run open loop, no problems with a 450/100, 250/100, two 150/35s and hawkes bay 90 working together 55.2V and 54.4V float.

I'm in the process of adding a smartshunt to the hb so I can see it as a pv charger in VRM. With victron energy meter going on the Rosie so I can track that as well (versus just seeing them both as a combined dc load) by selecting "has dc system" in my cerbo

[ClassicCrazy]

Does the latest Release of Rosie (24.12.16) and MNGP2 (24.12.10) support 3rd party BMSs which use the pylontech protocol?

I was able to get Solar-Assistant talking to a RUiXU battery and Rosie (one at a time) using the same CAN cable. I only connected the CAN Bus pair to the RJ45 (pin 4/5) connector as per other threads on the forum.
When I connected Rosie to the battery I got garbage voltage values and alarms etc. I did not have CAN Bus errors.

I didn't try very hard and abandoned the experiment for now.

This doesn't answer any of your issues , but in case you ever want to tinker  -here is a project that uses an esp32 with  canbus board and will convert data from a Victron Smart shunt into outputting as a Pylontech bms . I started this project last winter and got part of it working but not the canbus part to my Hawkes Bay.  I see they recently updated the project to just use one Lilygo esp32 board that has a built in canbus and rs485 port on it. https://github.com/sijones/DiyBatteryBMS?tab=readme-ov-file

Larry

[HIT99]

Because I don't seem to know when to give up - I decided to do another experimenent to try and debug the issue I have with MNRosie
and RUiXU integration.

I captured the CAN Bus data from the time the first (master) battery is turned on to when Rosie wakes up.
I had a voltmeter monitor the voltage on the battery cabinet bus bars.

The system was entirely shutdown. I have the Rosie FP switch installed and turned off so Rosie Inverter is off.There is no AC input (generator) or DC input (Solar Charge Controller).
The only load is the BMS, SPD, Rosie (with inverter off), MNGP2.

I wrote a crude parser script to process the captured CAN frames. The BMS sends a set of frames about every 700ms. The script scans the captured data to find the set of BMS frames which maybe interleaved with midnite CAN frames. Each set of frames gets decoded and written out as a row in a CSV (spreadsheet) file. I don't have a description for all the frames -but the ones that I do have information such as battery charge settings, Battery voltage, current, temperature, Alarms, #of batteries in parallel and more.
I also look for a frame id associated with the Rosie. I don't know what it means - but i used to to determin if Rosie is on the CAN Bus.


I then used a spreadsheet to plot some of the data which makes it easy to spot the abnomalies. My script is not very robust and a few rows the were a bit messed up when slave batterries were turned on. It was easier to delete those rows from spreadsheet than trying to improve the script.

Disclaimer - my knowledge of the BMS protocols is very limited and based on snippets of information out on the internet which may not be accurate for  the equipment in question.

What I found was that the BMS starts sending High/Low voltage data the moment Rosie is alive and connected to the CAN Bus.
The BMS messages return to normal as soon as the CAN cable to Rosie is disconnected.  The BMS sends bad data as soon as the cable is reconnected. The BMS data matches the MNGP2
The multimeter didnt show any battery voltage changes.
The were no CAN Bus errors detected by the capture program or recorded in the MNGP2 stats.
The BMS data is not random garbage. Voltage measurement data and Alarm data are in different messages and match.
Most of the messages that contain static data  - such as the number of battery packs in parallel or model number do not change.

The question is whether the bad interaction between Rosie and the Battery BMS is digital in nature such as a bad (misinterpretted) messages -  if there is some electrical interference (noise,ground loop, other) messing up the BMS measurement system.
The system seemed to work with a single battery pack -  using all the same cabling - which may contradict that line of inquiry.
Not sure if Rosie is trying to turn on its charger without AC input.
The system basically has no load - I havent been brave enough to turn on the inverter or have the inverter automatically startup on powerup.

So it is still a mystery.

Charts attached

Below are just more about the same stuff in more detail details about the setup, procedure etc.



**************************************************************************************************


=========================================
Setup
==========================================

CAN BUS:
-------

[LAPTOP]<->[USB-CAN]<-->[Battery Pack 5]<-->[Battery Pack 4] .. [Battery Pack 0]<-->[Rosie]<-->[MNGP2]<-->[teminator]

CAN cable between battery <---> sniffer and battery <--> Rosie only have pins 4 & 5 (CAT-H CAT-L) connected on both ends.
The sniffer is able to observe/capture CAN traffic whether or not the slave Batteries or powered up.


USB-CAN Adapter: Waveshare
                https://www.waveshare.com/product/iot-communication/wired-comm-converter/usb-to-rs232-uart-rs485/usb-can-a.htm
Capture SW    : WaveShare USB-CAN-A_TOOL_2.12
               


DC Load/Wiring:
---------------
[BATTERY] -> [T-Class Fuse] -------> [E-Panel Breaker/Disconnect] -> [Rosie] -> [MNGP2]
          \_[Fluke Multimeter]  \__[SPD 115]

The only DC loads in the test setup are BMS, SPD LED, Rosie (brains) and MNGP2. The inverter is off (FP Switch), Charger is off (MNGP2 menu)


Rosie E-Panel Breakers:
------------------------

BATTERY:    OFF
AC BYPASS:  Bypass
AC IN:      OFF (Generator OFF and Disconnected)
DC Breaker OFF:  (Solar Charge Controller powered down)
PV Breaker OFF:

Rosie Inverter:   
FW:  Rosie 25.2.13  ROSIE MNGP2 25.3.27
FP Switch OFF. (Inverter OFF on powerup)
MNGP2 Setup-Inverter-AC Input: [Generator Mode] [Charger OFF]
MNGP2 Setup-Inverter-Grid Tie: [Disabled]
MNGP2 Setup-Inverter-AC Input Ctrl: [Disabled]


Battery:

Mfg:    RUiXU
Model:  RX48100H  (Server Rack)
FW:    LD12
Packs:  6

Master DIPSwitch:  1-5 OFF 6-ON 7-ON. (Protocol ID 4 - LUX Power).  Used in the data collection experiment
                    1-5 OFF 6-ON 7-OFF.(Protocol ID 2 Pylontech).    Used initially. Same result.


========================================================================================
Experiment Procedure
========================================================================================


- Entire system shutdown.
- Start the CAN Sniffer/Capture program.
- Connect a DC Multimeter to the Rack Bus Bars.
- Turn on the First battery  (protocol was set to LUX)
- wait 1 min
- Verify the multimeter reading
- Turn on Slave 1
- wait 1 min
- Repeat until all packs are on. verify 1 master.
- Turn On E-Panel Disconnect
- Wait for the MNGP2 to boot.
- Change to battery status page.
- Verify the multimeter reading is good even though MNGP2 is bad.
- Disconnect CAN Cable to Rosie
- wait a bit - verify everythis is ok.
- Attempt reconnecting CAN cable to rosie.
- Disconnect can cable.
- Turn Off E-Panel Disconnect
- Shut the system down.

========================================================================================
Processing The data:
========================================================================================

The battery transmits a set of frames about envery 700ms. There are 6 Standard CAN frames
which are defined in the snippets of Pylontech documents.
There are a further 9 Extended CAN Frames for which i have not found and documentation.

My primitive parser script searches for the first known frame ID in the set and starts
populating a record with the decoded data and subsequent known frames. After the last known
frame in the set is processed - the record is written out as a line to a CSV (spreadsheet)
file. If a Midnite frame is detected - then the Midnite is assumed to be active.

The resulting CSV files was imported into a spreadsheet. A few charts were created:
- Voltage and Current vs Frame Count (Used to see the bad data. Confirm that the BMS is actually sending highlow voltage)
- Max Charge Current vs Frame Count. (Used to identify the battery packs coming online - and sanity.)
- Number of Batteries in Parallel vs Frame Count (Used to identify the battery packs coming online. - and sanity)
- Midnite Message Detected vs Frame Count. (Used to correlate bad voltage data with Midnite traffic)
- Midnite Message Detected vs Time Stamp. (useful to correlate frame count to time)

Using the approx frameid in the plots can be used to find the corresponding data in the spreadsheet table which contains
other fields such as alarms etc.

The batteries send CAN bus frames for a few seconds before they figure out that they are slaves. This messes up my basic
parser logic and some rows in the spreadsheet had missing columns. Instead of modifying my script to be more robust i just
deleted most the offending rows which were easy to identify as they messed up the charts.


========================================================================================
Obervation:
========================================================================================

- LED on the SPD turns on when the master battery is turned on. Not really a surprise.
  I am assuming this tiny draw doesnt prematurely trigger a precharge cycle which ends before the inverter breaker is closed.
- Multimeter Voltage reading was stable. The data i collected suggests the voltage abnomaly lasts for seconds at a time.
  I didn't think about setting it to capture
  min/max or trying and see if there was any AC noise.
- The BMS of slave batteries sends messages onto the bus for a few seconds when they turn on. The data is
  essentially zeroed out. These messages would be interleaved with the master. So the inverter may see voltage
  bounce between 0 and real value. I am not sure if other BMSs behave this way. Thies can be avoided by a
  managed  iniial startup - waiting for the system to stabilize before turing on the inverter.
- The  BMS does send High/Low Voltage shortly after  the Rosie/MNGP2 becomes active. This is the most serious problem.
  The Multimeter does not see the voltage swings.
  The bad data sent by the BMS is is well formed messages along with the corresponging alarms in other messages.
  In other words the "bad" data is being intentenionly transmitted and is not random garbage in random messages.
  The "static" cofiguration type data seems to remain or sane - with one exception - The Max Charge Current Limit.
  The Charge current Limit can be 0 under abnormal conditions which probably makes sense - but it can be a high nonsense
  value too. The charge voltage field in the same message remains correct.

  So it does not appear to be the result of transmission errors or a program thats gone nuts. There are no CAN bus errors
  reported by the sniffer or the MNGP2.
- The BMS reverts to sending normal data as soon as the CAN Bus cable to the inverter is disconnected.
  The BMS start sending bad voltage data as soon as the inverter cable is reinserted.
- The system behaves with one battery pack - which uses all the same CAN cabling.
  I have done this twice for a short period.

[ClassicCrazy]

Hit99 - you may want to post your testing results to DIY Solar forums on the lithium or bms topics since there are a lot more people who may have the experience or geek skills with the data you found.
https://diysolarforum.com/
Larry

[HIT99]

Will do.