britkat1980 / giv_tcp Goto Github PK

If you set the discharge start time slot followed by the discharge end time slot quickly (e.g. just in the gui or with a service), setting the end time slot overwrites the start time slot with the old value

Sorry if I'm not doing this correctly, never made a bug report on GitHub before.

Docker 2.3.0 works perfectly but since updating to 2.3.1 I now get this:

2023-07-31 07:35:35,694 - startup - [CRITICAL] - Recreating settings.py for invertor 1
Traceback (most recent call last):
File "/app/startup.py", line 256, in
{1: '192.168.76.138', 2: '192.168.76.150'}
if SuperTimezone: outp.write(" timezone=""+str(SuperTimezone)+""\n")
NameError: name 'SuperTimezone' is not defined

Rolling back to 2.3.0 and I'm up and running again.

I'm not sure if the following code is correct, as I would have assumed that the long term energy totals should also be total_increasing and not just total

            if GivLUT.entity_type[str(topic).split("/")[-1]].sensorClass=="energy":
                tempObj['unit_of_meas']="kWh"
                tempObj['device_class']="Energy"
                if topic.split("/")[-2]=="Total":
                    tempObj['state_class']="total"
                else:
                    tempObj['state_class']="total_increasing"

After restarting HomeAssistant I noticed all existing givtcp_* entities became unavailable and plots of these entities only show data before the restart.

There are new entities available, with "_2" added at the end. Switching to these entities works just fine, but all of the graph history is now lost.

Where is this entity renaming coming from and is it possible to undo it? Ideally, I would like history of these entities merged but I am OK losing a couple of days worth of recent data.

Only GivTCP entities are affected. All other entities (including other MQTT ones) have retained their names.

The current config can’t handle the octopus flux tariff. Flux gives you 4 time periods (02:00-5:00,5:00-16:00,16:00-19:00 & 19:00 to 02:00).
it also has 3 import prices and 3 export prices.

https://octopus.energy/smart/flux/

GivTCP currently only supports 2 import and 1 export rates.

I have a gen3 3.6 inverter recently installed, have been working on getting the whole HomeAssistant/batpred/givtcp setup in place, but noticed that batpred was complaining about clock skew/drift. From the GE API I can see UTC times being returned, and see the following in givtcp (version 2.3.3)

/app # curl -s localhost:6345/readData | grep 2023
        "Invertor_Time": "2023-08-21T15:55:42+01:00",
    "Last_Updated_Time": "2023-08-21T15:55:45.396453+00:00",
            "Discharge_Completion_Time": "2023-09-14T12:18:45.403268+01:00",
            "system_time": "2023-08-21 15:55:42",

