my ECU is disconnected daily (home assistant)

[niouniou49]

with release 1.3.0b i lose the connection daily. same with the version 1.2.30. I need to power cycle my ECU daily and wait for it to get started again and again. i have an ECU-R models (UID 2160xxxxx) connected with wifi. can you help me to find out what happen please?

best pascal

[HAEdwin]

Hi Pascal, Some questions to get more info on this... Have you looked at the home-assistant.log allready? Does it have warnings like: "Communication with the ECU failed after x repeated attempts."? Does the ECU have a sunspec logo on the back? Was anything changed, like position of the ECU, AP's. How good is the WiFi signal near the ECU?

You might allready have done this but you can create an automation to alert you when the ECU fails.

platform: state
entity_id:
  - switch.ecu_query_device
from: "on"
to: "off"

If it happens to me I have a smart plug that will toggle off/on to automatically reset the ECU and send a warning to my phone. The reason why I asked for the SunSpec logo on the back is that the later ECU-R models can be reset without the need of a smartplug. From version 1.2.29 this was heavily modified but tested.

Restarting the ECU does take a while, it tries to connect to the internet also so wait a while until both status lights are green. Then activate the query switch again. There is no need to query the ECU faster than every 300ms. Data is only updated every 5 minutes. Check the configuration setting if the value is at 300ms.

[niouniou49]

Thanks for the feedbacks. I have a old ECU-R (2020) and it seems not to have a Sunspec logo on the back... yes i have strange stuff in my logs "communication with the ECU failed after 5 repeated attempts. 2024-01-09 09:25:00.296 WARNING (SyncWorker_15) [custom_components.apsystems_ecur] Try manually power cycling the ECU. Querying is stopped automatically, turn switch back on after restart of ECU." the wifi is close and has no specific pb with others devices I will need to put a smartplug and reset it regularly. To implement this can you please guide me a bit i know how to create automation but i need to define the trigerring event what are the lines of code you sent, how to insert them in HA? Is it an automation or just a switch created or something else, i just need a bit more support to create all code needed to be able to detect when the ECU is off and then tell to the smartplug to go off and then on. should i add these lines in the configuration yaml? somewhere else?

thanks in advance pascal

[HAEdwin]

The entity switch.ecu_query_device is your trigger when you create an automation. After powercycle you should add a delay to enable the ECU to boot and after that don't forget to turn the switch.ecu_query_device back on.

But it is weird that the ECU is not responding that often. I have the same ECU model and never experience the need of a reboot. It does use the cache sometimes but never 5 times in a row. Did you assign a fixed IP-Address to the ECU or are you able to monitor the WiFi connection using Unifi network (Ubiquiti) for example? Currently I'm on firmware ECU_R_1.2.27

[niouniou49]

hi here i implemented a smartplug and now at least once a days the script does off/on and restart the ECU when it happens. Works well yet. At least the solution/work around works well pascal

[HAEdwin]

Should be nice if we could figure out why caching is needed that much in your case. Mine is ones in a while and just one time not really that often as you can see.

[niouniou49]

i moved my wifi AP so that its not as close to the ECU. was too close...lets see the effect

[gordonb3]

with release 1.3.0b i lose the connection daily. same with the version 1.2.30. I need to power cycle my ECU daily and wait for it to get started again and again. i have an ECU-R models (UID 2160xxxxx) connected with wifi. can you help me to find out what happen please?

New installation here. I have the Sunspec logo but the ECU-R reports UID 2160* and firmware is version 1.3.4a. I have been monitoring the IP traffic and it turns out I can only access the device for a maximum of 1 hour after pressing the AP button, i.e. when the AP shuts down it returns an active "access denied". I found that when I power cycle the ECU-R it defaults to having AP enabled and I can get back in.

Am I missing something here or is this some crazy new firmware "improvement"?

[HAEdwin]

@gordonb3 I guess you are using the temporary hotspot for setting up the ECU. You will need a WiFi connected ECU to your network. Assign a fixed IP-address to the ECU and from that point on you can use that IP-address.

[gordonb3]

@gordonb3 I guess you are using the temporary hotspot for setting up the ECU. You will need a WiFi connected ECU to your network. Assign a fixed IP-address to the ECU and from that point on you can use that IP-address.

