With the risk of becoming pedantic: you could define an “availability_template” instead of checking if the sensors are 0
Interesting to hear that you also saw the yield numbers decrease in FusionSolar. I’ll put your formula into the documentation when I do the next update.
Thanks! I didn’t know that!
This is something that a lot of people on various forums have observed. There was an intense discussion in a German PV forum where this could be coming from. There have also been various queries to Huawei support but no definite answers. The most likely answer is that the yield figures represent the energy on the AC side and that Huawei factors in conversion losses when the energy is converted from DC to AC (when being discharged from the battery). Therefore you would see the battery discharge (DC side) decrease faster than the yield (AC side) increases.
PS: Did you already have the chance to check why I don’t see the checkbox to get the advanced features of integration? (see above)
That formula includes grid energy that was used to charge battery at night though.
Using that formula right now (night time, battery discharged) gives me 11.69kwh, FusionSolar has a yield today of 7.27kwh.
The difference is about the amount of energy used to charge from the grid.
FusionSolar is able to account for it well enough, energy used to charge the battery doesn’t show up as consumption and when that energy is discharged it doesn’t count as self sufficiency.
How it accounts for all that though I’m not sure.
That is a good point though. I never charge the battery from the grid. That makes no sense in Germany as we have no reduced rates at night.
If charging from the grid always starts at a specific time, then you could track that amount yourself and include it in the formula.
I missed that question about the checkbox. It should always be visible when running 1.0.0a2. Can you use de “redownload” button in HACS, check the “Use beta versions” checkbox, and select 1.0.0a2 from the list?
The error when using more than 1 slave should be gone now.
PV yield (kWh) = Daily yield inverter 1 + Daily yield inverter 2 + Battery Day Charge - Battery Day Discharge
PV yield (kWh) 8.33 AM (now) = 3,44 + 0,28 - 3,78 = -0,06kWh
I already redownloaded version 1.0.0a2 multiple times, but the checkbox doesn’t show. I also deleted my browser cache, rebooted HA, deleted the integration manually from the config folder and reinstalled, anything. But the checkbox doesn’t show.
The error when using multiple inverters is gone. Working fine. I just don’t get the advanced features.
Update: Retried it this morning and now I’m getting the checkbox. Very strange. Maybe some kind of caching problem. Apparently, I was still using the old integration yesterday as the naming of the sensors has only changed today. Very quick first observation: The sensors become “unavailable” much more often than with the old version. But this is just a subjective first impression. Will continue testing.
Did you have energy left in the battery from yesterday? Than of course, that would lead to a wrong calculation. I didn’t have that case yet, but this will of course be a problem, because the “Energy discharged today” will then include energy from yesterday. I have to think about how this can be solved.
[quote=“ffm777, post:1262, topic:132350”]
will then include energy from yesterday. I have to think about how this can be solved.
[/quote] yes from march to october I often have 50%-60% on Luna2000 from previous day. But i will buy soon an EV and problem will solved by itself 
.
But what happens to daily_yield after midnight? It resets to 0 but doesn’t it increase anymore when the battery is discharging?
I tried changing the Grid Charge Cutoff SOC for the Battery through HA, it worked.
Although there seems to be some validation that restricts it to 70% max…
That explains why the 85% it had been set to with FusionSolar was underlined in red.
yes it seems remain to “0”, but if I take a look into “Reports” of Fusion solar I find different value for “PV Yield (kWh)” each value (every 1h) is calculated in kWh (of course 
) and is updated with a delay of 2 hour.
I tried to compare that value from report:
(yesterday)
Fusion solar report result for “PV Yield (kWh)” (see second pic → green column): 24,32kWh
but there’s a column that calculate “Inverter Yield (kWh)” too (, (see second pic → yellow column): 19,17kWh
but “Inverter Yield (kWh)” (is “daily Yield” in Fusion solar) I think isn’t equal to “PV Yield (kWh)” less battery charge/discharge
this is yesterday values of my inverter/battery:
|Yield (kWh)|19,17|
|Discharge (kWh)|-11,32|
|Charge (kWh)|15,04|
|Total energy kWh|22,89| **(but “PV Yield (kWh)” in fusion solar report is : 24,32kWh)**
maybe fusion solar use integral to calculate kWh from kw?
Hi everyone, anyone make this intégration works without sdungle and above all spc 117 version ? Because im not able to downgrade it neither make it works on this version… any idea?
I found the same but with total values, mayby it happends similar for daily values too. What I found, during the night the value of battery discharge is little higher than the total yield value, and both values should be the same (in the night) with less than 8% devitation ( according inverter efficiency curve), but I get a deviation of transformation in many reads with more than 40%!!. It results a accumulative deviation of about 1-1.5KWh daily. What I found is that that the deviation increase with very low loads, and with normal or high loads the accuracy increase to 95-98%. Here my therory why it happends: The accuracy of the inverter reading or data for Energy (KWh) is not enough, if the toleranz for each data/read is about 20-10Wh it would mean that during the night with low loads and relative high rate periodical reads acumulative reads errors can bring this deviation.
Here my case:
For the battery discharge during this period bellow value is 404,3kwh-402,72kwh=1,58 kWh and in the same period the total yield is 507,97kwh-507,03kwh=0.94kwh, it would means a transformation factor for the inverter during this period of 0.94/1.58=0.594 (59%). far a way of the Huawei specifications (95-92%) and unacceptable if it is real transformation of energy factor. A deviation is 0.640KWh for a battery of 5KWh it is a lot. But according my theory and data below if the data precision of the inverter for KWH is about +/-10 or 20Wh, it could justify this big error deviation. HUAWEI should give an answer.
| last_changed battery | state discharge battery | state_ total_yield |
|---|---|---|
| 2022-01-04 06:54:30 | 404,3 | 507,97 |
| 2022-01-04 06:44:30 | 404,27 | 507,95 |
| 2022-01-04 06:37:30 | 404,24 | 507,93 |
| 2022-01-04 06:31:30 | 404,22 | 507,92 |
| 2022-01-04 06:06:30 | 404,15 | 507,88 |
| 2022-01-04 05:48:30 | 404,09 | 507,85 |
| 2022-01-04 05:40:30 | 404,06 | 507,83 |
| 2022-01-04 05:26:30 | 404,01 | 507,8 |
| 2022-01-04 05:13:30 | 403,96 | 507,77 |
| 2022-01-04 05:06:30 | 403,92 | 507,75 |
| 2022-01-04 05:03:30 | 403,91 | 507,74 |
| 2022-01-04 04:59:30 | 403,89 | 507,73 |
| 2022-01-04 04:56:30 | 403,88 | 507,72 |
| 2022-01-04 04:52:30 | 403,86 | 507,71 |
| 2022-01-04 04:49:30 | 403,85 | 507,7 |
| 2022-01-04 04:13:30 | 403,7 | 507,61 |
| 2022-01-04 04:09:30 | 403,68 | 507,6 |
| 2022-01-04 03:53:30 | 403,63 | 507,57 |
| 2022-01-04 03:40:30 | 403,58 | 507,54 |
| 2022-01-04 03:21:30 | 403,51 | 507,5 |
| 2022-01-04 03:09:30 | 403,46 | 507,47 |
| 2022-01-04 03:02:30 | 403,43 | 507,45 |
| 2022-01-04 02:58:30 | 403,41 | 507,44 |
| 2022-01-04 02:51:30 | 403,38 | 507,42 |
| 2022-01-04 02:26:30 | 403,28 | 507,36 |
| 2022-01-04 02:21:30 | 403,26 | 507,35 |
| 2022-01-04 01:45:30 | 403,14 | 507,28 |
| 2022-01-04 01:26:30 | 403,07 | 507,24 |
| 2022-01-04 01:13:30 | 403,02 | 507,21 |
| 2022-01-04 01:08:30 | 403 | 507,2 |
| 2022-01-04 00:36:30 | 402,87 | 507,12 |
| 2022-01-04 00:31:26 | 402,85 | 507,11 |
| 2022-01-04 00:28:06 | 402,83 | 507,1 |
| 2022-01-04 00:24:13 | 402,81 | 507,09 |
| 2022-01-04 00:20:09 | 402,8 | 507,08 |
| 2022-01-04 00:15:09 | 402,78 | 507,06 |
| 2022-01-04 00:12:44 | 402,77 | 507,06 |
| 2022-01-04 00:00:44 | 402,72 | 507,03 |
An interesting test is to set the “Maximum Discharge Power” to 0 for the battery. This stops the battery from discharging, as can be seen by the “Battery discharge” line in the FusionSolar graphs dropping to 0.
However, my experience has been that there is a sizable auto-discharge anyway. You can see the graph of the Battery SoC of my 5kWh LUNA battery here between 17h and 23h discharging from 71% to 63%. This means an auto-discharge of 1.33% per hour 
The “Battery day discharge” sensor reports some discharge though: from 0.06kWh to 0.47kWh (as does “Daily Yield”: from 1.90kWh to 2.14kWh, note: a battery discharge of 0.41kWh results in a daily yield increase of only 0.24kWh):
Is this because it requires energy for the inverter to stay ‘on grid’? It that increase in ‘Daily yield’ really injected into my home electricity net?
It really doesn’t bode well for the overall profitability of my home battery 
. Say that I want to use it in winter only for reducing my peak grid usage (which is taxed in Belgium starting from this year), then it will cost me 32% of my battery SoC just to be available and do nothing, that’s a loss of 1.6kWh per day. Even if (0.24/0.41 =) 58% ‘leaks’ back into my home electricity net (which I doubt), this is a very poor performance.
Thank you wlcrs, 1.0.0a3 seems to be working fine. I have hass runing on an old laptop which has wired conenction to my network, so used the wifi on the laptop to connect to internal inverter AP.
I’m pretty use that I saw slave id 1 in the app, but when configuring in HASS it worked with 0
Also some random disconnects, but does seem to work.
Feb 11 07:08:13 pot hass[11744]: 2022-02-11 07:08:13 INFO (MainThread) [pymodbus.client.asynchronous.async_io] Protocol made connection.
Feb 11 07:08:13 pot hass[11744]: 2022-02-11 07:08:13 INFO (MainThread) [pymodbus.client.asynchronous.async_io] Connected to 192.168.200.1:6607.
Feb 11 07:08:17 pot hass[11744]: 2022-02-11 07:08:17 INFO (MainThread) [backoff] Backing off _do_read(...) for 2.0s (asyncio.exceptions.TimeoutError)
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [custom_components.huawei_solar.config_flow] Successfully connected to inverter SUN2000-12KTL-M2
Feb 11 07:08:20 pot hass[11744]: SUN2000-15 with SN [redacted]
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [pymodbus.client.asynchronous.async_io] Protocol lost connection.
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [homeassistant.setup] Setting up huawei_solar
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [homeassistant.setup] Setup of domain huawei_solar took 0.0 seconds
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [pymodbus.client.asynchronous.async_io] Protocol made connection.
Feb 11 07:08:20 pot hass[11744]: 2022-02-11 07:08:20 INFO (MainThread) [pymodbus.client.asynchronous.async_io] Connected to 192.168.200.1:6607.
Feb 11 07:08:24 pot hass[11744]: 2022-02-11 07:08:24 INFO (MainThread) [backoff] Backing off _do_read(...) for 2.0s (asyncio.exceptions.TimeoutError)
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.huawei_solar
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [homeassistant.components.number] Setting up number.huawei_solar
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [homeassistant.components.switch] Setting up switch.huawei_solar
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [homeassistant.components.select] Setting up select.huawei_solar
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [custom_components.huawei_solar.number] Skipping number setup, as parameter configuration is not enabled
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [custom_components.huawei_solar.switch] Skipping switch setup, as parameter configuration is not enabled
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [custom_components.huawei_solar.select] Skipping select setup, as parameter configuration is not enabled
Feb 11 07:08:27 pot hass[11744]: 2022-02-11 07:08:27 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.huawei_solar entity: sensor.input_power
According your comment: “The “Battery day discharge” sensor reports some discharge though: from 0.06kWh to 0.47kWh (as does “Daily Yield”: from 1.90kWh to 2.14kWh, note: a battery discharge of 0.41kWh results in a daily yield increase of only 0.24kWh)” “Is this because it requires energy for the inverter to stay ‘on grid’? It that increase in ‘Daily yield’ really injected into my home electricity net?”
It is exacly what I comment before your comment. If the inverter consume energy during transformation resulting an efficiency factor of 58%, it would means that Huawei must respond with warranty becouse the official efficiency for the inverter is from 99% to 92% ( handbook). If you try the same test with high loads probably youo will get a better results, instead 58% you will get 90% or more. My opinion is that the problem comes from the data resolution/precision provided by the inverter 10Wh. You have during this period 41 reads result a deviation of 0.41-0.24= 0.17Kwh=170 Wh, you can see the precision of 10Wh provided by Huawei inverter is not enough to monitoring/tracking low loads, the error introduced has a huge impact.
For better understand: for example when your battery discharge is 0.005Wh the fusionsolar shows 0.01Wh (round), it means an error of 0.004 every read, you have 41 reads then 41x0.004Wh= 164Wh which is aprox your deviation of 170Wh.
I hear your frustration, but I don’t think the 92-99% efficiency numbers are applicable in this case, as they are about the efficiency when there is a load being applied to the inverter.
My conclusion is that my SUN2000-3KTL-L1 inverter has a “no load” power consumption of around 66W. This number is quite bad compared to other inverters, but not uncommon.
Comparison with an inverter from Victron which has been optimized for no load power consumption:
Nullastvermogen = No load power consumption
Source (in Dutch): https://www.zonstraal.be/forum/viewtopic.php?p=302939&hilit=nullast#p302939
The last post contains a link to a German YouTube-clip that discusses battery performance and losses.
Interesting, 66W consumption is high. This consumption should be taken from grid. In my case during the day I don’t see discharge of the battery , according information from the installer he told me that the sun2000L , this model, is not prepare to work without grid connection, and takes the energy from the grid, it would require additional hardware to make possible to work without grid connection.
For Huawei, inverter SUN2000 efficiency vs load (%):
source: download (huawei.com)
Hi, how do you connect the wlcrs integration to the inverter?
I have the inverter connected to the same wifi subnet, as my wireless HA Rpi wl0 card (I can ping it). Can I use it like that?
My issue is that I can’t connect my RPi wifi card exclusive to the inverter wifi AP as I’m using it for most of my wifi gadgets at home.
My RPi:
ethernet net 192.168.1.X
wifi subnet 192.168.3.X