From the GE API ("https://api.givenergy.cloud/v1/inverter/XXXXXXXXXX/meter-data/latest"

{
  "data": {
    **"time": "2023-08-21T15:55:04Z",**
    "today": {
      "solar": 13.7,
      "grid": {
        "import": 5.7,
        "export": 3.7
      },

I've been able to work around this by setting the timezone for the givtcp container to UTC instead of default (Europe/London), just wanting to confirm this is correct/expected behaviour?

If so I'll happily raise a PR to add some docs

Since updating to 2.2 I'm getting constant Invertor Time Invalid state message

Is this my config causing this or is it a bug?

2023-06-29 20:58:10.836 WARNING (MainThread) [homeassistant.components.mqtt.sensor] Invalid state message '29-06-2023 20:57:52' from 'GivEnergy//Invertor_Details/Invertor_Time'
2023-06-29 20:58:32.194 WARNING (MainThread) [homeassistant.components.mqtt.sensor] Invalid state message '29-06-2023 20:58:14' from 'GivEnergy//Invertor_Details/Invertor_Time'
2023-06-29 20:58:53.569 WARNING (MainThread) [homeassistant.components.mqtt.sensor] Invalid state message '29-06-2023 20:58:35' from 'GivEnergy//Invertor_Details/Invertor_Time'
2023-06-29 20:59:15.321 WARNING (MainThread) [homeassistant.components.mqtt.sensor] Invalid state message '29-06-2023 20:58:56' from 'GivEnergy//Invertor_Details/Invertor_Time'
2023-06-29 20:59:36.685 WARNING (MainThread) [homeassistant.components.mqtt.sensor] Invalid state message '29-06-2023 20:59:18' from 'GivEnergy//Invertor_Details/Invertor_Time'

Existing givtcp entities have stopped working, new ones have been created with a suffix of _2 which are working

I'm running 2.2.3 but this issue appears to have been present since I started using the system in March. I have two batteries connected to my Hybrid Invertor (Gen 2). Home Assistant MQTT reports one device for the inverter, but only one battery device (the master).
My docker compose file contains:

NUMBATTERIES_1=2

The second battery isn't shown in Home Assistant and the following errors are reported (I'm guessing these "duplicates" are the second battery:

2023-07-05 02:19:39.942 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Serial_Number is already used by sensor.givtcp_battery_details_battery_serial_number - ignoring sensor.givtcp_battery_details_battery_serial_number 2023-07-05 02:19:39.944 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_SOC is already used by sensor.givtcp_battery_details_battery_soc - ignoring sensor.givtcp_battery_details_battery_soc 2023-07-05 02:19:39.946 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Capacity is already used by sensor.givtcp_battery_details_battery_capacity - ignoring sensor.givtcp_battery_details_battery_capacity 2023-07-05 02:19:39.950 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Design_Capacity is already used by sensor.givtcp_battery_details_battery_design_capacity - ignoring sensor.givtcp_battery_details_battery_design_capacity 2023-07-05 02:19:39.954 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Remaining_Capacity is already used by sensor.givtcp_battery_details_battery_remaining_capacity - ignoring sensor.givtcp_battery_details_battery_remaining_capacity 2023-07-05 02:19:39.956 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Firmware_Version is already used by sensor.givtcp_battery_details_battery_firmware_version - ignoring sensor.givtcp_battery_details_battery_firmware_version 2023-07-05 02:19:39.958 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cells is already used by sensor.givtcp_battery_details_battery_cells - ignoring sensor.givtcp_battery_details_battery_cells 2023-07-05 02:19:39.960 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cycles is already used by sensor.givtcp_battery_details_battery_cycles - ignoring sensor.givtcp_battery_details_battery_cycles 2023-07-05 02:19:39.962 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Temperature is already used by sensor.givtcp_battery_details_battery_temperature - ignoring sensor.givtcp_battery_details_battery_temperature 2023-07-05 02:19:39.964 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Voltage is already used by sensor.givtcp_battery_details_battery_voltage - ignoring sensor.givtcp_battery_details_battery_voltage 2023-07-05 02:19:39.966 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_1_Voltage is already used by sensor.givtcp_battery_details_battery_cell_1_voltage - ignoring sensor.givtcp_battery_details_battery_cell_1_voltage 2023-07-05 02:19:39.968 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_2_Voltage is already used by sensor.givtcp_battery_details_battery_cell_2_voltage - ignoring sensor.givtcp_battery_details_battery_cell_2_voltage 2023-07-05 02:19:39.970 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_3_Voltage is already used by sensor.givtcp_battery_details_battery_cell_3_voltage - ignoring sensor.givtcp_battery_details_battery_cell_3_voltage 2023-07-05 02:19:39.972 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_4_Voltage is already used by sensor.givtcp_battery_details_battery_cell_4_voltage - ignoring sensor.givtcp_battery_details_battery_cell_4_voltage 2023-07-05 02:19:39.974 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_5_Voltage is already used by sensor.givtcp_battery_details_battery_cell_5_voltage - ignoring sensor.givtcp_battery_details_battery_cell_5_voltage 2023-07-05 02:19:39.976 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_6_Voltage is already used by sensor.givtcp_battery_details_battery_cell_6_voltage - ignoring sensor.givtcp_battery_details_battery_cell_6_voltage 2023-07-05 02:19:39.978 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_7_Voltage is already used by sensor.givtcp_battery_details_battery_cell_7_voltage - ignoring sensor.givtcp_battery_details_battery_cell_7_voltage 2023-07-05 02:19:39.980 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_8_Voltage is already used by sensor.givtcp_battery_details_battery_cell_8_voltage - ignoring sensor.givtcp_battery_details_battery_cell_8_voltage 2023-07-05 02:19:39.982 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_9_Voltage is already used by sensor.givtcp_battery_details_battery_cell_9_voltage - ignoring sensor.givtcp_battery_details_battery_cell_9_voltage 2023-07-05 02:19:39.984 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_10_Voltage is already used by sensor.givtcp_battery_details_battery_cell_10_voltage - ignoring sensor.givtcp_battery_details_battery_cell_10_voltage 2023-07-05 02:19:39.986 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_11_Voltage is already used by sensor.givtcp_battery_details_battery_cell_11_voltage - ignoring sensor.givtcp_battery_details_battery_cell_11_voltage 2023-07-05 02:19:39.988 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_12_Voltage is already used by sensor.givtcp_battery_details_battery_cell_12_voltage - ignoring sensor.givtcp_battery_details_battery_cell_12_voltage 2023-07-05 02:19:39.991 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_13_Voltage is already used by sensor.givtcp_battery_details_battery_cell_13_voltage - ignoring sensor.givtcp_battery_details_battery_cell_13_voltage 2023-07-05 02:19:40.029 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_14_Voltage is already used by sensor.givtcp_battery_details_battery_cell_14_voltage - ignoring sensor.givtcp_battery_details_battery_cell_14_voltage 2023-07-05 02:19:40.031 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_15_Voltage is already used by sensor.givtcp_battery_details_battery_cell_15_voltage - ignoring sensor.givtcp_battery_details_battery_cell_15_voltage 2023-07-05 02:19:40.033 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_16_Voltage is already used by sensor.givtcp_battery_details_battery_cell_16_voltage - ignoring sensor.givtcp_battery_details_battery_cell_16_voltage 2023-07-05 02:19:40.035 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_1_Temperature is already used by sensor.givtcp_battery_details_battery_cell_1_temperature - ignoring sensor.givtcp_battery_details_battery_cell_1_temperature 2023-07-05 02:19:40.129 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_2_Temperature is already used by sensor.givtcp_battery_details_battery_cell_2_temperature - ignoring sensor.givtcp_battery_details_battery_cell_2_temperature 2023-07-05 02:19:40.131 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_3_Temperature is already used by sensor.givtcp_battery_details_battery_cell_3_temperature - ignoring sensor.givtcp_battery_details_battery_cell_3_temperature 2023-07-05 02:19:40.133 ERROR (MainThread) [homeassistant.components.sensor] Platform mqtt does not generate unique IDs. ID GivTCP_Battery_Details_Battery_Cell_4_Temperature is already used by sensor.givtcp_battery_details_battery_cell_4_temperature - ignoring sensor.givtcp_battery_details_battery_cell_4_temperature

Force export works and export starts but doesn't cancel when selected specified time from the drop down list and you have to manually cancel it. GivTCP version 2.1.13. Gen 2 3.6 Hybrid Inverter

Fresh install

Getting the error
Entity sensor.givtcp_ea2302g905_soc_kwh from integration mqtt has state class total_increasing, but its state is not strictly increasing. Triggered by state 3.047 (3.143) with last_updated set to 2023-07-13T22:29:53.669521+00:00. Please create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22

Repeated exceptions in log when connecting to Gen1 HY3.6. Claiming no serial number found, then loops thru Garbage or failed inverter exception over and over.

Only data that seems to be missing from invertor read is GivTCP Import Energy Today kWh from what I can see

Temporarily set Inverter_Ac_x to true to "kid" it an older inverter as a workaround and it seems all inverter data comes through

From replies on GE Community, this seems to be specific for Gen 1 Hybrids on this givtcp release as inverter firmware update is not available to Gen 1s but available to Gen2s

I've been running giv_tcp for about 2 weeks, and twice in that time, it seems to have stopped submitting data, but nothing useful is shown in the logs. Home Assistant simply claims to have not seen any data over mqtt. Restarting giv_tcp seems to restore service.

In this case, data seems to have stopped around midnight, but nothing seems to be reported in the logs

2023-08-22 23:25:17,378 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 00:00:08,948 - Inv1 - read        -  [CRITICAL] - Midnight, so resetting Day/Night stats...
2023-08-23 00:00:10,156 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/PV_Energy_Today_kWh
2023-08-23 00:00:10,157 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Import_Energy_Today_kWh
2023-08-23 00:00:10,157 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Export_Energy_Today_kWh
2023-08-23 00:00:10,157 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Invertor_Energy_Today_kWh
2023-08-23 00:00:10,158 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Self_Consumption_Energy_Today_kWh
2023-08-23 00:00:10,158 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Load_Energy_Today_kWh
2023-08-23 00:00:10,159 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Charge_Energy_Today_kWh
2023-08-23 00:00:10,159 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Discharge_Energy_Today_kWh
2023-08-23 00:00:10,159 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Throughput_Today_kWh
2023-08-23 00:00:10,161 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Rates/Import_ppkwh_Today
2023-08-23 00:00:19,864 - Inv1 - read        -  [CRITICAL] - Midnight, so resetting Day/Night stats...
2023-08-23 00:00:20,875 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/PV_Energy_Today_kWh
2023-08-23 00:00:20,875 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Import_Energy_Today_kWh
2023-08-23 00:00:20,875 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Export_Energy_Today_kWh
2023-08-23 00:00:20,876 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Invertor_Energy_Today_kWh
2023-08-23 00:00:20,876 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Self_Consumption_Energy_Today_kWh
2023-08-23 00:00:20,876 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Load_Energy_Today_kWh
2023-08-23 00:00:20,876 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Charge_Energy_Today_kWh
2023-08-23 00:00:20,876 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Discharge_Energy_Today_kWh
2023-08-23 00:00:20,877 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Today/Battery_Throughput_Today_kWh
2023-08-23 00:00:20,878 - Inv1 - mqtt        -  [ERROR   ] - MQTT error trying to send a <class 'list'> to the MQTT broker for: GivEnergy/FD2249G752/Energy/Rates/Import_ppkwh_Today
2023-08-23 00:00:30,157 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 00:00:30,158 - Inv1 - read        -  [CRITICAL] - Midnight, so resetting Day/Night stats...
2023-08-23 00:00:50,743 - Inv1 - read        -  [CRITICAL] - Midnight, so resetting Day/Night stats...
2023-08-23 00:20:38,880 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 01:15:59,135 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 01:36:06,066 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 01:41:07,978 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 01:46:09,782 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 01:51:11,553 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 02:16:20,504 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 02:26:24,400 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 03:21:48,095 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 03:31:51,604 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 03:36:53,296 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 03:57:00,065 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 04:12:05,483 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 04:17:07,692 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 04:47:18,610 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 05:12:27,783 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 05:22:31,582 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 07:08:13,246 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 07:18:16,943 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-23 07:23:18,710 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping

Here's a couple of graphs from home assistant showing the lack of data (and the data resuming once giv_tcp was restarted in the morning)

I am using 2.3.3 of the giv_tcp docker container (running via podman)

/usr/bin/podman run \
        --cidfile=%t/%n.ctr-id \
        --cgroups=no-conmon \
        --label "io.containers.autoupdate=image" \
        --sdnotify=conmon \
        --replace \
        --detach \
        --name givtcp \
        -p 6345:6345 \
        -e NUMINVERTORS=1 \
        -e INVERTOR_IP_1=192.168.1.20 \
        -e NUMBATTERIES_1=1 \
        -e LOG_LEVEL=ERROR \
        -e NIGHTRATESTART=23:00 \
        -e DAYRATESTART=8:00 \
        -e MQTT_ADDRESS=10.88.0.1 \
        -e MQTT_OUTPUT=True docker.io/britkat/giv_tcp-ma:2.3.3

Polling periods of less than around 15 seconds tend to cause a high degree of errors.
I'd suggest the default is set to 20 seconds with a warning not to go too low?

This doesn’t seem to work anymore since the update could I get some help debugging?

The logs don’t seem to show any issues but none of the sensors are available in home assistant. Any help is appreciated.

Thanks

setChargeRate mentions discharge rate and visa-versa

setChargeRate | Sets the charge power as a percentage. 100% == 2.6kW | /setChargeRate | {"dischargeRate","100"}
setDischargeRate | Sets the discharge power as a percentage. 100% == 2.6kW | /setDischargeRate | {"chargeRate","100"}

Since updating to HA Core 2023.5.3 earlier today, all GiVTCP entities are displayed as 'unavailable'.
I have updated to GiVTCP 2.1.13. I've tried restarts and checked my GivTCP config setting which seem correct.
Reverting to back up from yesterday didn't help.
The GiVTCP log includes text below.
Any ideas / suggestions?
Thanks

2023-05-15 12:59:39,460 - startup - [ERROR] - MQTT Broker process died. Restarting...
2023-05-15 12:59:39,461 - startup - [CRITICAL] - Starting Mosquitto on port 1883
1684151979: mosquitto version 2.0.11 starting
1684151979: Config loaded from /app/GivTCP_1/mqtt.conf.
1684151979: Opening ipv4 listen socket on port 1883.
1684151979: Error: Address in use

The readme says setBatteryMode has a numerical argument, but it actually takes a text string e.g. 'Eco'

setBatteryMode | Sets battery operation mode. Mode value must be in the range 1-4 | /setBatteryMode | {"mode":"1"} | setBatteryMode | 1

My inverter has just been upgraded from a Gen1 to Gen2. Somewhere in the process my ability to pause discharge has been lost.
Is there any known issue with the "enableDischarge" command?
I am accessing this via rest url

I am working around this by changing the discharge rate, so I know my connected etc are all ok

When used as a GUI control (forgive me, I don't know the correct terminology) i.e. a toggle switch - this control appears to work by remembering the "Battery power reserve" setting and then setting it to 100% when turning the toggle ON. When turning the toggle OFF it recalls the remembered setting of Battery Power Reserve.

... or it used to...

Now, it works when toggling it OFF (and sets the power reserve to 100%) but it can no longer be toggled ON again.

It works in an automation and properly sets or resets the power reserve (to remembered state) but if interrogated in a condition such as...

condition: state
entity_id: switch.givtcp_sa2236g166_enable_discharge
state: 'on'

...it fails to execute and the error "This node was not executed and so no further trace information is available." is issued in the trace.

Hi,

Firstly thanks for the great bit of software!

I have a Gen 2 5kw Hybrid(D0.909-A0.909) , with a 9.5kwH battery (3012)

GivTCP (2.1.14) running on Home Assistant 2023.5.4 Supervisor 2023.04.1 Operating System 10.2 Frontend 20230503.3 - latest

Not sure how long this has been happening, but Noticed this in the logs today:

2023-05-31 00:00:50,965 - read - [CRITICAL] - Midnight, so resetting Day/Night stats...
2023-05-31 00:20:13,789 - palm_soc - [CRITICAL] - PALM... PV Automated Load Manager Version: v0.8.3bSoC
2023-05-31 00:20:14,789 - palm_soc - [ERROR] - 404 Client Error: Not Found for url: https://api.solcast.com.au/rooftop_sites//forecasts?format=json&api_key=
2023-05-31 00:20:14,790 - palm_soc - [ERROR] - Error; Problem reading Solcast data, using previous values (if any)
2023-05-31 00:20:14,791 - palm_soc - [ERROR] - Incomplete Solcast data, setting target SoC to 100%
2023-05-31 00:20:14,791 - palm_soc - [ERROR] - Incomplete Solcast data, setting target SoC to 100%
2023-05-31 00:20:14,791 - palm_soc - [ERROR] - Incomplete Solcast data, setting target SoC to 100%
2023-05-31 00:20:14,792 - palm_soc - [ERROR] - Incomplete Solcast data, setting target SoC to 100%
2023-05-31 00:20:15,525 - write - [ERROR] - Setting Charge Target failed: (<class 'AssertionError'>, AssertionError('Unexpected response from remote end: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response'), <traceback object at 0x7fbc04850600>)
2023-05-31 02:26:24,593 - read - [ERROR] - Consecutive failure count= 3 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fdebb665280>)"), <traceback object at 0x7f106a73a2c0>)
2023-05-31 05:32:25,725 - read - [ERROR] - Consecutive failure count= 3 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(IR:183), <traceback object at 0x7fdebb6712c0>)"), <traceback object at 0x7f106a92dc40>)
2023-05-31 05:32:38,488 - read - [ERROR] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(IR:000), <traceback object at 0x7fdebb6714c0>)"), <traceback object at 0x7f106a3c6980>)
2023-05-31 05:32:48,746 - read - [ERROR] - Consecutive failure count= 5 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(HR:113), <traceback object at 0x7fdebb671080>)"), <traceback object at 0x7f106abe5400>)
2023-05-31 15:10:56,725 - read - [CRITICAL] - First time running so saving AC Charge status
2023-05-31 15:10:57,085 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-05-31 15:29:35,478 - read - [CRITICAL] - First time running so saving AC Charge status
2023-05-31 15:29:35,657 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-05-31 16:06:34,712 - read - [CRITICAL] - First time running so saving AC Charge status
2023-05-31 16:06:34,733 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-05-31 16:28:14,669 - read - [ERROR] - Consecutive failure count= 3 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(HR:120), <traceback object at 0x7fa3b1af8d00>)"), <traceback object at 0x7f940d9e9440>)
2023-05-31 16:28:25,424 - read - [ERROR] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(HR:120), <traceback object at 0x7fa3b1add3c0>)"), <traceback object at 0x7f940d3dd940>)
2023-05-31 16:28:38,185 - read - [ERROR] - Consecutive failure count= 5 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(HR:120), <traceback object at 0x7fa3b1af84c0>)"), <traceback object at 0x7f940cfc01c0>)
2023-05-31 16:29:47,777 - read - [ERROR] - Consecutive failure count= 3 -- (<class 'Exception'>, Exception("Garbage or failed Invertor Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fa3b1af0c40>)"), <traceback object at 0x7f940d5f3dc0>)
2023-05-31 16:51:16,750 - read - [ERROR] - Battery Object empty so skipping
2023-05-31 16:51:16,753 - read - [ERROR] - Battery_Cell_1_Temperature is missing from new data, publishing all other data
2023-05-31 16:51:16,754 - read - [ERROR] - Battery_Temperature is missing from new data, publishing all other data
2023-05-31 16:51:16,754 - read - [ERROR] - Battery_SOC is missing from new data, publishing all other data
2023-05-31 16:51:16,755 - read - [ERROR] - Battery_Cell_6_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,755 - read - [ERROR] - Battery_Cell_4_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,755 - read - [ERROR] - Battery_Design_Capacity is missing from new data, publishing all other data
2023-05-31 16:51:16,756 - read - [ERROR] - Battery_Cell_5_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,756 - read - [ERROR] - Battery_Cycles is missing from new data, publishing all other data
2023-05-31 16:51:16,756 - read - [ERROR] - Battery_Cell_8_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,757 - read - [ERROR] - Battery_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,757 - read - [ERROR] - Battery_Cell_3_Temperature is missing from new data, publishing all other data
2023-05-31 16:51:16,757 - read - [ERROR] - Battery_Cell_15_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,758 - read - [ERROR] - Battery_Cell_14_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,758 - read - [ERROR] - Battery_Cell_2_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,758 - read - [ERROR] - Battery_Cell_13_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,759 - read - [ERROR] - Battery_Cell_11_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,759 - read - [ERROR] - Battery_Serial_Number is missing from new data, publishing all other data
2023-05-31 16:51:16,759 - read - [ERROR] - Battery_Cell_2_Temperature is missing from new data, publishing all other data
2023-05-31 16:51:16,760 - read - [ERROR] - Battery_Cell_12_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,760 - read - [ERROR] - Battery_Remaining_Capacity is missing from new data, publishing all other data
2023-05-31 16:51:16,760 - read - [ERROR] - DX2243G390 is missing from new data, publishing all other data
2023-05-31 16:51:16,761 - read - [ERROR] - Battery_Cell_7_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,761 - read - [ERROR] - Battery_Cell_4_Temperature is missing from new data, publishing all other data
2023-05-31 16:51:16,761 - read - [ERROR] - Battery_Cell_16_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,762 - read - [ERROR] - Battery_Firmware_Version is missing from new data, publishing all other data
2023-05-31 16:51:16,762 - read - [ERROR] - Battery_Capacity is missing from new data, publishing all other data
2023-05-31 16:51:16,762 - read - [ERROR] - Battery_Cell_3_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,763 - read - [ERROR] - Battery_Cells is missing from new data, publishing all other data
2023-05-31 16:51:16,763 - read - [ERROR] - Battery_Cell_1_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,763 - read - [ERROR] - Battery_USB_present is missing from new data, publishing all other data
2023-05-31 16:51:16,764 - read - [ERROR] - Battery_Cell_10_Voltage is missing from new data, publishing all other data
2023-05-31 16:51:16,764 - read - [ERROR] - Battery_Cell_9_Voltage is missing from new data, publishing all other data

