When the battery reserve hits 20%, the inverter cuts discharge and switches to paid grid power. This happens around 2:00 AM. From that point on, I'm paying. And when the sun comes up, the inverter insists on recharging a buffer before releasing energy back to the house. So the grid bill keeps running until 7 or 8 AM with panels already producing above me. That's not a technical limitation. That's a delivery gap in the system's logic.

The manual workaround was simple: if tomorrow's forecast looked strong, I'd wake up at 5:00 AM and override the reserve limit to 0%, forcing the battery to drain just enough to meet sunrise perfectly. It made a noticeable difference on the bill. But one bad call on a cloudy day meant zero battery, and if the grid went down, zero house. The risk tolerance was unsustainable without automation.

So I built the brain.

The goal was a predictive engine that could make that call autonomously: is tomorrow's solar production reliable enough to justify releasing the reserve? Yes or no, with real data behind it.

The first approach used NASA irradiance data. Failed immediately. Timezone misalignment between UTC and my local zone made the solar curve completely unusable. Migrated to Open-Meteo and built an astrophysical filter that zeroed out below-horizon hours mathematically.

The second approach used Meta's Prophet model trained on months of my own production data. Also failed. I had recently doubled my panel capacity with a second inverter, and Prophet kept averaging against the old baseline. My system was producing 6,000W and the model stubbornly forecasted 2,000W. It couldn't adapt to an infrastructure change, which is a familiar problem for anyone managing environments that evolve faster than the models tracking them.

I'll be honest, I shelved the project for a while. Bought more batteries as a brute-force fix to survive the night. But the operational inefficiency kept nagging at me, so I came back to finish it right.

The solution was to abandon statistics entirely and build a physical scaling engine. Instead of training a model on historical averages, the system reads the last 7 days of real panel output to detect proven peak capacity, extracts thermal efficiency against the climate ceiling, and discounts tomorrow's cloud cover from the forecast API. Physics over pattern-matching. No training set, no hyperparameters. The model calibrates itself every night.

The output is a triple-curve forecast generated nightly: actual production (orange), ideal clear-sky potential (dotted bell), and a realistic prediction adjusted for every cloud in tomorrow's weather model (blue). The accuracy has been remarkably precise.

The decision engine is already built and tested. It doesn't run on a simple timer. It calculates three variables in real time: current household consumption, remaining battery capacity, and the scheduled sunrise hour. If the stored energy is enough to bridge that gap, it sends the release command. If not, it holds. A decision engine, not an alarm clock. I've been validating it by pushing automated Telegram notifications every time the system triggers a decision, and it works 

The only remaining piece is the Solar Assistant integration to execute the actual inverter parameter change automatically. Once that connection is live, the entire cycle runs without human intervention.

Beyond my specific use case, this opens the door to something bigger: automatically deciding when to consume battery and when to hold it, so you either pay less or use 100% of your installed capacity instead of letting the inverter's conservative defaults leave energy on the table.

I'm sharing the repo here. The README covers everything, and getting started is straightforward: just upload your inverter data. I left my own export files in as examples so you can see the expected format.

<a class="underline underline underline-offset-2 decoration-1 decoration-current/40 hover:decoration-current focus:decoration-current" href=" removed link "> removed link

Contributions welcome.

See connections g. Note that connections (CT1/CT2) that you talk about are typically reserved for external current transformers. Also in your case COM1 and COM2 are relay connections to start a generator and not RS485. I'm thinking that in the case of the 12000XP. The only RS485 is through the battery connection and the WiFi dongle. I believe in my case, the RS485 is shared with the WiFi dongle connection where as the battery connection is separate (but I would need to measure it. You may be able to use the WiFi connection and make either a break out cable with a HDMI connector on it or you could follow that connection back to the board that it connects to internally. In my case, I'm connecting the RS485 to a RS485 to Ethernet adapter like this -

I then set it up for Modbus communications and use Home assistant EG4 inverter Modbus for communications.

I'm not sure what is communicated through the 12000XP dongles RS485 port but you could try it.

I did look some more and see the following - 

• Port Location: Most users connect to the RJ45 port (often labeled for the Wi-Fi dongle or CT1/CT2) inside the inverter's wiring compartment.
• Pin Configuration: For custom cables, the standard pinout for RS485 communication on this unit is typically Pin 7 (RS485B) and Pin 8 (RS485A).

With a DVM, my RS485 signals measure +2.5V to ground. Of course this has the digital signal on it. The dongles cable inside my unit has 4 wires, of which the black and white wires appear to have the RS485 signals on them. Have not confirmed which is A or B on dongle cable. You could start by measuring the CT1/CT2 terminals and see if they are close to +2.5V. If you have a scope, you could also look for activity on the terminals.

Nature ALWAYS wins!  We just THINK we have game! (The proof is in! and it ain't pretty.)

The short version: Don't believe the IP ratings of ANY product, especially if that product is related in any way to electricity!

The truth is is out there ...  and it's costly! lesson RE-learned.

Lets just get the ugly part over with (see damage photos).

.

These little cuties are the WiFi extender and the PoE converter for one of the PTZ cameras (which survived).

This is the PoE range extender

We had a storm blow through parker county last week and dump a couple of inches of rain in a VERY short time.  As you have probably guessed by now; I lost, Nature won.   I forgot the basic principals of electricity I learned at Millington NAS 50 years ago.  DON'T MIX WATER AND ELECTRICITY.  period end of story.  

After taking advantage of all of my amazon insurance; I decided to do, what i should have done in the first place. At each junction mount the box below to the fence post with u-brackets and call it a day.

The OEM seals, etc might work, but after a lot of research and buying several different types of "waterproof" connectors, I found that the problem seems to be improper fitting of the back seal.  The quality of the seal depends on whether or not water can "wick" up the back side into the connecter.  This seems to be what is happening to me. 

The primary seal appears to hold; the rear seals do not.  The other issue with the back seals has to do with the coating on the wire.  If the wire "twist" or "strands" can be seen, you are probably using indoor instead of outdoor wiring and won't get a good seal.  I have found for the best seal to use "ground burial" quality cable. It has a very thick outer covering, but it cost more.

btw, the same problem occurs if there is an excessive "pattern" to the surface of whatever cable you use. I even found some buried cable online, but it had ridges in the coating for some reason.

Cameras are all good and I only lost one WiFi extender, one PoE booster and a handful of junctions (most covered by insurance).

For those who are thinking of just "waterproofing" the connector ....  great idea, bad outcome!  its waterproof, forever! AND ugly as sin.  Obviously there is no repairing this.   

Not sustainable,  I cut it out, reinstalled RJ-45 ends with a regular junction and installed a box as indicated above.

What I do have is the green terminal block above.

My questions:
1. Are COM1 and COM2 on the green terminal block the RS485 A+ and B− lines?
2. If so, which is A+ and which is B−?
3. Is there any conflict with the batteries already using BAT COM, or are these completely separate?

Goal is to connect a USB RS485 adapter to the terminal block and read inverter data locally via Modbus.