Limiter inverter with RS485 load setting

[Maggi80]

Hey Chris, cool docuentation of your Code.
I will give a try.
I modified a simple line to have the opportunity to change the number of Soyo inverters.

 

[merlin077]

Hi, I just saw this other version:

205.21US $ 16% OFF|WI FI MPPT Solar Grid Tie Inverter 1000W 1200W DC24V 48V 96V zu AC110V AC220V mit Limiter sensor PV/Batterie Entladung Inverter|Solar-Wechselrichter| - AliExpress

Smarter Shopping, Better Living! Aliexpress.com

de.aliexpress.com

No display, but a 'USB TTL' port - it looks like the dongle use an ESP module for wifi. Maybe we can decode the traffic on that 'usb port' and make our own interface with a Raspberry or something like that...

Hello there, i also got one of these (48V 1200W with Limiter).



I ordered the version with LCD display , but got one of these. Here's the link to Aliexpress: https://de.aliexpress.com/item/4000776611581.html?spm=a2g0s.9042311.0.0.985b4c4dpX34Jj

The USB-TTL port seems to be connected to the LCD port on the board. The WIFI stick does unencrypted MQTT (!) to Soyos servers (mqtt.soyo-dg.com).
There also is some kind of web portal at web.soyo-dg.com - if you register and add a WIFI stick S/N, you can look into the sites code and see the MQTT login credentials...

Unfortunately the web portal not shows any values, maybe it's never been finished... The android app works so far.

It also works with KlausLi's ESP control software: https://github.com/KlausLi/EspSoyosourceController/

Haven't had the time to hook the inverter up to PV voltage (my bench power supply only outputs 20V which is too low for the inverter to produce any power).
I will take some pictures of the inside of the GTI. Maybe its possible to change the USB-TTL Port for a proper LCD and buttons or even better control the inverter via whatever protocol there is spoken (looks like +5V, GND and two data pins - maybe SPI or even RS232?).
Does anyone know which protocol is used for communication between the LCD/button assembly and the main board?

Greetings,
merlin

 

[Chris H]

Wow Chris, well done. I'm hoping to investigate you post further when i have some more time. I also have a emonpi that I use to relay an MQTT signal for control using a Rpi at the inverter. I've also been able to update the refresh rate of the emonpi to around 700ms without it crashing. If you are interested I left some details here:

Emonhub- Edit Mosquitto update times

Here is a summary to do the same task after you have maybe upgraded the emonpi: cd /opt/openenergymonitor/emonpi/firmware/src sudo nano src.ino >> EDIT TIME_BETWEEN_READINGS= 5000; cd .. sudo systemctl stop emonhub sudo platformio run -t upload sudo systemctl start emonhub Edit - formatted...

community.openenergymonitor.org

Those emonpi details are interesting, its a shame you have to reprogram the micro-controller to change the polling rate, but I understand why. In my specific application I have found 7 seconds update rate is good enough to follow demand well, it would be nice to drop it to 4 seconds update rate but fiddling that much with the emonpi sounds like a recipe for disaster or frustration for relatively little gain. The Raspberry Pi3b that runs my emonpi also runs Home Assistant and TeslaMate in docker containers so I actually have to be careful about resource usage on it, for example Home Assistant has reduced logging because the database was getting so big it was causing the Raspberry Pi to lock up every night when it did it's database housekeeping task. At the moment I need it to be reliable more than I need it to be perfect.

Back to MQTT... I expect my code would be able to handle messages at 700ms rate, the limitation is how quickly it can decode and rebroadcast over RS485. Although the MQTT library has an input buffer I never wrote the code to expect message queuing so I don't know if it would deal with it gracefully, depends how the library handles the buffer really. I also havn't tested the inverter to see what maximum rate it is happy to receive messages at (which may also be RS485 cable length dependent - right now its 3 meters of speaker cable and working ok!), the minimum is about 1 message every 2 seconds otherwise it drops output to zero.

I stayed away from implementing this on a Rpi because it was just more complexity than I needed and I had no intention of extending this with features that take advantage of the extra hardware the Rpi offers. I wanted a very robust maintenance free implementation which was ideal for these ESP microcontrollers, RPi's are reliable but you do get SDcard errors if you abuse them enough, and they are harder to debug because you can't always isolate the problem to just your code.

 

[Cell-King]

Wow, that's a lot happening on a little Rpi 3. I wouldn't run the risk of catastrophic failure especially since the emonpi is so heavily tuned for low disc writing, compared to grafana. I run four rpi's at home for that reason, they are so cheap anyway!

 

[Chris H]

