RoganDawes

Hey there @RoganDawes , thanks for the reply.
Yes i successfully flashed the dongle :)
Busy redoing my dashboards to use the direct sunsynk data now from the dongle instead of from my rpi5 :)

There is no RTS/CTS required. You may well have the outbound RX and TX lines swapped. Would try that first.

Ok, so I finally took the time to flash ESPHome onto my Sunsynk wifi dongle. Took a while to figure out the details, which I wrote up in another thread: https://powerforum.co.za/topic/28044-anyone-noticed-weird-behaviour-from-their-sunsynk-inverter-charging-when-not-supposed-to-resetting-daily-totals-etc/?do=findComment&comment=202244
The end result is that you have a dongle running ESPHome, powered neatly from the inverter via the Ring Indicator pin of the DE9 connector, polling the inverter using modbus over RS232 at 9600 baud.
The diff from slipx06's original ESPHome config is minimal:
diff -w ESPHome-1P-Sunsynk-Deye.yaml sunsynk_dongle.yaml 12c12 < board: nodemcu-32s --- > board: airm2m_core_esp32c3 14a15 > variant: esp32c3 60,61c61,62 < tx_pin: GPIO1 < rx_pin: GPIO3 --- > tx_pin: GPIO5 > rx_pin: GPIO6 67d67 < flow_control_pin: GPIO16 Basically, change the board to an ESP32C3 (I just picked one, there may be better options), set the variant, and update the UART pins. Also, delete the modbus TX control pin, because RS232 is full duplex.
Shout if you have any questions.

Here is the YAML that I came up with. Note that the ESP07S is quite RAM limited, and I ran into "Out of Memory" conditions when enabling too many features. Main symptom of this was failure to connect to WiFi, or failure to complete OTA updates (leaving the esphome program on the client hanging)!

esphome: name: growatt friendly_name: Growatt esp8266: board: esp07s # Disable logging logger: # level: VERY_VERBOSE # level: INFO # the below lines move logging to the alternate UART pins # this exposes the TX line on the GD25Q SPI flash CS pin #1 # which can be snooped with a chip clip or pin grabbers. GND is pin #4 # If you want to keep the hardware UART for the modbus uart, # uncomment the baud_rate, and comment the hardware_uart # This is advised for "production" deployment! # baud_rate: 0 hardware_uart: UART0_SWAP # Make sure that the logger level is at least DEBUG # This is good for monitoring free heap space, etc # .debug.yaml simply contains the example configuration from # https://esphome.io/components/debug.html # <<: !include .debug.yaml # Disabled by default, because of limited RAM # required for the pcf8563 #i2c: # scl: GPIO4 # sda: GPIO5 time: - platform: sntp id: sntp_time # on_time_sync: # then: # pcf8563.write_time: # - platform: pcf8563 # id: pcf8563_time # address: 0x51 # SPI bus is connected to the GD25Qxxxx SPI NOR Flash chip # Mine was covered with conformal coating, so I couldn't make out the # exact part number # e.g. https://eu.mouser.com/datasheet/2/870/gd25q64e_rev1_4_20210820-1825464.pdf #spi: # clk_pin: GPIO14 # mosi_pin: GPIO13 # miso_pin: GPIO12 # There's no support for flash chips in ESPHome at the moment # But the CS pin is GPIO15 # Enable Home Assistant API api: ota: platform: esphome wifi: ssid: !secret wifi_ssid password: !secret wifi_password # Enable fallback hotspot (captive portal) in case wifi connection fails ap: ssid: "Growatt Fallback Hotspot" captive_portal: #web_server: light: - platform: status_led id: status_led_ output: led_red internal: true output: # Green LED - id: led_green platform: gpio pin: GPIO0 # Red LED - id: led_red platform: gpio pin: GPIO2 # Blue LED - id: led_blue platform: gpio pin: GPIO16 uart: - id: modbus_uart_master baud_rate: 9600 rx_pin: GPIO3 tx_pin: GPIO1 # debug: # direction: BOTH button: - platform: safe_mode name: "Safe mode" binary_sensor: # The button is connected to the ADC - platform: analog_threshold name: Button sensor_id: adc_button threshold: 0.5 filters: invert: sensor: - platform: uptime name: Uptime Sensor entity_category: diagnostic - platform: wifi_signal name: "WiFi Signal Sensor" update_interval: 60s entity_category: diagnostic - platform: adc pin: GPIO17 id: adc_button update_interval: 1s filters: delta: 0.1 # Use the stream_server for remote modbus RTU access #external_components: # - source: github://oxan/esphome-stream-server #stream_server: # - uart_id: modbus_uart_master # port: 502 modbus: - id: modbus_master uart_id: modbus_uart_master modbus_controller: - id: growatt_master address: 0x1 modbus_id: modbus_master setup_priority: -10 # .growatt.yaml contains the modbus register definitions packages: master_inverter: !include file: .growatt.yaml vars: modbus_device: 1 modbus_controller_id: growatt_master inverter: Master

