search

Emilv2 / huawei_solar

Home Assistant custom component for Huawei inverters
Apache License 2.0
174 stars 41 forks source link

Getting Data with 2 Inverters and 3 batteries #52

Open EmAnzi3 opened 2 years ago

EmAnzi3 commented 2 years ago

Hello, I'm struggling to setup my system in HA, having a double inverter, one linked to a battery, the other to the Power Sensor and the other 2 batteries. In configuration.yaml I did as follows:

  - platform: huawei_solar   
    host: '192.168.178.67'
    optimizers: true
    battery: true
    slave: 2

I can correctly read Power Sensor parameters but they looks completely different from the ones showed from the app in the main page. Any clue about how to properly setup the integration?

Emilv2 commented 2 years ago

What is wrong with the data shown?

EmAnzi3 commented 2 years ago

What is wrong with the data shown?

I'll show you an example from the Energy Flow readings, the ones the Power Sensor and Batteries.

Energy Flow Power Sensor Bat1 Bat2 Bat3

Ideally I'd like to recreate on HA the same flow available on Fusion but I don't quite understand how.

Emilv2 commented 2 years ago

So which information you want is still missing?

EmAnzi3 commented 2 years ago

So which information you want is still missing?

My goal is to be able to recreate, on HA, the Energy Flow provided by Fusion Solar.

JacoboSanchez commented 2 years ago

You did not show the values you get for that instant. While using batteries the data provided by the inverter is less straightforward so you would need to figure out how to compute the values you want and create sensors for them. I will try to explain some concepts but I will use my memory for that as my installation is not currently operative and can not check them to verify if I remember correctly so do not take the following as the truth.

First of all when you use batteries input power and active power (this is the value of the entity) are not the same. Input power is what your panels are generating (DC) and that can go to charge batteries (charge-discharge-power positive?) or to the inverter (active power). Active power may fully go to your home (power_meter_active_power <= 0: You are buying energy so all active power is consumed) or it can be partially exported to grid (power_meter_active_power >0: Home usage would be active power - power_meter_active_power).

That covers most of the lines you see in the flow diagram. However due to this values being fetched one by one from the inverter and obtained from different devices you may observe some missing/exceeding W at some point.

A basic example, you have power imported/exported to the grid on attribute power_meter_active_power as a negative/positive value. Some energy flow charts already support that but if you want to have separate sensors, you can define it like:

     import_from_grid:
       friendly_name: "Power imported from grid"
       unit_of_measurement: "W"
       value_template: >-
         {% set pm_active_power = state_attr('sensor.sun2000_XXXX', 'power_meter_active_power') | int %}
         {% if pm_active_power < 0 %}
             {{ (-1*pm_active_power) | int }}
         {% else %}
             {{ (0) | int }}
         {% endif %}

Another example about home usage mentioned previously. "active power" tells you the AC current going out of the inverter. To compute how much is using your house you have two options:

  1. power meter active power is positive: you are exporting to grid so your home is consuming less than active power you have to do active power - power meter active power
  2. power meter active power is negative: you are buying from grid so you are consuming more than the active power from the inverter. You have to do active power + (-1*power meter active power) == active power - power meter active power

TLDR: Home consumption is just active_power-power meter active power for all cases

In my case i observed that sometimes due to differences in the measures I got negative values (that should not be possible) so my sensor has a check to cut those values:

     home_usage:
       friendly_name: "Home usage"
       unit_of_measurement: "W"
       value_template: >-
         {% set active_power = states('sensor.sun2000_XXXX') | int %}
         {% set power_meter = state_attr('sensor.sun2000_XXXX', 'power_meter_active_power') | int %}
         {% if power_meter < active_power %}
             {{ (active_power - power_meter) }}
         {% else %}
             {{ (0) | int }}
         {% endif %}
EmAnzi3 commented 2 years ago

@JacoboSanchez, thanks for the tips. With your hint I successfully created the "Power imported from grid" and "Home usage" entities which are more or less matching Fusion values. Now, about the attributes got from the Power Sensor, I'm a bit struggling in understanding the PV input (I thought it was "input_power" but the values sensibly lower than the one provided by Fusion) and, in particular, batteries charge/recharge values. Below values are referring to this moment where there is not solar contribution.

