Inverter power (charge/decharge) controller: grottman.py (Do not use it, just for discussion!)

[johanmeijer]

In the examples/controller directory (Alpha Branche) I added a new python script (grottman.py) that I use to control my inverter power.

Ultimately I do not want to deliver or retrieve any power from the grid, with this script I try to control this by changing the charge or decharge percentages.

I am using this script for my MIN 3600 TL-XH inverter with ARK HV batteries (at this moment 7,5 Kwh will be extended to 15 soon).
Be aware until yesterday I did not had a smartmeter connected to the inverter so I had to build something myself.
I have a CHINT DSSU666 now but not connect to the inverter yet.

In the Netherlands we have standard a Smart Meter from the provider at home. This smart meter has a so called P1 port that can be use to read actual power/energy values (This is really actual information a message is being send every 2-4 seconds, if values changes)
I connected an ESP32 to this connector that reads the smart values and create a MQTT message. Format of the message:

{"device":"DOMO_P1Meter","data": "EtotlowR":9224878,"EtothighR":8108726,"EtotlowD":2977989,"EtothighD":6359094,"EactR":58,"EactD":0,"EactVL1":242800,"EactVL2":239100,"EactVL3":0}

Next to it I use the Grott MQTT message for reading actual Inverter information.

The inverter is being controlled by setting to right registers. You need Grottserver fors this (mode = server for grott v3).

In grottman I use EactR (received power) - EactD (delivered power) as actual Power used/delivered. The goal is to make this value as close to 0 if possible.

At this moment my inverter is set to charge (mode 1) the batteries from 08:01 - 18:00 and discharge (mode 2) from 18:01 - 08:00.
I made this settings with Grott in proxy mode via the Growatt App (TOU settings). Be aware you have to define 3 time periods (08:01 - 18:00, 18:01-23:59 and 0:00 - 08:00).
I am thinking of automating this too, but that is for MVP2 (if I ever reach that).

Grottman looks at the power used and in charge mode it will calculate the Charge percentage (the part of the solar energy used for Charging the batteries). This percentage is based on the total power the inverter can deliver. In my case 3600/100 = 36 watt per percentage.

This value is controlled by register 3047 (for a min TL-XH). If we deliver power to the grid the percentage can be raised (Use more to charge the batteries) and if we need power the percentage will be lowered.

In the evening I want as much power from my batteries as possible but do not want to deliver power to the grid. This can be controlled by setting the decharge percentage (register 3036). Again 1 percent is 36 watt so by increasing 1 percentage the inverter / batteries will deliver an additional 36 watt.

I did some additional things to smooth the spikes (defined max steps) and set the initial percentages at startup and mode change.

Grottman also send out a MQTT message with information on his behavior.

Maybe you can use this also as a base for your own controlling script (and you do not have a Growtt/Chint/Eaton smart meter).

Reactions/Remarks are welcome!

[tabascoz]

Hi there, looks awesome! I'm not used to this inverter, but looks it's full hybrid, right? So it is capable of injecting into grid? What you do if I got it right is like "batt charge priority" mode where the inverter should prioritize charging the batteries, but looks Growatt is not able to do it, right?

I have the SPF5000 series, so It's not able to do and my meter just have the optical port.

In Portugal, energy costs the grid pays is 1/3 to 1/4 of what they charge you and I'd need to spend some good money to have certification to be able to connect to grid, so no good incentive for me to do so.

I have another issue and this is why i need so much of Grott. I have total power of 7Kw available from the grid. And the cheap energy price in my plan is from 22 to 8. So I have automation in Home Assistant that , by 9:30 PM it fetches solar production forecast from Solarcast ( which is awesome precise) , gets the current battery percentage and estimates what would be the target battery percentage at 8:00 am ( worst case scenario) to go thought the next day without consuming from the grid during the peak hours.

Then asnwer could be three:

• stays at battery until the target SOC is reached and switches to Grid and back to Solar at 8:00am, or
• charges the batteries to target SOC and switches to grid and back to solar at 8:00 am or
• stays fully on batteries ( most of my summer)

Second automation is more complex and goes with charging routines, as i have tons of appliances and a big house with ACs and an EV. So charging the batteries and not overcoming 7Kw power is tricky. I do it with the help of Node-red where i read MQTT values ( from Grott) to learn about total power consumption at the moment and adjust battery power charge - like you do... I have a PID component to get right on 7KW target.

I could do it also the way you are doing, by reading on the multimeter or from a Pzem on the grid mains, but grott do it's job nicely and it is simpler.

[TheBobsta]

This is interesting Johan, thanks for sharing.

