No I didn’t get the batteries prompt. Or any additional entities showing. Only the inverter IP prompt.
My HACS version is 1.25.5
Frontend version. 20220529181005
I suspect my problem is more with HACS but I’m not seeing any way to check for/force an update.
Thanks, problem was with HACS as we thought. Sorted:-
For the sake of anyone else in the same position who cannot get the battery entities to appear -
I have the latest version of HACS (1.25.5) but within HACS/Integrations the GivEnergy Local integration was not being listed at all, despite my having had the original Inverter-only version of the integration working for a month or two.
I went back to basics and downloaded GivEnergy Local repository again into HACS.
Now loading the GivEnergy Local Integration from Settings/Devices & Services/Integrations has loaded the latest version with 26 entities.
PS The prompt I got for the inverter IP had a 2nd line with no information, just a space for a number. I assumed this was the number of batteries per @cdpuk earlier post to me. Might be worth making clear what this is asking for.
So I tried the new version. Weirdly does the same although I can’t spot the problem. Maybe someone else with multiple batteries can confirm?
I get this in the logs (serial replaced with XX)…
The serial seems to point to battery no. 2 (batt_num 1)
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:598
Integration: Sensor (documentation, issues)
First occurred: 11:04:40 AM (2 occurrences)
Last logged: 11:04:40 AM
Platform givenergy_local does not generate unique IDs. ID BEXXXXXXXX_battery_soc already exists - ignoring sensor.battery_charge
Platform givenergy_local does not generate unique IDs. ID BEXXXXXXXX_battery_remaining_capacity already exists - ignoring sensor.battery_remaining_capacity
I’m going to guess that the prompt issue is because your browser session hadn’t been fully reloaded since the update? Same thing quite often happens on HA core upgrades and a quick refresh sorts it out. If anyone else has issues, please do log an issue on Github. You should be seeing:
The remaining capacity being way off is probably an issue in givenergy_modbus - the integration isn’t transforming the value in any way.
In other news, I made an update last night that changes how connections are made to the inverter. I was previously getting loads of missed updates with frequent gaps of several minutes. It’s now working very reliably with updates every 30 seconds.
Unfortunately even with the latest version I’m simply having no luck connecting:
I have GivTCP running in a docker container, and that is working mostly. I assume (dangerous I know) there should be no issues with multiple modbus connections.
FWIW I often have my HA install and a development system both polling the inverter without issues. Also tried givtcp a few times in parallel - also fine.
If you’re getting absolutely nothing back I’d be thinking about trying some packet captures if possible - try to understand how the two approaches differ.
Maybe it’s a poll timing thing. The docker container polls every 5 secs, so it probably holds on to the connection long enough for a second to not connect.
Poll rate: No way to change it, though the hard coded rate was changed from 60s to 30s in a recent release. Care is needed here as some amount of time is required to read the data. This is typically a few seconds, but varies depending on whether a partial or full refresh is being done, and more time is required for each battery. A fast refresh rate will also bump up disk usage by HA’s recorder. If this does get added, it needs some warnings attached.
EPS power: Should be easy. I’d be happy to add this in. I’d appreciate feedback when added - mine isn’t connected so I’ve got no way to test it.
Poll rate isn’t actually that important, mainly just from a visual perspective in monitoring and to get slightly better estimated costs from the energy dashboard. If there was a way to change it (under caution/warning), it’d be pretty awesome. (I’m running HA on SSD/VM, so hardware resources are not so much of a concern in my case)
Thank you on the EPS side! Of course, very happy to feedback. Any reason you are not utilising EPS? It’s fantastic for lighting circuits and essentials like internet and heating system etc.
I actually prefer a higher poll rate for some automations. I’m currently using excess solar to run the immersion heater in the afternoon. I have an automation that runs the immersion, but kills it if the solar generation drops too low. Without the high poll rate, the immersion will continue running at 3.2kW and sap power from the batteries or worse, the grid.
EPS looking like it’s works a treat thank you again!
I run a couple of sockets and my lighting circuits off the EPS. The sockets power a small UPS for my internet, the boiler and heating system and the fridge/freezer. The EPS reading allows me to keep an eye on the general power usage of these devices (in addition to smart plugs with power monitoring dotted around the house, to give an overall idea of what’s utilising power). Aiming to have the majority of the house powered by solar/battery for peak rate hours.
Firstly, GREAT work on this integration. I’ve already created some dashboards (albeit very basic as I get to grips with HA).
I took a look at some automations, and I can see the services for GivEnergy are:
Activate Eco Mode
Timed Discharge
Times Export
Set Charge Power and
Set Discharge Limit.
However I couldn’t see the one to activate Timed Charge from Grid of the batteries.
My use case: I am using the Timed Charge from Grid to make use of cheap electricity in my off peak rate (12:30 - 4:30am). Once the battery is charged at 4:30, the house will then draw upon this stored power to run until the panels start generating at about 7am ish. By this time the charge in the battery is sub 50%. Because I am only charging from panels and grid during the off peak house, I don’t think my battery will replenish with any spare generation. meaning that by 5pm on a cloudy day my batteries are flat. what id like to do is set an automation to charge off peak using Timed Charge mode, and then once my battery hits 50% switch over to Eco Mode for the rest of the day so any overage goes into my batteries. this should allow me to use spare generation into the battery for usage later in the day and then for me to set another automation in the evening to switch back to Timed Charge.
Good stuff. I guess I never considered it important as I don’t live in an area that has a problem with power cuts. I honestly have no idea when we last had one. Like you I’ve got a UPS that can keep the internet, NAS and Wi-Fi going. I’m sure the fridge can go an hour without power but not sure I’d cope the same without internet!
If anything I may just wire in a standard socket at some point, just to cover any emergencies with an extension lead.
Should be doable relatively easily. I’ll see if I can find some time to add it over the next couple of weeks.
I guess I added the things I needed first! I’m a big exporter (6kW panels, no EV yet), so my system is optimised and automated to make the most of the Octopus Agile Outgoing rates by charging from solar at times of lower rates and discharging to the grid when it can make the most profit.
This integration is great, proved to be easy to install and get started, producing a useful set of entities very easily (I failed to get other options working). So many thanks - it meets my needs very well.
As a new GivEnergy owner I am a bit confused by some of the sensors: eg inverter_output_today and consumption_today. Consumption_today can sometimes decrease, which feels wrong. Maybe I need to find the GivEnergy modbus spec.
For my purposes it is easy to create a consumption sensor that provides the ‘house’ usage of the form (pseudo code): consumption = (grid_import - grid_export) + (battery_discharge - battery_charge) + PV_generation
I guess strictly this takes no account of inverter losses. I have a local smart meter input and PV measurements from my Solar Edge system. With this approach I can select which device to use for each field; but differences in update interval can create misleading results. I am still assessing this.