day_active_power_peak: 0
reactive_power: -81
power_factor: -0.755
efficiency: 655.35
grid_frequency: 50
grid_voltage: 390.4
grid_current: 0.337
line_voltage_A_B: 389.3
line_voltage_B_C: 382.5
line_voltage_C_A: 388.5
phase_A_voltage: 232.7
phase_B_voltage: 212.3
phase_C_voltage: 223
phase_A_current: 0.326
phase_B_current: 0.311
phase_C_current: 0.32
power_meter_active_power: -2315
input_power: 0
grid_A_voltage: 232.8
grid_B_voltage: 214.3
grid_C_voltage: 224.8
active_grid_A_current: -2.44
active_grid_B_current: -8.37
active_grid_C_current: -0.53
active_grid_power_factor: -0.935
active_grid_frequency: 49.97
grid_exported_energy: 0.69
grid_accumulated_energy: 197.36
active_grid_A_B_voltage: 387.8
active_grid_B_C_voltage: 377.7
active_grid_C_A_voltage: 392
active_grid_A_power: -513
active_grid_B_power: -1752
active_grid_C_power: -52
startup_time: '2021-11-30T06:42:42+00:00'
shutdown_time: '2106-02-07T05:28:15+00:00'
internal_temperature: 35
device_status: On-grid
system_time: '2021-11-30T18:09:41+00:00'
model_id: 428
model_name: XXX
serial_number: XXX
rated_power: 8000
nb_pv_strings: 2
grid_standard: CEI0-21
grid_country: Italy
nb_optimizers: 0
nb_online_optimizers: 0
storage_running_status: running
storage_current_day_charge_capacity: 4.78
storage_current_day_discharge_capacity: 4.39
storage_working_mode_a: 0
storage_unit_1_working_mode_b: 7
storage_time_of_use_price: 0
storage_lcoe: 0
storage_maximum_charging_power: 10000
storage_maximum_discharging_power: 8800
storage_power_limit_grid_tied_point: 2147483647
storage_charging_cutoff_capacity: 100
storage_discharging_cutoff_capacity: 15
storage_forced_charging_and_discharging_period: 60
storage_forced_charging_and_discharging_power: 0
storage_state_of_capacity: 15
pv_string_01_voltage: 0
pv_string_01_current: 0
pv_string_02_voltage: 0
pv_string_02_current: 0
unit_of_measurement: W
friendly_name: XXX
icon: mdi:solar-power
device_class: power
JacoboSanchez commented 2 years ago

You have to be clear and provide examples to help others understand what you are asking for. If I didn't post examples of configuration from what I was explaining probably it would be harder to you to try to understand my post. Let's see... yo say you dont undertand the PV input values but you don't post what values you get, how or what Fusion app is showing, also attributes are from a moment with 0 incoming power... I can not provide any advice with that info.

Same about batteries. What values are you obtaining? keep in mind that battery charge discharge power (W) are not present (they were in previous versions of the integration) in the attributes list. As stated in the README of the integration there are specific home assistant sensor entities with such values imagen

EmAnzi3 commented 2 years ago

@JacoboSanchez, sorry for the lack of information, I had not much time during the day. I now collected more info, see Excel file, beside the unit measurement difference (W in HA, kW on the app), my first guess is that there is a sensitive variation of values based on the reading moment, seems like HA gets higher data frequency. In most of cases PV input values seem underestimated compared to the app ones but, once again, it might be just an issue related to reading time. Thanks for you support. FusionSolar.xlsx

JacoboSanchez commented 2 years ago

I have not time to check the excel at this moment but I can confirm you that Fusion app does have a 5minutes update time while the home assistant does update values a lot more often. So it is somehow expected to have different values:

I would recommend you to analyze graphs of the whole day production so you can see if they have the same production curve (for example creating a sensor for input power and creating a historic graph card in a HA dashboard)

EmAnzi3 commented 2 years ago

I can confirm you that Fusion app does have a 5minutes update time while the home assistant does update values a lot more often.

