Determining the "Power calculation method"

[careyer]

In the CLI output it says: "Using the new method of calculating the power demand" (which overshoots by quite a lot). Is there a way to use the "standard method"?

I found out, that this is in soyosource_virtual_meter.cpp (L82-L88ff) Here I can see there is the determination of what method to use.

However both versions do not fit my needs. I want to implement a "PV-first" functionality in my system and therefore I need the unaltered last MQTT power measurement. This power measurment refelcts the current PV input in Watts and I want to command my inverter to invert exaclty this power so that the PV power gets absorbed right awaybefore charging my batteries.

Thanks for any hints mate!

[syssi]

There are two methods available:

1. DUMB_OEM_BEHAVIOR
2. NEGATIVE_MEASUREMENTS_REQUIRED

You can choose between the methods here:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/esp8266-example.yaml#L60

I cannot recommend to use the dump OEM behavior because the method is unable to detect overshooting.You should stick to the NEGATIVE_MEASUREMENTS_REQUIRED method instead and add some buffer:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/esp8266-example.yaml#L65-L67

Another option is smoothing the readings of the smart meter locally by applying additional filters:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/esp8266-example.yaml#L112-L113

[careyer]

BTW: I felt lucky enough to add a 3rd method called "PASSTHROUGH" (you can observe the changes in my fork: https://github.com/careyer/esphome-soyosource-gtn-virtual-meter -- I am sorry but I had to fork because otherwise the esphome build processs does overwrite my local changes with the status of your online repo while building because it pulls the latest code during buildtime) 🙄

The use-case of this method is the following: I wanted to implement a "Solar/PV-First"-Approach... i.e.: I am measuring what power comes from my solar panels right at the very same moment and I want my SoyoSource Inverter to invert exactly this ammount of power while not charging my batteries and leaving them +-0W charging current.

[syssi]

Feel free to fork this repository (it's how GitHub works). ;-) I would be happy about a contribution / pull request if you want to introduce a third method which fits to your needs.

[careyer]

Thank you! I see you are embodying the open source idea! Kudos! Sadly I am not very good at coding... I managed to implement my passthough method meanwhile (just to discover that I had fallen short of a missconception) ¯_(ツ)_/¯

However I had ideas on how to improve on your 'NEGATIVE_MEASUREMENTS_REQUIRED' method:

1. From what I can tell you need the negative input values to determine if you are in an overshoot situation (you are inverting more than the actual demand). As long as you are seeing positive values you keep adding them to the previous power demand and hence approaching the actual power demand (you are incremennting towards the power demand). You do that until you see the very first negative value and then you take a step back. Alright!!!! Good approach.... However you can improve that: In your situation you will increment as long as you reach an overshoot and try stabilizing arround that point with the chance of hitting more overshoots over time and always stepping back from them. --Here goes my idea on how to improve on that: Each time when receiving a new power reading you can just observe "Have I been actively inverting the last time I received a value (i.e. output power >0)?"... if so the current received value needs to be added to the power demand. If not (wasn't inverting on the last power reading) --> Inverting had been stopped due to overshoot and we need to start a new approximation cycle. Bennefit: You achieve pretty much the same buth without the need for negative values being needed/allowed (makes it more versatile). The negative prefix is basically replaced by the observation: Was I inverting before or not?

2. Use a PID controller to approximate the needed power demand without much overshooting (if at all). I believe this might be the most sophisticated method with mimium jitter and less 'approximation cycles'. However coding a PID-controller is way over my head

What are your thoughts? Best regards!

[syssi]

Let's talk about idea 1 in detail: Could you try to explain / outline your idea using example values?

[careyer]

Hey @syssi,

sorry for answering late: I have been way to busy these days. Okay- here comes my proposal for another method that does not overshoot and that can also work without nagative values:

Preliminary considerations: We can determine at any point in time if the inverter is currently active and inverting by taking a look of the currently inverted power (output power >0W). Now lets use that information to approximate our power demand from the lower end without ever overshooting:

Lets take a look at an example: 1.) Given our limiter signals a power demand of 400W 2.) Now start inverting at 90% that power with 400W x 0,9 = 360W 3.) Now upon the next measurement we see that there are 40W of demanded power left -- AND -- we see that our inverter is already inverting (output power 360W>0W). That is: We know we have to add more power to the currently set output power. 4.) Now we add another 90% of the demand that is left, ie: 360W + 40 x 0,9 = 396W 5.) Now upon the next measurement we see that there are 4W of demanded power left -- AND -- we see that our inverter is already inverting (output power 396W>0W). That is: We know we have to add more power to the currently set output power. 6.) Now we add another 90% of the demand that is left, ie: 396W + 4 x 0,9 = 399.6W 7.) Now lets assume our power draw suddenly drops from 400W to only 150W 8.) Out limiter power reading will signal <=0W, i.e. we stop inverting and set the new power output to 0W 9.) On the very next reading the Power limiter value will read 150W and hence we repeat approximating the needed power like before (Back to step 1. but this time with the new value of 150W)

