ECU-B freezes after Homeassistant integration is turned on after a few minutes

[Zuendapp]

Hello :),

Since a few days I have the problem that my ECU-B freezes when the Homeassistant integration is switched on.
What I have to mention:

Before with the old ECU-R integration there was the same error, so I switched to the new “ECU Reader”.

I increased the interval from 300 (before) to 600, but that didn't help.
The ECU is also not sending any values to the EMA Cloud Portal at this moment and also no new values to Homeassistant.
When I turn on the hotspot from the ECU and connect via the EMA Manager APP, I can usually see the values, but some are lost when I try to turn the ECU off and on again.
On some days, the EMA Cloud Portal has received lower values due to the ECU restarting or have not been transmitted at all.

The only solution that helps is to deactivate the Homeassistant integration and then restart the ECU. Then at least the EMA cloud works properly.

Homeassistant Version: 2025.7.1 (formerly with ECU-R Integration 2025.6.2)

Firmware version of the ECU-B according to Homeassistant: ECU_B_1.2.36A

Signal level of the ECU to the inverter is: -11dBm

What could be the problem here?

Thank you very much!

[HAEdwin]

Best thing is to turn on debug mode of the integration. Make sure there is a good connection to both WiFi and Zigbee. My ECU-B freezes also at random time intervals and is then being reset by using an automation and a smartplug. It is not really an integration issue but correct placement of the ECU and handling of the moments where the ECU freezes.

Here my ECU-B freezes

And is being reset by the automation.

Also look at the home-assistant.log

[Zuendapp]

Hey,

thank you for your reply :)!
What pull intervall would you choose for ECU-B and DS3?

Can you share your code for this history sensor?
At which intervall do you restart?

Thank you very much!

BR

[HAEdwin]

Because the data is only refreshed once every five minutes, I set the interval to 300s. The EMA site is also only updated once every five minutes. This is essentially microinverter independent.

The history sensor shown is in the integration and named: Using Cache Counter
It contains valuable info about how well your ECU is receiving both WiFi and Zigbee signals.

In the integration settings it is currently set to 5 retries when ECU fails to respond.

This means that the integration will try to open the socket connection to the ECU five times in a row. If that fails than Cache counter becomes 1 and after five minutes the integration will again try to connect 5 times in a row. If it fails again Cache counter becomes 2 and so on until the set number of 3.
For the ECU-B I have an automation which uses a smart plug to reset the ECU-B after 3 cache counts (15 minutes downtime):

alias: Reboot ECU-B when needed
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.ecu_21630010xxxx_using_cache_counter
    above: 3
conditions: []
actions:
  - type: turn_off
    device_id: fce68d2e68212bdcc4a913caxxxxxxx
    entity_id: f929b4e74f38f195328734b14xxxxxxx
    domain: switch
  - action: persistent_notification.create
    metadata: {}
    data:
      message: ECU-B is being rebooted
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - type: turn_on
    device_id: fce68d2e68212bdcc4a913ca3xxxxxxx
    entity_id: f929b4e74f38f195328734b14xxxxxxx
    domain: switch
mode: single

So take a close look on the Use Cache Counter, it indicated how well the ECU is positioned. Also keep in mind that the ECU needs at least 5 minutes after a restart before all the collected data is complete. My advice is to wait 10 minutes after the ECU restart to try connecting to the ECU again (or to install the integration). You do not have to deactivate the integration but be aware of the fact that the Use Cache Counter might still add up to 2 before all is well. The ECU requires, so to speak, a bit of patience.

For an overview of the ECU's parameters you can add to the dashboard, navigate to:
Settings > Devices & Services

Click on "X DEVICES" and click on your ECU for a dashboard view

From my own experience I found that proper placement of the ECU is quite important and makes a difference in cache counts.

[Zuendapp]

Hey :),

thank you very much!!
I will keep an eye on the cache sensor and the placement of the ECU and switch it as in your automation if necessary.

Thank you very much :)

BR

[Zuendapp]

Hello,

I have been monitoring the cache counter for several days now and your automation has also triggered a few times, but today the counter is at 0 and I haven't seen any new values for over 40 minutes. Neither in the Home Assistant nor in the EMA web portal.
The last time the data was sent is identical here.

WLAN reception is great, and the Zigbee reception strength is also -14 dBm, which I think should be fine.

Do you have any other ideas?

My firmware on the ECU is 1.2.36A, maybe it has a bug?

Thanks and greetings

[HAEdwin]

The ECU still seems to freeze dispite the automation. What does the history look like now? It's hard to tell if there are reasons for the issues you are facing. Might be interference or other Zigbee devices, even distorsion/interference from the WiFi signal. Try to point the antennas opposite each other.

[jeje-digifab]

Hello,

I experienced very similar issues with my ECU-B gateway over the course of a few weeks. Initially, data updates started to become progressively irregular, both in the official app and in Home Assistant (which is how I first noticed the problem): instead of receiving updates every 5 minutes as expected, I was getting them every 15 or 30 minutes—or not at all. To temporarily work around the issue, I set up an automation that regularly rebooted the gateway using a smart plug, which helped restore data transmission for a while.

One day, while observing the gateway, I noticed the communication LED briefly turned off and then came back on. A few days later, it stayed permanently off, and the gateway stopped sending any data.

At that point, I started troubleshooting by pinging the gateway’s IP address, but it didn't respond on the local network. I then attempted to connect via access point (AP) mode in order to check its network settings, but the gateway's AP SSID didn’t appear in the list of available Wi-Fi networks on my phone—even after multiple reset and reboot attempts. In short, I had no access either through the local network or via AP mode.

Since the device was still under warranty, I contacted the reseller (based in France, like me) and explained the symptoms and tests I had already performed. They confirmed by email that they would contact the manufacturer. A few hours later, I received another message telling me that a replacement unit had been approved and that I would receive a new ECU directly at home. The shipment originated from the Netherlands, which suggests it was likely sent directly by the manufacturer.

The new gateway has been operational for a few hours as I write this, and so far, data updates are working correctly—both in the official app and in Home Assistant.

[Zuendapp]

Hey :),

a few weeks have passed, but the problems remain.
I opened a support case with APSystems Support and they sent me a new ECU-R (serial number: 21600021xxxx) with firmware version 1.3.18A. What irritates me is that I had a defective ECU-B :).

I use the LAN connection instead of the Wi-Fi connection for a permanent connection. To set it up, I used of course the ECU-R's hotspot AP.

However, the “ecu_reader” does not recognize the ECU-R and always says “No ECU found at this IP address or the ECU is being restored from a restart.”

The ECU connects to the internet normally and also connects cleanly to the EMA portal.

Is it absolutely necessary to use the WLAN connection for queries via Homeassistant?

Thanks and best regards