I'm intrigued to know how often your script changes register values on a typical day, and whether you have any concerns on the impact this may have on the life of the inverter storage (EEPROM, flash, whatever is used).

I've been running some automations for a while (about 2yrs) on my SPH inverter that adjusts the battery charge rate according to solar output. In my case I want to maximise total "solar capture" and the AC output rating of my hybrid inverter is less than the maximum output from my panels. When PV output nears the maximum AC output, I open up the charge rate to the batteries to capture that extra power. It works well... but recently I began thinking about whether this system (which can make in excess of 200 changes per hour when solar output is highly variable due to clouds) could be prematurely ageing my inverter.
I did some research and decided to re-write my Home Assistant automations to implement some hysteresis and less granular changes (I move up around in 12% steps now rather than 6%) resulting in far fewer changes of the register.

I'd be interested to know if anyone knows what storage mechanism Growatt uses in the inverters. If these values were stored in RAM I'd have no concerns but if they're using EEPROM or other types of storage with a limited write life, our fancy automations could kill them off quite rapidly.

[johanmeijer]

Yeah I did not realize that this might be EEPROM. Lest see if there is more information on that.

In the meanwhile I have a Chint DSSU666 installed, I will connect it soon. This will change things I think.

[johanmeijer]

I did some research @ the internet and until we now the type of EEPROM used it might be nut a good idea to write to much to the Inverters EEPROM.

According chatgpt it is plausible that the used registers are based in the EEPROM (not all registers are).

Thanks to @TheBobsta for attending me.

I will stop using Grottman and start using the Chint Smartmeter a soon as possible.

[tabascoz]

Btw the inverter it stays in Brazil, my summer house, it has been switching inverter mode for the last 4 years at least three times per day and it's there rock and solid.

[skinkie]

What about implementing the Eastron/CHINT protocol? And just answering the queries from the inverter?

[johanmeijer]

@skinkie I thought about that to. I ordered a rs485 to USB adapter and maybe if I can find some time I will write a python script with the code. I think it should be already there @the internet (we will not be the first with this idea).

For now I have different problems while the inverter does not connect with the Chint smart meter I have installed. But maybe that is also an additional reason to look at an emulated Smart Meter.

@tabascoz the script I wrote was modifying the register appr. 3000 times a day. That is a bit to much I think. But it worked perfectly.
The received / delivered power stayed within the +/- 35watt (only with sudden peaks it took some time to adjust).

[skinkie]

@johanmeijer is the modbus ID correctly specified in the chint meter? I recall you needed to set that as well.

[tabascoz]

@tabascoz the script I wrote was modifying the register appr. 3000 times a day. That is a bit to much I think. But it worked perfectly. The received / delivered power stayed within the +/- 35watt (only with sudden peaks it took some time to adjust).

yep a lot, my ac charging PID has a limit of 30 sec updates, my grid power meter trips around 60sec of overload.

So i took a look at the growatt controller board. No external mem, no identification of the main processor. But it has memory so my good guess is that they might be storing some common parameters like mode, ac charge in ram backed-up by the battery. One way to test it would be to remove the battery and see what are the parameters that survive. But i need a test sample... was looking on ebay and could not find any board to purchase and i don't have now any spares.

If i find something with reasonable price i'll give it a try.

[johanmeijer]

I tried 1,2 and 4. It does not make any difference.

[skinkie]

Tried 3? https://www.youtube.com/watch?v=SqH-rlspI6c&list=PL6HFRfocQ2SgEbwL88V0_PfJjK9UbSu5o&index=12

[johanmeijer]

Unfortunately does not work either :(

[skinkie]

Checked the A/B wirering of the RS485?

[robupham]

Quick update (@TheBobsta here - I accidentally used the wrong account when commenting previously).

I had some maintenance to perform on my SPH inverter at the weekend. To carry this out I disconnected it from AC, battery and PV. (i.e. a full power-down)

After 15 mins of work I reconnected power and noticed that whilst the inverter maintained some settings (grid max/min, CT mode, battery type, etc.) as well as the clock, it LOST all the Work Mode data - schedules, charge/discharge rates, stop charge/discharge values.

This leads me to think that the values we're changing with our automations may in fact be stored in RAM and not EEPROM.

[skinkie]

If you read the modbus RTU document, there are settings that can be explictly stored. I think those include the maximum (re)active output, but only when this option is set. So I would agree that some options triggen een eeprom write, while others are in memory.

[gavintweedie]

A few months on, wondering how those who are using this on a regular basis are finding it?

I'm tempted so would be great to hear how it's gone and any gotchyas.