I am a long time Classic owner and have finally decided to take a shot at trying to integrate my Classic to the Schneider ComBox (865-1058) . Not to be confused with the Midnight Solar internal project of the same name.
My target is to collect specific Classic parameters over the Classic Serial RJ12 jack and re-present these to Schneider ComBox via its RS485 using Schneider registers and in format , scale , offsets etc that it is comfortable with. In essence Making the Classic look like a friendly Schneider MPPT60.
I am doing this to enhance the LOCAL monitoring and logging via the ComBox that will result if I can get it working .
As of now I have assembled the hardware for this interface and have successfully bench tested the Serial RS232 interface (to Classic) and the RS485 interface (to ComBox) . I am currently crafting the Code and have just completed what I am calling 'Module 1' which is the system Boot and stabilization sequence.
I am just starting to code Module 2 - The classic polling engine.
I am posting to share with this group. I am happy to share progress as I move forward and welcome any questions and especially welcome feedback of any gotchas from other users.
I realize that the ComBox is somewhat old tech but the approach I expect to be scalable / adaptable to other platforms that use RS485 Modbus.
A picture of the Hardware build for this interface . Classic RS232 RJ12 interface on the left , ESP32 H/w Middle , Combox RS485 to Combox on the right. 55.6 milliamps at 9Vdc.
I have been using AI for some of my projects and it is really helpful. Actually more than helpful since it wrote python code I never could have.
If you want , try out google gemini or other AI . Give it all the info you can when you ask your first question and you may be surprised how this could save you a lot of time. If you have the Schneider communications documents , attach that to the question.
I like your hardware build.
You may also want to look into using Home Assistant which can do a lot of getting data , sharing it , automations, etc.
Larry
Thanks for the tip Larry. Is Home Assistant an IP based solution ?
My setup is at a remote off grid location . I am cautious / considerate of any incidental loads including those added by monitoring and management equipment. This build (the box pictured) has a power footprint of 55.6mA @ 9Vdc . I am hoping the 9V power from the Classic RJ12 has enough oomph to power the interface without needing an external source. Until I establish this I am using a 9Vdc wall wort for power. My thinking is that this is a minimum tradeoff in incremental parasitic power load for the functionality gain
This use case emphasis is on LOCAL monitoring. The Schneider Combox also offers data logging. Since the ComBox is already part of the system I don't take an added power hit for this functionality . Using the RS232 to RS485 minimizes outboard power requirements of a IP Router or Internet access point etc when I am not there. When I am , I can power up a local LAN and the ComBox has a nifty UI that I can get at.
In the software design / architecture there is a strong emphasis being placed on unattended reliability, availability and fault tolerance. The software is being developed using an approach where both the Classic polling and translation to Schneider are based on configurable tables (read as user modifiable and easily adjustable) These two files will be kept on a small capacity microSD card that is on the ESP32 board used in this build. By doing it this way, the Classic extraction can be iteratively managed "if" the Classic firmware ever changes or if/when some of the registers that the documentation indicates are "reserved for future use get utilized. This makes the data extraction very scalable.
For translation/ transformation a table is also being used so that the transformaiton side of the interface is also easily maintainable / scalable and ,as a bonus, so that a translation table could be easily deployed to emulate ANY vendors MPPT or management system (in my case a Schneider MPPT60) but it would be equally do-able to create translate libraries for any make of MPPT and this device will allow a Classic to 'emulate ' what is needed for a particular vendor's MPPT or management ecosystem . I've been having fun working on the code and making it 'industrial grade' . A long time ago , in my past life, I had some responsibility for developing solutions used by banking / trading systems / mutual fund industry and stock markets . Am enjoying dusting off some 30 year old engineering cobwebs and having a bit 'o' fun doing it .
I will look in to the Home Assistant suggestion. thanks for that it is appreciated.
The Home Assistant is an operating system so would have to run on a computer of some sort, though they also sell a Home Assistant board that will run it. Do you have internet at your off grid site ?
Now that I have plenty of pv and battery power here at home, I haven't been counting the watts like I used to.
The options for Home Assistant to run on would be a mini pc , a raspberry pi 5 ( with nvme drive is best) or that Home Assistant board which I don't know much about. But you would probably be looking at a lot more power than what you are doing - more like 10 watts at least I think. But the monitoring and control capabilities would be worth it if you ever could get the power to run it.
You can use a program called Tailscale to get secure remote access over the internet without having to open any ports. A bit of geek work.
I just got an esp32 board that has rs485 and canbus ports built in. Something like that might be an option for you .
I looked at your post again and maybe you don't want to have remote access to the site if you aren't running internet unless you are there ?
Here is info from people who use the home assistant with I think the schneider stuff you have. I don't know anything about those. Maybe their info can be of help to you on your project. Also look on github for projects .
https://community.home-assistant.io/t/schneider-electric-solar-tcp-modbus-integration/312604
below is photo of my Home Assistant graphic of solar showing 4 different controllers and two different inverters. Home Assistant is getting data from Classic directly via modbus ip , Hawkes Bay and Rosie via canbus ( to a python program running on a raspberry pi ) from EG4 ( luxpower) inverter via rs485 , and from Victron via its bluetooth and also from ve direct wired connection . My Home Assistant runs on a vm on a mini pc running proxmox. I also have linux mint running on another vm on that if I ever need it. I am sure my power budget for all this monitoring is much higher than you would do since I have a router, mini pc, raspberry pi 3, raspberry pi 5 all messing around with each other in various ways in my power room. Fun hobby keeping it all going !
Larry
Larry , Just a thought but have you considered connecting to the grid to power all gear you use to enable such robust monitoring for your renewable energy system ?? You sure do have a veritable bouillabaisse of equipment. :)
(this was meant to make you chuckle. If it offended in any way I apologize )
Thank you for your great and useful input .
Russ
I am calling this hardware-software project "ClassicBridge".
ClassicBridge is being designed to act as a data broker or translator rather than a one-off solution for just the Schneider Combox. Expect it to be fully shaken out / viability tested using the Schneider Combox as a patient zero as it were.
A few points on the design principles being used as the software is being built. (in 4 distinct modules, System Initialization Module, Classic Polling Module, Translation Module , Target Output Module )
0) Minimum power footprint - goal is less power overhead than the MNGP
1) Adaptability , Maintenance and Scalability : Classic extraction AND Transformation are configuration file driven. To minimize reads from the Classic
2) Separation of Concerns: keeping raw Classic data, translation logic, and ComBox outputs separate. Making it easier to swap or extend any part.
3) As noted ,Table-driven Translation: Using .map files for target-specific logic. I have imagined one .map for Schneider (already created) , one for Victron, one for... anything else. No code changes needed, just a new map.
4) Hardware Resilience: Solidify The RS232/RS485 interfaces and fail-safe mechanisms so the software can stay agnostic about the target — it just reads Classic data and outputs according to the map.
5) Minimal Overhead: The approach will add almost no runtime complexity — the map is just a lookup table applied in memory. The main "extra work" is making sure the map parsing is robust and errors are caught.
6) Scalability: Later, if somebody else wants more registers or a more complicated device, they just make a new .map — the same polling and translation engine handles it. Future-proofing without locking in.
* A note on the failsafe - if for any reason there is an error in any module that renders data unreliable then the destination registers are set to null or default values and we set execute a function that , in the case of the Combox , sets the "Device State " register (#65) to a value of 255 (Data Not Available). This prevent erroneous reporting downstream .
If anyone thinks of anything I missed from a design perspective please let me know as now is the time to think about these things.
Have you seen Grahams projects for the Classic ?
https://github.com/ClassicDIY
Also I posted info on getting classic data via modbus over ip might help ?
https://midniteftp.com/forum/index.php?topic=9687.0
Larry
For the ClassicBridge (Modbus RTU protocol bridge) the software component is now completed and loaded on to my little box. (Pictured in prev post) .
Next step is two isolated tests.
1) physically test the RS485 connection to the ComBox . I have simulation running that will allow the ClassicBridge ,acting as a Modbus slave @ address 30, to publish Classic telemetry to the Schneider Combox.
2) physically test the rs232 connection to the Classic and make sure I have the TX and RX lines correct
I will have to wait a bit to get physical access to my Classic but if anyone reading has any questions please do no t hesitate to ask .
It remains to be seen what or how the Schneider ComBox will react with the Classic data. Fingers crossed
I would like to get all the various controllers I have talking to each other, but in the end it seems easier to just set the one I want as the lead and then stagger the float voltages so they more equally contribute power when the light levels drop in afternoon. I can do the same thing with absorb voltages and absorb times. In my system I have to tweak it all just right since my common bus bar system is not ideal so voltage drops can be different .
Larry
Posting this update for anybody in the future that finds this thread. FINDINGS
Short version: You can't make a third-party MPPT look native to the Schneider Combox—but you can fake a tiny slice of it.
Due to the closed and proprietary nature of Schneider's control and monitoring ecosystem, I've had to adjust my expectations of what the ClassicBridge can achieve in this application.
While it's true that an external (third-party) monitoring system can access published Modbus registers on the Schneider Combox, this is limited to upstream monitoring use cases. In this role, the Combox effectively acts as a Xanbus data aggregator and presents itself as a Modbus slave to the upstream monitor. However, using it this way largely bypasses the Combox's internal performance monitoring capabilities.
Full device identity and integration within the "Combox" ecosystem are strictly limited to Schneider devices. This restriction is enforced through the Xanbus protocol, both in its topology and its device identification payloads. In practical terms, the Combox operates with a mindset of: "If you're not on Xanbus, you don't exist."
There are a few limited exceptions available via the RS485 interface. However, even here Schneider tightly constrains integration through the Modbus "device type" selection in the Combox UI. The user is restricted to a short list of predefined Schneider devices, and the Combox will only poll specific, known registers for whichever device type is selected.
This is essentially a one-way negotiation: the Combox dictates the device identity, the expected register map, and the data it wants—leaving no room for dynamic or custom device integration.
None of the available device types represent an MPPT charge controller. The only option with any PV-related data is the Conext RL, which exposes just three relevant registers.
As a result, I've adapted the ClassicBridge approach to map those three PV-related registers from the Conext RL profile. This represents a scaled-back but still functional integration path. I'll report back once I have results.
Possible Path Forward : The ClassicBridge (device I built pictured prev) is purpose built so that a physical CANBUS interface could be added which is technically compliant with Xanbus at the physical layer. The decomposition of the Xanbus protocol and payload becomes the material variable. For this I would need to capture and analize the first 30seconds of traffic with an actual MPPT60 in a Schneider environment. Using this analysis I believe it possible to replicate the handshake and have a ClassicBridge take Classic Charge controller inputs and emulate a Schneider MPPT to the Schneider Combox for the purpose of monitoring it using Schneiders UI. Unfortunately I have no immediate access to acquire this payload for analysis . If anybody can help with this please reach out .