BBMT proof of concept

[Barry Fields]

I would like to commit to doing proof of concept for the proposed BBMT (Barrys Better Mouse Trap).

I would concentrate on the following in the order listed below:
                                 
1. Add waste-not PWM              Classic series w/ WizBang & MNMPPT60DIY   & look alikes

2. Add Endamps capability    MNMPPT60DIY & look alikes

3. Better Load Management    All of them

4. Add FLOAT Controlled ABSORB   All of them
               
5. Add Multibank Health Monitor   All of them
   
My initial thought is to use an Arduino R4.

1. As I am new to C++ , I did write a large Dbase3 program 30 years ago, but this old dog will need the apparently vast help available for the Arduino. I feel the Raspberry PI would be over my head for now.

2. The R4 can do  Modbus, SPI, Wi-fi, Bluetooth, USB and SD card (for history data)

3. By using hardware, whatever "fast" tasks I would implement would leave the R4 would be handling mostly communication for small data/read writes and I/0 with some minor data manipulation.

4. Most of the data I/0 requests would be in the time frame of minutes.

I would start by asking if any of you would assist in this endeavor.  I am willing to invest in an R4 kit. I already have the ability of creating hardware or incorporating existing modules.  I have a copy of the Classic 150 register map and believe I have found the registers I would need to use.

The BIG problem I have is I do not have a Midnight Controller.  I do have a "look alike" MNMPPT60DIY (Renogy Rover 60A).  I contacted Renogy, but they will not share their register map.  I did find a partial register listing for their BT-1 module. If Midnite's MNMPPT60DIY uses the BT-1, it probable that Midnite has a registry map with the information I would need.

I am certainly open to any comments, suggestions or help you might offer.

Thanks Barry

PS I have attached a preliminary outline.

[ClassicCrazy]

Without boB around any longer I doubt you will find any takers to help you with these kind of things.
I certainly am not up to that level you often talk about.
But what I did do recently was discover and alternative instead of me spending hours reading documents and watching how to videos for getting some data out of my home assistant which I just started to use. 
I just asked ChatGpt to write the code and it did it in less than a minute and explained to me where in home assistant to put it. There was an error in something but I just asked it to fix the format and then the code it made worked.
I am going to try to use chatgpt more now to make things work around here. My brain gets woozy trying to take in all the info other ways and figure it out, so if chatgpt can tell me in one minute what to do - I will take that !
So if you need coding or other  help - ask the chatgpt or other AI and maybe it can help you in your endeavors too. It isn't always right but worked for me.
You can just attach the classic modbus document and ask it to do write your program and see how it works.
It might help you with your hardware design too.
Contact Midnite about getting a Classic - they might have a return repaired one they can sell you for your experiments. 
Larry

[ClassicCrazy]

Look here and you will probably find the modbus or communications info you want for your Renogy Rover
https://github.com/ElD4n1/home-assistant-renogy-rover-integration
actually this one has the modbus info
https://github.com/corbinbs/solarshed/blob/e63d2031e50d41015dd67e48154f4dd2cba1c9cb/solarshed/controllers/renogy_rover.py
Larry

[Barry Fields]

Larry,

Thanks for the reply. Me thinks I might depend on you for some real world experience.

Would I be correct that Battery temperature is not going to change significantly in less than 5 minutes?
If true, sampling the Battery charging set-point voltage any more often than 5 minutes would be a waste of CPU time.

Thanks again
Barry

[ClassicCrazy]

Yes the battery temperature isn't going to change too quickly.
Of course that depends on if they are outside with no insulation on them. But still would take more than 5 minutes . Batteries are heavy and have a lot of mass to hold heat so will take some time to cool down , even if the temperature was to drop quite a bit very suddenly.
Larry

[ClassicCrazy]

I asked my new chatgpt friend if it had any suggestions for your project - see below

Thank you for sharing the block diagram! Let me review the structure to better assist you. Based on your description earlier and the block diagram, it seems you've laid out a functional architecture for interfacing the Arduino R4 with the charge controller and other peripherals.
Key Observations from the Block Diagram:

    Inputs:
        Data coming from the charge controller via Modbus (or other protocols).
        Sensors (likely for voltage, current, or temperature measurements).
        Timer or manual overrides for Absorb and Float stages.

    Processing Unit:
        Centralized on the Arduino R4.
        Responsible for logic processing, communication management, and hardware control.

    Outputs:
        Feedback to relays for load control.
        Data logging and monitoring via SD card and possibly Wi-Fi or Bluetooth.
        Potential expansion for PC or mobile interface visualization.

    Core Functionalities:
        Dynamic switching between Absorb and Float modes.
        Monitoring and logging critical metrics (via SD card).
        Load management and other features to optimize battery health and system performance.