The garbage ones I am aware is already raised, and the solcast I dont use GIVTCP as I dont have enough API calls for 2 and hour, but the issue is the other errors. Any ideas where to understand where this error may be? Seems that GivTCP cant read it from the inverter?

Hi Guys.
Updated to 2.1.14 yesterday. Battery was charged to 100% last night when it really didn't need to.
Looking at the logs, the solcast URL is invalid with double forward slashes after rooftop sites.
404 Client Error: Not Found for url: https://api.solcast.com.au/rooftop_sites//forecasts?format=json&api_key=

This is a re-introduction of an issue fixed by OckhamSter in a previous version who has already raised a PR

Logs initially append the latest events correctly to the log file but after a day or two, they start to be overwritten by the latest events. This then results in only a couple of events in the rather small sized log file. The overwriting appears to coincide with the creation of “yesterday’s” backup file, which also consists of only the latest events (from today) rather than yesterdays logs. Same for all previous logs back to at least March 2023.
It is suspected that this issue is related in some way to issue 45.
Background info. I have 2 inverters creating 2 log files which both behave in a similar way. GivTCP configured to save log files to the default location and set to INFO level. I am running automations to balance the two inverters, which produce at least 4 info level logs per minute, 24/7 to each file.

To recreate this:

Slide the target_soc to 0% and nothing happens