OK, that's a sort of relief, I'll keep an eye on the data to see how it goes. Can I bother you for a very last question? Which FusionSolar entities or attributes shall I utilize for the HA energy page? Thanks again.

JacoboSanchez commented 2 years ago

Check this comment in other thread

EDIT: Both daily_yield or total_yield can be used but daily_yield may have some issues on the daily reset time if system time is not the same in inverter and home assistant so I recommend to use total_yield for produced energy

EmAnzi3 commented 2 years ago

Check this comment in other thread

EDIT: Both daily_yield or total_yield can be used but daily_yield may have some issues on the daily reset time if system time is not the same in inverter and home assistant so I recommend to use total_yield for produced energy

So, I set it up as in the attached image. For batteries I utilized entities storage_total_charge, storage_total_discharge while for solar panels I utilized total_yield.

For grid consumption I utilized energy_used.

      energy_used:
        friendly_name: "Energy Consumption"
        unit_of_measurement: 'kWh'
        value_template: >
          {% if states('sensor.total_yield') | float(0) > 0 and state_attr('sensor.sun2000_8ktl_m1','grid_exported_energy') | float(0) > 0 and state_attr('sensor.sun2000_8ktl_m1','grid_accumulated_energy') | float(0) > 0 %}
          {{ '%0.2f' | format(states('sensor.total_yield') | float(0) - 
                            state_attr('sensor.sun2000_8ktl_m1','grid_exported_energy') | float(0) + 
                            state_attr('sensor.sun2000_8ktl_m1','grid_accumulated_energy') | float(0)) }}

For return to grid I utilized grid_exporterd_energy:

      grid_exporterd_energy:
        friendly_name: "Grid Exported Energy"
        unit_of_measurement: 'kWh'
        value_template: "{{ state_attr('sensor.sun2000_8ktl_m1', 'grid_exported_energy') | float(0) }}"
        device_class: energy

Capture Given this, I'm not sure if the obtained result might be reasonable or not, FusionSolar provides more Power info rather than Energy ones. Any feedback is appreciated. HA-20211202 HA-20211201

JacoboSanchez commented 2 years ago

If you read the grid consumption value, it is in the "Electricity grid" section. That does not refer to your house consumption but the energy imported from the grid. I would use just the value of grid_accumulated_energy for that

EmAnzi3 commented 2 years ago

I would use just the value of grid_accumulated_energy for that

Done but with that parameter seems like my house is absorbing a bit too much... 😄 Capture

JacoboSanchez commented 2 years ago

Energy is an cumulative value, not instant power like W. And those are total energy values so at the time of setting it HA initializes the increment from 0 to the total value... you will have to wait until tomorrow so HA knows the increments produced on the current day

EmAnzi3 commented 2 years ago

you will have to wait until tomorrow so HA knows the increments produced on the current day

Hi, seems like situation isn't really improving. Capture Capture1

Emilv2 commented 2 years ago

Yes that doesn't look correct, it looks like somewhere Wh is being interpreted as kWh.

Emilv2 commented 2 years ago

What do the values of the Energy Consumption template sensor look like?

EmAnzi3 commented 2 years ago

What do the values of the Energy Consumption template sensor look like?

Hi, please refer to attached image, but yes, seems like there is a unit issue. Capture1

About entities I got the codes from a Community thread but I suppose unit measurements are wrong.

      grid_accumulated_energy:
        friendly_name: "Grid Accumulated Energy"
        unit_of_measurement: 'kWh'
        value_template: "{{ state_attr('sensor.sun2000_8ktl_m1_bt20c0026947', 'grid_accumulated_energy') | float(0) }}"
        device_class: energy
      grid_exporterd_energy:
        friendly_name: "Grid Exported Energy"
        unit_of_measurement: 'kWh'
        value_template: "{{ state_attr('sensor.sun2000_8ktl_m1_bt20c0026947', 'grid_exported_energy') | float(0) }}"
        device_class: energy
Emilv2 commented 2 years ago

I think the issue is those drops to zero, which gives those jumps of ~350kWh. Unknown values are cast to 0 instead of unknown. I had that issue as well with some template sensors, let me see how I fixed that.

Emilv2 commented 2 years ago