Wow, that's a lot happening on a little Rpi 3. I wouldn't run the risk of catastrophic failure especially since the emonpi is so heavily tuned for low disc writing, compared to grafana. I run four rpi's at home for that reason, they are so cheap anyway!

Its not as bad as it first sounds for the following reasons:

1. Home Assistant can generate a lot of writes (up to 1 a second in default config) but you can change it to only commit database writes every 30 or more seconds, then it behaves much more like EmonPi, and you can cut down what it saves (again everything is on by default).
2. TeslaMate doesn't make any writes when the car is asleep, charging is probably 1 a minute, only during drives is it once every couple seconds. So that is manageable.
3. As far as I can tell Grafana isn't caching anything so it should be almost no writes to SD card. The problem is some dashboards can create a very high number of database queries if you set the wrong date range, there appears to be no rate limit and it causes the RPi to become completely unresponsive for minutes or hours. As I use automation within Home Assistant this is the undesirable behavior I want to avoid as it blocks automations from running.
4. However the main reason I am less bothered about SD card wear is that I have switched to using "High Endurance" cards rated for dashcam use. I have done my own testing and a regular brand name SD card or USB flash drive can survive 70 full disk write/erase cycles before they wear out, the manufacturers of High Endurance cards rate them at over 900 cycles. I also go for larger cards as a card twice as big will take twice as long to achieve its full number of cycles (accounting for wear leveling). I used to get about 2 to 3 years of 24/7 operation with applications that do a moderate amount of logging (e.g. PiHole) on a small 16Gb card, using a card 4x the size and 10x the write cycles should allow a fair bit of headroom to thrash the card.

That's not to say it won't fail... but I don't think it will be due to SD card wear! Also because almost everything is on Docker it is super easy to rebuild, and try out new software without accidentally trashing the current installation. The only time I had issues was when the Home Assistant database had got to 1.5Gb in size and was taking too long to do nightly housekeeping task, and thats when I did some learning on log filtering!!

I do have more than 1 RPi doing tasks in the house but I try and keep the number of them down to reduce complexity and power consumption which is low but it's not completely insignificant. Because most home automation style apps spend most of their time idle the low disk throughput and slow processor aren't a huge problem when it comes to multiple uses on a single device, the limit is keeping a sensible amount of free RAM so it doesn't start paging main memory to the SD card, this is why I need more than 1 RPi on the network.

 

[Chris H]

Hello, i am using also an soyo Inverter and reading with interest this thread. I want to replace the limiter with an software solution. I have an shelly 3EM and all the values in IO-Broker.

How can i write via IO Broker or Home Assistant the values to the soyo inverter ? That really is confusing me because i am not to expericened with coding. Ist there any How to ? I did not find anything yet.

I found this but still not clear how to build that.

GitHub - syssi/esphome-soyosource-gtn-virtual-meter: ESPHome component to simulate the current clamp to control the Soyosource GTN1200 limiter

ESPHome component to simulate the current clamp to control the Soyosource GTN1200 limiter - GitHub - syssi/esphome-soyosource-gtn-virtual-meter: ESPHome component to simulate the current clamp to c...

github.com

Would be happy for support. Thank you

It looks like an add-in for the ESP Home project:

https://esphome.io/

It's part of the Home Assistant project and is designed to be easily integrated into that platform. It lets you create your own internet of things devices without having to get involved in writing your own microcontroller code. You install it as a HomeAssistant add-on then define the sort of IOT device you want by writing a config script and it will build the correct firmware for your ESP board and download it to the board. Once working the ESP board will then present back data to home asssistant that you can use there like any IOT device you might have configured (e.g. Philips Hue, etc).

I think the github you linked to is basically a ESPHome custom 'component'... so sort of like a library in Arduino speak.

I did consider using ESPHome for my own little Soyo inverter interface project as it appeared to have all the components (a MQTT client, serial device, all the usual sensor inputs) I needed, but there was a bit of a learning curve and in the end I decided it was a bit too complex for what I wanted to achieve (and for my experience level!!).

The project you linked to does look very good giving a dashboard and the ability to control using just Home Assistant scripts. But it does require you to have a working Home Assistant installation with all of the inputs you need to control the inverter being available in Home Assistant (e.g. if you are matching a load then you need to have CT clamp readings available to Home Assistant). Behind the scenes it is just subscribing to a MQTT feed and relaying that to the inverter, and also capturing a status message and publishing that back to MQTT in a format Home Assistant can understand automatically. - If you have Home Assistant all up and running and are used to that ecosystem this should be the goto way to control the inverter.

 

[BavarianSuperGuy]

