Hey @emv,
Thanks for the update.
I can set the charge time per location so that the controls at home don’t interfere with a potential charge session at a public location. The location can be set using the option --location-id in the example code I published.
Hey Hollie,
I have some issues with the Alfen Eve Pro Modbus interface since I have updated the firmware to 6.x. (Installed firmware release 6.3.0-4185)
Alfen has implemented in the 6.x firmware a hourly network connection check. At my end it is reporting that there is no Internet connection, and starts to re-config the network.
I use the Alfen as standalone charger and have no backoffice configured. During this network re-config it stops the Modbus network connection causing the charge current setpoint to go to the max (16A) value for approx 2 min until the Modbus is restarted again. (see attached log files)
Do you hare the same firmware installed? and have the same issues? and/or can you advise how to disable the connection check or why its reports that there is no internet connection available.
Thank you for your support,
Regards Peter
Hey @Pedro_65
I just checked I am running firmware 5.8.1-4123 and the tool tells me ‘the firmware on this station is up to date’.
I see that I can force the update to version 6.3.0-4185 by using the ‘more options’ but if I understand from you this is something I better avoid for the time being.
Looking from the log you provided I agree with your analysis, the only issue is: what connection is the charging station attempting to make for this connection check? I cannot imagine that the device needs to be connected to an actual server to allow it to work without interruption. I would think that the station attempts to ping somewhere to see if there is a network connection. Do you have outgoing traffic from the charging station blocked one way or the other? Are you able to log network traffic on the port of the station with Wireshark to see what is happening right before the log entry about the ‘no internet connection’ is displayed?
Best regards,
Lieven
I checked the changelogs for all v6 versions of the firmware but I don’t find a mention about the connectivity check that is added. Did you immediately upgrade from v5 to v6.3? If you were running a previous version of the v6 firmware then you can consider downgrading back to that version as a temporary workaround.
Best regards,
Lieven
Thank you for your quick feedback.
I had the same issues with the previous 6.x firmware.
Downgrading is not possible since Alfen has changed the boot loader for the 6.x firmware :-(.
I have already contacted Alfen service support but they were not very cooperative.
As far as I’m aware of haven’t blocked the outgoing internet network traffic.
Best Regards,
Peter
Hey Peter,
any chance that you could put Wireshark network monitor on the switch port to see where the charge point is trying to connect to for the network check? If you have an old network hub just plug a computer in the hub together with the cable that goes to the chargepoint. If you have a managed switch you can put a second port in ‘monitoring mode’ so that it sees all the traffic the port of the chargepoint is seeing.
I could set such thing up but as you can image I am a bit reluctant to deploy the new firmware on my chargepoint as long as it is not clear how to resolve this… Are there other people with a similar setup and firmware who can confirm the issue that Peter is seeing?
Best regards,
Lieven.
Hi guys,
is there a possibility to set this entity “sensor.alfenwallbox_current_limit” with modbus register?
How could i do to find the correct modbus address and value?
My wallbox limit is 32A = 7.4kw.
Thanks in advance.
Regards,
Alessandro
I’ve update the hass plugin for alfen wallbox
you can get the gprs, wired cable and more information
Hey Hollie,
As requested for please find attached the Wireshark scan (Alfen Chargepoint and PC connected to a network hub without further connection to the network/router).
According the Alfen log file on 16:13 a periodic connection check was requested.
Can you advise form this scan what could the root cause of the network re-config/restart .
Thank you for your support,
Regards Peter
Hey Peter,
Hmm, I was hoping to see some attempts to reach an external server that were failing, but from the trace you show this is not immediately visible. Is there some traffic before the TCP retransmission that could give a clue? And to be sure: 192.168.2.200 is your Alfen, right? Who is 192.168.2.230? Is that the device that is running the Alfen software tool?
Best regards,
Lieven
Hey @Pedro_65,
due to an unfortunate incident on the grid I was forced to replace my chargepoint. It comes with the v6 .3.0 firmware and exhibits the same behaviour you see. The modbus connection is interrupted hourly.
I tried putting the device in ‘standalone mode’ but this does not change the behaviour.
Not clear to me how to resolve the situation.
Kind regards,
Lieven.
I need some help (please). I cannot get this working for some reason. I am sure that modbus is activated on the charger (i could manually add a sensor reading the chargers name).
If i use the HACS addon (manuall installed the version from @leeyuentuen i fail to connect.
I have enterered this: (i cannot find configuration settings for the modbus side on the charger so i entered the chargers owners password? (is that correct)? Should i use admin or owner as a user?
This is what the log shows:
2023-08-06 08:51:34.026 ERROR (MainThread) [custom_components.alfen_wallbox.config_flow] ClientError
Traceback (most recent call last):
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 980, in _wrap_create_connection
return await self._loop.create_connection(*args, **kwargs) # type: ignore[return-value] # noqa
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/asyncio/base_events.py”, line 1112, in create_connection
transport, protocol = await self._create_connection_transport(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/asyncio/base_events.py”, line 1145, in _create_connection_transport
await waiter
File “/usr/local/lib/python3.11/asyncio/selector_events.py”, line 970, in _read_ready__get_buffer
nbytes = self._sock.recv_into(buf)
^^^^^^^^^^^^^^^^^^^^^^^^^
ConnectionResetError: [Errno 104] Connection reset by peer
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File “/config/custom_components/alfen_wallbox/config_flow.py”, line 43, in _create_device
await device.init()
File “/config/custom_components/alfen_wallbox/alfen.py”, line 44, in init
await self.async_get_info()
File “/config/custom_components/alfen_wallbox/alfen.py”, line 152, in async_get_info
response = await self._session.request(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/client.py”, line 536, in _request
conn = await self._connector.connect(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 540, in connect
proto = await self._create_connection(req, traces, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 901, in _create_connection
_, proto = await self._create_direct_connection(req, traces, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 1209, in _create_direct_connection
raise last_exc
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 1178, in _create_direct_connection
transp, proto = await self._wrap_create_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/lib/python3.11/site-packages/aiohttp/connector.py”, line 988, in _wrap_create_connection
raise client_error(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host 192.168.68.15:502 ssl:<ssl.SSLContext object at 0x7ff5638411c0> [Connection reset by peer]
Any help is greatly appreciated,
tnx, Mike
the ip is without the port 502
to be sure, password should be the password of your cp
edit: my integration is not using modbus but using http polling system
Thanks for your reply, what password do you use? I cannot find any settings in the ACE tool?
Do i need to do any configuration via the ACE tool to get this working?
Thanks, Mike
the password is the same that you use on the my eve app on mobile phone
how i got the password, is the card that i got from the installer of the charging pole. i don’t know how you get them if you lost them. maybe you can get a recovery key from alfen support. but this i can’t help you here
Hi Hollie,
Thank you for your feedback. I also use the charger without backoffice.
As hotfix I increased the EMS current validity time from 60 sec to 150 sec to prevent charging current spikes when the Mobus communication is interrupted.
Best Regards
Peter
Thanks for your help. Got supported by Alfen!
Hi Hollie,
Issue seems to be resolved in firmware release 6.4.0
Release note:
Fixed an issue where the periodic connection check was executed when the charging station was
configured as a standalone charging station. This meant that the charging station was
unnecessarily disconnecting the Ethernet connection, for example the modbus slave connection,
even when that was not supposed to happen.
Best regards,
Peter
Hey @Pedro_65
thanks for this info, I have updated the firmware in my chargepoint and I can confirm the connection remains stable now for more than one hour.
Best regards,
Lieven.
I’ve searched around but can’t find a definitive answer to this question: how exactly do you enable the modbus interface through the ACE application? I don’t see an option for this anywhere. I do have the license for Active Load Balancing though, but not the one for “Smart Charging Network”. What this means is that I can select either “Meter” or “Energy Management System” as a Source, but when I select EMS the “Mode” setting is locked to “Socket” (see screenshots). Is that an issue?
The only modbus related thing I see is when I select “Meter” as a Source, I can select “Modbus TCP/IP” instead of the DSMR protocol, but that doesn’t seem to work.
If anyone has any tips I’d be much obliged.