Don't do float(0) but float, I think that should fix your issue. With float(0) you specify that invalid numbers should be cast to 0, so if for some reason (restart, ...) the value is incorrect your sensors drops to 0. HA will think the meter has rolled over and do nothing, once the value is correct again the sensor will jump back to 350kWh and HA adds 350kWh to your energy used. With float invalid values propagate and HA will use the old value until it's valid again.

EmAnzi3 commented 2 years ago

Don't do float(0) but float, I think that should fix your issue. With float(0) you specify that invalid numbers should be cast to 0, so if for some reason (restart, ...) the value is incorrect your sensors drops to 0. HA will think the meter has rolled over and do nothing, once the value is correct again the sensor will jump back to 350kWh and HA adds 350kWh to your energy used. With float invalid values propagate and HA will use the old value until it's valid again.

Thanks for the tip, tomorrow I'll figure out if worked, unfortunately today the batteries generated 2x 21 kWh absorption peaks from the grid, having 2 blackouts. Apparently is an issue with the device itself, I had to unflag the option to get energy from the grid. Capture

EmAnzi3 commented 2 years ago

Don't do float(0) but float, I think that should fix your issue. With float(0) you specify that invalid numbers should be cast to 0, so if for some reason (restart, ...) the value is incorrect your sensors drops to 0. HA will think the meter has rolled over and do nothing, once the value is correct again the sensor will jump back to 350kWh and HA adds 350kWh to your energy used. With float invalid values propagate and HA will use the old value until it's valid again.

So, situation isn't really changed applying proposed solution. Am I doing something wrong?

      grid_exporterd_energy:
        friendly_name: "Grid Exported Energy"
        unit_of_measurement: 'kWh'
        value_template: "{{ state_attr('sensor.sun2000_8ktl_m1', 'grid_exported_energy') | float }}"
        device_class: energy
      grid_accumulated_energy:
        friendly_name: "Grid Accumulated Energy"
        unit_of_measurement: 'kWh'
        value_template: "{{ state_attr('sensor.sun2000_8ktl_m1', 'grid_accumulated_energy') | float }}"
        device_class: energy

Capture Capture1

skenhall commented 2 years ago

Closely following this thread and others like it as I have a similar setup (2 inverters, 1 battery & 1 smart meter), but when using this integration only one inverter's data shows up - the one without battery... So would really like to understand what configuration of SDongle and Inverter you are using @EmAnzi3 as you can get data from all connected devices! (I have been through the firmware process together with Huawei support and are now on version V100R001C00SPC139 for inverters and V100R001C00SPC124 for SDongle) image

EmAnzi3 commented 2 years ago

@skenhall, I had a similar problem at the beginning because I had slave: 1 at the beginning but in my configuration I had to set it on slave: 2. Give it a shot. Consider that my firmware versions are V100R001C00SPC135 for inverters and V100R001C00SPC123 for SDongle.

EmAnzi3 commented 2 years ago

@Emilv2, BTW I got fixed the zeros issue, this is how:

      grid_exporterd_energy:
        friendly_name: "Grid Exported Energy"
        unit_of_measurement: 'kWh'
        value_template: >
          {% if state_attr('sensor.sun2000_8ktl_m1','grid_exported_energy') | float(0) > 0  %}
          {{ state_attr('sensor.sun2000_8ktl_m1', 'grid_exported_energy') | float(0) }}
          {% endif %}
        device_class: energy
      grid_accumulated_energy:
        friendly_name: "Grid Accumulated Energy"
        unit_of_measurement: 'kWh'
        value_template: >
          {% if state_attr('sensor.sun2000_8ktl_m1','grid_accumulated_energy') | float(0) > 0  %}
          {{ state_attr('sensor.sun2000_8ktl_m1', 'grid_accumulated_energy') | float(0) }}
          {% endif %}
        device_class: energy

Now I just need to figure out how to properly setup a Power Flow card.

skenhall commented 2 years ago

@skenhall, I had a similar problem at the beginning because I had slave: 1 at the beginning but in my configuration I had to set it on slave: 2. Give it a shot. Consider that my firmware versions are V100R001C00SPC135 for inverters and V100R001C00SPC123 for SDongle.