ups2

 

[ProfProfessorson]

The project you linked to does look very good giving a dashboard and the ability to control using just Home Assistant scripts. But it does require you to have a working Home Assistant installation with all of the inputs you need to control the inverter being available in Home Assistant (e.g. if you are matching a load then you need to have CT clamp readings available to Home Assistant). Behind the scenes it is just subscribing to a MQTT feed and relaying that to the inverter, and also capturing a status message and publishing that back to MQTT in a format Home Assistant can understand automatically. - If you have Home Assistant all up and running and are used to that ecosystem this should be the goto way to control the inverter.

I'm the author of https://github.com/syssi/esphome-soyosource-gtn-virtual-meter

Feel free to ask questions. The project doesn't require a Home Assistant instance. If you flash the example yaml to your ESP it will publish MQTT messages out of the box which can be consumed by any home automation. The yaml can also be extended/used to consume MQTT topics (f.e. the current power consumption of your smartmeter). So you are able to setup a standalone solution (smartmeter <-> virtual limiter <-> soyosource). It does basically the same like @BavarianSuperGuy solution. The configuration layer (yaml) makes it more flexible but it's hard to understand at the first time.

 

[Chris H]

The project doesn't require a Home Assistant instance. If you flash the example yaml to your ESP

Sorry, I didn't read your readme thoroughly enough to realise it can be standalone from Home Assistant (or that ESPHome in general can be). My point was, to program the ESP micro-controller board of your choice you need a programmer on your computer, either the optional one provided as part of a Home Assistant installation or the python command line programmer outlined here: https://esphome.io/guides/getting_started_command_line.html I think its that step that was tripping people up (at least I thought it was)? Although you do explicitly list out on the github readme how to get it installed.

I agree the yaml file does make it more flexible, once you are used to using them, but to flash the file onto the ESP requires knowledge of the above step.

I really like that your ESPhome code can be modified through the YAML file to take in any MQTT topic, that flexibility makes it super useful, and it implements in one place everything known so far about the RS485 protocol used by the inverter.

 

[merlin077]

Hello there, i also got one of these (48V 1200W with Limiter).

View attachment 26227

I ordered the version with LCD display , but got one of these. Here's the link to Aliexpress: https://de.aliexpress.com/item/4000776611581.html?spm=a2g0s.9042311.0.0.985b4c4dpX34Jj

The USB-TTL port seems to be connected to the LCD port on the board. The WIFI stick does unencrypted MQTT (!) to Soyos servers (mqtt.soyo-dg.com).
There also is some kind of web portal at web.soyo-dg.com - if you register and add a WIFI stick S/N, you can look into the sites code and see the MQTT login credentials...

Unfortunately the web portal not shows any values, maybe it's never been finished... The android app works so far.

It also works with KlausLi's ESP control software: https://github.com/KlausLi/EspSoyosourceController/

Haven't had the time to hook the inverter up to PV voltage (my bench power supply only outputs 20V which is too low for the inverter to produce any power).
I will take some pictures of the inside of the GTI. Maybe its possible to change the USB-TTL Port for a proper LCD and buttons or even better control the inverter via whatever protocol there is spoken (looks like +5V, GND and two data pins - maybe SPI or even RS232?).
Does anyone know which protocol is used for communication between the LCD/button assembly and the main board?

Greetings,
merlin

So, i had a few days testing this fine chinese apparatus...

It works. Kind of. The MPPT is complete and utter crap, it won't find a suitable maximum power point which leads to fluctuating output power.
So for PV use it's useless. I unfortunately don't have a 48V power supply with enough beef to test this thing in battery mode...

I'm not too sure if i might keep the thing, because i will add a ePever charge controller and a 48V battery pack. If it works in battery mode, it's fine

Does your MPPT work?

Best regards,
merlin

 

[Chris H]

So, i had a few days testing this fine chinese apparatus...

It works. Kind of. The MPPT is complete and utter crap, it won't find a suitable maximum power point which leads to fluctuating output power.
So for PV use it's useless. I unfortunately don't have a 48V power supply with enough beef to test this thing in battery mode...

I'm not too sure if i might keep the thing, because i will add a ePever charge controller and a 48V battery pack. If it works in battery mode, it's fine

Does your MPPT work?

Best regards,
merlin

It works in battery mode, although the voltages displayed on the LCD for both AC grid and battery are way off. For Grid-Tie it seems to work so whatever it is reading as the voltage doesn't seem to affect operation of the inverter circuitry (i.e. internally it must be correct for it to syncronise and export power). For battery (input) voltage it reads slightly low compared with a multi-meter at the terminals so this does affect the programmed low voltage disconnect values this is both on and off load, if you want it to shut off at a particular voltage then just bias the voltages programmed into the inverter.