This way we rapidly approach the current power demand with immediatly and effectively stepping back from any overshoot and without the need for negative power limiter values.

[syssi]

I understand your idea. Could you explain why you don't like overshooting and why do you prefer stopping the inverter instead of slowly decrease the limiter signals to find a new "positive sweet spot" (f.e. if the smartweter reports a power consumption of 1W).

[careyer]

Sure! There are two major reasons for this: a) Every overshoot means loosing energy to the energy grid (for anyone who does not get paid for it) b) For blackout prevention I have a offgrid-inverter at hand which I can use to simulate the grid for my Grid-Tie inverters. This works well but one has to make sure that in case of sudden powerdemand drops the overshoot is very quickly resolved - otherwise the offgrid-inverter releases its magic smoke. There is no time to slowly approach a new sweetspot. ;-)

[syssi]

Last question before implementing the method: Are you able to measure negative values (overshooting/exporting to the (off)grid) in case of b) or are you looking for a "positive measurements method" because of this reason?

[careyer]

Ohh... yes, I can also measure negative values. Just thought it would be beneficial to have a 3rd method that doesn't rely on this prerequisite. Just to make this whole suite of tools more universal ;-)

[syssi]

Please give it a try:

substitutions:
  name: soyosource-gtn-virtual-meter
  device_description: "Monitor a Soyosource GTN and control the power output on demand both via RS485"
  external_components_source: github://syssi/esphome-soyosource-gtn-virtual-meter@restart-on-crossing-zero-method
  tx_pin: GPIO1
  rx_pin: GPIO3

soyosource_virtual_meter:
  power_id: powermeter
  power_sensor_inactivity_timeout: 20s
  power_demand_calculation: RESTART_ON_CROSSING_ZERO
  min_power_demand: 0
  max_power_demand: 900
  power_demand_divider: 1
  buffer: 10
  operation_mode_id: operation_mode_id
  update_interval: 3s

The implemention isn't exactly your approach but it's pretty similar. The configuration above tries to control the limiter to import 10W from the grid always. If your smartmeter reports a value less than 10W the method tries to reach 10W again. If your smartmeter reports a value <= 0 we stop the inverter and start from scratch.

[careyer]

Hey Sebastian,

thanks! Sorry... I was busy again like crazy. I will try it this weekend and will report back to you! Thanks in advance!

Best regards Thomas

[blacklopo]

Hi, I'm also very concerned of minimising of overshooting. I have question about calculation of power demand - If my PV has at the moment not enough production, script very quickly rises the power 900W. But generally I only need to produce what is detected by clamp. Is in understable? IMHO we have to compare demand with real production of the invertor.

[syssi]

@blacklopo Do you have a smartmeter which provides negatives measurements of you overshoot / export to the grid?

[blacklopo]

@blacklopo Do you have a smartmeter which provides negatives measurements of you overshoot / export to the grid?