Thanks for quick reply! This is what I get in the log when using slave: 2, and no sensor appears: image

When I use slave: 1 I get info from one of the inverters and the log looks like this: image

I'm thinking we perhaps something different in inverter settings? Not much to set there, but the Dongle parameter Start address for automatic address allocation that can be set via local WLAN and the App I have it set to 1. Same for you or other value?

EmAnzi3 commented 2 years ago

I'm thinking we perhaps something different in inverter settings? Not much to set there, but the Dongle parameter Start address for automatic address allocation that can be set via local WLAN and the App I have it set to 1. Same for you or other value?

I have the same values, unfortunately I feel like I can't help you much, I'm not really a pro. 😉 @Emilv2, after some cross-check I noticed that, in a situation like mine with double inverter and 3 batteries (2 batteries read on an inverter, 1 on the other), the integration isn’t able to read properly the whole system. Currently I'm on slave 2 where I have 2 batteries and power sensor, therefore I'm unable to get data from the other battery on slave 1 Straight question, would it be possible for the integration to read data both from slave: 1 and slave: 2 simultaneously?

Emilv2 commented 2 years ago

@EmAnzi3 Do you want to read one inverter from slave 1 and the other from slave 2, or do you want to read from different slaves on one inverter?

EmAnzi3 commented 2 years ago

@EmAnzi3 Do you want to read one inverter from slave 1 and the other from slave 2, or do you want to read from different slaves on one inverter?

Currently I'm set on slave: 2, in this way I read data from 1 inverter having Power Sensor and 2 batteries, but in this way I'm missing the information coming from the other inverter with the third battery sent on slave: 1. Practical example, in total today I had a Charge Capacity = 6.64 kWh and Discharge Capacity = 6.22 kWh, but from slave 2 I only got Charge Capacity = 4.92 kWh and Discharge Capacity = 4.59 kWh, meaning that I'm missing 1.72 kWh Charge Capacity, and 1.63 kWh Discharge Capacity, available on slave: 1. In short, I'd need to read 1 inverter on slave 1 and another inverter on slave 2.

Emilv2 commented 2 years ago

Does this not work, or am I misunderstanding you?

sensor:
  - platform: huawei_solar   
    host: '192.168.0.123'
    battery: true
    slave: 1
  - platform: huawei_solar   
    host: '192.168.0.124'
    battery: true
    slave: 2
EmAnzi3 commented 2 years ago

Does this not work, or am I misunderstanding you?

sensor:
  - platform: huawei_solar   
    host: '192.168.0.123'
    battery: true
    slave: 1
  - platform: huawei_solar   
    host: '192.168.0.124'
    battery: true
    slave: 2

No because both inverters have the same IP, 192.168.178.67, I suppose one is master, one is slave. I need to get data from the same IP address but both from slave 1 and slave 2.

skenhall commented 2 years ago

Actually to follow Modbus terminology it is Home Assistant and this integration that is the master. According to the Huawei Modbus Interface Definition, it is then the SDongle that is the first slave with address 0 and the each connected inverter is a sub-slave. Illustration of this from the interface definition document, chapter 6.2.2.3: image

However this is exactly what I have tried, but not succeeded to sort out! My setup is according to illustration below and when I set slave: 1 I get data from the 8KTL-M1 inverter, but I can't get data from the 10KTL-M1 inverter by setting slave to 2 (and I have tried 0 and even 3, but without success...) image

I would be very happy if someone could help pointing out the problem and solution!

skenhall commented 2 years ago

Actually to follow Modbus terminology it is Home Assistant and this integration that is the master. According to the Huawei Modbus Interface Definition, it is then the SDongle that is the first slave with address 0 and the each connected inverter is a sub-slave. Illustration of this from the interface definition document, chapter 6.2.2.3: image

However this is exactly what I have tried, but not succeeded to sort out! My setup is according to illustration below and when I set slave: 1 I get data from the 8KTL-M1 inverter, but I can't get data from the 10KTL-M1 inverter by setting slave to 2 (and I have tried 0 and even 3, but without success...) image

I would be very happy if someone could help pointing out the problem and solution!