I have also noticed that the instantaneous output power (in Watts) shown on the LCD is inaccurate (probably because it is measuring the wrong voltages), however connecting an AC power meter to the output shows that the inverter can accurately output the power requested by the limiter (in my case RS485 port), it just doesn't show it accurately on the LCD display... the total power exported meter on the LCD display is also inaccurate as a result.

In short, don't trust what the LCD says... it is broadly correct but only really useful for confirming the inverter is operating. If you need to verify the inverter is operating to specification then external measurement is required, a cheap plug in mains power monitor is suitable as it doesn't care which way energy is flowing and has a reasonable update interval.

So you may find the MPPT is functioning correctly, depending on if you were monitoring it just using values displayed on the LCD or using an external meter. Also if the inverter is limiting output then it won't be operating in the MPPT range because it is intentionally not taking all the power available from the PV.

Some people have previously commented on here that in battery mode the inverter de-rates its maximum output at low battery voltages, this is externally measurable, but again not as severe as the LCD readings make out. I believe the derating is because current draw through the inverter goes up as battery voltage goes down and the device is limited by the maximum current it can handle, this is likely why they are rated at lower output in battery mode verses PV, because the maximum battery voltage is 56v but PV can be 72v which would draw considerably fewer Amps for the same power, also PV voltage and power are also correlated whereas on battery they are not.

One other unrelated observation, the inverter will work perfectly fine if the battery is being charged at the same time as the inverter is exporting power, at least in my setup the two don't interact with each other. Although you would need a 'reasonable' size battery to buffer the charger input, I imagine directly connecting a charger output to the inverter input terminals would result in very unpredictable (bad) results as the two would be fighting with each other to establish equilibrium in power delivery with the charger attempting to follow its pre-programmed charge curve.

 

[merlin077]

