How does sensor.goe_xxx_pvopt_averagepgrid get calculated?

[karliwalti]

My understanding is that this is the value that is being used to drive the controller of the PV optimized charging. The target would be a sensor.goe_xxx_pvopt_averagepgrid between -200 and 0

The reason I ask is that I observe a strong oscillatory behavior in control if I transmit PV, Battery, and Grid information. When I send only grid information, the system runs much more stable but depletes the battery before stopping.

[marq24]

Hi Walt,

the simple & honest answer is - I don't have a clue at all. All data the integration provide will be read 1:1 from the Wallbox [technically this is not 100% correct - some of the values will be divided by a constant - you can find the factor attribute in the entity descriptions in the source code.

So the integration provide the data from the wall box without any kind of additional functionality. When you made the observation, that sending only GRID information would lead to more/stable results, then it could be the case, that the 'sign' of the battery might be not correct? This might be a a bug in the documentation [what means "exporting" and what means "importing" (from where to what?)]...

But coming back to your initial question -> 'sensor.goe_xxx_pvopt_averagepgrid' will be calculated by go-eCharger Wallbox internally and this integration just provide the data to HA... -> I just can recommend to ask your question @ https://github.com/goecharger/go-eCharger-API-v2/discussions

[karliwalti]

Hi @marq24

OK, I think I get it now. This integration is a parser for the API and it also sends the values from the power sensors. My mistake was to think that the emulation of the eController would need more than that.
Thank you!

[marq24]

I am/was also totally surprised, that go-eCharger offers the feature to provide PV data "manually" via the API (as alternative to the installation of the hardware solution)... Actually when I saw this in the documentation @ github that was the point where I wanted to create/provide this integration - and also 'yes' you are fully right - this is a simple wrapper of the existing API into HA entities...

[karliwalti]

I think the truth is a bit in between. Reading the full posts here goecharger/go-eCharger-API-v2#110 suggests that pGrid is used, and to some extend also pAkku, but not pPv. this means that for more complex settings a custom controller on the HA side might be more suitable (by modifying/hacking pGrid and pAkku when in ECO mode or directly with the commands amp (Ladestrom einstellen), frc (Ladevorgang starten/beenden) und psm (Phasenumschaltung) )

[marq24]

