It looks like I am far from the only one to suffer this issue. The EVC drops off the network with a W-104 Error message about every one or two days. I installed the EV Charger 8 days ago to charge my new EV. The house is off-grid and uses all Victron gear. The controller is a Venus. The network is a Unifi system. After reading this entire thread I have tried the following:
I created a dedicated 2.4Ghz wifi SSID that is only broadcast from one AP and is ONLY used by the EVC.
Wifi has Enhanced IoT Connectivity turned on.
The EVC is set to zero scanning and only one wifi network is listed.
A continuous ping has responseās that range from 19ms to 1200ms and drops one packet in about 40 (scanning is OFF)
I have done some embedded systems programming with with Espressif esp32 boards and know how erratic they can be - and how difficult it can be to debug Wi-Fi and Bluetooth issues. While Iām extremely disappointed by this problem, Iām here to offer as much info and help as possible - not to simply complain.
The only solution I have found is to completely reboot the EVC from the Bluetooth interface - not great when I am away from home for a week!
I have had issues like this with other boards and have sometimes found that the workaround is more about what the board does once the error is detected (for example, can it not just reset the Wi-Fi subsystem and try to reconnect when a W-104 error is detected??).
As I said, I am offering my help to the developers who are trying to track down the cause of the issue, the error seems to be fairly regular on my system - so Iām happy to try things (when Iām home) and/or collect data.
What we all are experiencing is not just a simple Wi-Fi drop.
My EVCS every WPA2 rekeying (3600 sec):
does not reconnect automatically and enter a 40 sec event
UniFi try a new Group Key Handshake
Client (probably ESP32 into EVCS fw) does not answer correctly
AP force dissociation
Client try complete reassociation
Restore after ~30ā60 s
Sometime does not recover
Sometime even after power cycling
it only recovers after a forced reboot via Bluetooth
means something very specific:
The EVCS Wi-Fi stack enters a dead/locked state after the rekey.
This is not a radio issue.
This is not a DHCP issue (I have fixed IP).-
And itās not even just about GTK.
It is a bug in the EAPOL / WPA state machine handling on the EVCS side.
Why doesnāt power cycling fix it?
This is the interesting detail.
If you remove power and:
the Wi-Fi module remains in an undefined state
or the ESP32 does not properly reset the Wi-Fi subsystem
then it means:
the power cycle does not fully reset the Wi-Fi stack
the software reboot does
So the problem is in the internal Wi-Fi firmware, not in the infrastructure.
A new firmware release is mandatory ASAP. My car charging system was compromised by one of these disconnections which caused the internal contactor to cycle badly cyclically every 2-3 seconds. I had to restore at the car workshop.
@Lpopescu please ping the right people inside Victron to get this problem solved. Probably some coding and a FW release can fix the problem. I am available for any discussion with developers and can share logsā¦
The mesh already has a dedicated SSID with single band broadcasting, fixed channel and a number of other configuration IoT wise. The UniFi network is the one the achieve better stability. I have tried a number of other APs that all works awful. The worst has shown a 1-2 minutes down every hour until it eventually crash completely and only a reboot forced in the VictronConnect app via BT can fix.
I think there is a problem in the stack management as told in the chatā¦ for sure the main problem is the rekeyingā¦ at a certain point the stack get stuck and no further negotiation happensā¦
I have ordered the micro TP-Link router one of the guys said it worked for him but I will configure tomorrow.
My coleague will contact you. But please, tell me if workes better with the tp-link.
With some APs there are not issues. For exmple, Iām using Mikrotik, something similar as the UI mesh, and there are no issues.
But letās see, maybe we can learn something togehter.
Another issue: firmware updated with device as Access Point. After restart, impossible connect to the Ssid (new computer never connected, new phone, reset of all preexisting wifi configurationsā¦). Factory reset and same issue.
Since a firmware update to 2.05 I had connection issues. I thought it must have been related to the firmware. As soon as I turned on the Enhanced IoT setting an hour ago the EVCS has remained online.
I will join the group, having the same issues with the EVCS dropping its WiFi. My system is simple and stand alone, off grid. A Cerbo GX, a Ubiquiti NanoStation Loco M2 and the EVCS. Nothing else. No home router or other EiFi clients. Fixed ip addresses, 2.4GHz, good signal. Here is my observation:
WiFi is stabil and never drops while standing idle. But when charging (even with my small settings of 6-8A only) the WiFi drops inside of an hour. No automatic re-connection. The EVCS drops off the Remote Console but still displays its correct WiFi station. Rebooting sets it back to normal until next time, also less than one hour away.
Could it be internal interference with the charging current?
Top priority: Did you try to disable AC Mesh/AirTime Fairness on your NanoStation?
Other tips: If not: Reduce your NanoStation Loco M2 to 20 dBm or less.
Last point, Iāve found that channels 1 , 6 and 11 are more stable with EVCS.
I do not recommend using EVCS w any good IT mgt like Ubiquiti.
Since youāre off-grid, did you notice an EVCS inrush? Iām used to EVCS with mainy commissioning and have never noticed that, even on (well-sized) off-grid sites.
If we assume your network is undersized, the NanoStation Loco M2 could shut down due to a voltage drop, and then reconnection could fail for the reasons mentioned above.
To confirm that the problem isnāt caused by an inrush on Ubiquiti, generate an inrush on your network with a power consumer like an air compressor and check that the NanoStation hasnāt rebooted.
FYI, my workaround when clients have high-end IT infrastructure that causes the EVCS to crash is to integrate a WiFi bridge into the EVCS. In that case I use a MikroTik map Lite with PoE, setting the signal strength to its weakest, locking it to Channel 1, and locking it to 2GHz-g/n (not b). It gets a little warm, but itās been 100% functional for years.
It looks like two different problems: first dropping the WiFi only while charging, never when ready to go, plugged in but waiting. Second not reconnecting even though charging has stopped after a minute or so.
This EVCS is doing serious damage to Victronās reputation. If this cannot get solved we have to sell our EV we only bought based on the promised EVCSās capabilities.
Maybe a good moan on the internet is half the remedy. Today, with clouds passing by, toggling between power going in and going out of our batteries the EVCS has behaved remarkably well. Turned on automatically when the batteries reached their set threshold and turned off again and went into waiting mode as soon they dropped to their defined cut-off SoC. The WiFi dropped only once so far and here it gets a bit esoteric: it dropped when I walked past it after marvelling how well it worked today from a safe distance monitoring the Remote Console. It is like trying to tune a radio maybe and it goes hissing and carrying on while I move my arm or walk around. I will observe this closer. Yesterday when it dropped every 20 minutes I was close to the EVCS, keeping watch. Today I am busy elsewhere and it behaves much better.
Anyway, I will lower the TX power and check if Fairness is disabled. I know I am on 20MHz and 2.4GHz only. Will change channels from 1 to 6 or 11 and see if that helps.