Yes, Shelly 3M. Attaching graph from today. Finally I tried new variant - RESTART_ON_CROSSING_ZERO . But data will be available tomorrow.

[syssi]

Keep me updated. I will try to provide a similar graph for comparison.

[blacklopo]

This is something I don't like to see:

[syssi]

Could you explain what I can see here? I must admit I didn't get the meaning of FVE and DS yet.

[blacklopo]

Now I can see problem with settings - RESTART_ON_CROSSING_ZERO. When negative value is detected, system automatically set Demand power to 0, and iniciate "reset", but for next several seconds the inverter still generates higher power than is expected...

[blacklopo]

• DS: Power from grid. Detected by Shelly 3M
• FVE: "Production" of inverter measured by smart tuya plug.

[kev300]

Hi, I also have some issues with the overshooting of the default method. My smartmeter is read every second and I update the inverter every 2 seconds (does not like 1s 😉) Buffer is set to 0 because i want 0W.

See attached screenshot of the smartmeter power measurement. It never settles at 0 but keeps jumping back and forth. My powe consumption before the test runs is at stable 122w, so it should not jump like that.

Any idea besides smoothing the sensor? I want a fast response with less overshooting. 😄

[syssi]

Could you provide your YAML configuration? I would like to know the update interval of the powermeter sensor for sure. It is throttled?

[syssi]

Please try to throttle the powermeter0 sensor step by step. At the moment your parameter set reacts too fast and the inverter cannot respond as fast. This leads to oscillation and the virtual meter is unable to close the feedback loop.

[kev300]

Its just that:

• platform: homeassistant id: powermeter0 name: "smartmeter power consumption" entity_id: sensor.stromz_power_power_curr

The sensor itself sends a value as soon as the meter is updating it's measurement, which is about 1s So not throttled.

I am thinking about changing the calculation to something like int16_t power_demand = (importing_now - this->last_power_demand_delta_ / 2) + last_power_demand; to "wait" a little bit for the inverter based on the last demand change.

Throttling the sensor would slowdown the initial reaction on sudden load change. Changing the calculation method would only slow down the following adjustments.

I will try to test both methods and see if my assumption can work. ;-)

[syssi]

If you clone this repository you can make/test all changes locally if you compile the YAML using:

esphome -s external_components_source components run esp8266-example.yaml

This will build the project using the local component directory instead of cloning the repository.

[syssi]

I'm happy about possible improvements. My knowledge of control engineering is very limited.

[ButschFPV]

@kev300 I'm running my inverter with these parameters:

power_demand_calculation: NEGATIVE_MEASUREMENTS_REQUIRED
buffer: 0
update_interval: 1s
#- throttle_average: 15s

I have no oscillation. My smartmeter updates every second. It's working okay but overshoots for 1-2 seconds are normal. You mentioned in #102 that you have a quiet soyosource. What Version is it 24V/48V? What error does it show if you send the power demand too frequently (1 second)?

[kev300]

It's 48v 1200w with display; no wifi. It does not show any errors, but the rs485 logo disappears for 1-2 seconds and it goes to 0w. Then it start working again for 2-3s.

Interesting. I just tested with low power consumption, because my battery is empty and not connected to solar, yet. But mine never stops oscillating. I'm trying a new algorithm at the moment but didn't have enough time yet.

[ButschFPV]

I have hooked up the original RS485 limiter to a logic analyzer and it's transmitting the power demand every 0.5s. Maybe it's the status request frame that quiet inverter don't like.

Have you bought your inverter with the original limiter?

[syssi]

I made the same experiment. The periodic requests are:

[13:07:24][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:25][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:25][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:26][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:26][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:27][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:27][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:28][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:28][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:29][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:29][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08
[13:07:30][D][uart_debug:114]: <<< 24:56:00:21:00:00:80:08

This is the "power demand" frame implemented here: https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/components/soyosource_modbus/soyosource_modbus.cpp#L86-L114

I can acknowledge the OEM update interval of 0.5s.

This is my workbench setup: