Bijoux problemette with GivTCP

Hi
I am not sure this is an issue solely with GivTCP3.0 or not, and it does not seem to be affecting my installation so far but when I startup predbat, I get the following message in predbat.log

Note: Cannot find battery charge curve (no final curve), one of the required settings for predbat_status, soc_kw, battery_power and charge_rate do not have history, check apps.yaml

It appears that I am missing the predbat_status element., the others are all there and reporting history

Am I correct in assuming that I should add the following to apps.yaml

predbat_status:

• sensor.givtcp2_xxxxxxxxxx_status`

where xxxxxxxxxx is my inverter serial number?

Weasel The sensors you need to have defined in apps.yaml are all defined in the documentation https://springfall2008.github.io/batpred/apps-yaml/#battery-chargedischarge-curves

Predbat status comes from Predbat itself, it doesn’t need to be configured

If you are not able to create a charge or discharge curve then its almost certainly because the sensor history doesn’t have a charge to totally full or discharge to totally empty.

As it explains in the documentation (wot I wrote), the curves are only used to improve the accuracy of the plan

Weasel
No, not correct.

I believe predbat_status is an internal function self-generated within Predbat (which has values like "Discharging", "Idle", etc). I would be looking elsewhere for the issue.

Assuming you are using a recent version of Predbat, go to its web page, and then choose the apps.yaml page. Anything in red there? In particular, are the soc_kw, battery_power, and charge_rate items correctly showing? My suspicion is that they will not be - that you have still got eg sensor.givtcp_xxxxxxxx_soc_kwh and since you have moved to GivTCP3 this has changed to sensor.givtcp2_xxxxxxxx_soc_kwh or something (check in HA).

Or it may be that you have not yet collected sufficient data history to calc the charge/discharge curves since you changed sensor name.

Ooops - crossed with Geoffrey. Sorry

Thank you folks. My GivTCP3 sensors look ok but I do see some errors in the log
Warn: Failed to decode response from http://supervisor/core/api/states/predbat.status
which might point at an issue. I never got GivTCP v2 to work with my installation, but v3.0 seems fine for me

There is nothing obviously amiss with apps.yaml and predbat seems to be working fine.

I do not discharge my battery fully and until I am properly enrolled in an export tariff, I don't really want to, but I do note that this may be necessary to get a good curve.

Meanwhile, I am happy to have a slightly suboptimal set up since I can now import all my juice at off-peak rates whilst taking into account the likely solar generation

Weasel Warn: Failed to decode response from http://supervisor/core/api/states/predbat.status
which might point at an issue

Can you share a fragment of the logfile showing this, doesn’t sound right, never seen it before.

I assume you can look at the predbat.status entity and its attributes OK in HA?

geoffreycoan Once again, many thanks for your assistance - and your thoughts have pushed me in the right direction (hopefully)

I can see the predbat.status entity in HA and although I have entities defined in the apps.yaml, when I look at the HA entities that are referenced are not actually present in HA i.e. my apps.yaml shows

charge_rate:
- number.givtcp2{geserial2}battery_charge_rate
discharge_rate:
- number.givtcp2{geserial2}battery_discharge_rate

and the corresponding entities are not showing in MQTT. In my naivety, I had simply copied and pasted values from an example config. I will dig around to see what the new names for these entities might be

Weasel You don’t mention what inverter you have, but if you only have 1 inverter the lines will be

givtcp_{geserial}_xxxx 

Its only if you have two inverters then you’ll have:

givtcp_{geserial}_xxx
givtcp2_{geserial2}_xxx

And if you have a multi AIO then this is all controlled through the gateway so you need to set geserial to the gateway serial number. The prefix might be givtcp, givtcp2 or givtcp3 depending on how GivTCP has numbered the AIO’s and gateway (suggested tip you change the prefixes to GW, AIO1, AIO2, etc but that will require more changes to apps.yaml to match)

and once again, I show my stupidity - the charge and discharge rate are there as numbers, not sensors - silly me for filtering incorrectly

I have an AIO with a gateway - the gateway is geserial1 and the battery is geserial2, so I think that I have the correct numbers plugged in

PianSom Assuming you are using a recent version of Predbat, go to its web page, and then choose the apps.yaml page. Anything in red there?

This is an easy check that things are set up ok in apps.yaml. The web page should be at
http://[the IP address of the machine running Predbat]:5052

You should see no red, and the working sensors values should be shown correctly

PianSom thanks for the thought. There is nothing running on port 5052, I checked with the netstat command. I can see port 5052 is stated in web.py, but there is definitely nothing running on that port

I can see all the apps.yaml entries on the appropriate screen in the predbat dashboard, and there are no red entries at all. I am not sure where to go next except for perhaps turning up the debug level.

This is not an urgent issue because everything appears to be working well enough

Weasel There is nothing running on port 5052, I checked with the netstat command. I can see port 5052 is stated in web.py, but there is definitely nothing running on that port

you have to be running an 8.4.x version of Predbat AND be using the Predbat add-on. If you are using AppDaemon to run Predbat (as I still am), the web front end isn’t available.

Weasel have an AIO with a gateway - the gateway is geserial1 and the battery is geserial2, so I think that I have the correct numbers plugged in

Yes if it’s a single AIO then you point all the predbat config in apps.yaml to the AIO battery, i.e. givtcp_{geserial2}_xxx

Just make sure the other entries that Predbat needs for the charge/discharge curves are not commented out in apps.yaml. If you don’t get a curve created then its probably because you need to fill/empty the battery in recent (i.e. days_previous) history for predbat to be able to pick it up

geoffreycoan I have not emptied the battery recently. It gets filled (or nearly so) by predbat once or twice per day, but until I get paid an export tariff, it seems wasteful to dump energy.

I suppose I could simply put predbat into monitor mode and let the battery discharge completely, but I like the idea of being able to survive a power cut relatively unscathed. On that note, how often should I completely cycle the battery to keep it healthy?

Weasel If your battery history doesn’t include emptying the battery then Predbat won’t be able to find the discharge curve (which is generally minimal anyway). The fills to full should be enough for it to create the charge curve which is the one where there’s usually more variation and slowdown in rate than the discharge curve.
But either way, it only improves the plan accuracy so isn’t critical to have.

As regards your question ‘how often should I cycle the battery to keep it healthy’ I can only pass on what I’ve gleaned from others on the forum that batteries (particularly AIO’s) can suffer from SoC drops if they are kept full for extended periods of time as the inverter looses track of what the battery charge level is. My battery gets regularly cycled between full and empty and I personally don’t see SoC drops at all.

I’d suggest maybe cycling the battery every few weeks or so, but that’s just my personal opinion

geoffreycoan Thank you sir, I think I shall cycle once a month or so once I am enrolled onto an export tariff and have the vital stuff in the house protected by a few UPSs in case I have a power cut whilst the battery is discharged. Both my wife and I work from home and 24x7 IT availability is important to us. This was the primary driver behind buying a GivEnergy system.

Weasel Good plan

I recently bought a Cyberpower UT850EIG (850VA) UPS to protect my home assistant server and internet from power failures. We have the house on EPS circuits but this will definitely keep the power flowing to those devices if we do have a power cut as the inverter has a finite cutover time

Still to integrate it to HA though ...

I hadn't considered integrating HA with a UPS, and even now am not sure of the utility of it. I have a total of 4 UPSs which have all been renewed this year. My wife and I both have APC BX1600MIs and I have a pair of APC BE850s. There is one in the garage for the Internet stuff (modem, router, switch) plus the gas CH boiler, Hive heating controller and the water softener. The final one is in the lounge and protects the HA appliance, TV and associated gizmos.

Since I have an AIO plus gateway, unless the AIO battery is flat, I only need power for a few milliseconds at a time. I intend to keep a large reserve in the AIO so I can survive a long power cut with minimum fuss. We rarely have power cuts, but given my wife and I both work at home, any power cut can be a massive pain, so we have had UPSs for years and only the one in the lounge is a recent addition.

Weasel Sounds like you are well protected with UPS’s then, I’m a new purchaser as I suffered a Home Assistant database corruption following a series of brief power cuts and power resumptions in short succession.

The thinking on connecting the UPS to HA was to monitor when the UPS power was low and shut HA down cleanly. Basically a backstop to the backstop. But if I move from running HA in a Windows VM to running on a Pi or using Proxmox then this won’t work so maybe it remains on the ideas pile that never happens

Until yesterday (when I threw one away because it was badly misbehaving) I had 4 UPSs too. All used to protect network kit, even though I too have an AIO.

@geoffreycoan - I don't know about Windows, but pretty much every *nix-based OS I have ever come across includes (or one simply adds) the "nut" program. I don't know if you know it, but it is one of those things which is both hugely powerful and yet quite easy for a novice to implement. In short it monitors a UPS and then - if something horrible happens - will send a message to any machine that is listening to it (and usually in particular the machine it is running on). That machine can then - on receiving a message - graceful shut down. In a consumer context, most UPSs have a USB port specifically for this. See also https://www.home-assistant.io/integrations/nut/

I too am mulling Proxmox as my next move.

PianSom
I am glad I am not the only one that has taken a belt and braces approach to powering the home "essentials" 🙂

I have heard good things about Proxmox (disclaimer: I work for Broadcom, the owners of VMware). I have previously used VMware ESXi at home and currently use Windows Hyper-V. One disadvantage of Hyper-V is that there is no real support for USB pass-through, but I have had little/no cause to use physical USB devices on my VMs. Now that VMware Workstation is free, I suppose I could migrate my VMs if I needed USB support since I no longer have a dedicated bare-metal server and run everything from a huge PC - except for HA which now runs on its own appliance

The 2 UPSs that are not connected to a PC will have to "fly solo". There is no easy way top connect a USB cable from them into a physical PC/Pi/Server without buying new hardware specifically for this purpose. If I get a power cut, the UPSs will alert me either by the alarm beeper and/or email notifications.

Weasel
Or you could, I guess, have a tiny little computer (I'm thinking Pi Zero) dedicated to running a Nut server USB-connected to one of your UPSs, then run a Nut client on the machines that you are concerned about to listen in to the server and shut down if/when needed.

Or you could - as you say - just listen out for loud beeping noises 🙂

My AIO has been behaving badly since install, about a year ago. 99% of the time it works just fine. The only exception is if there is a grid failure (something that has happened three times over the year, ALL while I was away from home!), when it has failed miserably to work as a UPS and instead flips either its own RCB, or all the RCBOs on my consumer unit. My installer (at GE's expense, them having shipped me a new unit) replaced the Gateway a couple of months ago - no joy. I have a GE engineer coming next week.