What I would expect:

The target_soc should be set to the minimum valid value (eg 4%)

Alternatively:

It should not be possible to slide the target_soc to lower than the valid minimum

The correct argument name is:

reservePercent

And not 'dischargeToPercent' as mentioned in the Readme

Can we have REST API for the following two functions:

a)
client.set_mode_storage(slot1,slot2,export)

Where slot1, slot2 are optional and export can be False or True?

And also to call:

client.set_mode_dynamic()

This is to automate timed export, but avoiding having to depend on the cache contents for registers that don't need to change

I am getting many "GivTCP Discharge Completion Time" messages in the log. I can configure Recorder to ignore them but should I have to?

I can't see any in log before V2.2.2 installed.

Hi,

I'm getting an error (log file at the bottom) when trying to pull data from a GEN1 3.6kW inverter.

Worthy notes:

• Running latest v2.1.13, was using HA, however, running locally to debug as well
• Also have a GEN2 5kW, this works perfectly fine with GivTCP
• The GEN1 was working before with GivTCP, until a dodgy firmware update bricked the inverter
• A GivEnergy engineer came today to replace the GEN1 control board
• The GEN1 is now back online and reporting back to the GivEnergy Portal just fine
• The GEN1 does not have a battery attached (before, I noticed GivTCP would only work with NUMBATTERIES_1=1 even though no battery was attached)
• Default config except for LOG_LEVEL=Debug