I have Shellys on each of my inverters. The green line is my existing Hoymiles 4 MPPT inverter, the orange one is the new SoyoSource. You can see the dodgy MPPT But you are right, the values on the LCD or on the app (as i don't have an LC screen) are a bit off

 

[Chris H]

I have Shellys on each of my inverters. The green line is my existing Hoymiles 4 MPPT inverter, the orange one is the new SoyoSource. You can see the dodgy MPPT But you are right, the values on the LCD or on the app (as i don't have an LC screen) are a bit off

It might look a bit dodgy but the yellow line seems to be above the green.... does that mean it outputs more power from the same PV in the same location, or do the two inverters have dissimilar inputs? In my mind more==better even if its wobbly and ugly looking!

 

[completelycharged]

Will post some info in relation to some questions asked and some other updates.

The units would appear to be able to accepts updates (message) at about 4 per second. My setup I send updates at around 500ms intervals in paralle to all 4 units (separate bus).

Given the message about the WiFi unit and unencrypted passwords I would not touch the WiFi with a "barge pole" (non UK might have to look that one up...) - basically use it as long as your happy for someone to take control of your system in the future. Horified if true.

Low voltage levels impact the efficiency, which is why I have set my system to derate the output maximum to around 500W when the voltage is below about 46V. Below 44V they struggle...

Readings from the units compared to the actual battery voltage are like throwing darts at a dartboard while blindfolded. They also factor in your cabling volt drop between bus bar and inverter....

Below is my system just now, 2 units running, 2 of them offline (why keep all 4 loaded at low ouptut, low efficiency and reduce the lifespan...)

I also calculate a "normalised battery voltage" (last chart) by taking my power meter reading (more reliable) and calculating what the equivalent voltage loss is between the battery and power meter so that I have a more stable and representative true voltage. I did this my taking a few power and voltage measurements, put them in a chart and then use excel to add a trend line, then show the formula and you have your values....
The green line is the batter and the red is the measured voltage. It's a bit off at the moment as I have not corrected it since adding back a few packs, which altered the losses, hence it moves about a bit more than it would otherwise do.... Shows that I have about 150mV drop with 12A draw between the battery packs and busbar.

The last update is in mS elapsed since i rebooted the system - 4,774 hours ago.

(5) Inverter 0 is a place holder for a 5th unit which does not have RS485 and is set for constant ouptut of 100W. I use this to offset some loads which are not captured by the CT metering.

I use an old laptop running linux with several dot net runtimes (one for each component in the system : 4xinverter 1xbattery 1xcontroller, etc.) and run RabbitMQ as the messaging broker. RabbitMQ can work with MQTT add-in and have used this for some ESP devices. Why use a cheap laptop ? In built UPS system....

I have 6 separate RS485 USB adapters plugged into a couple of hubs (4 inverters, 1 MPPT, 1 battery meter) at the moment. The 2 CT measurements are sent separately through RS485 to ethernet adapters and a gateway to RabbitMQ running on my desktop. Not ideal and have a separate more accurate power meter to install so that I can tune the imbalance more effectively...

The green line in the second chart is new imbalance (measued with the crapy not so accurate CT-RS485 meters the untis were shiped with) and this is generally not so good with reactive loads.... my imbalance tends to be within about 150W.

Each of my units is connected with a separate RS485 port - this is because of an issue I have with older units randomly sending status data conflicting with updates. Also this allows all 4 units to be updated at the same time if needed.

Tracking load with more than a second lagg will result in some house loads being completely unbalanced. The Iron we have seems to have a quite short on time (seconds) and other devices that have 10-20 second on / off cycles could end up missing out on upwards of 10% of the load, effectively reducing your system efficency by 10%.....

I have 3 set to turn off below 120W and on when more than 400W per active unit is required. The last unit is set to switch off below 70W. This is because the efficiency of the units at low wattage output seems to be <70% so my view is that I'd rather concerve the energy than heat the shed. Why 70W for just one unit ? This is the oldest unit I have so I figured I would load this one unit up most of the time and see how long it lasts, plus about 100-120W seems to be the start of the decrease in efficiency loss at low loading.

About around 80% loading the efficiency also starts to drops off, which is why I operate 4 in parallel with the load spread between all of them in parallel. This then allows the per unit loading to remain lower for the majority of loading. This also keeps them cooler.... heat is a killer.

With my system I have 4 (5) units that have just passed an aggregate of 11MWh throughput, 11,000kWh in 2 years.

The issues which can be very annoying are the cut-off and startup voltage setting as this does not work in the older models when used in battery mode. For this reason I turn off the units above the battery off voltage level in my own software. The newer units would appear not to have this issue. If they (older untis) lock up dut to auto cut-off voltage being reached there is no way to reset them with a message and I have to power cycle them....

MPPT tracking accuracy - no idea, They are completely the wrong not ideal (more expensive per watt capacity) device to buy if your hooking up some solar panels.


I have wondered why they recomend the battery voltages to units with a far wider voltage tollerance (Vmax) with the battery voltage closer to the MPPT voltage range. With these units, if the "48V" unit can tollerate Vmax of 90V, why not hook it up to a 72V battery for higher input voltage and efficiency ? The 36V unit would appear to have a Vmax more inline with a 48V battery operating range.... ??

 

[completelycharged]

This is with the battery / solar charge active and a cup of coffe in the making...


Inverter throughput figures :
1706 + 779 + 3171 + 3011 + 3114 = 11,781kWh

Also note.... the kWh figure for the units is calculated from the target W and not the measured watts. The target watts is whatever the unit recieves, so you can set the target to 20,000W and this will aggregate in the Wh figure.....When I figured this out after some testing it was bit of a home simpson doh moment crossed with WTF.... might have been corrected in the later units, or not...

 

[completelycharged]

I do need to adjust the resistance value in the battery voltage calculation to smooth it back out again as it's way too noisy... (green line)

 

[Johann G]

I have Shellys on each of my inverters. The green line is my existing Hoymiles 4 MPPT inverter, the orange one is the new SoyoSource. You can see the dodgy MPPT But you are right, the values on the LCD or on the app (as i don't have an LC screen) are a bit off

Hi Merlin
what kind of shelly are you using on the inverters, the usual plugs ?

 

[Chris H]

Inspired by @ProfProfessorson I have been looking at ESPHome and running his soyosource virtual meter plugin. All was great with the world except that his code is written to match the output of the mqtt meter input whereas my code is written to try and make the meter input go to zero+buffer, so I had to do a bit of re-writing if I wanted to keep the benefits of running ESPHome, and make use of the stats that can be pulled off the inverter by @ProfProfessorson code. (By this point I was also using some Dallas 1 wire temperature sensors and a nice home assistant dashboard so didn't want to ditch ESPHome because it made adding these so ridiculously simple!)

The easy route would be to modify the actual virtual meter plugin C source code, but I didn't want to go that route as I would then be running code that differed from github so wouldn't be able to keep it sync'ed and its just a bit messy! Doing a bit of digging I discovered you can just dump C source code into ESPHome config files so I did a bit of work to try and keep as much functionality within the ESPHome libraries and as little of it in custom C code and after a lot of head scratching (due mainly to my stupidity) I have now ported my ESP32 Arduino code into the ESPHome yaml file format, I present to you an utter abomination of badly written code that should really be a "Custom Sensor Component" but isn't because I wanted to keep it all in the single yaml file:

esphome:
  name: ${name}
  platform: ESP32
  board: heltec_wifi_kit_32

# Enable logging
logger:
  baud_rate: 0
 
ota:
  password: "system_generated"

wifi:
  ssid: "username_here"
  password: "password"

mqtt:
  broker: "192.168.1.103"
  username: "username_here"
  password: "password"
  id: mqtt_client

substitutions:
  name: housebattery

globals:
    - id: demand
      type: int
      initial_value: '0' #current power inverter should deliver (default to zero)
    - id: importbuffer
      type: int
      initial_value: '120' #minimum amount of import from grid that should be targeted
    - id: maxOutput
      type: int
      initial_value: '500' #maximum power inverter should deliver
    - id: importingnow
      type: int
      initial_value: '0'

uart:
  id: uart1
  baud_rate: 4800
  tx_pin: GPIO1
  rx_pin: GPIO3

dallas:
  - pin: 23
    update_interval: 120s

number:
  - platform: template
    name: "${name} power demand"
    id: powerdemand
    min_value: 0
    max_value: 1000
    step: 1

interval:
  - interval: 1s
    then:
      lambda: !lambda |-
        static byte byte0 = 36;
        static byte byte1 = 86;
        static byte byte2 = 0;
        static byte byte3 = 33;
        static byte byte4 = 0; //(2 byte watts as short integer xaxb)
        static byte byte5 = 0; //(2 byte watts as short integer xaxb)
        static byte byte6 = 128;
        static byte byte7 = 8; // checksum
        static byte serialpacket[8];
       
        // -- Compute serial packet to inverter (just the 3 bytes that change) --
        byte4 = int(id(demand)/256); // (2 byte watts as short integer xaxb)
        if (byte4 < 0 or byte4 > 256){
            byte4 = 0;}
        byte5 = int(id(demand))-(byte4 * 256); // (2 byte watts as short integer xaxb)
        if (byte5 < 0 or byte5 > 256) {
            byte5 = 0;}
        byte7 = (264 - byte4 - byte5); //checksum calculation
        if (byte7 > 256){
            byte7 = 8;}
            serialpacket[0]=byte0;
            serialpacket[1]=byte1;
            serialpacket[2]=byte2;
            serialpacket[3]=byte3;
            serialpacket[4]=byte4;
            serialpacket[5]=byte5;
            serialpacket[6]=byte6;
            serialpacket[7]=byte7;
        uart1->write_array (serialpacket, 8);
        ESP_LOGD("Serial", "Inverter Demand Signal Sent: %d", id(demand));
   
font:
  - file: 'OpenSans-Light.ttf'
    id: my_font
    size: 14

i2c:
  sda: 4
  scl: 15

display:
  - platform: ssd1306_i2c
    model: "SSD1306 128x64"
    reset_pin: 16
    address: 0x3C
    id: my_display
    lambda: |-
      it.printf(0, 0, id(my_font), "Grid Import: %.1f", id(powermeter).state);
      it.printf(0, 20, id(my_font), "Inv Demand: %d", id(demand));
      it.printf(0, 40, id(my_font), "Batt Temp: %.1f", id(batt_temp).state);

sensor:
  - platform: dallas
    name: "Outside Ambient"
    id: out_temp
    index: 0
  - platform: dallas
    name: "Battery Pack 1"
    index: 1
  - platform: dallas
    name: "Battery Pack 2"
    index: 2
  - platform: dallas
    name: "Battery Pack 3"
    index: 3
    id: batt_temp

  # mqtt subscribe
  - id: powermeter
    internal: true
    platform: mqtt_subscribe
    name: "${name} instantaneous power consumption"
    topic: "emon/emonpi/power1"
    accuracy_decimals: 0
    unit_of_measurement: W
    device_class: power
    on_value:
      then:
        lambda: !lambda |-
          id(importingnow) = id(powermeter).state - id(importbuffer); //target grid demand minus buffer
          ESP_LOGD("main", "importnow processed: %d", id(importingnow));
          id(demand) = id(demand) + id(importingnow); //add grid import to current demand, expects that grid import will be negative if exporting
          ESP_LOGD("main", "demand raw: %d", id(demand));
          if (id(demand) >= id(maxOutput)){
            id(demand) = id(maxOutput); //cap at maxOutput - if the inverter is off or not keeping up with demand then the demand value would get very large if not capped
            ESP_LOGD("main", "demand capped: %d", id(demand));
            }
          else if (id(demand) <= 0){ // if demand is negative reset to zero (control of a charger can be added here)
            id(demand) = 0;
            ESP_LOGD("main", "demand zeroed: %d", id(demand));
            }
          auto call = id(powerdemand).make_call();
          call.set_value(id(demand));
          call.perform();

And the ultimate miracle... if you paste this on the bottom you get back all the stats from the inverter that @ProfProfessorson provides in his library (by using his library without the virtual meter component):

#----------------------------------------------------------------------------
# ---  Additions for github://syssi/esphome-soyosource-gtn-virtual-meter@main
#-----------------------------------------------------------------------------
  - platform: soyosource_inverter
    operation_mode_id:
      name: "${name} operation mode id"
    battery_voltage:
      name: "${name} battery voltage"
      id: battvolt

    battery_current:
      name: "${name} battery current"

    battery_power:
      name: "${name} battery power"

    ac_voltage:
      name: "${name} ac voltage"
    ac_frequency:
      name: "${name} ac frequency"
    temperature:
      name: "${name} temperature"
      id: invtemp

text_sensor:
  - platform: soyosource_inverter
    operation_mode:
      name: "${name} operation mode"

binary_sensor:
  - platform: soyosource_inverter
    fan_running:
      name: "${name} fan running"

external_components:
  - source: github://syssi/esphome-soyosource-gtn-virtual-meter@main
    refresh: 0s

soyosource_modbus:
  - id: modbus0
    uart_id: uart1
soyosource_inverter:
  - id: inverter1
    soyosource_modbus_id: modbus0

#----------------------------------------------------------------------------
# --- END --  Additions for github://syssi/esphome-soyosource-gtn-virtual-meter@main
#-----------------------------------------------------------------------------

I have tested this for a few days.. unsurprisingly it works just as well at matching house demand with the inverter and is perfectly stable. I have noticed that the ESPHome libraries seem a bit quicker and more stable than the Arduino libraries when it comes to establishing a wifi and MQTT connection, like my code ESPHome uses a hardware watchdog to reset the microcontroller if the MQTT connection drops but it has a slightly longer timeout. The only difference is my old code would immediately set the inverter demand to zero if it lost the MQTT connection, whereas this new code will keep transmitting the last demand signal until either a new MQTT message is received or the watchdog timer is triggered.

Feel free to use this code as you wish (most of it isn't really my own work anyway!!), if you don't have any dallas temperature sensors or a different ESP micro-controller you will need to delete or edit as appropriate. You will also need the font for the oled display, I got this from google's free font collection.

 

[Chris H]

Also note.... the kWh figure for the units is calculated from the target W and not the measured watts. The target watts is whatever the unit recieves, so you can set the target to 20,000W and this will aggregate in the Wh figure.....When I figured this out after some testing it was bit of a home simpson doh moment crossed with WTF.... might have been corrected in the later units, or not...

Thanks for the huge amount of info. I have an inverter bought in 2021, so newer firmware: I just had a look and can confirm that the total elapsed kwh figure on the display now appears to show actual power exported rather than aggregating the demand signal. No idea if thats from measured battery input or inverter output, but I do know its not wonderfully accurate if you measure it against what the inverter really outputs (even though it actually outputs very close to what is demanded).. my suspicion is this is energy flowing into the inverter, so is therefore inclusive of losses (I have an expensive SMA solar inverter that follows that methodology, you can calculate its efficiency by looking at its total export verses the export meter fitted by the electricity company).

On your other points:

-low voltage cuttoff now works and the inverter will automatically restart once voltage goes past the user programmable restart limit (you can program a cuttoff voltage and a higher restart voltage to stop the inverter cycling due to voltage drop under load).
-no serial status packet is sent unless prompted by the appropriate command that others on this board have discovered.
-I transmit a demand signal once a second and that works fine, I have experimented with twice a second and that works. If you leave an interval of ~3 seconds between commands then the inverter moves to zero output until it gets another command. Some people have stated that the inverter uses an averaging algorithm on the demand signal, I have not noticed that, it will instantaneously move to the new output level when commanded although the value displayed on the screen can be a little laggy.
-inverter seems to de-rate itself at high output and low battery voltage, but will hold 400w output all the way to low voltage shutdown.

Some of my observations:
-inverter consumes 2 watts of electricity if switched on but at zero output. 7 watts if the screen is on, but that times out after a few minutes. For this reason I have mine on a wifi smart socket and turn it on only for the hours I want the battery to run (my use case doesn't need the inverter matching the load 24/7). This also means I sometimes turn the inverter off under load, but this is within design spec for the inverter.
-I don't have high expectations about exactly matching load, my only requirement is that I don't export any significant amount of power. My battery is small enough that I can empty it in a few hours so I don't need to eeek out extra power by getting as close as possible to zero grid import. I also have a solar diverter for hot water heating and getting to less than100 watts of grid import can cause that to false trigger and then not shut down causing the inverter to back power and load match the diverter which is also undesirable. I have found targeting a buffer of 120w grid import seems to be a happy medium between never exporting or triggering the diverter and feeding the most power to the house, given the type of loads we have.
-The inverter lives in a waterproof box and miraculously doesn't overheat or activate its fans despite limited ventilation... I shall improve this 'one day'... It only operates a few hours at a time at lowish load so that's why I am not concerned at the moment.

 

[completelycharged]

Thanks for the huge amount of info. I have an inverter bought in 2021, so newer firmware: I just had a look and can confirm that the total elapsed kwh figure on the display now appears to show actual power exported rather than aggregating the demand signal. No idea if thats from measured battery input or inverter output, but I do know its not wonderfully accurate if you measure it against what the inverter really outputs (even though it actually outputs very close to what is demanded).. my suspicion is this is energy flowing into the inverter, so is therefore inclusive of losses (I have an expensive SMA solar inverter that follows that methodology, you can calculate its efficiency by looking at its total export verses the export meter fitted by the electricity company).

On your other points:

-low voltage cuttoff now works and the inverter will automatically restart once voltage goes past the user programmable restart limit (you can program a cuttoff voltage and a higher restart voltage to stop the inverter cycling due to voltage drop under load).
-no serial status packet is sent unless prompted by the appropriate command that others on this board have discovered.
-I transmit a demand signal once a second and that works fine, I have experimented with twice a second and that works. If you leave an interval of ~3 seconds between commands then the inverter moves to zero output until it gets another command. Some people have stated that the inverter uses an averaging algorithm on the demand signal, I have not noticed that, it will instantaneously move to the new output level when commanded although the value displayed on the screen can be a little laggy.
-inverter seems to de-rate itself at high output and low battery voltage, but will hold 400w output all the way to low voltage shutdown.

Some of my observations:
-inverter consumes 2 watts of electricity if switched on but at zero output. 7 watts if the screen is on, but that times out after a few minutes. For this reason I have mine on a wifi smart socket and turn it on only for the hours I want the battery to run (my use case doesn't need the inverter matching the load 24/7). This also means I sometimes turn the inverter off under load, but this is within design spec for the inverter.
-I don't have high expectations about exactly matching load, my only requirement is that I don't export any significant amount of power. My battery is small enough that I can empty it in a few hours so I don't need to eeek out extra power by getting as close as possible to zero grid import. I also have a solar diverter for hot water heating and getting to less than100 watts of grid import can cause that to false trigger and then not shut down causing the inverter to back power and load match the diverter which is also undesirable. I have found targeting a buffer of 120w grid import seems to be a happy medium between never exporting or triggering the diverter and feeding the most power to the house, given the type of loads we have.
-The inverter lives in a waterproof box and miraculously doesn't overheat or activate its fans despite limited ventilation... I shall improve this 'one day'... It only operates a few hours at a time at lowish load so that's why I am not concerned at the moment.

Really apperciate the input and feedback.

Solar hot water to me (at the moment) just seems conflicted and unfortunate, but it is what it is for the system and societary rational that exists at the moment, although I could contine for a few pages on this... every positive difference counts.

Good to be able to confirm they have corrected what I would class as a horendous bug... this is the sort of feedback that all of the posts really need for us all to make a bigger difference. Makes the status message a whole lot more useful.

I'm currently debating on getting another 1-2 units vs the GTIL 2kW unit and driftying back towards another 1-2 units. I tend to switch off the units (via zero output - 2W) rather then keep them "online" and output active power, which I'm thinking (hope) should minimise the loading on the internal caps and extend life significantly. This is where I think many rather than the few could have an advantage for a multitude of reasons.

What I still don't about these units is the manufacturer or anyone representing them does not respond to "any" wetern consumer feedback (requests or otherwise). This is what I think really undermines any "real legitimacy" wihtin the market and greater confidence of consumers. I guess any manufuacturer can easily choose to destroy or miss out on part of their own market, although Homer Simpson would be a far better CEO in these instances. (maufcacturer : "do something !!!""). Western market is looking for a "solution", why not help ??? (FFS "leak" the full protocol !!!!!)

Back to Chris....... keep it up...