Just a pleasure, you are doing impressive conversions 👍

I made a custom geyser controller based on the Geyserwise thermostat (which you can get for about R260), and a Sonoff THR320 (about R400). I also changed the element in my geyser to a 2kW from the 3kW it had orignally. I was actually fortunate enough to have my geyser pack up, and get replaced by insurance at the time, so I got the installers to fit the new element before it was even installed in the roof.
I have an 8kW Sunsynk, and 10kWh battery. Geyser is on the AUX section of the Sunsynk, though in hindsight, I'd be happy to move it to the essential loads, freeing up the AUX for a generator at some future point.
I am monitoring my Sunsynk using the KellerZA/sunsynk integration in Home Assistant, and the Sonoff is flashed with ESPHome firmware, exposing the geyser as a generic thermostat (heating only).
I also have some automations that monitor the state of the grid (based on Sunsynk grid power, which normally idles at 30W to prevent backfeeding, but obviously drops to zero when the grid disconnects), the state of charge of the batteries, and the rate of charge of the batteries, and apply automations to turn off the geyser whenever load shedding is active after 16:00 and before 9:00 (i.e. when the solar is not producing). If the geyser thermostat changes to heating overnight (i.e. 16:00 to 9:00), it turns off the inverter timer, and sets the battery charge current to 0A. This runs the whole house from the grid while the geyser is heating, but doesn't charge the batteries. This change gets undone when the geyser stops heating, or if the time crosses the thresholds.
One of my best automations checks the battery State of Charge (>70%), and rate of charge (>2500W), and then sets the thermostat to 70C, or back to 45C if it goes below 70% or charge power goes negative for 5 minutes (i.e. discharging from the battery to run the geyser). This can be quite effective at absorbing an additional 4kWh from the panels as hot water, which would otherwise just get discarded when the batteries are full.
To answer your questions more directly, it depends on the size of the element in your geyser as to whether this will be feasible for you, and what other loads you expect to handle. Trying to run a 4kW element on a 5kW inverter, with other loads as well is asking for trouble, obviously. If you can downgrade to a 2kW (which just means that the water takes longer to heat up), then the impact on the inverter will be a lower magnitude, but require a longer run time to get the same result. If you can install a heat pump, the energy requirements drop significantly too. Roughly 1kW for a 4kW equivalent heat output. That becomes a lot more reasonable to put onto a 5kW inverter, but is obviously a lot more expensive.

You are on the right track. Battery voltage never lies. Therefor I let the inverters manage the charge on the base of battery voltage. No coms. I also have differences on SoC between packs. But they all jump to 100% SoC when reaching bulk charge voltage.
Various BMS have different algorithms to figure out SoC. One is to meter in and outgoing Ah. That method neglects internal losses of the battery and therefor reaches 100% Soc while the battery is still charging.

Yes, that's why I occasionally cast an eye on cell voltages, pack temps, etc.
HA is great for that, as I'm sure you already know! 