- INVERTOR_IP_1=192.168.10.16
- NUMBATTERIES_1=0
- MQTT_OUTPUT=False
- MQTT_ADDRESS=
- MQTT_USERNAME=
- MQTT_PASSWORD=
- HOSTIP=
- CACHELOCATION=/config/GivTCP
- TZ=Europe/London

GEN1 3.6kW Log: https://gist.github.com/stuartornum/d25677051bb5d6f201a3d8c84b91f1be

Thanks

Enabling pylint on salewis38 branch of GivTCP repository flags a large number of code issues. Many are down to non-standard Python coding, some may be more serious bugs.
Suggest reviewing and updating once the 2.3 branch is stable (happy to help!).

Currently via REST you can only force a entire refresh of the register set (runAll), but you can't read a particular register

Could we have it so that you can read a register directly?

Being able to write directly would also be nice, but I understand the risk of breaking stuff maybe too high.

The Palm SoC function has been working great until recently but the last three days or so, it's failed to set the SoC logging the following error.

2023-08-09 23:20:14,712 - Inv1 - palm_soc    -  [INFO    ] - Overmorrow correction not needed/applied
2023-08-09 23:20:14,713 - Inv1 - palm_soc    -  [INFO    ] - SoC Calc Summary;         Max Charge Min Charge      Max %      Min % Target SoC
2023-08-09 23:20:14,713 - Inv1 - palm_soc    -  [INFO    ] - SoC Calc Summary;               5.04      -5.36         26        -55         80
2023-08-09 23:20:14,714 - Inv1 - palm_soc    -  [INFO    ] - SoC (Adjusted);                 5.04      -5.36        106         25          
2023-08-09 23:20:14,715 - Inv1 - palm_soc    -  [CRITICAL] - Sending calculated SoC to inverter: 80
Min & max -74 4
Min & max -53 26.0
Min & max -49 114
Min & max -55 26
2023-08-09 23:20:15,569 - Inv1 - write       -  [INFO    ] - Setting Charge Target to: 80
2023-08-09 23:20:16,427 - Inv1 - write       -  [INFO    ] - Setting Charge Target 80 failed: (<class 'AssertionError'>, AssertionError('Unexpected response from remote end: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response'), <traceback object at 0x7fa8cabdc0>)

I can't be certain, but it was working fine before the recent HAOS and Supervisor updates. Interestingly, if I set the SoC manually via the slider in GivTCP the log reports a success.

2023-08-09 23:38:08,581 - Inv1 - write       -  [INFO    ] - Setting Charge Target to: 79
2023-08-09 23:38:10,971 - Inv1 - write       -  [INFO    ] - Setting Charge Target 79 was a success
2023-08-09 23:38:36,380 - Inv1 - write       -  [INFO    ] - Setting Charge Target to: 73
2023-08-09 23:38:38,672 - Inv1 - write       -  [INFO    ] - Setting Charge Target 73 was a success
2023-08-09 23:38:44,029 - Inv1 - write       -  [INFO    ] - Setting Charge Target to: 75
2023-08-09 23:38:46,344 - Inv1 - write       -  [INFO    ] - Setting Charge Target 75 was a success

Also, and perhaps unrelated, there are a number of inverter timeout and sync errors which are not unusual, (I have the poll set to 15s) but I can't recall seeing the battery object error in the past.