I have now done some further research using separate Modbus tool, and there seems to be something not working as it should in Huawei's implementation - at least that is my suspicion :) I have posted an "Ask for Help" in their community forum, to see if there are any leads: https://forum.huawei.com/enterprise/en/problem-addressing-cascaded-inverters-via-modbus-tcp/thread/799941-100027

(And I have been investigating this a bit, I have had two mails sent during November to Huawei support staff, but there was not even an answer back on those... Perhaps I try a third time now :) )

EmAnzi3 commented 2 years ago

(And I have been investigating this a bit, I have had two mails sent during November to Huawei support staff, but there was not even an answer back on those... Perhaps I try a third time now :) )

Following your thread too, let's see if we get some light at the end of the tunnel.

skenhall commented 2 years ago

There is some light coming!

I got reply from Huawei support today, and it turns out there is no automatic address allocation - at least not for this purpose (I asked for further clarification on this).

So: You have to log in using each inverter's local WLAN and find the RS485_1 setting for the used ´Com address´ for that inverter: image

In my case I had address 1 on the slave and 16 on the master - and then I can communicate with them separately. Inverter at address 1: ` C:\Temp>modpoll -m tcp -a 1 -r 30070 -t 4 -l 10000 -o 5.0 -0 -c 1 192.168.1.194 modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator Copyright (c) 2002-2021 proconX Pty Ltd Visit https://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: MODBUS/TCP, FC3 Slave configuration...: address = 1, start reference = 30070 (PDU), count = 1 Communication.........: 192.168.1.194, port 502, t/o 5.00 s, poll rate 10000 ms Data type.............: 16-bit register, output (holding) register table

-- Polling slave... (Ctrl-C to stop) Reply time-out! -- Polling slave... (Ctrl-C to stop)

Inverter at address 16: C:\Temp>modpoll -m tcp -a 16 -r 30070 -t 4 -l 10000 -o 5.0 -0 -c 1 192.168.1.194 modpoll 3.10 - FieldTalk(tm) Modbus(R) Master Simulator Copyright (c) 2002-2021 proconX Pty Ltd Visit https://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: MODBUS/TCP, FC3 Slave configuration...: address = 16, start reference = 30070 (PDU), count = 1 Communication.........: 192.168.1.194, port 502, t/o 5.00 s, poll rate 10000 ms Data type.............: 16-bit register, output (holding) register table

-- Polling slave... (Ctrl-C to stop) Reply time-out! -- Polling slave... (Ctrl-C to stop)

` @Emilv2 would it in the configuration be possible to add a list of slave id, optimizers flag and battery flag for same IP address?

EmAnzi3 commented 2 years ago

Hello guys abd Merry Christmas. Any development about this issue?

Emilv2 commented 2 years ago

I think that shouldn't be too complicated. Are you saying your can also read out optimizer data this way?

EmAnzi3 commented 2 years ago

I think that shouldn't be too complicated. Are you saying your can also read out optimizer data this way?

Hi, as explained in my previous posts, having 2 inverters and 1 dongle setting slave only in one place ("2" in my case) doesn't give me the whole picture. On slave "1" I have information about part of my solar production and on of the 3 batteries. In short, I need to get info from slave 1 and slave 2.

Emilv2 commented 2 years ago

Ok, I see now what you meant. I'm thinking about how to specify which register value should be used with which slave without making the configuration overly long, any idea?

EmAnzi3 commented 2 years ago

Ok, I see now what you meant. I'm thinking about how to specify which register value should be used with which slave without making the configuration overly long, any idea?

Not sure I can give you many tips about it. Checking values between Fusion Solar app and HA I can only say that Total/Daily Yield are underestimated in HA, same for batteries charge/discharge. Accumulated and exported energy seems to be fine.

Emilv2 commented 2 years ago

Checking values between Fusion Solar app and HA I can only say that Total/Daily Yield are underestimated in HA, same for batteries charge/discharge.

I don't see how that is relevant to the question?

prezesBB commented 2 years ago

hello, I have the same problem... on slave: 1 I have data only from SUN2000-10KTL-M0 (master inverter with dongle), when I have slave: 2, in HA I return data only from SUN2000-8KTL-M1