IMHO the discussion thread you linked have indeed contradictory information - for me only the posts from @0xFEEDC0DE64 are the 'source of information'... If you installed multiple chargers it will be for sure a total different story and additional hardware (or the use of evcc might be more sufficient -> https://github.com/marq24/ha-evcc).

I haven't spotted the post where you have found the info, that "pAkku" should be used - and pPv should not be provided... But at the end of the day it's not important - since you are in control of the automation (https://github.com/marq24/ha-goecharger-api2?tab=readme-ov-file#example-automation) and have the option to include only the sensors as data provider you believe in.

Of course I am highly interested, if the situation will change for you, when you do not provide ppv data (or if the situation will remain the same)... We can also switch to German language here - since it might make things a bit easier in communication.

[karliwalti]

goecharger/go-eCharger-API-v2#110 (reply in thread)
I dont have a reliable source for pAkku, but for pPV (only for display)

[IngmarStein]

So I also started using this integration including the automation which sends pPv, pAkku, and pGrid to the charger.
I noticed that the charger was overshooting, consuming the PV production, the maximum battery discharge, and importing from the grid to reach 11 kW and I think it's because of the pAkku direction. Like goecharger/go-eCharger-API-v2#110 (comment), I've been passing through the values from a SolarEdge inverter which is positive when the battery is charging and negative when it's discharging. That script is negating the value and it was mentioned in the thread that negative values indicate charging, positive values discharging.

However, it's totally sensible to set pAkku to 0 (or not pass it) if one wants to prioritizes the home battery over the car.

[karliwalti]

Hi @IngmarStein I use now following solution that seems to work quite well for my system / car (note I have a battery with max 2500W C ). I set pAkku to 0 and modulate pGrid using following sensor template:

- name: "Spare Power for Charging Car"
   unit_of_measurement: "W"
   state: > 
     {% set grid_active_power = (states('sensor.power_meter_active_power') | default(0) | float(0) * -1) %}
     {% set battery_active_power = (states('sensor.battery_charge_discharge_power_with_loss') | default(0) | float(0) * -1) %}
     {% if battery_active_power < 0.0 %} 
         {# battery is charging, add margin #}
         {% if battery_active_power < -2000.0 %} 
             {# battery is charging over a threshold, expose excess #}
             {{ battery_active_power + 2000.0 + grid_active_power }}
         {% else %} 
             {{ grid_active_power + 0}}
         {% endif %}
     {% else %}
       {# battery is feeding, sum up power fed into house #}
       {{ battery_active_power + grid_active_power }}
     {% endif %}

[IngmarStein]

So I got official confirmation from go-e support that the charger is currently always prioritized over the battery, so your template above is the right way to do it the other way around. Eventually, they want to expose the prioritization as a setting in the API and app.

[IngmarStein]

Maybe I'm not seeing something. I now only submit pgrid an here's a case where I plug in the car at 21:00 after sunset when the house was drawing from the battery. Before plugging it in, pgrid was ~0, as expected:

Still, charging started with 4.2 kW (6A, 3 phases) even though pgrid was far away from the configured start (1400 W):

I'll now try @karliwalti's approach of adjusting pgrid by the battery power, but as I understood the semantics of pgrid, this shouldn't be necessary, no?

[marq24]

With a home battery you should set the value Zielwert Netz to -200W (or lower) in your go-eCharger settings (that's a hint in the go-eCharger app)...

[IngmarStein]

Yeah, that's where I have it now. But even in the app, the description of the positive/negative direction of this value is confusing. It says "positive values lead to a lower grid import, negative values to a lower grid export". I would expect it to be the other way around.

[marq24]

I fully agree with you that the "instructions" are very confusing - and I also agree, that this "minus" (and minus minus minus means plus) is making me scratching my head all the time.

I just can assume, that the developers of the go-eCharger firmware have a technical point of view of these values - and for me it would help extremely to see the actual code that would do the math/calculation. Since in my personal experience sometimes alternative variable names and inverting values and the meaning would make the readability much easier...

So let's see, what will happen with -200W once the sun goes down this evening (and the home battery is full) and you will plug in the car (and if it's not fully charged)... that's some "if's",,,

[karliwalti]

This is now a bit speculative, but it is likely that the charger "probes" how much it can drain until pGrid becomes positive (or larger Zielwert Netz). When a battery is attached, it can do this up to the max battery discharge current without seeing a change in the pGrid value. The default setting is likely that a battery discharge for charging a car is OK (since it is temporary stored PV power).

[IngmarStein]

I think that's plausible once charging has started.
When I sent the battery values according to the documentation, the Gemini interpreted that as "battery is charging" instead of "battery is draining" and then probably thought that there is a PV surplus that should go into the car instead of the house battery.
However, when I stopped sending pAkku, the go-e system didn't know about the battery and I can't explain why it started charging before reaching the initial minimum of 1.4 kW (and why 3 phases).

Today, I tested how it looked with the fixed pAkku direction and during the day everything was as expected. That, however, prevented testing the scenario from yesterday, as the car battery is now full. Next time…

[core66]

I don't have a battery and had the same problem. I have now set this target grid value (Zielwert Netz) to -1500 and it now leaves me with 1500 watts surplus.

Is it working so far, am I right?

[marq24]

am I right?

that's my understanding so far - can do some additional/internal tests end of next week...

[core66]

does anyone know whether it is possible to change the PV surplus calculation interval? it would be great if it could be reduced slightly rather than at 300 (stopped charging process) or 30 (active, paused charging process) second intervals.

[core66]

The main problem is actually the calculation interval. can this be changed anywhere?

[marq24]

this is a question you have to ask the the official go-eCharger Support team - since the integration can only adjust what's available via the API - and if you do not find a value in the API-Key documentation of go-e, then the chances are quite high, that currently it's not possible for the end user to adjust this interval...

[karliwalti]

I am not sure whether I can follow your question. Are you asking whether it is possible to override the pause?
Check here https://github.com/goecharger/go-eCharger-API-v2/blob/main/apikeys-en.md, the mc* can fix the pause length or stop the pause.
However, if your question is to speed up the power tracker itself, then your best option is to move the power tracking control algo to HA and do all calculations yourself. You would be updating then at the update rate of any of the input parameters.

[core66]

ty mate, i mean the "pv surplus calculation" ... standard its 30 Seconds....this i wanna change to 10 secs for example

[core66]

Because I don't have a battery, I have the following problem:

Sun is shining - car is charging

Cloud is coming or a larger consumer in the house is activated - charging is stopped (because the calculation takes too long for the charger to adapt to the available PV power).

[karliwalti]

If you check the API documentation link, you will find for 'ids': Needed all 5 seconds. Can be read back within 10 seconds after set.
Are you providing the values at that interval? If not, you could force it by HA. The values are averaged by the go-e "pvopt_averagePGrid" over a certain period, i.e. 30 s (I am not sure about that number), and if in HA the numbers do not change, then they will not be sent. The consequence is that the average number lags.

Nevertheless, your logic above suggests the opposite: You need to implement a larger filter (stronger smoothing) to avoid stopping the car's charging (but you will pull power from the grid). You do not need to update the calculation frequency; you need to update the value you feed to 'pGrid'.
The API also has a tool for you: 'sh'. The hysteresis will define how much change, and in combination with 'fmt', you could probably find a good solution for you with only API calls.

[core66]

My goal is....that the charging process is not stopped if the load on the grid increases briefly and the value falls into the "positive" value before the charger (+ integration) has adapted to the new value.

[karliwalti]

Alright, some more questions then:

1. do have a e-controller or not? The e-controller would replace the DTSU666H and HA.
2. How do you integrate your Huawei system in HA? Are you using the serial or internal WLAN? https://github.com/wlcrs/huawei_solar or are you using the FusionSolar cloud data i.e. https://github.com/tijsverkoyen/HomeAssistant-FusionSolar ?
   In the earlier option, you have to set the polling frequency to 5s as shown in https://github.com/wlcrs/huawei_solar?tab=readme-ov-file#inverter-polling-frequency, in second option you robablyhttps://github.com/wlcrs/huawei_solar?tab=readme-ov-file#inverter-polling-frequency have to reconfigure the inverter to send more often to the cloud)
3. What is the max acceptable load on the grid and for how long?

[core66]

No i have no controller yet. i use the huawei_solar integration, polling is here 10 sec....but I'm thinking more in a different direction: isn't it somehow possible to set a kind of gap in the "stop automation" of Marq24 so that it doesn't stop immediately but only after one minute, for example?? because the adjustment happens after 30 seconds at the latest?

[marq24]

Well - if the optional go-e FORCE STOP of PV surplus charging automation is the root cause - then simply disable it - there had been reports, that the charger did not stop charging when PV is gone (sun is down) - so this additional automation is really just optional.

[karliwalti]

I do not use this automation, it just works fine for me without...

If you want to use it or if the averaging in the pv surplus calculation of the charger is not sufficient, use a filter:
https://www.home-assistant.io/integrations/filter/
the low pass or moving average will do what you want.

[core66]

ok the solution with the deactivation of the stop automation was good. Now I still have the problem that the recalculation of the surplus (the 30 seconds) is simply too long.

Example: If my car is charging with 22kW and then suddenly a cloud appears, it can happen that it continues to charge with 22kW for 25 seconds even though the value from the PV has long been less. I ask again: Is it not possible to change this calculation time???? I get the data from my inverter every 10 seconds.

[marq24]

Is it not possible to change this calculation time????

only go-e can give you this answer - in the API there is no key to adjust this value - so this integration can't do this.

[karliwalti]

This is not an issue with this plugin but likely due to the rate (and filter) used by the charger. It could very well be (for good reason) that it only reacts slowly to changes. It is likely not very good for the switching electronics (in charger and car) to change more frequently than 30 seconds.

If you want to ignore this warning, then here is your answer:
HA and the plugin recalculate and send new values to the charger as often as one value in the equation gets updated. In your case this will be 10s. In mine it is rather 5 s:

To overwrite the charger logic, you have to turn it on/off and set the load through the API. That means all logic is run on HA.

1. Turn off PV charging on charger.
2. send start/stop, phase number and load

This will be a bit complicated, as you need to also decide when to do phase switch etc.