Those cell voltage graphs actually don't look too bad....better than mine! So you seem to have 32 healthy cells!
What I do find interesting, is if you look at the SOC vs pack voltage graphs, pack 2 is the one always showing the lower SOC, yet it has/follows a slightly higher voltage (+-100-200mV over the whole pack) on the pack voltage graph.
To me that would just indicate that the SOC calibration for pack 2 is not OK (or is it the other way round!)
I found a similar SOC variance on a 4 Hubble AM-2 set of batteries (Also has the PACE BMS). Voltage per pack is all equal, but SOC% is all over the show.
These batteries are remote, so I can't help the owner to fix it, as he does not have a extra USB/RS232 cable to use PBMSTools to re-calibrate them. Even so, I haven't done that myself (my packs don't exhibit this SOC% variance).     
I saw a Hubble techie do it remotely, so I know it can be done. It seem's it can be done at any time. He basically determined which pack's SOC is the highest, and reset the other pack/s to that value.  He used PBMSTools to do this.

 

@RoganDawes,
I have a similar setup, just not Greenrich, but LiFePo4 + Pace BMS, and my SOC's run within a few 1/10th of a % from another.

Perhaps you have a cell/s that is sagging. Maybe plot each pack's 16 x cell voltage over time and see if it shows any anomalies. Up to 120 mV delta is not ideal, but acceptable.
If that doesn't show anything conclusive, then maybe use PBMStools to look at the setting of each battery. 

Not that I am aware of. If you want the Sunsynk dashboard, you are stuck with their firmware. At least they updated it to turn off the default access point after it was connected to your own WiFi!

That’s my thoughts. Run the coldest geyser earlier and the hottest later. That I think would also increase efficiency. 
 
Will look into this avenue. I’ve gone through your post on my broadband and it looks very comprehensive. 

Not at the moment but something I could add
That's your `essential_power:` entity. If you have not defined one in your card config then there will be no state history and its not clickable.
The card will automatically calculate this sensor based on the formula below if the attribute is set to none or the sensor is not defined. You can override this by supplying a sensor that measures essential power.
essential = inverter_power_175 + grid_power_169 - aux_power_166  

Not going to comment on whether you have enough battery etc to go off grid, but can possibly help with the geyser questions. I built my own smart geyser controller, based on a geyserwise thermostat and a Sonoff THR320, all running ESPHome. I use it to dump excess solar into the geyser in the form of hot water, but can also manage them remotely, or automatically using Home Assistant. One important thing I did was to change the element from a 3kW to a 2kW, to reduce the peak draw when the geyser is running, so that the load stays under the threshold of available solar. Doing the same for your 4 geysers could take you from 12kW just in geysers to 8kW or less, depending on which are actually running. Note that this just reduces the peak load from your geysers, but they would obviously have to run longer to achieve the same amount of hot water.
You can find details here: https://mybroadband.co.za/forum/threads/esphome-geyserwise-smart-thermostat.1231463/ Note that if I were to do it again, I'd try really hard to just replace the thermistor with a Dallas DS18b20 1-wire sensor at the tip of the thermostat, rather than futzing with the interposer!
If you want to spend money, you could consider heat pumps as a much more efficient way of heating water (3 times). Given your goal to go offgrid, it would be smarter to reduce your consumption before investing in more batteries. Regardless of the technology you select, having some degree of load control is advisable, whether that is turning off geysers, pool pumps, chest freezers, etc.
That sounds like around R12-14k each, which is about the same price as an equivalent heat pump, I think. But reducing the consumption will pay off by making panels previously dedicated to heating water available for other loads, like charging batteries. And with smart control, you can possibly change thermostats on the heat pumps to run when your batteries are near full, and there is more solar available than needed to fill the batteries.

This is mine:
 
ESP32 talks to the SP3232 transceiver (yellow wires), which has 2 channels in each direction, perfect for 2 UARTs. The jumpers at the bottom either swap RX/TX (two blocks on either side), or connect/disconnect the TX lines from the transceiver/ESP32. When the ESP32 TX lines are disconnected, the ESP32 can snoop but not transmit, which is enough for most purposes.
I run ESPHome on the ESP32, because it has a ton of useful functionality (OTA updates, built in UART buffering, debug logging via WiFi, etc), and simply put the Sunsynk dongle on one side, and a DE9 cable to the inverter on the other side.
The string of numbers you posted is actually just the dongle trying to identify the address of the inverter (first column). Second column (3) is a "read holding register" command, starting at address 0, and returning 9 registers. last two columns are the CRC. Apparently the inverter was not responding for some reason. Not connected, maybe?
0 3 0 0 0 9 132 29 1 3 0 0 0 9 133 204 2 3 0 0 0 9 133 255 3 3 0 0 0 9 132 46 4 3 0 0 0 9 133 153 5 3 0 0 0 9 132 72 6 3 0 0 0 9 132 123 7 3 0 0 0 9 133 170 8 3 0 0 0 9 133 85 9 3 0 0 0 9 132 132 10 3 0 0 0 9 132 183 11 3 0 0 0 9 133 102 12 3 0 0 0 9 132 209 13 3 0 0 0 9 133 0 14 3 0 0 0 9 133 51   

This is mine:
 
ESP32 talks to the SP3232 transceiver (yellow wires), which has 2 channels in each direction, perfect for 2 UARTs. The jumpers at the bottom either swap RX/TX (two blocks on either side), or connect/disconnect the TX lines from the transceiver/ESP32. When the ESP32 TX lines are disconnected, the ESP32 can snoop but not transmit, which is enough for most purposes.
I run ESPHome on the ESP32, because it has a ton of useful functionality (OTA updates, built in UART buffering, debug logging via WiFi, etc), and simply put the Sunsynk dongle on one side, and a DE9 cable to the inverter on the other side.
The string of numbers you posted is actually just the dongle trying to identify the address of the inverter (first column). Second column (3) is a "read holding register" command, starting at address 0, and returning 9 registers. last two columns are the CRC. Apparently the inverter was not responding for some reason. Not connected, maybe?
0 3 0 0 0 9 132 29 1 3 0 0 0 9 133 204 2 3 0 0 0 9 133 255 3 3 0 0 0 9 132 46 4 3 0 0 0 9 133 153 5 3 0 0 0 9 132 72 6 3 0 0 0 9 132 123 7 3 0 0 0 9 133 170 8 3 0 0 0 9 133 85 9 3 0 0 0 9 132 132 10 3 0 0 0 9 132 183 11 3 0 0 0 9 133 102 12 3 0 0 0 9 132 209 13 3 0 0 0 9 133 0 14 3 0 0 0 9 133 51   

Sure, that's why you take a backup, and can reinstall it if you ever need to do an upgrade. And while doing so, log all the data written out on the serial port to see how it is done 😛

Sure, that's why you take a backup, and can reinstall it if you ever need to do an upgrade. And while doing so, log all the data written out on the serial port to see how it is done 😛

So, it wasn't as simple as I thought it would be to get ESPHome running on the Sunsynk dongle.
Flashing is not too tricky, although I do end up contorting my fingers a little, holding 3 jumper wires for G,R,T and a pair of header pins with a jumper on them to bridge GPIO0 (aka "short for ISP" - edit: turns out this is GPIO8 on the C3) with one finger, and holding 3v3 against the capacitors to the left of the C3-Mini module to power it.
I used:
esptool.py -p /dev/cu.usbserial-01E7DF5F -b 230400 read_flash 0 $((4*1024*1024)) sunsynk2.bin to take a backup (it's a 4MB part, so you can do the calculation manually if you are using Windows).
Flashing a minimal config ended up in a boot loop when powered as above via a 3v3 supply, held against the decoupling caps. I guess it wasn't enough to power the WiFi when it initialises. So, using a DE9 breakout, and feeding 12V on the RI (pin 9), and ground on pin 5, I was able to get it running stably. It took me an AGE to figure out what pins to use for the uart! I first thought I'd be clever and use the ESPHome kickstart firmware to dynamically adjust the pins, and wasted a few hours trying to get that to work, firstly making changes for the ESP32C3, and then just iterating through the pins and looking for behaviour on the RX and TX pins of the DE9 connector. All for naught, the kickstart firmware just wasn't working properly for some reason.
BTW, I did test restoring the backup firmware, and it worked perfectly (when powered using 12V). It was actually the stock firmware boot loop when powered via 3v3 to the capacitors that clued me in to checking for power problems.
In the end, my diff to slip06x's config on github was pretty minimal:
diff -w ESPHome-1P-Sunsynk-Deye.yaml sunsynk_dongle.yaml 12c12 < board: nodemcu-32s --- > board: airm2m_core_esp32c3 14a15 > variant: esp32c3 60,61c61,62 < tx_pin: GPIO1 < rx_pin: GPIO3 --- > tx_pin: GPIO5 > rx_pin: GPIO6 67d67 < flow_control_pin: GPIO16 I did also figure out the GPIOs for the LEDs (3 and 7 for the red and green LEDs, respectively), but haven't yet bothered adding those to the config.
With that, you can now flash ESPHome onto your Sunsynk dongle, and detach yourself from the cloud entirely.

I actually built something like this, based on an ESP32. I posted some pictures of it, and a little description, here: https://infosec.exchange/deck/@RoganDawes/111595769934719217
Sorry, the pictures are too large for this forum 🙂
ESP32 has 3 UART's, I put an SP3232 on some veroboard to get 2 inbound signals and 2 outbound signals, mapped to U1RX/U1TX and U2RX/U2TX. The jumper pins in the middle let you switch from just snooping to active interception, by connecting the TX signals, and breaking the "Straight through" connections in the middle.
And yes, while it is possible to pass through the data from the genuine dongle (running e-linter firmware) to the inverter, and its responses in the other direction, and then issue your own commands when it is quiet so as not to trample over the e-linter comms, actually identifying and using those intervals of quiet is not the simplest problem to solve.
I think I mentioned it above, but another approach is to emulate the e-linter firmware using Wokwi, and forward the emulated UART to the dongle. Still some impedance matching required (e-linter firmware will expect a response within X ms, otherwise will resend the query, so you can simply drop a duplicated query, etc, etc).

So, it wasn't as simple as I thought it would be to get ESPHome running on the Sunsynk dongle.
Flashing is not too tricky, although I do end up contorting my fingers a little, holding 3 jumper wires for G,R,T and a pair of header pins with a jumper on them to bridge GPIO0 (aka "short for ISP" - edit: turns out this is GPIO8 on the C3) with one finger, and holding 3v3 against the capacitors to the left of the C3-Mini module to power it.
I used:
esptool.py -p /dev/cu.usbserial-01E7DF5F -b 230400 read_flash 0 $((4*1024*1024)) sunsynk2.bin to take a backup (it's a 4MB part, so you can do the calculation manually if you are using Windows).
Flashing a minimal config ended up in a boot loop when powered as above via a 3v3 supply, held against the decoupling caps. I guess it wasn't enough to power the WiFi when it initialises. So, using a DE9 breakout, and feeding 12V on the RI (pin 9), and ground on pin 5, I was able to get it running stably. It took me an AGE to figure out what pins to use for the uart! I first thought I'd be clever and use the ESPHome kickstart firmware to dynamically adjust the pins, and wasted a few hours trying to get that to work, firstly making changes for the ESP32C3, and then just iterating through the pins and looking for behaviour on the RX and TX pins of the DE9 connector. All for naught, the kickstart firmware just wasn't working properly for some reason.
BTW, I did test restoring the backup firmware, and it worked perfectly (when powered using 12V). It was actually the stock firmware boot loop when powered via 3v3 to the capacitors that clued me in to checking for power problems.
In the end, my diff to slip06x's config on github was pretty minimal:
diff -w ESPHome-1P-Sunsynk-Deye.yaml sunsynk_dongle.yaml 12c12 < board: nodemcu-32s --- > board: airm2m_core_esp32c3 14a15 > variant: esp32c3 60,61c61,62 < tx_pin: GPIO1 < rx_pin: GPIO3 --- > tx_pin: GPIO5 > rx_pin: GPIO6 67d67 < flow_control_pin: GPIO16 I did also figure out the GPIOs for the LEDs (3 and 7 for the red and green LEDs, respectively), but haven't yet bothered adding those to the config.
With that, you can now flash ESPHome onto your Sunsynk dongle, and detach yourself from the cloud entirely.

Would still be amazing to get into the orignal firmware and see if it is possible to retain the original communications but add in a stream server of the RS323 (modbus).

So, it wasn't as simple as I thought it would be to get ESPHome running on the Sunsynk dongle.
Flashing is not too tricky, although I do end up contorting my fingers a little, holding 3 jumper wires for G,R,T and a pair of header pins with a jumper on them to bridge GPIO0 (aka "short for ISP" - edit: turns out this is GPIO8 on the C3) with one finger, and holding 3v3 against the capacitors to the left of the C3-Mini module to power it.
I used:
esptool.py -p /dev/cu.usbserial-01E7DF5F -b 230400 read_flash 0 $((4*1024*1024)) sunsynk2.bin to take a backup (it's a 4MB part, so you can do the calculation manually if you are using Windows).
Flashing a minimal config ended up in a boot loop when powered as above via a 3v3 supply, held against the decoupling caps. I guess it wasn't enough to power the WiFi when it initialises. So, using a DE9 breakout, and feeding 12V on the RI (pin 9), and ground on pin 5, I was able to get it running stably. It took me an AGE to figure out what pins to use for the uart! I first thought I'd be clever and use the ESPHome kickstart firmware to dynamically adjust the pins, and wasted a few hours trying to get that to work, firstly making changes for the ESP32C3, and then just iterating through the pins and looking for behaviour on the RX and TX pins of the DE9 connector. All for naught, the kickstart firmware just wasn't working properly for some reason.
BTW, I did test restoring the backup firmware, and it worked perfectly (when powered using 12V). It was actually the stock firmware boot loop when powered via 3v3 to the capacitors that clued me in to checking for power problems.
In the end, my diff to slip06x's config on github was pretty minimal:
diff -w ESPHome-1P-Sunsynk-Deye.yaml sunsynk_dongle.yaml 12c12 < board: nodemcu-32s --- > board: airm2m_core_esp32c3 14a15 > variant: esp32c3 60,61c61,62 < tx_pin: GPIO1 < rx_pin: GPIO3 --- > tx_pin: GPIO5 > rx_pin: GPIO6 67d67 < flow_control_pin: GPIO16 I did also figure out the GPIOs for the LEDs (3 and 7 for the red and green LEDs, respectively), but haven't yet bothered adding those to the config.
With that, you can now flash ESPHome onto your Sunsynk dongle, and detach yourself from the cloud entirely.

Just turn off the "Time sync" option on the inverter. That way the totals won't be mucked up like that.

I saw on the Fb page that someone said that there was an issue with the time zones and dates. This could have created havoc with the time settings.