VederJay commented 2 years ago

Same here: two inverters, one on slave 1 and one on slave 2. A configuration like this seems like it would do the trick without being overly complicated: 

sensor: 
  - platform: huawei_solar
    host: '192.168.x.y'
    slaves:
      - slave: 1
        optimizers: false
        battery: true
      - slave: 2
        optimizers: false
        battery: false

Would be terrific if that could be made possible, as then I can get the full picture of what my installation is doing.

prezesBB commented 2 years ago

Same here: two inverters, one on slave 1 and one on slave 2. A configuration like this seems like it would do the trick without being overly complicated:

sensor: 
  - platform: huawei_solar
    host: '192.168.x.y'
    slaves:
      - slave: 1
        optimizers: false
        battery: true
      - slave: 2
        optimizers: false
        battery: false

Would be terrific if that could be made possible, as then I can get the full picture of what my installation is doing.

when I use this value, I have this comment: Invalid config for [sensor.huawei_solar]: [slaves] is an invalid option for [sensor.huawei_solar]. Check: sensor.huawei_solar->slaves. (See ?, line ?).

VederJay commented 2 years ago

when I use this value, I have this comment: Invalid config for [sensor.huawei_solar]: [slaves] is an invalid option for [sensor.huawei_solar]. Check: sensor.huawei_solar->slaves. (See ?, line ?).

I think you misunderstood my comment. I was responding to Emilv2's question in proposing a straightforward configuration:

Ok, I see now what you meant. I'm thinking about how to specify which register value should be used with which slave without making the configuration overly long, any idea?

My proposal will not work unless and until Emilv2 (or someone who knows enough Python to do a PR) decides it's the way forward and implements it.

VederJay commented 2 years ago

I'm trying to understand the code but I'm completely confused by the "AsyncHuaweiSolar". What is that thing? An object of some kind? From which class - where is the class definition? How do I update its properties (I need to alter the slave before getting more values) ? Creating a second of those doesn't work, I then get "could not read register value, is an other device already connected?" (I'm from the Java world, maybe I'm just not getting something Python related here?)

VederJay commented 2 years ago

Alright, found it, some other repo apparently. https://gitlab.com/Emilv2/huawei-solar/-/blob/master/src/huawei_solar/huawei_solar.py

This is getting to be a deep rabbit hole for a quick update. Really hoping one of the more experienced devs can take this up...

VederJay commented 2 years ago

So, I got it working by manually tweaking all the files on my HA installation. In huawei_solar.py, I updated the AsyncHuaweiSolar class so that the get-method also takes a slavenumber parameter. Cascading from that, also the decode_response and time_offset. In sensor.py, I updated the HuaweiSolarSensor class so that it has an added attribute slave, which I set when the objects are created. Furthermore, every get call inside this class then needs to include the slave.

To create multiple HuaweiSolarSensor, I basically duplicated the code in async_setup_platform. That should of course be a proper loop, making use of the multiple slaves from the configuration, but I didn't find any examples on using an array in the configuration so I just hardcoded it for my use case while awaiting a clean solution.

VederJay commented 2 years ago

So, although my manually updates files work, it's not a clean solution. I got confused by the name "inverter" (line 164):

inverter = AsyncHuaweiSolar(
            host=config[CONF_HOST], port=config[CONF_PORT], loop=hass.loop, slave=config[CONF_SLAVE]
        )

When actually this object isn't an inverter at all, it's the modbus connection. The same connection needs to be reused for both inverters, whereby for each get the slave needs to be specified. As it currently stands, with 2 sensors, I've had to specify a "delay" in fetching values over modbus for the second slave, otherwise the calls start interfering. This delay, needing to be large enough that the calls from slave 1 and slave 2 don't overlap, of course then introduces... delay. A better solution is probably to have a single sensor (with multiple derived sensors) that gets updated, so that it can call all required values (from all inverters) sequentially as fast as possible, removing the need for delay between slave 1 and slave 2.

And configuration of which values need to be fetched would also be a good thing; by removing all the ones you don't need, you can substantially increase the refresh rate for the values you do need.