Integration Solar inverter huawei 2000L

@wlcrs , do i loose the sensors then? or will it recreate an map those automatically again?

In my experience HA recreates them with exactly the same name again.

2 Likes

ok will try, the installer comes next week to perform the upgrade. fingers crossed :slight_smile:

Hi, I am trying to get the riemann logic posted on wiki and here to work but get this:

Invalid config for [sensor]: required key not provided @ data[‘platform’]. Got None. (See ?, line ?).

Code in configuration.yalm:

# Solar
sensor input_power_with_efficiency_loss:
- name: "input_power_with_efficiency_loss"
  unique_id: "input_power_with_efficiency_loss"
  unit_of_measurement: "W"
  device_class: power
  state_class: measurement
  state: >-
    {% set inverter_rating = 10000 %} # adjust this value to the rated power of your inverter
    {% set inpower = states('sensor.input_power')|float(0) %}
    {% if inpower < (inverter_rating*0.1) %}
      {{ inpower * 0.90 }}
    {% elif inpower < (inverter_rating*0.2) %}  
      {{ inpower * 0.95 }}
    {% else %}
      {{ inpower * 0.98 }}
    {% endif %}

try this code in developers tools :hammer:–> template

working for me

check YAML indent, to edit your configration.yaml use VS code https://code.visualstudio.com/

Hi, has anyone seen this before? - a dump at 5m to midnight that looks like a (close, but not exact) summary of the values. It really distorts the graph. I am using emulv2 via mqtt and either using the huawei inverters energy values or calculating from the voltage/current readings. This has been constant since the last 2021 versions.

is your connection to the inverter stable?

Yes, its the same day after day - the last 5 minutes before midnight.

I do get wifi and read errors from the mqtt script (running at the limts of the raspberry pi wifi that it runs on - mqtt runs on a different machine with HA) but the values published to HA are stable and consistent.
My experience of errors caused by a network drop are they occur on restart/reconnect at the time that occurs - this is the same time every day and covers solar, battery charge and discharge, load and imported power - exact mix depends on what has happened over the day. Is it your experience that network problems will show consistently at midnight? - if so I will have some work to do!

Yes, in my case it was issue with network, which used to damp data like this.

Why you are using mqtt?

I could suggest using @wlcrs integration GitHub - wlcrs/huawei_solar: Home Assistant integration for Huawei Solar inverters via ModbusTCP.
Simple to setup and more reliable.

For networking, you can use either of the three methods. In the router method, you don’t need some brand new WIfi 6E device, anything which will allow a wireless bridge will work. even a cheap old Netgear WNDR 3700 etc

  1. Raspberry pi wifi with or without dongle method. Connecting to the inverter · wlcrs/huawei_solar Wiki · GitHub
  2. Official client mode method (Connecting to the inverter · wlcrs/huawei_solar Wiki · GitHub) I think it works with some tplinks (see wlcrs example) and netgear routers. Set Up The Router In Bridge Mode - NETGEAR WNDR4300v2 User Manual [Page 113] | ManualsLib.
  3. Custom firmware method. Which again can be divided on the basis of atheros or broadcom routers. Connecting to the inverter · wlcrs/huawei_solar Wiki · GitHub
    Atheros are easier with openwrt/ddwrt, while Broadcom can be done with dd-wrt or freshtomato (I am using this method.) Connect to Huwaei SUN2000 inverter using asus rt-ac68u | Page 2 | SmallNetBuilder Forums

On the subject of custom firmware, freshtomato has the best support in terms of forum members, they will guide you through. DD-Wrt has the worst (every question will be answered with “google first”). Openwrt best if you know the stuff.

Who can explain this behavior to be. Sometimes my house usage(verbruik huis live) is showing negative value and a few minutes after it’s showing positive values.

And than there are days it’s only showing positive values like it suppose to.


Has anyone setup an automation which would control battery charging from Grid based on hourly electricity prices?

Currently we have entity “Charge from grid”, which needs to be turned on to be able to charge from the grid. This setting can be easily changed via scheduler.

Though LUNA2000 batteries are only charged from grid when working mode is set to “Time of Use” and at the same time you need to set working mode to “maximum self consumption” to be able to use electricity from batteries.

Currently it’s not possible to change working mode in scheduler.

I am using MQTT because of the problems routing or nat’ing the inverters inbuilt wifi across my network, and the inverters physical position in relation to my networks. I may have to run another network cable or buy a small switch… I also suspect the inverter uses some rtt magic to only allow close physical connections (be interesting if someone can confirm that!). MQTT itself works really well providing a nice reliable stream of data despite the underlying network issues - its HA and the energy dashboard where the problem seems to lie.

Can you post the MQTT graph for the whole day?
what firmware you are using with the inverter? With the latest firmware, the only method is to connect with the internal wifi of the inverter i.e 192.168.200.1 for a reliable method of reading data.I

The inverter does interfere with the wifi signal so the closer the wifi device is to the inverter the better. Obviously maintaining at least 30inches from the inverter.

I have just bought another switch so I can place the rpi 1.5m on other side of the wall with a wired connection … with this I should be able use the wlcr integration - but I would like to persist with the MQTT for now due to its flexibility. It will take a couple of days of stable operation to prove if thats of benefit. I dont know what firmware (the app shows a blank for most of the components) but I can only connect to 192.168.200.1:6607 - I will enable the firmware version lis in the MQTT script and see if it shows that way. I should also look into the HA MQTT integration to see if its coming from there.

I discovered a possible cause - the HA MQTT integration sends “birth” and “will” messages every MQTT reconnection causing a recalc of values. Ive turned them off and will see if it still happens tonight. With the switch and placing the rpi closer to the inverter the connection now seems rock solid.

stable connection = stable graphs

I have up to now only automated when the battery is charged by solar energy by setting the “Maximum Charging Power” to 0 or 2500, depending on whether I want the battery charged or the solar power to be sent to the grid. This works really good.

Not sure what you mean by that is isn’t possible to change working mode? I have not tried it, but the working mode is a configuration parameter so you should be able to change it both from the GUI and from automation.

I have been thinking about an idea. If I configure the Time of Day parameters directly in Fusion Solar so that it charges the battery ALL the time according to that parameter (I guess you have to set some period to discharge, if the manual is correct, so leave one hour somewhere for discharge). Then you could toggle the Working Mode so that “Time of Use” really means “Charge from Grid”. Then you can set it to “Time Of Use” for a couple of cheap hours during the night. When it is finished, you toggle back to “Maximum Self consumption” for normal operations and discharging logic. I have not tested this yet, but I cannot see why it should not work. Can anybody see a flaw in that usage?

1 Like

I have a TP-Link TL-WR802N with a Fritzbox 6820v3 LTE and somehow I can’t get a connection. From the TL-WR802N I can ping the inverter 192.168.200.1 but nothing works from the Fritzbox. Does anyone have an idea what could be the reason? Thank you very much







@colseven I am confused why do you mix 192.168.0.0/16 and 192.168.200.0/24
Can you post logical diagram of what your connection is, what IPs are used, etc.? It would make things easier than looking at wrongly rotated pictures.