All looks fine:
However the battery charge and discharge on the Energy Dashboard gave some funny errors but they seem to have gone now I went to take a screen clip.
Many thanks for your wesom work, @cdpuk .
I also saw some errors related to HA statistics but I think that was just because they were brand new sensors and it was waiting for a couple of values for them to be usable on the dashboard. Been absolutely fine since then.
Glad to see it working for others. Anyone tried re-adding the integration to get the battery device showing up?
I did. Also changed my IP to a static one at the same time. Adding the battery on re-install worked as expected.
Glad to see it working for others. Anyone tried re-adding the integration to get the battery device showing up?
I’ve tried doing this but the battery hasn’t appeared (It was working fine with the battery support branch of the previous version. In the logs I see (I’ve masked out my inverter serial number):
2022-06-26 17:13:53 ERROR (SyncWorker_7) [givenergy_modbus] Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
2022-06-26 17:13:54 ERROR (SyncWorker_7) [givenergy_modbus] Did not receive expected response type: ReadHoldingRegistersResponse != ReadInputRegistersResponse
2022-06-26 17:13:54 ERROR (SyncWorker_7) [givenergy_modbus] Returned base register (0) does not match that from request (60).
2022-06-26 17:13:55 ERROR (SyncWorker_7) [givenergy_modbus] Returned base register (60) does not match that from request (120).
2022-06-26 17:13:55 ERROR (SyncWorker_7) [givenergy_modbus] Did not receive expected response type: ReadInputRegistersResponse != ReadHoldingRegistersResponse
2022-06-26 17:13:56 ERROR (MainThread) [custom_components.givenergy_local] Error fetching Inverter data: Error communicating with API: HR:013
2022-06-26 17:13:56 WARNING (MainThread) [homeassistant.config_entries] Config entry 'Solar Inverter (S/N **********)' for givenergy_local integration not ready yet: None; Retrying in background
2022-06-26 17:14:06 ERROR (SyncWorker_1) [givenergy_modbus] Transaction failed
2022-06-26 17:14:06 ERROR (SyncWorker_1) [givenergy_modbus] Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 164 bytes (44 received)
NoneType: None
2022-06-26 17:14:06 ERROR (SyncWorker_1) [givenergy_modbus] Did not receive expected response type: ReadHoldingRegistersResponse != ModbusIOException
2022-06-26 17:14:07 ERROR (MainThread) [custom_components.givenergy_local] Error fetching Inverter data: Error communicating with API: HR:120
2022-06-26 17:14:21 WARNING (MainThread) [custom_components.givenergy_local] Ignoring battery 0 due to missing serial number
Looks a lot like the usual comms error that we can’t do much about right now (except try again a few times). The released version pretty much contains what was on that battery-support branch.
I’ve tried a few times, but each time I’m still seeing the following line.
I get a device for the inverter each time which has normal looking readings, but no device for the battery.
WARNING (MainThread) [custom_components.givenergy_local] Ignoring battery 0 due to missing serial number
Ah, right. That’s a safety check I added because a multi-battery system needs to use the serial numbers to uniquely identify each battery in HA. I always get that error, I thought due to my faulty comms, but perhaps there’s something more to it.
I’m a bit stuck this end until the comms issue gets fixed, but feel free to investigate. Using the debug script in the repo, this is all I can get:
# ./scripts/debug.py -b 1 <host> | grep battery_serial
<snip>
root INFO Decoding and printing battery 0 data...
"first_battery_serial_number": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
"battery_serial_number": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000",
I was hoping everyone else with working batteries would have this filled in.
So that worked for me. I get the following (I’ve replaced the numbers in the serial with n
root INFO Decoding and printing battery 0 data...
{
"battery_serial_number": "DYnnnnGnnn",
"v_battery_cell_01": 3.275,
"v_battery_cell_02": 3.279,
"v_battery_cell_03": 3.277,
"v_battery_cell_04": 3.279,
"v_battery_cell_05": 3.277,
"v_battery_cell_06": 3.279,
"v_battery_cell_07": 3.277,
"v_battery_cell_08": 3.272,
"v_battery_cell_09": 3.277,
"v_battery_cell_10": 3.275,
"v_battery_cell_11": 3.274,
"v_battery_cell_12": 3.275,
"v_battery_cell_13": 3.275,
"v_battery_cell_14": 3.277,
"v_battery_cell_15": 3.277,
"v_battery_cell_16": 3.275,
"temp_battery_cells_1": 25.7,
"temp_battery_cells_2": 24.5,
"temp_battery_cells_3": 24.9,
"temp_battery_cells_4": 25.9,
"v_battery_cells_sum": 52.353,
"temp_bms_mos": 36.1,
"v_battery_out": 52.68,
"battery_full_capacity": 177.71,
"battery_design_capacity": 158.72,
"battery_remaining_capacity": 143.99,
"battery_status_1_2": [
0,
0
],
"battery_status_3_4": [
14,
16
],
"battery_status_5_6": [
0,
0
],
"battery_status_7": [
0,
0
],
"battery_warning_1_2": [
0,
0
],
"battery_num_cycles": 2,
"battery_num_cells": 16,
"bms_firmware_version": 3007,
"battery_soc": 81,
"battery_design_capacity_2": 160.0,
"temp_battery_max": 25.8,
"temp_battery_min": 24.5,
"usb_inserted": true,
"e_battery_charge_total_2": 17.1,
"e_battery_discharge_total_2": 11.4
}
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?
1 Like
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.