search

britkat1980 / giv_tcp

TCP connection (from inverter) and MQTT implementation
86 stars 37 forks source link

setChargeRate and setDischargeRate #255

Open BrianUK6 opened 1 month ago

BrianUK6 commented 1 month ago

MQTT Control setChargeRate and setDischargeRate In v2 these were Watts and the inverter battery charge/discharge levels could be directly controlled, and as Inverter level it applies to all attached batteries. These map to 72 & 73 via the Giv API and control the inverter charging level. GivTCP v2 did the same. So everything was in agreement.

v3 docs (https://github.com/britkat1980/giv_tcp/blob/main/SETTINGS-GUIDE.md) and code now say percentage, but that is wrong. They should remain as Watts and the v2 code restored. v3 converts % to watts by looking at a battery max power, but how does it know what battery to use it a mixed battery setup. Let alone the inverter has the max ch/disch power control - not the battery. Logic doesn't work.

If you want to add 2 new fields to pass in a %, then add them as new - plus you'll need to identify which battery you are referring to.

For ref Palm.py directly uses reg 72/73 to set 0/3000 (AC3) [completely out of date for additional equipment] Plus it sets % via
id": 77,"name": "AC Charge Upper % Limit",

britkat1980 commented 1 month ago

v3 Uses the same charge rate controls and logic using watts as v2. there is no change there. There is an additional control which has been added which uses the AC Rate Limit registers which provides a complementary 0-100% control. This has greater granularity than the traditional derived watts control. you can choose which you wish to use.

If you think this is not the case can you provide more details on the system you are using and what the errors you are seeing.

BrianUK6 commented 1 month ago

ok - I'll do code compares etc. My code didn't change, but on switching over to v3 I received errors about setting the Charge/Discharge rate.

I have a verification loop that is triggered by my Zappi starting to charge meaning and I have cheap IOG. I then change the battery charge/dischard accordingly. I wait for the MQTT to change to give verification and also do a read via the GE API to get the charge/discharge rate (it does not cache that). When all agree then I can guarantee everything is what it should be and then switch other large house items on/off as needed. If that is not done the changes that don't work are missed. Costs money to miss them :-) :-)

The foolproof checking immediately did not work with v3 - it was giving mismatches. Tracked down to the using 0/3000 (which has worked for eons) and finding it needs to be a %.

I'll get to the bottom of it and report back.

BrianUK6 commented 1 month ago

Looks like my sys was using older code that I had cleaned up and at the same time made the Charge/Disharge agree with the docs at that time. Have found various versions of old givtcp that do things differently.

Anyways, I'll bring my code up to GivTCP v3.

Also, looking through all the G.3 code (for this purpose) highlighted how there are so many different ways to acheive the same thing and get from A to B... must be nightmare to verify them all....

APoller1 commented 4 weeks ago

I have a similar issue. I can change the charge Rate, but it reverts in about 2 seconds to 2600. Wherever I change it, it is changed back to 2600. HA, Giv App or portal. Any suggestions?

APoller1 commented 4 weeks ago

It worked in v2.