I certainly get the battery sensors when I change line 284 in sensor.py
if not batt.battery_serial_number:
to
if batt.battery_serial_number:
(which presumably just bypasses the sanity check)
Not sure I have 86 kWh remaining though! That would be a lot of batteries!!
Actually that looks like it’s an underlying issue with the modbus as givtcp has the same factor of 10 discrepancy.
EDIT: ok - not actually sure what that number is, but I have 2 bats and it doesn’t seem to be kWh. This is data directly from the modbus - currently fully charged. They’re 5.2kWh batteries.
Blockquote
I have one forecast for each string and template sensors to group the data together as required.
For those of us struggling with Covid brain fog (my excuse, I suck at templates), care to share your template sensor?
In other news, integration has been solid for me for me since my last update.
Also, there’s something else not quite right with the add batteries nested for loops. Presumably we’re expecting each battery to show up as a device. At the moment it only seems to do the first.
If I tweak this code and run the async twice with 0 and 1 as battnum I get both my bats:
for batt_num, batt in enumerate(coordinator.data.batteries):
# Only add data for batteries if we can successfully read the serial number
LOGGER.info("S/N: '%s'", batt.battery_serial_number)
if not batt.battery_serial_number:
async_add_entities(
BatteryBasicSensor(
coordinator, config_entry, entity_description, batt_num
)
for entity_description in _BASIC_BATTERY_SENSORS
)
else:
LOGGER.warning("Ignoring battery %d due to missing serial number", batt_num)
I’ve been testing now since the new release and generally everything has been good however every now and then I get some strange numbers that screw up the home assistant figures and graphs for the day. Here’s an example of the battery percentage jumping to 54,319% and the battery charge and discharge figures for the day turning into some crazy numbers.
I’ve also seen the PV energy today sensor add 40 units on just before midnight once.
I’ve noticed that the random spikes appears to be a common problem with energy sensors in home assistant and it seems to be related to when the sensor is unable to retrieve the required data due to communication/network errors. The suggestion is that by adding availability to the sensor code this resolves the problem.
Energy Integration Spike - Configuration - Home Assistant Community (home-assistant.io)
Is this something that could be added ?
I have already added a first attempt at detecting the bad data, which has worked for me, but perhaps there’s more to it. The trick is to find a simple and reliable indicator that the data is bad and can’t be trusted. At the moment, it looks for when the inverter and charger temperatures report zero, which is obviously extremely unlikely. When it sees that, it marks all sensors as unavailable until the next read.
A couple of questions:
When you see bad energy dashboard data, has it been caused by the energy readings dropping to zero momentarily? Or did the values spike upwards?
Also, when you see a bad data point for a given sensor, are those temperature sensors still reporting normal values for the exact same point in time?
So on the example given above I can see the temperature sensor spikes down from 39 to 25 and at the same point the Battery Discharge Today sensor spikes up from 2 units to 2,124 units and then back down. The battery percent and battery charge today sensors all spike up as well at the same moment in time.
I seem to have a knack for finding a way to not get the expected result.
Integration removed and re-added but still have the same 15 entities so no battery related new ones. Tried without & with restarting HA in between removing & reinstalling the integration.
What blindingly obvious thing am I missing?
I assume you got the new “number of batteries” prompt when re-adding? Anything in the logs? Any new devices registered against the integration or just the inverter?
My battery comms issue still isn’t resolved, making it quite hard to investigate things like this.
Not sure if that’s the problem for @DickiePhitt
You’d still expect to see the battery percent sensor show up for the inverter. Seems more trouble getting HACS to update.
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.
If you go into HACs, you can force it to redownload the integration:
HACS > Integrations > GivEnergy Local > (3 dots) > Redownload
I’ve installed the latest version and its found my battery now. However both values keep cycling between a real value and zero.
Additionally the charge % looks reasonable, however the Remaining capacity seems to be way off as its showing 108.39kWh for a 8.2kW battery.
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.
No. You can only connect once. I have to disable my docker to test.