2023-08-10 00:42:28,050 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 01:18:39,766 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 02:06:18,167 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-10 02:33:46,505 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 05:03:27,373 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 05:12:26,603 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping
2023-08-10 05:31:43,003 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 05:33:07,572 - Inv1 - write       -  [INFO    ] - Setting dayRate via external trigger
2023-08-10 05:53:35,403 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 06:03:59,317 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 06:05:05,381 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 06:27:23,205 - Inv1 - sync        -  [ERROR   ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-10 07:18:13,654 - Inv1 - read        -  [ERROR   ] - Battery Object empty so skipping

Hopefully this makes sense. This is a great addon BTW. Thanks for the hard work in maintaining this.

Log rotation is working, but it's not adhering to the 7 historical file limit in the TimedRotatingFileHandler call (History = 7). It's keeping all previous versions of the log file.

I believe this only happens when Home Assistant is restarted via Developer Tools but I can test more if no-one else has encountered this issue.

I've recently moved to givTCP from givenergy_local HA addon, and migrating my dashboards over.
I've noticed that the 'GivTCP Charge Time Remaining' & 'GivTCP Discharge Time Remaining' entity values appear to be wrong.

Specifically these entities in question:
sensor.givtcp_ea########_charge_time_remaining
sensor.givtcp_ea########_discharge_time_remaining

Around 8:20 my system went from discharge to charging the battery. battery was 15% full, and battery charging rate around 1.3kw, so that should mean approximately 4hours to 100%.

Based on how the graph reports historic values, it appears there's an incorrect calculation somewhere rather than no data.

the related timestamp entities also seem wrong.
sensor.givtcp_ea########_charge_completion_time = 2023-07-07T08:08:43+00:00
sensor.givtcp_ea########_discharge_completion_time = 2023-07-07T08:27:24+00:00

The current real time is 09:08 (UK timezone), so it puts the charge time as NOW, and discharge in about 15mins time, even battery is in a charging state.

I should be on the latest & greatest versions of software:
Home Assistant 2023.7.1
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest

giv_tcp 2.2.3

Changes to the Export rate set within the Config does not change the value in the sensor, export_rate_2. Constantly reads 0.04.

Cheers, Chris

On HA 2023.05.xxx sensors without a device class are assumed to be numeric. This causes errors in the log for the Inverter Time sensor.

2023-05-07 17:19:36.777 ERROR (MainThread) [homeassistant.components.mqtt.models] Exception raised when updating state of sensor.givtcp_xxxxxxxx_invertor_time, topic: 'GivEnergy/xxxxxxxx/Invertor_Details/Invertor_Time' with payload: b'07-05-2023 17:19:24'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 579, in state
    numerical_value = int(value)
ValueError: invalid literal for int() with base 10: '07-05-2023 17:19:24'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/models.py", line 270, in process_write_state_requests
    entity.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
    if (state := self.state) is None:
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 583, in state
    raise ValueError(
ValueError: Sensor sensor.givtcp_xxxxxxxx_invertor_time has device class None, state class None unit  and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: 07-05-2023 17:19:24 (<class 'str'>)

Hi there,

First-time user setting up on HA. Ten minutes before the battery level is set, this event was fired and gave the following error:

INFO: Accepting connections at http://localhost:3042.
2023-08-01 02:12:46,291 - Inv1 - read - [CRITICAL] - First time running so saving AC Charge status
2023-08-01 02:12:46,300 - Inv1 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-08-01 02:12:54,469 - Inv1 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-08-01 02:12:58,644 - Inv1 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-08-01 02:13:05,872 - Inv1 - read - [CRITICAL] - Publishing Home Assistant Discovery messages
2023-08-01 02:15:37,451 - Inv1 - palm_soc - [INFO ] - PALM... PV Automated Load Manager Version:v1.0.0SoC
2023-08-01 02:15:38,843 - Inv1 - palm_soc - [INFO ] - No second array
2023-08-01 02:15:38,843 - Inv1 - palm_soc - [INFO ] - Successful Solcast download.
2023-08-01 02:15:38,845 - Inv1 - palm_soc - [INFO ] - Applying BST offset to Solcast data
Traceback (most recent call last):
File "/app/GivTCP_1/palm_soc.py", line 704, in
solcast.update()
File "/app/GivTCP_1/palm_soc.py", line 619, in update
pv_est10[i] = int(solcast_data_1['forecasts'][cntr]['pv_estimate10'] * 1000)
IndexError: list index out of range

The Solcast API key is correct as the GivEnergy dashboard uses the same key without issue, showing three days historical and three days predicted. As I am new to this, any additional info you wish for me to provide I'll gladly add.

Thanks!

I have a brand new 13.5kWh GivEnergy AIO with the Giv-Gateway. However, when I try to connect GivTCP I just get errors all the time and no data. I'm using the following:

GivTCP: 2.3.3
AIO: D0.607-A0.607 (latest firmware)
Gateway: D0.0-A0.5 (latest firmware)

I have tried every combination of the AIO_1 and AC_1 flags and all cause the same type of error (just a slightly different error number). I have also tried to sync the Inverter time several times, with no effect. I'm not trying to connect to the Gateway as all the data comes through the battery. The following is the log output from starting the plugin:

2023-08-28 19:21:23,088 - startup - [CRITICAL] - HA MQTT Service has been found at core-mosquitto
2023-08-28 19:21:23,091 - startup - [INFO] - Supervisor Timezone: Europe/London
2023-08-28 19:21:25,096 - startup - [INFO] - Networks available for scanning are: {0: '192.168.xxx.1'}
2023-08-28 19:21:25,097 - startup - [CRITICAL] - Scanning network for inverters...
2023-08-28 19:21:25,097 - startup - [INFO] - Scanning network (1):192.168.xxx.1
2023-08-28 19:21:26,306 - startup - [INFO] - 2 Inverters found on 192.168.xxx.1 - {1: '192.168.xxx.yyy', 2: '192.168.xxx.zzz'}
2023-08-28 19:21:26,520 - startup - [CRITICAL] - Inverter CHxxxxxxxx which is a Gen 1 - All in One has been found at: 192.168.xxx.yyy
2023-08-28 19:21:26,816 - startup - [CRITICAL] - Inverter GWxxxxxxxx which is a Gen 1 - Gateway has been found at: 192.168.xxx.zzz
2023-08-28 19:21:26,817 - startup - [CRITICAL] - GivTCP isAddon: True
2023-08-28 19:21:26,817 - startup - [CRITICAL] - Config directory already exists
2023-08-28 19:21:26,818 - startup - [CRITICAL] - Running Redis
2023-08-28 19:21:26,818 - startup - [CRITICAL] - Setting up invertor: 1 of 1
2023-08-28 19:21:26,903 - startup - [CRITICAL] - Recreating settings.py for invertor 1
2023-08-28 19:21:26,904 - startup - [CRITICAL] - Running RQ worker to queue and process givernergy-modbus calls
2023-08-28 19:21:26,904 - startup - [CRITICAL] - Running Invertor read loop every 5s
2023-08-28 19:21:26,905 - startup - [CRITICAL] - Subscribing MQTT Broker for control
2023-08-28 19:21:26,911 - startup - [CRITICAL] - Starting Gunicorn on port 6345
[2023-08-28 19:21:27 +0100] [35] [INFO] Starting gunicorn 21.2.0
[2023-08-28 19:21:27 +0100] [35] [INFO] Listening at: http://0.0.0.0:6345 (35)
[2023-08-28 19:21:27 +0100] [35] [INFO] Using worker: sync
[2023-08-28 19:21:27 +0100] [36] [INFO] Booting worker with pid: 36
[2023-08-28 19:21:27 +0100] [39] [INFO] Booting worker with pid: 39
[2023-08-28 19:21:27 +0100] [40] [INFO] Booting worker with pid: 40
2023-08-28 19:21:27,887 - Inv1 - mqtt_client - [CRITICAL] - Connecting to MQTT broker for control- core-mosquitto
2023-08-28 19:21:36,164 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fe256fd7c80>)"), <traceback object at 0x7ffaf2d5fa80>)
...
2023-08-28 19:23:03,529 - Inv1 - read - [ERROR ] - 10 failed inverter reads in a row so removing regCache to force update...
2023-08-28 19:23:07,985 - Inv1 - mqtt_client - [ERROR ] - No serial_number found in MQTT queue. MQTT Control not available.
Traceback (most recent call last):
File "/app/GivTCP_1/mqtt_client.py", line 44, in
logger.debug("Serial Number retrieved: "+GiV_Settings.serial_number)
AttributeError: type object 'GiV_Settings' has no attribute 'serial_number'
2023-08-28 19:23:54,899 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fe256fe0e80>)"), <traceback object at 0x7ffaf2d85d00>)

Any help would be appreciated.

Perhaps I'm misunderstanding what the various outputs in GivTcp mean, but the 'battery power' seems to reflect a positive/negative flow of power into/out of the battery (regardless of where its going)? However I find that it does not include exporting to the grid?

I'm trying to use that (perhaps incorrectly) as a guage in Home Assistant but when exporting it sits relatively idle whilst 'battery to grid' is registering the export:

Since the last few days, possibly introduced in v2.2, I have several log errors such as the following:

Exception raised when updating state of sensor.givtcp_fa*****_charge_time_remaining, topic: 'GivEnergy/FA***/Power/Power/Charge_Time_Remaining' with payload: b'2023-07-03T16:00:34.684064+01:00'
Exception raised when updating state of sensor.givtcp_fa*****_charge_time_remaining, topic: 'GivEnergy/FA***/Power/Power/Charge_Time_Remaining' with payload: b'2023-07-03T16:00:46.896739+01:00'
Exception raised when updating state of sensor.givtcp_fa*****_charge_time_remaining, topic: 'GivEnergy/FA***/Power/Power/Charge_Time_Remaining' with payload: b'2023-07-03T16:00:59.291146+01:00'
Exception raised when updating state of sensor.givtcp_fa****_charge_time_remaining, topic: 'GivEnergy/FA****/status' with payload: b'online'
Exception raised when updating state of sensor.givtcp_fa****_charge_time_remaining, topic: 'GivEnergy/FA****/Power/Power/Charge_Time_Remaining' with payload: b'2023-07-03T16:01:13.661348+01:00'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/sensor/init.py", line 583, in state
numerical_value = float(value) # type:ignore[arg-type]
^^^^^^^^^^^^
ValueError: could not convert string to float: '2023-07-02T19:06:48.170542+01:00'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/mqtt/models.py", line 270, in process_write_state_requests
entity.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 590, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 654, in _async_write_ha_state
state = self._stringify_state(available)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 596, in _stringify_state
if (state := self.state) is None:
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/sensor/init.py", line 585, in state
raise ValueError(
ValueError: Sensor sensor.givtcp_fa****_charge_time_remaining has device class 'None', state class 'None' unit '' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '2023-07-02T19:06:48.170542+01:00' (<class 'str'>)

Looks like its unable to cast the datetime string to a float as expected...

Previously working perfectly, since 2.3.2 the SoC has not been and a quick look of the log, while I'm no expert here, doesn't look to healthy. In addition to the IndexError on the palm_soc section, there are increase connection errors. While I'm used to seeing a few, they seem to have increased.

Inverter F/W : D0.450-A0.451
Inverter model: GIV-HY3.6
Battery F/W: 3013
Battery model: 8.2kWh

I have the old inverter firmware switch enabled.

Extract from log.
2023-08-03 00:20:11,354 - Inv1 - palm_soc - [INFO ] - Successful Solcast download.
2023-08-03 00:20:11,358 - Inv1 - palm_soc - [INFO ] - Applying BST offset to Solcast data
Traceback (most recent call last):
File "/app/GivTCP_1/palm_soc.py", line 704, in
solcast.update()
File "/app/GivTCP_1/palm_soc.py", line 619, in update
pv_est10[i] = int(solcast_data_1['forecasts'][cntr]['pv_estimate10'] * 1000)
IndexError: list index out of range
2023-08-03 00:30:03,683 - Inv1 - read - [INFO ] - Saving current energy stats at start of night rate tariff (Dynamic)
2023-08-03 00:56:15,773 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 00:56:18,288 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 01:45:21,410 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 01:50:23,457 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 01:55:25,048 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 01:56:25,325 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 01:56:27,837 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 01:56:41,497 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 02:32:17,967 - Inv1 - write - [INFO ] - Disabling Discharge
2023-08-03 02:32:22,042 - Inv1 - write - [INFO ] - Setting shallow charge 100 was a success
2023-08-03 02:34:57,601 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 03:01:52,173 - Inv1 - write - [INFO ] - Enabling Discharge
2023-08-03 03:01:55,935 - Inv1 - write - [INFO ] - Setting shallow charge 4 was a success
2023-08-03 03:15:16,819 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fac371ac0>)"), <traceback object at 0x7f9e152380>)
2023-08-03 03:15:28,567 - Inv1 - read - [ERROR ] - Consecutive failure count= 5 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:113), <traceback object at 0x7fac371cc0>)"), <traceback object at 0x7f9c8b1680>)
2023-08-03 03:15:40,783 - Inv1 - read - [ERROR ] - Consecutive failure count= 6 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fac371d40>)"), <traceback object at 0x7f9cbaf180>)
2023-08-03 03:15:52,092 - Inv1 - read - [ERROR ] - Consecutive failure count= 7 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fac371c00>)"), <traceback object at 0x7f9cb78340>)
2023-08-03 03:19:42,898 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(IR:110), <traceback object at 0x7fac35d340>)"), <traceback object at 0x7f9e15f1c0>)
2023-08-03 03:20:49,408 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(IR:183), <traceback object at 0x7fac35dcc0>)"), <traceback object at 0x7f9d808380>)
2023-08-03 03:22:28,463 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fac365e00>)"), <traceback object at 0x7f9c889a80>)
2023-08-03 03:26:36,799 - Inv1 - read - [ERROR ] - Consecutive failure count= 4 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:013), <traceback object at 0x7fac35dbc0>)"), <traceback object at 0x7f9e44ca40>)
2023-08-03 03:31:50,759 - Inv1 - write - [INFO ] - Disabling Discharge
2023-08-03 03:31:54,366 - Inv1 - write - [INFO ] - Setting shallow charge 100 was a success
2023-08-03 03:55:50,780 - Inv1 - write - [INFO ] - Enabling Discharge
2023-08-03 03:55:54,460 - Inv1 - write - [INFO ] - Setting shallow charge 4 was a success
2023-08-03 04:30:09,424 - Inv1 - read - [INFO ] - Saving current energy stats at start of day rate tariff (Dynamic)
2023-08-03 04:51:33,412 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 04:56:35,233 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 05:26:45,884 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 05:31:47,950 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 05:38:54,422 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 06:52:33,310 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 07:07:22,172 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 07:17:26,036 - Inv1 - read - [ERROR ] - Battery Object empty so skipping
2023-08-03 07:39:21,444 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 08:06:52,481 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 08:19:03,638 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out
2023-08-03 08:19:06,156 - Inv1 - sync - [ERROR ] - Connection to (192.168.1.117, 8899) failed: timed out

Hi

Tried reinstalling / installing / clearing configs etc, I know the IP of the inverter is right, app working and reports IP, I can see in router, but always get this in log

2023-07-14 20:39:57,064 - startup - [CRITICAL] - HA MQTT Service has been found at core-mosquitto
2023-07-14 20:39:57,077 - startup - [ERROR] - Error scanning for Inverters
2023-07-14 20:39:57,077 - startup - [CRITICAL] - GivTCP isAddon: True

Versions in use -
Home Assistant 2023.7.1
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest

GivTCP
Current version: 2.2.3

Any advice gratefully received..thanks

Calling this service:

service: switch.turn_off
data: {}
target:
entity_id: switch.givtcp_sa2243g277_enable_charge_schedule

Is leading to this error in the log, the same issue happens when I toggle in the GUI

2023-05-19 07:44:08,318 - write - [INFO] - Disabling Charge Schedule
2023-05-19 07:44:13,304 - write - [INFO] - Disabling Charge Schedule
2023-05-19 07:44:27,221 - mqtt - [ERROR] - Error connecting to MQTT Broker: (<class 'TypeError'>, TypeError('payload must be a string, bytearray, int, float or None.'), <traceback object at 0x7fd3f5d2f0c0>)

