I’ve polished the integration in the past weekend, and am looking for people willing to test the beta-version. I expect the sensor-part to be very stable already, but am not formally releasing it because of the new configurable parameter-entities that need some testing.
I’m especially looking for users with more advanced setups with multiple inverters, batteries, etc.
Changes since the previous release (v0.5.1)
Added support for changing some parameters, all related to batteries: maximum charge/discharge power, working mode, enable/disable charge from grid, …
Added some services to start/stop forced charge/discharge;
Added login-mechanism which uses the installer-account of your inverter to make changing parameters possible;
Improved naming of some entities to better differentiate between similar values (ex. ‘active power’ and ‘grid active power’);
Improved support for multiple inverters, batteries, power meters in the same setup;
Shifted some of the complexity from the HA integration into the library, to (hopefully) speed up the process of getting accepted in core;
Note that due to the multi-inverter support, I had to change the way the underlying unique_ids are calculated for entities. This can cause the old entities to become Unavailable “ghost” entities, and new ones to appear instead. I thererfore advice you to remove the integration and add it again if you encounter such issues.
Go to HACS, click on the three-dots menu of the Huawei Solar integration, and choose ‘Redownload’. Check the ‘Beta versions’ checkbox, and choose version ‘1.0.0a’ from the dropdown list.
Please let me know if you encounter any problems (or not). Include some details about your inverter setup: model name, firmware version, do you have a power meter/battery/sdongle/ … All feedback is appreactiated, either here or as a GitHub issue.
Hi @wlcrs , when @ffm777 pointed me out to the formula (inverter and power meter) I looked into the source code and I discover the sensor.active_power and sensor.active_power_2 since they have the same name in the code.
If I can give you a suggestion here or maybe you prefer the suggestion as an issue in github. Maybe its worth it to name the sensor something more easy to identify and related with the inverter.
I find sensor.active_power quite general, but something (idea) like sensor.sun2000_5tkl_active_power is more clear: sensor.<inverter_model>_attribute_name
I tried to setup the new version but it is not working. The config flow never finishes but exits with a “Unexpected error” message. In the log I can see the following:
Logger: custom_components.huawei_solar.config_flow
Source: custom_components/huawei_solar/config_flow.py:86
Integration: Huawei Solar
First occurred: 9:22:15 AM (2 occurrences)
Last logged: 9:23:33 AM
‘HuaweiSolarBridge’ object has no attribute ‘get_info’
Traceback (most recent call last):
File “/config/custom_components/huawei_solar/config_flow.py”, line 170, in async_step_user
info = await validate_input(user_input)
File “/config/custom_components/huawei_solar/config_flow.py”, line 86, in validate_input
slave_info = await slave_bridge.get_info()
AttributeError: ‘HuaweiSolarBridge’ object has no attribute ‘get_info’
Those ID’s are generated from the “user friendly” name by HA. So if I would apply your suggestion, that entity would appear in the user interface as “SUN2000 5KTL Active Power” as well. As that is way too long, the last words would disappear behind an ellipsis (…) , which is no good. I settled for the middle ground of naming the active power sensor of the power meter “Grid Active Power”, which will thus result in sensor.grid_active_power.
I just installed 1.0.0a2.
Looks pretty good.
I have a SUN2000-6KTL-L1 with the Luna 5kwh battery and the smart power meter.
It’s a single phase inverter with built in wifi.
The inverter is connected to my wifi and the integration is connecting to the inverters ip.
Only slightly odd figure is from the power meter, it has two entities grid_active_power and grid_active_power_2, I not sure what the second one is, it seems to be max int constant.
The battery settings that are exposed have been read correctly, I haven’t tried changing any yet.
I have it in Time of Use working mode at the moment, it has the charge limits and charge rates read out ok, doesn’t have the time slots but I imagine those are going to be tricky to handle in HA.
One value that would be nice to have is PV yield for the day.
The daily yield value on the inverter includes energy from the battery that was put there from the grid.
For example right now I have daily yield from the integration of 7.65 kwh but in fusion solar daily yield on the overview is just the PV and is 3.15kwh. The rest of the energy came from the grid charging the battery on lower priced night rate. Maybe fusion solar is doing something on the backend to accumulate this and it’s not easily available from the registers.
I’ll remove the second Grid Active Power entity in the next update. I wasn’t sure what it was reading the modbus register documentation, but it clearly is not useful.
I can read/write the time of use times in the underlying library (implemented, but untested to be honest). However, I don’t really see a good way to expose them in HA. I can always implement a custom entity, but then some work needs to be done on the front-end to be able to display/manipulate it. (Contributions welcome!!)
PV Yield is not exposed by the inverter. I’ve seen that other brands of inverters also don’t expose that value. The commonly suggested solution is to calculate it yourself using a Riemann sum. More info in this GitHub issue. I’m still testing this solution myself, and for today I see a deviation of about 10% between the calculated yield (top entry) and the actual yield (which should be equal as my battery is currently depleted):
hola, perdona, pero no había leido esto. Lo hice entrando en la web de eu5.
Tienes que entrar en la web de tu planta solar, ir a administracion de planta, administracion de actualizaciones y ahí añadir una nueva tarea con la instalación del firmware, tienes que seleccionar INVERSOR, y luego la version que quieres poner y luego el equipo… que sale en un desplegable.
many thanks for your work. I want to test it this weekend. I have a question. Can you integrate de daily export and the selfconsumption daily? I have it on accumulated value… or can I calculated it?
Ok. Tested the new version. Now the setups goes through fine, but I don’t get the checkbox anymore for setting up the advanced features (like the switch for AC charging the battery).
As I said. This is not necessary and this way you will never get numbers which match those from the Fusionsolar app. Just define a template sensor which uses the calculation that I gave above.
I’ve already experimented with your formula, but it gave me trouble because when the solar panels are not producing, and you’re thus using your battery, the “Daily Yield” increases more slowly than the “Battery Day Discharge”. For example: when the “Battery Day Discharge” reported 1.00 kWh, the Daily Yield was only 0.93 kWh.
This resulted in a lot of warnings from HA because I the calculated yield decreased instead of monotonically increased. The worst that can happen is that HA even decides that a new ‘cycle’ has begun, which will mess up your statistics completely. That is why I cannot recommend this approach.
Are you seeing the same behavior, or is your “Daily Yield” and “Battery Day Discharge” really identical if you look to your numbers before the sun comes up in the morning?
For the energy dashboard, I use the same formula except for the fact that I use the sensors with the total values. However, to avoid any miscalculations, the template sensor checks that the required sensors are > 0. Otherwise whenever the sensors become unavailable, the calculations from the energy dashboard go haywire.
For the daily numbers (which I display on my HA dashboard), I use the formula with the daily sensors that I suggested without any problems. The sensor values replicate the values from inside the Fusionsolar app 100% (you can check by going to the Device Management page of the inverter/battery in Fusionsolar) so that the resulting calculation is also spot on. I’m pretty sure that the values in Fusionsolar are calculated exactly the same. The fact that the daily yield slightly decreases is also 100% consistent with what is happening in Fusionsolar. I think that Huawei corrects for the conversion losses from converting DC to AC by slightly adjusting the values. But again: In my case this is perfectly consistent with the numbers that I can see in Fusionsolar. And my main goal is to replicate the values from the Fusionsolar app, because I would assume that Huawei knows how to calculate the values properly.
