ECU-B time out solution

[Xqlus1ve91]

Currently running the following:

V1.2.29 ECU-B, firmware 2163xxxxxx

i noticed now for the second time that the data in HA stops and keeps running at the last know value, i then need to delete the integration and wait for an hour or-so for me to get it back to work.

what is the best solution to prevent this from happening? Do i need to restart my ecu every day or 12 hours?

[HAEdwin]

I often read that the integration is uninstalled and reinstalled, that makes absolutely no sense. Software and settings will remain exactly the same except for the position of the ECU Query Device switch*.

Because you write that you sometimes have to wait an hour or-so before new data appears, you should also check whether the Zigbee connection between the ECU and Inverter(s) is still established. You can check this by looking at the EMA site. Is a flat-liner visible on the EMA site? It is then sufficient to move the ECU closer to the inverters or reorient the antennas, you then have to wait a maximum of 5 minutes for the next signal to arrive. The Zigbee signal can be (temporarily) disrupted by other sources or weather conditions.

In summary, you can pay attention to the following if you do not receive any new data (where you did receive data before):

• Zigbee signal is too weak or has become too weak
• ECU is stuck (see log) restart the ECU (Old model ECU-R or ECU-B)
• *The ECU query device switch is still in the off position it will be reset if you reinstall but you can also turn it back on ;) Make the switch part of the dashboard so you can check it's position easily.
• Inverters are offline

Seems to be the same issue as https://github.com/ksheumaker/homeassistant-apsystems_ecur/issues/163

[Xqlus1ve91]

The data from the ecu towards the cloud works fine and is detailed per 5 minutes. My connection between ecu and repeater i should say is fine and strong enough for good reception. So when i have these issues in HA and i look in the EMA app everything is ok and reporting. Inverters are not offline

An Query switch, where to look for and how to implement?is there a instruction for that? In the mean time i will check issue #163.

[HAEdwin]

How often do you query the ECU? Data on EMA might have been made complete in de evenings, check at the moment the problems occur. The switch.ecu_query_device is an entity you can add to the dashboard, check it's status. The ECU-B should be working just as stable as the ECU-R.

[Xqlus1ve91]

Query has been set to default (300), i noticed that when the query device has been switched off this was during peak sun days with maximum energy yield, around 14:00ish the query device switched to off.

The only thing i do during those days is checking the EMA app itself when away from home and rarely HA (as i need to switch between VPN's).

[HAEdwin]

Did you check the home-assistant.log?

[Xqlus1ve91]

Yes i have, i have seen that the query device has been shut off and that that causes the data to stop updating. I have put the switch on my dashboard in case it happens again, hopefully switching it back on get my readings back alive.

Second thing i noticed is that the 'ECU using cache data' entity keeps turning on and off, is normal behavior?

[HAEdwin]

The frequency in which the cache is being used is way too often. Check the quality of WiFi connection and whether there is any interference. If the integration fails to do the query the set number of times in a row, it is assumed that the ECU needs a reset. The switch ensures that you can be alerted to, for example, your telephone via an automation. But again the cache is being used too often in your case. I've had it twice during the last 24 hours (ECU-R) and that's normal behaviour. It also could be a firmware issue.

[Xqlus1ve91]

Well, we are a couple of days further, my caching switching has minimised to only once a day, i haven’t changed anything so far. But this was only happening on days where i got maximum energy production so i will keep a close eye to another day like those.

[HAEdwin]

There also seems to be an issue with HA installations on Intel NUC's. I'm using an ODROID N2+ and works just as stable as a RPi.

[Xqlus1ve91]

I am not using a Intel NUC, I am using a Intel CPU on a Synology NAS in VM. The issue still persists, i am currently trying to configure an automation that will switch my ECU on and off if the 'using cache data' has turned ON for 3 or 5 times. Still struggling how to create a proper counter for it that will activate the automation an afterwards reset the counter.

I have configured an input_number helper but doubt i wrote it properly.

[HAEdwin]

The setting "Retry when ECU fails" determines when the "ECU Query Device" switches over. So you don't need a counter, only the status of this switch. If it turns off after, for example, 5 attempts and you link an automation to it, you can arrange everything (powerplug, notification, etc.)

[P-Verbrugge]

Query has been set to default (300), i noticed that when the query device has been switched off this was during peak sun days with maximum energy yield, around 14:00ish the query device switched to off.

The only thing i do during those days is checking the EMA app itself when away from home and rarely HA (as i need to switch between VPN's).

Exact same thing happened here at the same time. At 14:00 hours too. First time it happened in a couple of weeks. After turning the ecu off and on again, it worked again. I only found out a couple of hours after it went down. Guess I have to add an automation to restart the ecu after query fails with a power plug.

[HAEdwin]

Yes, but I can also imagine that communication was lost somehow, might be signal interference from a device nearby if it happens at 14.00 every day. Could be a microwave oven, gameconsole, ESP device or whatever.

[P-Verbrugge]

So far it happened only once. Will keep an eye on it.

[HAEdwin]

@P-Verbrugge @Xqlus1ve91 It is acceptable if the ECU does not respond to the query at times, but the next query usually succeeds. If all else fails, an (automated) power cycle from the ECU always works. I'll close this issue for now, If there is reason to do so, feel free to reopen the issue or create a new issue.