Hi,

This looks like a great project, exactly what I need. I just had my GivEnergy All in One system installed. Is All in One model supported though? I can see the 'INEVRTOR_AIO_1' environment variable, and 'AllinOne' model in the givenergy_modbus library, but I don't seem to be able to get a valid response from the inverter, regardless whether I set it to True or False.

Running giv_tcp in Docker on Synology NAS.

The log keeps logging in a loop:

2023-07-26 16:47:50,126 - Inv1 - read        -  [DEBUG   ] - ----------------------------Starting----------------------------
2023-07-26 16:47:50,127 - Inv1 - read        -  [DEBUG   ] - Getting All Registers
2023-07-26 16:47:50,127 - Inv1 - read        -  [DEBUG   ] - Connecting to: 192.168.1.36
2023-07-26 16:47:50,128 - Inv1 - queue       -  [DEBUG   ] - Pushed job 82b86077-add2-48ca-978e-e44281a7201f into GivTCP_1
2023-07-26 16:47:50,472 - Inv1 - sync        -  [DEBUG   ] - Connection to Modbus server established. Socket ('192.168.1.12', 47791)
2023-07-26 16:47:50,473 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - IDLE
2023-07-26 16:47:50,474 - Inv1 - transaction -  [DEBUG   ] - Running transaction 1
2023-07-26 16:47:50,476 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:50,724 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:50,729 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:50,734 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 1
2023-07-26 16:47:50,737 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:51,242 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:51,243 - Inv1 - transaction -  [DEBUG   ] - Running transaction 2
2023-07-26 16:47:51,244 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:51,474 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:51,476 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:51,477 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 2
2023-07-26 16:47:51,485 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:51,986 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:51,987 - Inv1 - transaction -  [DEBUG   ] - Running transaction 3
2023-07-26 16:47:51,988 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:52,234 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:52,235 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:52,237 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 3
2023-07-26 16:47:52,237 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:52,739 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:52,741 - Inv1 - transaction -  [DEBUG   ] - Running transaction 4
2023-07-26 16:47:52,742 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:52,974 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:52,976 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:52,977 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 4
2023-07-26 16:47:52,977 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:53,479 - Inv1 - transaction -  [DEBUG   ] - Current transaction state - TRANSACTION_COMPLETE
2023-07-26 16:47:53,482 - Inv1 - transaction -  [DEBUG   ] - Running transaction 5
2023-07-26 16:47:53,484 - Inv1 - sync        -  [DEBUG   ] - New Transaction state 'SENDING'
2023-07-26 16:47:53,714 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2023-07-26 16:47:53,715 - Inv1 - payload     -  [DEBUG   ] - [b'\x00\x00', b'\x00\x00', b'\x00\x00', b'\x00\x8a']
2023-07-26 16:47:53,716 - Inv1 - transaction -  [DEBUG   ] - Adding transaction 5
2023-07-26 16:47:53,717 - Inv1 - transaction -  [DEBUG   ] - Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2023-07-26 16:47:54,237 - Inv1 - queue       -  [DEBUG   ] - Starting BLPOP operation for queues rq:queue:GivTCP_1 with timeout of 405
2023-07-26 16:47:54,672 - Inv1 - read        -  [ERROR   ] - Consecutive failure count= 11 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'ValueError'>, ValueError('hour must be in 0..23'), <traceback object at 0x7feb490da7c0>)"), <traceback object at 0x7f9cb57d4940>)
2023-07-26 16:47:54,675 - Inv1 - read        -  [ERROR   ] - 10 failed inverter reads in a row so removing regCache to force update... 

Any advice would be greatly appreciated.

Martin

EDIT: Please cancel this issue. The pkl files are fine. I was using the HA file editor to view the files and I think it is trying and failing to unpickle the files, so my observation that the pkl files are all with the same error message is incorrect. The error message is from the file editor, not the contents of the pkl file.

Original content:
All the .pkl files have the same error message in them:

'utf-8' codec can't decode byte 0x80 in position 0: invalid start byte

I believe (I might be wrong) that these files hold state information used by GivTCP to "remember" settings.

What might be wrong and can I fix it or is it something only britkat1980 can fix?

I believe that Eco(Paused) just sets Battery Power Reserve to 100% in order to disable discharge. It would appear though, that 100% is not a valid setting for Battery Power Reserve, either from HA or from the portal. 99% is however a valid setting and it is suggested that GivTCP could use this instead of 100%.

Calling the getCache endpoint gives an error, in the logs I see:

2023-05-30 20:33:50,165 - app - [ERROR] - Exception on /getCache [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 2525, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1823, in full_dispatch_request
return self.finalize_request(rv)
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1842, in finalize_request
response = self.make_response(rv)
File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 2153, in make_response
rv = self.json.response(rv)
File "/usr/local/lib/python3.10/site-packages/flask/json/provider.py", line 309, in response
f"{self.dumps(obj, **dump_args)}\n", mimetype=mimetype
File "/usr/local/lib/python3.10/site-packages/flask/json/provider.py", line 230, in dumps
return json.dumps(obj, **kwargs)
File "/usr/local/lib/python3.10/json/init.py", line 238, in dumps
**kw).encode(obj)
File "/usr/local/lib/python3.10/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
File "/usr/local/lib/python3.10/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
File "/usr/local/lib/python3.10/site-packages/flask/json/provider.py", line 122, in _default
raise TypeError(f"Object of type {type(o).name} is not JSON serializable")

Upgraded from Version 2.2.4 to 2.3.0. After upgrade I get many errors like this:

2023-07-30 16:00:30,860 - Inv1 - read - [ERROR ] - Consecutive failure count= 11 -- (<class 'Exception'>, Exception("Garbage or failed inverter Response: ERROR:-(<class 'KeyError'>, KeyError(HR:243), <traceback object at 0x7f804e95c0>)"), <traceback object at 0x7f821f4e80>)

I have restored to 2.2.4 and tried upgrade again. Same problem. Restored again.

(Interestingly, even though in the configuration inverters 2 and 3 are disabled, givtcp goes through a scan on the network for servers. It finds my (only) inverter (a Gen 1 Hybrid) AND my Humax TV box which it interrogates and fails to get inverter info from!
I have noticed that even on 2.2.4 it does this as well - though it doesn't cause any problems and hence seems unrelated to this issue)

I have tried to use statistic card with the grid voltage sensor but this is not listed and in the HA suport info it says that this needs to be flaged to the developer . CAn we have please the gris voltage as one of the statistics entities. The reason this is critical in mine and many peoples cases is that the local rid network is very high voltage and stops export of energy if it exceads 253v. This is often the case and statistics of this are needed. to correlate the loss of export and the gris voltage .Many thanks Simon

Spelling mistake for new client reboot call:

def reboot_invertor(self):

If not "wrong" then inconsistent ?