No, I am in fact accessing the ECU-R through the DHCP assigned address from my Wifi/LAN bridge. What I am seeing is a reject, not a timeout.

[HAEdwin]

It is always difficult to determine where the problem lies, but it is usually possible to establish a connection in the end. For example, the WiFi adapter is also an ESP and it often does not stand out among the other ESP devices. Or sometimes people think they have the right node, but it later turns out to be the wired IP address or another node. Depending on the DHCP settings the lease might have been given to another node. Every active node can respond with a reject for the port. If you are able to use the EMA app or EMA manager app you should also be able to use this integration.

[gordonb3]

The ECU-R is not wired. The DHCP server is configured to hand out a static IP. Unsure about that last line, EMA app in fact only works when the phone is connected to the ECU AP, are you saying that the ECU only opens the local port to LAN when the device is bound to an active user account with APSystems? Yes I noticed that it wants access to the same ports as Tuya. For now that is all open, i.e. I have not yet setup the fake server to prohibit bad firmware updates (which I guess I already got?).

[gordonb3]

Turns out that my issue is unrelated.

For the wiki: my firewall did not allow all of the ports that the ECU wants and apparently that causes it to shut down the communication port same time that it drops the AP.

[HAEdwin]

Thanks for the feedback, indeed blocking the EMA sites will cause the ECU buffer to overload. There are several checks the ECU will perform to keep the EMA data updated (check ECU data agains the EMA site or if it can't post it's data buffer it), as well as initiating an OTA update when one becomes available. I managed to go cloudless bij returning fake responses to the ECU but overall that really does not solve anything. I wish APSystems would be more communicative when it comes to ECU firmware updates. I will close this issue, might any other question arrise, feel free to create a new issue.

[gordonb3]

Thanks for the feedback, indeed blocking the EMA sites will cause the ECU buffer to overload. There are several checks the ECU will perform to keep the EMA data updated (check ECU data agains the EMA site or if it can't post it's data buffer it), as well as initiating an OTA update when one becomes available. I managed to go cloudless bij returning fake responses to the ECU but overall that really does not solve anything. I wish APSystems would be more communicative when it comes to ECU firmware updates. I will close this issue, might any other question arrise, feel free to create a new issue.

Sorry, but I kind of hijacked this topic as I thought what I was seeing was related to the original raised issue. You should check with @niouniou49 whether this issue can indeed be closed.

One addition with respect to the closed port (8997), after adding that to the list of allowed ports my inverters would no longer communicate with the ECU. I ended up also needing to open ports 9220 and 9222 which are apparently used for firmware updates. Only after the ECU upgraded to 1.3.5 first and then 1.3.9, followed by an inverter update as well the inverters came back online.

[HAEdwin]

Oh yes, you are right @niouniou49 what is the status of your issue? Does the smartplug solution work for you? What firmware does your ECU have?

[niouflex49]

Hi guys Had a lot of deconnexions so I changed my WiFi box. Seems a bit better but I still have pb. I have implemented a smart plug scenario that kicks off 1 or t si z on 24 h period.

[HAEdwin]

People with the same problem even removed the WiFi antenna from the ECU and everything went a lot better. But it's hard to understand why... maybe interference with zigbee (also 2.4Ghz) who will tell? I don't have any issues so it's always hard to figure out what could go wrong if I'm not able to reproduce the issues. Suggested sometimes to place the ECU somewhere else, mine is placed away from electronic devices, access points or fuse boxes.

[niouflex49]

Ok. I Will remove the antenna and move it away and I will let you know if anything improved

[niouniou49]

hi, i removed the antenna and changed my wifi to another system. Nevertheless, i still have 1 or 2 ecu off per 24h period, (you can see the grey stuff within the graph) even if the wifi is still up and running, so should be related to something else within the ECU

my automation fix that but the ecu is rebooted 1 or 2 time a day....

[HAEdwin]

This is a fairly calm and normal behavior. There will undoubtedly be an occasional I/O conflict because the ECU itself also uploads to the EMA website. The cache will also be accessed more often if an OTA firmware update takes place. Is it okay to close this issue?

Edit: A power cycle of the ECU is only necessary if the set number of cache uses has been exceeded. In my situation, if the cache is used three times (consecutively) in a row, I receive a signal on my phone that the ECU is being rebooted.