Currently predbat does not work via GivTCP on GivEnergy 3 phase Inverters #1607
Labels
Comments
|
I'm midway through trying to set this up myself so interesting to see it works in a limited fashion. I hope to get my battery to charge up during "octopus intelligent go" smart sessions and stop my Zappi from using the battery to charge the EV during this time! (expect having the battery on charge mode will just sort this tbh) hopefully, your helpers here will help on that road as I'm a relative novice. I'm following your threads on here, givenergy and givtcp as it seems we are in the same boat. I'm going to give the givenergy cloud template a go as it might give better results. |
|
Hmm, it maybe better to add a new AC3 mode to Predbat to control in this way. Is it just the three switches replacing the Battery mode that is needed, is everything else the same? |
Not sure if everything else ids the same yet. @britkat1980 might be able to give you better behind-the-scenes information. I was told by GivEnergy just after my install when I complained about how lacking the available control is that they work very closely with him..... (passing the buck?) I can send details of all the available settings in the Portal, but as you can see I'm not 100% certain what they all really do. I have posted those details before somewhere in GitHub. I can find them if they would help. There are too many predbat modes. Haha. Many "Warn:....." statuses, Read-Only etc. Too many statuses to be explicit. I have modified my automation as below - |
|
My automation is not picking up when predbat.status moves to or from "Warn: Inverter 0 Write to .......". In theory the automation is triggering any time there is a change in status, but I wonder if these Warn statuses are not really a status and therefore the trigger is missed? At the highlighted time when Idle changed to Warn, and also when Warn changed to Idle the automation should have triggered, but it seems it did not.
|
|
Yes they are real state changes to predbat.status, that's why you can see them in the sensor history The warn: statii are usually transient, the next predbat run usually predbat works OK |
|
If they are real Statuses, why does the automation (above) not fire when it changes to Warn:... and when it changes from Warn: ... Anyway, I have now changed the automation to fire each time the attribute 'last updated' changes. This fires every time predbat recalculates even if there is no change of state. Hopefully this will work round the issue. The real problem is how to get predbat to work natively with the Inverter settings. Freeze Discharge seems an odd one. Freeze Discharge does not appear to ever set any Discharge Timeslot times, so not sure how it is going to do any discharging. Maybe this is a fundamental difference between AC3 and previous Inverters? Here is my newly modified automation in case @Ryuisnod or anyone else is following. |
|
Great I'll have a look though this thanks.
…On Thu, 14 Nov 2024, 12:46 LeeFarm11, ***@***.***> wrote:
If they are real Statuses, why does the automation (above) not fire when
it changes to Warn:... and when it changes from Warn: ...
Anyway, I have now changed the automation to fire each time the attribute
'last updated' changes. This fires every time predbat recalculates even if
there is no change of state. Hopefully this will work round the issue.
*The real problem is how to get predbat to work natively with the Inverter
settings.*
*Freeze Discharge seems an odd one. Freeze Discharge does not appear to
ever set any Discharge Timeslot times, so not sure how it is going to do
any discharging. Maybe this is a fundamental difference between AC3 and
previous Inverters?*
Here is my newly modified automation in case @Ryuisnod
<https://github.com/Ryuisnod> or anyone else is following.
alias: PredbatStatusChangeAutomation2
description: Modify Inverter Settings depending on predbat.status
triggers:
- trigger: state
entity_id:
- predbat.status
attribute: last_updated
conditions: []
actions:
- if:
- condition: or
conditions:
- condition: state
entity_id: predbat.status
state: Charging
- condition: state
entity_id: predbat.status
state: Hold charging
- condition: state
entity_id: predbat.status
state: Freeze charging
- condition: state
entity_id: predbat.status
state: No charge
then:
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_ac_charge_enable
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_discharge_enable
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_charge_enable
else:
- if:
- condition: or
conditions:
- condition: state
entity_id: predbat.status
state: Discharging
- condition: state
entity_id: predbat.status
state: Freeze discharging
then:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_ac_charge_enable
- action: switch.turn_on
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_discharge_enable
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_charge_enable
else:
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_ac_charge_enable
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_charge_enable
- action: switch.turn_off
metadata: {}
data: {}
target:
entity_id: switch.givtcp_td2343g049_force_discharge_enable
mode: single
—
Reply to this email directly, view it on GitHub
<#1607 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNYOW2HENFPCPMKOBOOIL32ASLT3AVCNFSM6AAAAABRPQNSUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZWGI3DSMBTGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I think you are misunderstanding the Freeze Discharge status. Freeze Discharge is NOT a discharge, it is 'freeze the current SoC level and stop it increasing (by solar charging), but allow the battery to discharge if house demand requires it' So effectively it's a capped version of the default Eco mode - Eco mode but don't let the SoC increase from solar generation. It therefore doesn't need any start or end times. |
|
That script is not good when in Read-Only mode. The status continues to be updated each 5 minutes, so while in Read-Only mode (so that user can control the Inverter manually) the automation continues to turn off all the switches each 5 minutes. Now testing another version. |
You just need to add a condition to the automation to check that Predbat read only mode is not set. If it is, the condition will stop the automation |
Yes. I am now testing a new version which does something like that. When I am happy with it I will post it here. |
|
I seem to have a problem with the Load prediction. Not sure if this relates to 3 phase. Between 20:30 and 21:00 yesterday and day before we were using around 9kW. But predbat is predicting that today we will run at about 3.5kW during that time. Maybe only picking up one phase? Or average of 3 phases? Or? |
|
I don't have Car or iBoost. But I do have EVC but it is not used. But log says 20kWh of car/iBoost excluded. Looks like maybe something related and not related to 3 phase. But I have no idea why. I did disable GivEVC within GivTCP settings a couple of days ago. But that should not be relevant?
|
|
I think I must have accidentally turned on 'Car charging hold' at some point. I turned it off and the load predictions now look more sensible. But since I have never used the car charger except once back in April, I don't understand how it could have such a large impact. |
|
It's generally not advised to set days_previous to 1, see https://springfall2008.github.io/batpred/apps-yaml/#understanding-how-days_previous-works so this will have an effect on your prior load history. It's better to look further back (as far as you can without your load history). Do turn switch.predbat_load_filter_modal on to exclude the part-day that you will get in your broken load history. Have a look at the car charging config https://springfall2008.github.io/batpred/apps-yaml/#car-charging-filtering |
Thanks for the pointer. switch.predbat_load_filter_modal was already switched on. |
Thanks. I do not have zappi or Wallbox. I only have a GivEnergy EVC so therefore car_charging_energy presumably finds nothing. The documentation suggests that these alternate figures will only be used if car_charging_energy is commented out. But it is not commented out. So it seems they are also used if car_charging_energy is not valid. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Brought here from britkat1980/giv_tcp#286
Is your feature request related to a problem? Please describe.
GivEnergy 3 phase Inverters appear to be very different in controls to previous Inverters. The controls which predbat uses to control the Inverters are not available on the 3 phase. There are some controls which predbat uses which might be fixable within GivTCP, but there are some controls which predbat relies on which (I think) are simply not available on the Inverter.
Summary problem -
3 phase Inverter does not have any modes. You cannot 'set' Eco or Timed_Export etc.
The GivTCP control of mode does not work, because it does not exist.
If I try setting to any of the other settings, it just reverts back to Eco (paused) next time the inverter is read.
But predbat relies on it.
There are only 3 main controls on the 3 phase Inverter (other than % and Times)
Force AC Charge Enable
Force Charge Enable
Force Discharge Enable
To charge from the grid, the 2 charge switches are set to On.
To discharge to the grid, the Discharge switch is set to On.
The relevant time slots and %s then become active.
I have not found any useful functionality to only using Force AC Charge Enable or Force Charge Enable. They do have an impact but I have not found any useful functionality. In my world so far, they may as well be a single switch.
One of the controls which predbat relies on in apps.yaml is
But switch.givtcp_{geserial}_enable_charge_schedule does not do anything (yet).
With help from @gcoan I have created some helpers/ automations which I think are now working for me.
First improvement - scheduled_charge_enable
Setting up a helper and automation for scheduled_charge_enable was the first big step forward -
I created a helper toggle switch. I called it helper_predbat_enable_charge_schedule.
I then created an automation -
I have commented out REST in apps.yaml -
and I set this is apps.yaml
This works well, except that predbat turns off scheduled_charge_enable during Hold Charging or Freeze Charging.
This results in strange behaviour. I have cheap rate 13:00 - 16:00. This happens -
Further testing with inverter_mode
Because predbat is setting inverter mode via this -
I did set up another helper and automation to set the 3 Inverter controls via the predbat inverter_mode. Unfortunately the predbat inverter mode stays in Eco unless Discharging, so it does not help too much.
Further development using predbat.status
I have now added another automation which takes the predbat.status and updates the 3 switches depending on predbat.status. predbat populates the Timeslots and percentages in advance of the Charge or Discharge periods, so potentially, this might delay the start of those periods by a couple of minutes, but they will end on time because the end slot times are populated.
Only been using this for a couple of hours and looks positive.
But I think I do now see another issue already.
In the GivTCP thread I said this -
I note that the Charge Slot SOC target was not changed (it was previously set at and remains at 4%), but the (global) Charge Up To % was changed by predbat/GivTCP (in this case to 98%). I assume that individual slots SOC targets are therefore not used by predbat, and therefore I have now set Slot 1 SOC to 100%. (I have also set Discharge Slot 1 SOC to 4% making the same assumption).
@gcoan replied with this -
On your question r/e charge slots, Predbat only ever uses slot 1 for charging and discharging and sets the global charge-to limit. So you need to make sure that the other slots are all cleared as otherwise the inverter will start obey those other charge/discharge instructions and Predbat won't know about them.
What I now see is predbat aiming for 90% or 93% or whatever. It sets the global Charge Up To %. But overshoots. I think that global Charge Up to % is not being respected by the Inverter when Force Charge/ Force AC Charge is being used. Will try some more tests when time permits.
The text was updated successfully, but these errors were encountered: