GivTCP 2.1.0 Testing/Bug Reports

@Britkat
This keeps coming in the error log, looks to be linked to the change in value for charging from % to absolute

TheDragon (GivEnergy) Yes, I did wonder my charge rate automation stopped working. Thought I was going loopy with a charge rate of 100W. This seems to have happened with the move to version 2.1.2 (or maybe 2.1.1).

@Britkat I appreciate you're trying to iron out bugs and improve the reliability, but it would have been useful to have been forewarned of the change, or at least for it to be logged in the Github Repository changelog.

Latest Docker version is 2.1.3 - was updated yesterday - not sure what it was to fix as I can't find anything obvious on the git.

anglefire 2.1.3 was to fix the 100w 100%, fixed to the real max W value. However this error is still present, when checking the system logs

I know there's some discussion going on around the power flow % with @cdpuk (givenergy-local) as well.

I was looking at the underlying GivEnergy modbus library, which all the integrations ultimately rely on. It has a hard-limit of 50% and rejects values above that. The code and comment might give insight.

"""Set the battery charge power limit as percentage. 50% (2.6 kW) is the maximum for most inverters."""
    if not 0 <= val <= 50:
        raise ValueError(f'Specified Charge Limit ({val}%) is not in [0-50]%')`

For those that don't have facebook, Mark has put a post about what has changed in 2.1.3 - though apparently there is a bug in that the enable discharge doesn't get enabled automatically when doing a forced export.

GivTCP Update - 2.1.3
Apologies for the bug introduced into 2.1.2. This is now fixed and Force Charge/Export is now working s expected again. As compensation for the issue check out two new features added into 2.1.3:
[2.1.3] - 2023-02-12
BUG FIXES:
Fixed error on garbage invertor output
Force Charge/Export power rate setting from 100(%) to maxInvertorRate
NEW FEATURES:

• Per Invertor MQTT Topic now available
• Overlapping ForceCharge\Export now handled gracefully. You can extend a current Force action byt recalling it with a new duration and it will set a new Force end time

I've updated to 2.13 and now get this error ....
2023-02-14 14:59:47,899 - read - [ERROR] - Invertor Update failed so using last known good data from cache
2023-02-14 14:59:59,285 - read - [ERROR] - Consecutive failure count= 6 -- (<class 'KeyError'>, KeyError('Current_Rate'), <traceback object at 0x7f2f4a28b080>)

Any ideas on how to resolve ? or do I need to wait for another update from GivTCP

Annaka I don't have the answer, but a read error (from the inverter) suggests to me that the inverter isn't responding within the timeout. Maybe try stopping GIVTCP and restarting? If the inverter is busy responding to your app in local mode, or if your battery is in debug mode (during a battery calibration) sending data to the Givenergy portal every few seconds, it may well be too busy to talk to GivTCP as well.

Strangley, with the error above the force charge option works perfectly.

Set a charge for 2 mins at 1700, via run service in Dev tools

Went to GivPortal, and re-read the values on the Inverter, AC Charge was enabled, Start was 1700, end was 1702.
So the force charge now sets the start and end times on the inverter, so there is nothing on GivTCP needed to finish the setting. Also would allow overlapping charges, as its does is write the start and end times.

So i can use this now in my Agile automation, charge if under 25p, set a force of 30mins
If the next slot is also under 25p, all it will do is set a new start and end time, just as the R&D does.
Be sure to have the trigger at min=/30 is on the hour+30secs (Possible) and half hour, to co-incide with Agile slots
Conditions, use a Soc value to prevent it forcing over a set value maybe.

Tim Thanks Tim, I rebooted the Inverter and all seems to be settled again. Must say these latest updates do seem to have made GivTCP a little unstable compared to previous versions. Anyway its free, excellent HA add on, allows multitude of automations and more fun than TV ;-) keep up the good work Britkat

@TheDragon (GivEnergy) @Britkat I'm running 2.1.3 and if I set the Battery discharge Rate to 100 - it sets the discharge to 100 W but if I set it to 3000 it's back to normal.

ispookie666 That was the point of my initial comment; that I was using a %age but had to change to Wattage to get the charge rate right.

Tim don't think this has been fixed.
At least the automation worked ok and did not charge to 100% during the timed charge window

ispookie666 think we are at crossed purposes here. In my timed charge automation, I don’t modify the charge to %. I do that manually and usually no more often than every week or so to reflect the general solar forecast. In December the charge too was 100%, dropping to 80% at the end of January and down to 60% currently. What I do automate is the charge rate which calculates how quickly the inverter needs to charge the battery to reach the current Charge to % given the SoC at the start of the charge window. Up until GivTCP 2, the Home Assistant entity battery charge rate units were % but since 2.1.1 it has been Watts. I modified my Node-RED function mode to update as Watts rather than % and it’s now working ok.

Tim you are way more hands on!
I set up four different scenarios depending on predicted solar generation. I'm hoping it would suffice for the whole year.
Looks like the problems following upgrade have solved itself. I'm using it as Add-on in HA.
I might need to look into running the automation in parallel if GivTCP freezes.