Suggestions and Clarifications:

    Communication Protocol:
        Ensure Modbus RTU or another protocol is correctly interfaced with the Arduino using a UART or RS485 module.
        Confirm the register mappings for the charge controller to access desired parameters (voltage, current, state, etc.).

    Modular Approach:
        Break down the software into smaller components for each feature (e.g., PWM control, endamps, load management).
        Design the logic for each stage (Absorb, Float, Load) as distinct modules to enable easier debugging and enhancement.

    Data Handling:
        SD card logging is crucial for storing historical data. Make sure you also timestamp the entries for later analysis.
        Consider adding Bluetooth or Wi-Fi support for real-time data monitoring and system status updates.

    Load Control:
        Ensure load management relays are designed to handle the system's power requirements.
        Use optoisolators or MOSFET drivers for efficient and safe control.

    Hardware Integration:
        Verify compatibility between the Arduino and all external modules (e.g., RS485 transceiver, SD card module, sensors).
        Ensure proper isolation to protect the Arduino from high-current or high-voltage lines.

Would you like help designing the software architecture for this system or assistance with implementing specific features like Modbus communication or PWM control?

[ClassicCrazy]

Barry - the midnite diy modbus info is on website
https://www.midnitesolar.com/firmware.php?firmwareProduct_ID=7

[ClassicCrazy]

Thank you for providing the Modbus register map for the MidNite Classic. Based on the document, we can design software to interface with this device using the Modbus protocol.

Here's how we can structure the software design:
Software Design for MidNite Classic Modbus Communication
Objective

Develop software that communicates with the MidNite Classic controller via the Modbus protocol to read and write data, monitor device status, and control settings.
Key Features

    Modbus RTU/TCP Communication
        Support both RTU (serial) and TCP (network) communication modes for flexibility.

    Register Access
        Implement methods to read and write to the Modbus registers as defined in the provided document.

    Data Interpretation
        Parse raw register values into meaningful units (e.g., current, voltage, power).

    Error Handling
        Detect and handle errors such as communication timeouts or invalid responses.

    User Interface
        Provide a command-line or graphical interface for users to interact with the software.

    Data Logging
        Log readings to a file or database for historical analysis.

Software Architecture

    Modbus Driver Layer
        Low-level communication using a library like PyModbus (Python) or libmodbus (C/C++).
        Handles read/write requests and CRC error-checking.

    MidNite Classic Interface
        Functions corresponding to key registers (e.g., PV voltage, battery voltage, status codes).
        Map register addresses to human-readable identifiers.

    Application Layer
        User-friendly interface (CLI/GUI).
        Data visualization and control settings.

    Logging and Storage
        Store readings in JSON, CSV, or database formats.
        Include timestamped records for analysis.

Steps for Implementation

    Modbus Communication Setup
        Identify connection type (RS-232/RS-485 for RTU or Ethernet for TCP).
        Configure parameters (baud rate, parity, stop bits, Modbus ID, etc.).

    Register Map Parsing
        Create a dictionary or database of register addresses and descriptions from the provided document.

    Develop Read/Write Functions
        Implement functions to:
            Read multiple registers.
            Write single or multiple registers.

    Handle Specific Data Points
        Examples from the document:
            Read PV Input Voltage (Register 4101, scaled by 10).
            Read Battery Voltage (Register 4115, scaled by 10).
            Set Charge Limit Current (Register 4118).

    Error Management
        Retry on timeout.
        Validate response length and CRC.

    Interface Design
        CLI: Commands like read_voltage, write_current_limit, etc.
        GUI: Display key metrics with options for setting parameters.

    Testing and Debugging
        Simulate Modbus devices if hardware is unavailable.
        Validate against the MidNite Classic device.

Sample Python Code (Using PyModbus)

from pymodbus.client.sync import ModbusSerialClient

# Modbus client setup
client = ModbusSerialClient(
    method='rtu',
    port='/dev/ttyUSB0',
    baudrate=9600,
    parity='N',
    stopbits=1,
    bytesize=8,
    timeout=1
)

if client.connect():
    print("Connected to Modbus device")
   
    # Example: Read Battery Voltage (Register 4115, scale by 10)
    address = 4115 - 40001  # Convert to zero-based address
    response = client.read_holding_registers(address, count=1, unit=1)

    if not response.isError():
        raw_value = response.registers[0]
        battery_voltage = raw_value / 10.0
        print(f"Battery Voltage: {battery_voltage} V")
    else:
        print("Error reading register")
   
    client.close()
else:
    print("Failed to connect")

Next Steps

    Confirm the communication parameters (Modbus ID, baud rate, etc.).
    Identify the critical registers you wish to monitor or control.
    Let me know if you need help refining the software design or implementation!

Would you like me to expand on any specific part of the design or help with code examples for additional features?

[Wizbandit]

Barry, Ever heard the phrase "why reinvent the wheel" ?

Even since the MNCOMBOX project was cancelled due to lack of personnel and company resources I have continued working on Python code for myself on my time. I am almost finished porting the code from the SBC used in the MNCOMBOX to a Raspberry Pi 3B+.  The SBC used in the MNCOMBOX was slightly under powered and with no vent it runs hot and overheats.

I have code "engines" all done for:
Classic
Hawkes Bay
Barcelona
Rosie
MN-ONE10K AIO Inverter
PowerFlow5 Lithium battery BMS
OLED Display
LCD 4x20 Displays

And somewhere in my development archives proto-type engines for the MNDIY-60, MNDIY3024, MNDIY3548 and MNDIY5048.

The Classic Engine only supports TCPIP but I may get ambitious and port it over to Serial MODBUS aka MODBUS RTU. One prototype engine I need to finish is the Classic to MNCANBUS engine that allows the Classic as a device to be controlled on the new MNCANBUS which all the new products use as their communication protocol.

[Barry Fields]

Thanks to both of you for your input. 

Larry - Really good info. I have been able to glean most of the registry data required (except my Renogy).  I would say that I (semi-survivalist) try to avoid anything cloud based or otherwise internet dependent. I want this stuff to work after Armageddon.

Wizbandit - Would I be correct to say that the MNCOMBOX was intended to organize and  display each units existing data and functionality? Admiral goal to say the least.  Looks like you have an excellent handle on that goal.  Sorry it got yanked.

What I am proposing is to add functionality and data that does not presently exist.

Seems to me that both concepts could work together well.

Thanks again
Barry

[Barry Fields]

I sent an email to Renogy today asking if they might share some specific registers I cannot find.

The ones I have found are (source documents attached)



REGISTERS NEEDED      Classic            MidniteDYI         Renogy
BATVraw           R        4276                                         E101H
BATVTarget      R        4244
ABSSetpoint     R        4149                                          E008H
FLTSetpoint      R        4150                                          E009H
ABSTime        R/W      4154                                          E012H
PWMWidth      R        4169
PWMOffset        R      4176 or 4177
FORCEBulk        W      4160 value 20
TIMESTAMP       R      4256-1   ??
ABSState            R      4120-1 highbit 3                         E0120H lowb4
FLTState             R       4120-1 highbit 5 or6                  E0120H lowbit5
TEMPcomp        R                                                         E014H      

WIZBANDIT,
Would you be so kind to see if there might be some agreement between the MNMPPT60DIY the Renogy Rover 60A.
I could pay you by mail but you would have to watch carefully for it. 
Thanks Barry   

[Wizbandit]

Here is the OEM document.
FYI BOOST = ABSORB
BOOST RECOVERY = REBULK

[Barry Fields]

Thank you so much!
looks like the ROVER60 and the MNMPPT60DIY are indeed the same.

One parameter I am unsure of is the temp compensated Battery target charging voltage. Is there one or would I have to recalculate that from Setpoint and Temp comp and Bat temp.

Also, if I want to communicate from a Win10 PC, would "QMODMASTER" be a good choice?

Thanks so much
Barry

[ClassicCrazy]

Also, if I want to communicate from a Win10 PC, would "QMODMASTER" be a good choice?

Thanks so much
Barry

Take a look at this modbus tool
https://github.com/ClassicDIY/ModbusTool

Larry

[Barry Fields]

I have contacted RENOGY in the quest for accurate needed registers. So far so good, they seem willing to help.
I have attached below a preliminary plan for FLOATcurrent controlled ABSORB time.  I hope ya'll kind find if I have any errors.