[Alfen Laadpaal] Ervaringen & Discussie

[JPD68]

Idr548 schreef op maandag 25 mei 2026 @ 14:19:
[...]

Ik dacht aan deze setting:
pauze: als er min 5 min netafname is van 700 watt
hervat: als er min 3min een overschot is van 1000 watt

Das ook beetj het ding. Met de pure 'solar' setting van alfen houd de auto ermee op na een tijdje.
Die swiched wel snel.

Max laadstroom naar 0. Ik had dat al eens getest en dan kreeg ik de laadsessie maar lastig weer van start.
En heeft dit nadeel op het geheugen? maar ik neem aan dat dit met modbus gewoon hetzelfde is.

Heb iets soortgelijks ingesteld in HA, lader gaat naar Comfort als er een bepaald overschot is en bij een bepaalde afname weer naar Green. Interval op 15 minuten gezet, draait nu een maand of 3 en de afname van netstroom is minimaal gebleken. Heb de lader voor die tijd elke paar seconden zien switchen als de modus op Green stond en dat vond de auto (Skoda Elroq) inderdaad niet zo fijn.

[Idr548]

JPD68 schreef op dinsdag 26 mei 2026 @ 09:07:
[...]

Heb iets soortgelijks ingesteld in HA, lader gaat naar Comfort als er een bepaald overschot is en bij een bepaalde afname weer naar Green. Interval op 15 minuten gezet, draait nu een maand of 3 en de afname van netstroom is minimaal gebleken. Heb de lader voor die tijd elke paar seconden zien switchen als de modus op Green stond en dat vond de auto (Skoda Elroq) inderdaad niet zo fijn.

Hey,

Super. Zo had ik het nog niet bekeken.
Switchen naar green zal er idd voor zorgen dat de laadpaal stopt bij afname.
Ik vermoed dat deze aanpassing ook geen problemen geef voor het geheugen als je daar een delay / timer op zet?

Jammer dat Alfen zelf geen optie aanbied om 'green' te kiezen met een delay om te vaak switchen te voorkomen.

[JPD68]

Idr548 schreef op dinsdag 26 mei 2026 @ 09:36:
[...]

Hey,

Super. Zo had ik het nog niet bekeken.
Switchen naar green zal er idd voor zorgen dat de laadpaal stopt bij afname.
Ik vermoed dat deze aanpassing ook geen problemen geef voor het geheugen als je daar een delay / timer op zet?

Jammer dat Alfen zelf geen optie aanbied om 'green' te kiezen met een delay om te vaak switchen te voorkomen.

Heb daar nog geen nadeel van ondervonden. Aangezien je alleen tussen de modi switcht lijkt mij dat geen probleem, dat is standaard functionaliteit.

[marciej123]

Luisterlijk schreef op maandag 25 mei 2026 @ 06:18:
Goedemorgen allen,

Bij mij nu ook gebeurd de 102. Lader 8 maanden oud en laadt 80% mijn Volvo en 20% onze Hyundai Kona. Na zonneladen te hebben ingeschakeld is het ineens mis bij laden van een Hyundai kona. Tot 2x toe 2 hoofdekzeringen in de meterkast er uit. Na de eerste keer werkte de lader weer, maar na de 2e keer dus niet.

Dit is waarschijnlijk geen garantie toch? Wat vinden jullie? Ik ga maandag wel bellen met de leverancier, maar waar ontstaat die fout en waar staat fase switching ingesteld? In Ace service installer?

Alvast bedankt!

sommige modellen van Kia / Hyundai (Waaronder de Niro ev / Kona) schakelen bij minder dan 8A over van 3 fasen naar 2 fasen.
Dit kan je kortsluiting veroorzaken.

Dus als je op 3 fasen wilt laden, altijd minimaal 3x 8A laden.
Met 1 fase zou dit geen probleem moeten zijn.

[Idr548]

Heeft er iemand toevallig weet van een "Anti-Toggle Time" setting.
Waarmee je voor bv "solar charging" de delay voor te stoppen met laden zou kunnen instellen?
Zodat hij bv 5min wacht alvorens te stoppen of te starten met laden ipv redelijk snel. Waardoor er toggle effect ontstaat

[elparia]

Today we are releasing Firmware Release 7.4 for our NG9 charging platform for Alfen Charging Equipment.

Our comprehensive assortment of electric charging stations are available in a wide range of charging capacities and functionalities, and we continue to add more capabilities to meet your needs.

Applicable Products
NG9xx firmware is used in: Eve Single S-line, Eve Single Pro-line, Eve Double Pro-line, Eve Double PG-line and Twin 4XL.

Release Content
In the download section, you will find the update file, release notes, configuration keys, error code list as well as an updated Service Installer.

The new firmware version comes with improvements and new functionalities outlined in the attached release notes.

Note: The firmware will be installed on Alfen charging stations produced starting today onwards.

Technical Support
Please report comments or questions via a ticket at support.alfen.com. Specify the firmware version and build number in your description.

If the firmware installation via the local configuration application (MyEve or Service Installer) fails due to a dropped connection, please retry either via a remote system (OCPP) or temporarily set the station to standalone and retry the firmware update.

Firmware terms
The Alfen firmware terms apply to this release and can be downloaded here.

Thank you for being a valued Customer.

[elparia]

1 Introduction

Firmware Release 7.4 includes new features, stability improvements and bug fixes. These release notes describe what is included in this release.

2 New features

- Added the possibility to reset the owner password back to the default password via OCPP using the configuration key PW-ResetChargerPassword.

- Added the possibility for a temporary user to change and reset the owner password. This allows for a CPO to set a temporary password and allow a local engineer to access the firmware without requiring Secure Service Access.

- Added the possibility to update to the bootloader to an earlier version than the current version in case it is determined that the current bootloader is corrupted.

- Added the possibility to erase personal data such as transactions, passwords, certificates, keys, local/white list, charging profiles and log data using our applications.

- Added the possibility for either an AFIR compliant disclaimer or a non-AFIR compliant disclaimer.

The AFIR compliant disclaimer states “Only applicable for ad-hoc charging”, the non-AFIR compliant disclaimer states “Additional costs may apply”. For this purpose a new OCPP

configuration key Pricing-ShowComponent is introduced with the options disclaimer-NonAfir and disclaimer-Afir.

- Added the possibility to permanently lock a charging cable to Eve Single S-line or Eve Single Pro-line charging stations equipped with a socket, using the configuration key “Connector1-Type” or Alfen Service Installer configuration item “Connector type” through the “Power settings”-menu (tick the “Advanced settings” checkbox).

Important notice: Alfen cannot be held accountable for any water ingress or subsequent damage to the electrical socket as a result of this application.

3 Improvements

- Improved the switching sequence of the onboard relays. The relays now switch simultaneously instead of sequentially.

- Added a new error code (error 215) to account for a loss of communication between the charging station and an external Modbus RTU energy meter.

- Stability improvements to Smart Charging Network

- Improved the distribution of available current when combining Active Load Balancing and Smart

Charging Network

- Cybersecurity improvements

- DigiCert root certificates are added

34 Bug fixes

- Fixed an issue where the error message relating to a defective relay (error 102) was not permanent and the charging station went out of the relay error state despite there being a defective relay.

- Fixed an issue where the ACE Service Installer did not update the displayed current/voltage values of the individual phases correctly after changing the phase mapping.

- Fixed an issue where updating firmware of multiple NFC readers in one charging station failed. In case of multiple NFC readers there will now be updated sequentially.

- Fixed an issue where disabling the cover lock on an Eve Double PG-line with a custom display logo caused an inconsistency in the user interface.

- Fixed an issue where a double socket charging station with two feeder cables in a Smart

Charging Network was limited in current when both sockets are occupied. Now the default maximum station current (StationMaxCurrent) is set proportionally to the amount of sockets after a reboot.

- Fixed an issue where the modem continuously tried to initialize during an active connection. Now if the charger has an active 4G connection or utilizes ethernet for connectivity the modem will not re-initialize.

- Fixed an issue where stopping the transaction caused by an RCD trip on an Eve Double PG-line caused an error with the signed meter data

- Fixed an issue where setting the maximum current of a sub SCN was limited by the maximum socket current. Now the maximum current of the SCN (which the subgroup is a part of) enforces the limit for the maximum current of the corresponding sub SCN.

- Fixed an issue where the charging station would not transition from suspendedEV to suspendedEVSE when charging is suspended.

- Fixed an issue where the meter values were incorrectly passed through in Wh instead of kWh

- Fixed an issue where the lockout timing was passed through in milliseconds instead of seconds to the ACE Service Installer

- Fixed an issue where the charging station returns an unknown error message in the ACE Service Installer after entering an invalid owner password

- Fixed an issue where setting up a back-office connection while a charging session is ongoing would crash a specific hardware revision of the Eve Double Pro-line. The charging station will now go into Inoperative mode when a download is ongoing and not download during a charging session.

- Fixed an issue where the SessionId incremented within the same Eichrecht transaction.

45 Back-office communication changes

- Fixed an issue where the charging station replied incorrectly to an out of range value for a RemoteStartTransaction. It now reports back an PropertyConstraintViolation after receiving such an out of range value, where previously the charging station reported a Format Violation in this situation.

- Fixed an issue regarding smart charging using charging profiles, where the lowest current of the TxDefaultProfile was obeyed while applying a TxProfile. The default profile is no longer overruling TxProfile even in case of a lower maximum limit.

- Added logging to detect a failed GetDiagnostic request when using an LTE network.

- Fixed an issue where the configuration of meter values was rejected when no phase was specified in the request. If no phase is specified the charging station determines if it can report it as multiple values per phase. If this is the case it will report these values to the back-office.

- Fixed an issue where the unit of measurand Energy.Active.Import.Register is inconsistently reported in either Wh or kWh. Now Energy.Active.Import.Register is reported in kWh by default.

- Fixed an issue where the charging station did not report when a reboot is required (RebootRequired) after a configuration change.

- Fixed an issue where the charging station would try to connect to a higher network profile during a firmware update, which could cause the update to fail. The charging station will now not connect to a higher priority network profile during an update.

- When a back-office requests a StatusNotification, the charging station will now confirm acceptance of the request or that the request is pending acceptance.

- Fixed an issue where the charging station would not clear a Faulted state towards the back-office when the user forces the end of a charging session

[Idr548]

Wanneer ik "green" selecteer en ik heb de "green share" op 50% staan zie ik dat het laden vaak stopt.
Ook al heb ik momenteel continue 1380watt net export.

Ik zie dan in de logs dingen zoals

• Wait Vehicle Charging
• Charge Point Ready, Waiting For Power
• Charging Power Off Low Max Current

(comfort level staat op 1450 watt)

Iemand een idee aan wat dit kan liggen?

[despijker]

Zoals in een eerdere post aangegeven ben ik naar 7.3.0-4377 gegaan op een single pro, omdat de laadtransacties niet zichtbaar waren. Nu heb ik constant issues met de HomeWizard P1 uitlezing via tcp. Zeer regelmatig de melding "P1 data not valid, no required records found". Dit tpoic al doorgespit, maar niet expliciet gevonden. Ik vermoed een bug in deze release, hebben meer mensen dit?

[elparia]

Upgrade naar 7.4 gedaan, alles lijkt vooralsnog goed te zijn. P1 data komt goed door, geen rare meldingen in de logs.

[Wietsee.]

Ik kan die 7.4 update nergens vinden.

[UlrichT]

Ik heb ook een vraag over HA, Alfen en het pauzeren van het laadproces.

Even mijn setup:
- SolarEdge systeem met thuisbatterij (9,2 kWh) - thuisbatterij heeft een max van 5000 watt.
- Alfen Eve Single Pro-line (3-fase, firmware 7.0.5-4328)
- Skoda Elroq

Mijn use cases:
1. Geen haast met laden
- Laden alleen op zonnestroom
- 4000 W
- Laden pauzeert als de thuisbatterij onder de 50% komt
- Laden hervat pas weer bij 90%

2. Wel haast met laden
- Laden met 11 kW

Beide scenario’s werken op zich prima, maar nu nog handmatig:
- Case 1 doe ik via Solar Charging Mode (Comfort) met comfort level op 4000 W. Bij 50% stop ik via de Skoda app het laden. Bij 90% moet ik de kabel even loshalen en opnieuw aansluiten.
- Case 2 via de Solar Charging Boost optie

Wat ik eigenlijk wil:
Dit proces via Home Assistant kunnen sturen, met name het pauzeren en hervatten van laden via de Alfen. Weet iemand welke entity of aanpak hiervoor het meest geschikt is?

[remmuz]

Wietsee. schreef op woensdag 27 mei 2026 @ 07:36:
Ik kan die 7.4 update nergens vinden.

Misschien de app updaten? 7.4 is vrij nieuw; https://knowledge.alfen.com/nl/categories/CAT-00916/KA-01643

[elparia]

Hmmm ik had een direct linkje. Hij staat ook hier zie ik:

https://knowledge.alfen.com/categories/CAT-00916/KA-01643

[helm71]

UlrichT schreef op woensdag 27 mei 2026 @ 07:59:
Ik heb ook een vraag over HA, Alfen en het pauzeren van het laadproces.

Even mijn setup:
- SolarEdge systeem met thuisbatterij (9,2 kWh) - thuisbatterij heeft een max van 5000 watt.
- Alfen Eve Single Pro-line (3-fase, firmware 7.0.5-4328)
- Skoda Elroq

Mijn use cases:
1. Geen haast met laden
- Laden alleen op zonnestroom
- 4000 W
- Laden pauzeert als de thuisbatterij onder de 50% komt
- Laden hervat pas weer bij 90%

2. Wel haast met laden
- Laden met 11 kW

Beide scenario’s werken op zich prima, maar nu nog handmatig:
- Case 1 doe ik via Solar Charging Mode (Comfort) met comfort level op 4000 W. Bij 50% stop ik via de Skoda app het laden. Bij 90% moet ik de kabel even loshalen en opnieuw aansluiten.
- Case 2 via de Solar Charging Boost optie

Wat ik eigenlijk wil:
Dit proces via Home Assistant kunnen sturen, met name het pauzeren en hervatten van laden via de Alfen. Weet iemand welke entity of aanpak hiervoor het meest geschikt is?


[Afbeelding]

Ik doe het met homey, maar dat zal met home assistant op dezelfde manier kunnen.


Bij inpluggen gedurende de dag gaat de paal op 100% groen en slurpt dan al het overschot aan stroom op, als het avond wordt schakelt hij over op laden op de goedkoopste kwartieren met het doel klaar te zijn op een instelbare tijd in de ochtend.


Systeem kijkt ‘s avonds elk kwartier hoeveel er nog in de auto moet, hoeveel kwartieren dat zijn, bepaald wat de goedkoopste kwartieren zijn voor dat aantal, kijkt of het toevallig dat kwartier is en gaat dan laden, volgend kwartier hetzelfde.


Het “stoppen en starten met laden” gedurende de nacht doenlijk door de paal ‘s nachts op 100% groen te zetten, de laadsessie blijft dan staan maar hij laad dan natuurlijk niet. Was even puzzelen, maar werkt inmiddels prima.

[MR. RHS]

helm71 schreef op woensdag 27 mei 2026 @ 12:06:
[...]

Ik doe het met homey, maar dat zal met home assistant op dezelfde manier kunnen.


Bij inpluggen gedurende de dag gaat de paal op 100% groen en slurpt dan al het overschot aan stroom op, als het avond wordt schakelt hij over op laden op de goedkoopste kwartieren met het doel klaar te zijn op een instelbare tijd in de ochtend.


Systeem kijkt ‘s avonds elk kwartier hoeveel er nog in de auto moet, hoeveel kwartieren dat zijn, bepaald wat de goedkoopste kwartieren zijn voor dat aantal, kijkt of het toevallig dat kwartier is en gaat dan laden, volgend kwartier hetzelfde.


Het “stoppen en starten met laden” gedurende de nacht doenlijk door de paal ‘s nachts op 100% groen te zetten, de laadsessie blijft dan staan maar hij laad dan natuurlijk niet. Was even puzzelen, maar werkt inmiddels prima.

Ik wil deze use case ook implementeren op mijn net nieuwe homey. Heb je hier een flow van ter inspiratie?

[helm71]

MR. RHS schreef op woensdag 27 mei 2026 @ 12:34:
[...]

Ik wil deze use case ook implementeren op mijn net nieuwe homey. Heb je hier een flow van ter inspiratie?

Zeker.. ik zal het setje vanavond posten.

het is een stapeling van homeyscript, advanced flow en regular flow.

ik heb eerst een homeyscript dat de kwartierprijzen van tibber ophaalt en in lokale variabelen stopt.

daarna heb ik dan flow die aangeven of de auto klaar is om te gaan laden.

vervolgens dan weer een homeyscript dat in de avonduren elk kwartier draait wanneer de auto klaar is om te gaan laden. Dat script maakt weer gebruik van lokale variabelen die aangeven hoe vol de auto mag en wanneer hij vol moet zijn.

daaromheen zit nog een structuur die er voor zorgt dat als ik “nu” wil laden dat ook kan.

Er zitten ook nog voorzieningen voor mijn thuisbatterij in, daar moet je dan even doorheen kijken.

[NTiBhohoSJ66vgJ]

Wietsee. schreef op woensdag 27 mei 2026 @ 07:36:
Ik kan die 7.4 update nergens vinden.

@elparia en @remmuz hadden de directe link al gepubliceerd, dus waarschijnlijk heb je hem al gevonden. Voor al diegenen die graag meer context bij de firmwares hebben: Hij staat inmiddels ook op de (vernieuwde) algemene firmware pagina: Release notes - Firmware updates NG-Platform (NG-910 / NG-920) | Alfen Knowledge Base

[balblas]

NTiBhohoSJ66vgJ schreef op woensdag 27 mei 2026 @ 13:33:
[...]

@elparia en @remmuz hadden de directe link al gepubliceerd, dus waarschijnlijk heb je hem al gevonden. Voor al diegenen die graag meer context bij de firmwares hebben: Hij staat inmiddels ook op de (vernieuwde) algemene firmware pagina: Release notes - Firmware updates NG-Platform (NG-910 / NG-920) | Alfen Knowledge Base

De 7.4 firmware upgrade verschijnt bij niet automatisch in ACE installer. Ik heb geprobeerd de firmware te upgraden na deze eerst handmatig gedownload te hebben, maar dat gaat niet goed. Ik krijg telkens een time-out na enkele minuten uploaden van de firmware naar de laadpaal (een Eve Single Pro-line NG910). Ik draai momenteel ng9xx 7.3.0-4377.

[helm71]

Ik zie hem ook gewoon in de MyEve app..

[balblas]

helm71 schreef op woensdag 27 mei 2026 @ 16:55:
Ik zie hem ook gewoon in de MyEve app..

Ik nu ook in de ACE installer en heb de firmware succesvol kunnen upgraden.

[Mighty Giesso]

Ik heb succesvol firmware 7.4 geïnstalleerd, download gedaan via ACE Service Installer. Ik kwam van 7.3. Ik zie de laadpaal, geeft ook IP adres en versie 7.4 maar tijdens inloggen krijg ik:



Herkennen mensen dit probleem? Laadpaal al 2x stroomloos gemaakt maar mag niet baten.... Laden werkt verder ook prima.

Via de MyEve app op de telefoon krijg ik Communicatiefout bij de webserver van het laadstation.

[ Voor 12% gewijzigd door Mighty Giesso op 27-05-2026 20:20 ]

[Hydraulic]

.

[ Voor 99% gewijzigd door Hydraulic op 27-05-2026 20:27 ]

[PizzaPete]

Mighty Giesso schreef op woensdag 27 mei 2026 @ 20:10:
Ik heb succesvol firmware 7.4 geïnstalleerd, download gedaan via ACE Service Installer. Ik kwam van 7.3. Ik zie de laadpaal, geeft ook IP adres en versie 7.4 maar tijdens inloggen krijg ik:

[Afbeelding]

Herkennen mensen dit probleem? Laadpaal al 2x stroomloos gemaakt maar mag niet baten.... Laden werkt verder ook prima.

Via de MyEve app op de telefoon krijg ik Communicatiefout bij de webserver van het laadstation.

Ik heb precies hetzelfde. Kan met geen mogelijkheid meer verbinden, niet via de Ace Service Installer, MyEve en ook niet met Eve Connect.

[asaki]

Hier is na het stoppen met laden de paal automatisch geüpdatet naar 7.4. Hier alleen geen connectie problemen. Geen verbinding problemen met de AceInstaller software en EVCC verbind ook nog prima.

Ik kan overigens geen release notes vinden van de firmware, heeft iemand die gezien?

[Koen Hendriks]

asaki schreef op woensdag 27 mei 2026 @ 21:48:
Hier is na het stoppen met laden de paal automatisch geüpdatet naar 7.4. Hier alleen geen connectie problemen. Geen verbinding problemen met de AceInstaller software en EVCC verbind ook nog prima.

Ik kan overigens geen release notes vinden van de firmware, heeft iemand die gezien?

In dit topic: elparia in "[Alfen Laadpaal] Ervaringen & Discussie"

[Kusterse]

Mighty Giesso schreef op woensdag 27 mei 2026 @ 20:10:
Ik heb succesvol firmware 7.4 geïnstalleerd, download gedaan via ACE Service Installer. Ik kwam van 7.3. Ik zie de laadpaal, geeft ook IP adres en versie 7.4 maar tijdens inloggen krijg ik:

[Afbeelding]

Herkennen mensen dit probleem? Laadpaal al 2x stroomloos gemaakt maar mag niet baten.... Laden werkt verder ook prima.

Via de MyEve app op de telefoon krijg ik Communicatiefout bij de webserver van het laadstation.

Had ik ook maar na herstart laadpaal alles OK.

In het verleden heb ik ook wel eens de router opnieuw moeten starten om de paal in het netwerk te kunnen zien en in te kunnen loggen.

[asaki]

- Added the possibility to reset the owner password back to the default password via OCPP using the configuration key PW-ResetChargerPassword.

Dit is wel echt een lompe optie. Buiten het feit dat deze firmware automatisch werd geïnstalleerd (dit heb ik nog nooit gezien bij een Alfen paal) maak ik me toch wel een beetje zorgen dat de backoffice het wachtwoord van de paal aanpast

[teddytbp]

Hier idem na 7.4 paal is in ace installer te zien maar time-out.

Spanningsloos zetten is hier alvast niet de oplossing geweest 1 maal 10 sec en 1 maal 15 minuten.

in de MyEve app geeft hij aan dat er een communicatie fout bij de webserver.

[ Voor 20% gewijzigd door teddytbp op 27-05-2026 23:45 ]

[Mighty Giesso]

Kusterse schreef op woensdag 27 mei 2026 @ 22:55:
[...]

Had ik ook maar na herstart laadpaal alles OK.

In het verleden heb ik ook wel eens de router opnieuw moeten starten om de paal in het netwerk te kunnen zien en in te kunnen loggen.

Herstarten van mijn routers, switches en ap's helpen helaas ook niet. Heb ondertussen ook een case aangemaakt bij Alfen.

[ Voor 6% gewijzigd door Mighty Giesso op 27-05-2026 23:48 ]

[Kusterse]

Mighty Giesso schreef op woensdag 27 mei 2026 @ 23:45:
[...]

Herstarten van mijn routers, switches en ap's helpen helaas ook niet. Heb ondertussen ook een case aangemaakt bij Alfen.

Is er al geprobeerd direct verbinding te maken (zonder router) Misschien zit er een component tussen dat de reactie tijd verlegd?

[despijker]

asaki schreef op woensdag 27 mei 2026 @ 23:34:
[...]


Dit is wel echt een lompe optie. Buiten het feit dat deze firmware automatisch werd geïnstalleerd (dit heb ik nog nooit gezien bij een Alfen paal) maak ik me toch wel een beetje zorgen dat de backoffice het wachtwoord van de paal aanpast

Hoezo automatisch? Dat zou wel erg bijzonder zijn.

[Wietsee.]

Dank voor de link. Update succesvol uitgevoerd van 7.3 naar 7.4.

[teddytbp]

Hier ondertussen rechtstreeks wel gelukt. Ga hier voorlopig even kijken naar mogelijk IP probleem mijn range is 192.168.1.x rechtstreeks geeft de paal een intern falback ip op aan verbonden toestel en dan lijk ik er direct op te kunnen.

[ Voor 13% gewijzigd door teddytbp op 28-05-2026 08:13 ]

[despijker]

Ik ben benieuwd naar de reden en oplossing. Daarom de update even on hold hier.

[asaki]

despijker schreef op donderdag 28 mei 2026 @ 00:06:
[...]

Ja mee eens, heb het ook nog nooit gezien. Maar ik trok de stekker uit de auto en liep naar de laadpaal om de kabel op te hangen toen ik dit zag.

Ik zal Eneco eMobility eens aantikken om te vragen waarom ze deze FW hebben gepushed. Ik zit er bijna aan te denken om een rollback te doen. Ik zie in de release notes niet echt fixes die nodig zijn.

[ Voor 5% gewijzigd door asaki op 28-05-2026 13:17 ]

[Microstar]

asaki schreef op donderdag 28 mei 2026 @ 13:15:
[...]


Ik zie in de release notes niet echt fixes die nodig zijn.

Daarom snap ik niet waarom zoveel mensen in dit topic nu al gaan updaten. Als je de historie van Alfen kent, weet je dat nieuwe releases oude bugs opnieuw kunnen introduceren of juist nieuwe bugs kunnen bevatten.

[asaki]

Vuistregel: Voor elke fix gaan er twee dingen kapot

[mrdop]

asaki schreef op donderdag 28 mei 2026 @ 13:15:
[...]


Ja mee eens, heb het ook nog nooit gezien. Maar ik trok de stekker uit de auto en liep naar de laadpaal om de kabel op te hangen toen ik dit zag.[Afbeelding]

Ik zal Eneco eMobility eens aantikken om te vragen waarom ze deze FW hebben gepushed. Ik zit er bijna aan te denken om een rollback te doen. Ik zie in de release notes niet echt fixes die nodig zijn.

Eens. Eneco doet 5 jaar niks, en dan deze wel in enen?

Ik kon er eerst ook niet in, EveConnect werkte wel en daar zag ik dat de paal een ander ip-adres (bij mij eentje lager) heeft gekregen/afgedwongen. Dat aanpassen en zonder rebooten weer overal in.

[despijker]

Je had je laadpaal niet op een fixed IP gezet dus en kennelijk je ARP tabellen al opgeschoond. Tja dan kan dit zomaar. Verder geen gekke bugs gezien in 7.4? Werkt P1 communicatie via TCP?

[ Voor 22% gewijzigd door despijker op 28-05-2026 17:19 ]

[mrdop]

despijker schreef op donderdag 28 mei 2026 @ 17:18:
Je had je laadpaal niet op een fixed IP gezet dus en kennelijk je ARP tabellen al opgeschoond. Tja dan kan dit zomaar. Verder geen gekke bugs gezien in 7.4? Werkt P1 communicatie via TCP?

Vandaag auto op zonneladen geladen, ging prima. Dus P1 comms werkt (maar hier gewoon via de rj11 kabel). Daarna zag ik pas dat de paal (uit zichzelf) geupdate had. Verder (nog) geen bugs gezien (gelukkig). Had ook liever willen wachten.

[Mighty Giesso]

Vandaag maar weer ff verder gestoeid, laptop maar eens direct op de paal aangesloten en ik kon er in. Fixed IP gekozen reboot etc. op afstand niet te beheren. Daarna downgrade van firmware gedaan, op afstand beheer weer mogelijk. Daarna opnieuw naar 7.4 geflashed en op afstand inloggen werkt weer. MyEve app werkt weer en Eve Connect ook. Heb nog wel geregeld de melding "p1 data not valid no required records found" Toen ik hem terug geflashed had op 7.3 zag ik hem ook voorbij komen continu. Volgens mij had ik dat voordien niet. Maak gebruik van HomeWizard.

Blijft toch beetje krakkemikkelig allemaal.

[despijker]

Dank voor de reactie. Precies die melding heb ik nu ook in 7.3.0-4377. Dus het heeft voor mij geen zin om naar 7.4 te gaan dus.

[Rink76]

Hallo,

Ik heb mijn Alfen Eve Single Pro-line (ACE0030972) zojuist bijgewerkt van firmware 7.3.0-4377 naar 7.4.0-4401 via de ACE Service Installer. Upgrade heb ik al vaker gedaan, altijd zonder problemen.

Na de update komt de paal gewoon online bij mijn back-office (Tap Electric) en zie ik ook de nieuwe firmwareversie staan. De paal laadt ook gewoon. Alleen kan ik er via de ACE Service Installer niet meer mee verbinden, ik krijg een 'Login request timeout'.

Eerst dacht ik dat het een wachtwoordprobleem was. Via Tap Electric zie ik dat ik de configuratiesleutel PW-ResetChargerPassword op True kan zetten om het wachtwoord te resetten naar de fabrieksstandaard. Dat heb ik echter nog niet geprobeerd, omdat ik daarna een poortscan heb gedaan en daar een opmerkelijke uitkomst uit kwam.

Wat ik al geprobeerd heb:

• - Spanningsloos gemaakt (60 seconden), probleem blijft
• - Volledige poortscan gedaan met nmap (1-65535)

Uitkomst nmap: host is up (ping werkt), maar alle 65535 poorten zijn gesloten. De paal reageert dus wel op ping en communiceert via OCPP met de back-office, maar de lokale service stack lijkt niet opgestart na de firmware-upgrade. Een wachtwoordreset via PW-ResetChargerPassword lijkt daardoor ook geen zin te hebben zolang er geen enkele poort open staat.

Heeft iemand dit eerder gehad na een upgrade naar 7.4? En zo ja, hoe opgelost?

[rally]

Rink76 schreef op donderdag 28 mei 2026 @ 20:10:
Hallo,

Ik heb mijn Alfen Eve Single Pro-line (ACE0030972) zojuist bijgewerkt van firmware 7.3.0-4377 naar 7.4.0-4401 via de ACE Service Installer. Upgrade heb ik al vaker gedaan, altijd zonder problemen.

Na de update komt de paal gewoon online bij mijn back-office (Tap Electric) en zie ik ook de nieuwe firmwareversie staan. De paal laadt ook gewoon. Alleen kan ik er via de ACE Service Installer niet meer mee verbinden, ik krijg een 'Login request timeout'.

Eerst dacht ik dat het een wachtwoordprobleem was. Via Tap Electric zie ik dat ik de configuratiesleutel PW-ResetChargerPassword op True kan zetten om het wachtwoord te resetten naar de fabrieksstandaard. Dat heb ik echter nog niet geprobeerd, omdat ik daarna een poortscan heb gedaan en daar een opmerkelijke uitkomst uit kwam.

Wat ik al geprobeerd heb:

• - Spanningsloos gemaakt (60 seconden), probleem blijft
• - Volledige poortscan gedaan met nmap (1-65535)

Uitkomst nmap: host is up (ping werkt), maar alle 65535 poorten zijn gesloten. De paal reageert dus wel op ping en communiceert via OCPP met de back-office, maar de lokale service stack lijkt niet opgestart na de firmware-upgrade. Een wachtwoordreset via PW-ResetChargerPassword lijkt daardoor ook geen zin te hebben zolang er geen enkele poort open staat.

Heeft iemand dit eerder gehad na een upgrade naar 7.4? En zo ja, hoe opgelost?

Exact hetzelfde probleem hier
Laadpaal proberen te herstarten door de stroom eraf te halen. Geen van de Alfen apps (EVE Connect en EVE pro op iOS en Alfen Service Installer op mijn laptop) krijgen meer verbinding.

Mighty Guisso heeft een case aangemaakt, dus hopelijk krijgt hij snel een oplossing.

Gelukkig werken de management portalen nog wel, want daar is alles online en staat ook dat hij firmware 7.4.0 heeft.

[r2504]

asaki schreef op woensdag 27 mei 2026 @ 23:34:
[...]

maak ik me toch wel een beetje zorgen dat de backoffice het wachtwoord van de paal aanpast

Terug naar het "default" paswoord... dat heb je normaal toch ?

Geen idee of men nu al een "niet default" paswoord kan instellen via OCPP.

[Will_M]

Rink76 schreef op donderdag 28 mei 2026 @ 20:10:
Hallo,

Ik heb mijn Alfen Eve Single Pro-line (ACE0030972) zojuist bijgewerkt van firmware 7.3.0-4377 naar 7.4.0-4401 via de ACE Service Installer. Upgrade heb ik al vaker gedaan, altijd zonder problemen.

Na de update komt de paal gewoon online bij mijn back-office (Tap Electric) en zie ik ook de nieuwe firmwareversie staan. De paal laadt ook gewoon. Alleen kan ik er via de ACE Service Installer niet meer mee verbinden, ik krijg een 'Login request timeout'.

Eerst dacht ik dat het een wachtwoordprobleem was. Via Tap Electric zie ik dat ik de configuratiesleutel PW-ResetChargerPassword op True kan zetten om het wachtwoord te resetten naar de fabrieksstandaard. Dat heb ik echter nog niet geprobeerd, omdat ik daarna een poortscan heb gedaan en daar een opmerkelijke uitkomst uit kwam.

Wat ik al geprobeerd heb:

• - Spanningsloos gemaakt (60 seconden), probleem blijft
• - Volledige poortscan gedaan met nmap (1-65535)

Uitkomst nmap: host is up (ping werkt), maar alle 65535 poorten zijn gesloten. De paal reageert dus wel op ping en communiceert via OCPP met de back-office, maar de lokale service stack lijkt niet opgestart na de firmware-upgrade. Een wachtwoordreset via PW-ResetChargerPassword lijkt daardoor ook geen zin te hebben zolang er geen enkele poort open staat.

Heeft iemand dit eerder gehad na een upgrade naar 7.4? En zo ja, hoe opgelost?

Mijn Eve Single Pro draait 7.3.0-4377 en laat in de Eve Connect / My-EVE App niet zien dat er een update beschikbaar is. Is 7.4.0-4401 misschien nog in Bèta?

[Rink76]

Will_M schreef op donderdag 28 mei 2026 @ 20:36:
[...]


Mijn Eve Single Pro draait 7.3.0-4377 en laat in de Eve Connect App niet zien dat er een update beschikbaar is. Is 7.4.0-4401 misschien nog in Bèta?

7.4 is gewoon een stabiele release, geen bèta. Ik had een mailtje van Alfen gekregen met de aankondiging, en de ACE Service Installer had de firmware ook automatisch gedownload en aangeboden.

Waarom de Eve Connect app hem niet toont weet ik niet, maar via de ACE Service Installer was hij gewoon beschikbaar.

Documentatie van Alfen:

- Release Notes NG9xx 7.4

- Firmware upgrade file NG9xx 7.4

[Rink76]

rally schreef op donderdag 28 mei 2026 @ 20:24:
[...]

Exact hetzelfde probleem hier
Laadpaal proberen te herstarten door de stroom eraf te halen. Geen van de Alfen apps (EVE Connect en EVE pro op iOS en Alfen Service Installer op mijn laptop) krijgen meer verbinding.

Mighty Guisso heeft een case aangemaakt, dus hopelijk krijgt hij snel een oplossing.

Gelukkig werken de management portalen nog wel, want daar is alles online en staat ook dat hij firmware 7.4.0 heeft.

Goed om te weten dat ik niet de enige ben, maar ook wel zorgelijk dat het dus breder speelt.

Ben zeker benieuwd naar de uitkomst van die case. Wat ik me wel afvraag: als er lokaal helemaal geen enkele poort meer open staat (ik heb een volledige nmap scan gedaan van 1-65535, alles gesloten), hoe denkt Alfen dit dan op afstand op te lossen? Er is geen enkele lokale service meer bereikbaar. De paal praat wel nog via OCPP met de back-office, maar dat lijkt de enige communicatie die nog werkt.

[asaki]

r2504 schreef op donderdag 28 mei 2026 @ 20:32:
[...]

Terug naar het "default" paswoord... dat heb je normaal toch ?

Geen idee of men nu al een "niet default" paswoord kan instellen via OCPP.

Mijn paal is geleverd met firmware 4.x, toen was er geen eis om met een wachtwoord in te loggen, maar er was wel een default wachtwoord ingesteld (dit heb ik toen niet gekregen). Tijdens de installatie van firmware 5.x kan je een wachtwoord instellen, en met dat wachtwoord log ik altijd in. Het default wachtwoord weet ik dus niet.

[teddytbp]

Hier met direct connect naar 7.3 en daarna 7.4 geen succes. Nu dan maar even op 7.3 verder.

[rally]

Ik kan nog in mijn PlugChoice portal en daar zag ik onderstaande melding.

Eerder nog stond daar dat er firmware 7.4.0. Op draaide…

Maar PlugChoice en TapElectric geven nog aan dat de paal online is en ik kan gewoon laden (dat is wel fijn)

[ Voor 9% gewijzigd door rally op 28-05-2026 22:06 ]

[Kusterse]

asaki schreef op donderdag 28 mei 2026 @ 21:20:
[...]


Mijn paal is geleverd met firmware 4.x, toen was er geen eis om met een wachtwoord in te loggen, maar er was wel een default wachtwoord ingesteld (dit heb ik toen niet gekregen). Tijdens de installatie van firmware 5.x kan je een wachtwoord instellen, en met dat wachtwoord log ik altijd in. Het default wachtwoord weet ik dus niet.

Het is geeeen password issue. Er word ook niet aangegeven dat het wacht woord verkeerd is.

Hier boven was iemand die zijn computer direct aan de laadpaal heeft aangesloten en kwam er toen weer in. Er is geen reden voor dat het wachtwoord aangepast is tijdens de update. Het wachtwoord van mij paal is ook niet origineel en ik heb het originele ook niet. Toch kom ik er na de update 7.3 --> 7.4 gewoon in na een herstart. Het aanpassen van het wachtwoord via occp kan je hooguit verder in de problemen brengen.

[asaki]

Ik zeg ook niet dat ik er niet meer in kom. Het feit dat ze nu vanuit de backoffice het wachtwoord kunnen resetten naar default vind ik wel een probleem. Ik zeg niet dat ze het doen, maar ze hebben dus de mogelijkheid.

[Mighty Giesso]

Rink76 schreef op donderdag 28 mei 2026 @ 20:10:
Hallo,

Ik heb mijn Alfen Eve Single Pro-line (ACE0030972) zojuist bijgewerkt van firmware 7.3.0-4377 naar 7.4.0-4401 via de ACE Service Installer. Upgrade heb ik al vaker gedaan, altijd zonder problemen.

Na de update komt de paal gewoon online bij mijn back-office (Tap Electric) en zie ik ook de nieuwe firmwareversie staan. De paal laadt ook gewoon. Alleen kan ik er via de ACE Service Installer niet meer mee verbinden, ik krijg een 'Login request timeout'.

Eerst dacht ik dat het een wachtwoordprobleem was. Via Tap Electric zie ik dat ik de configuratiesleutel PW-ResetChargerPassword op True kan zetten om het wachtwoord te resetten naar de fabrieksstandaard. Dat heb ik echter nog niet geprobeerd, omdat ik daarna een poortscan heb gedaan en daar een opmerkelijke uitkomst uit kwam.

Wat ik al geprobeerd heb:

• - Spanningsloos gemaakt (60 seconden), probleem blijft
• - Volledige poortscan gedaan met nmap (1-65535)

Uitkomst nmap: host is up (ping werkt), maar alle 65535 poorten zijn gesloten. De paal reageert dus wel op ping en communiceert via OCPP met de back-office, maar de lokale service stack lijkt niet opgestart na de firmware-upgrade. Een wachtwoordreset via PW-ResetChargerPassword lijkt daardoor ook geen zin te hebben zolang er geen enkele poort open staat.

Heeft iemand dit eerder gehad na een upgrade naar 7.4? En zo ja, hoe opgelost?

Voor mij was de oplossing de laptop direct aan de laadpaal te hangen, dan is hij weer te beheren via de ACE Service Installer. Hij stond bij mij op DHCP, fixed ip gegeven en daarna terug geflashed naar 7.3 Daarna gewoon weer via het netwerk te benaderen, toen een flash gedaan naar 7.4 waarna alles weer werkte.

Ik heb nog geen reactie op de case op dit moment. Zodra ik hier meer over hoor zal ik mij melden.

[Rink76]

Mighty Giesso schreef op vrijdag 29 mei 2026 @ 07:40:
[...]

Voor mij was de oplossing de laptop direct aan de laadpaal te hangen, dan is hij weer te beheren via de ACE Service Installer. Hij stond bij mij op DHCP, fixed ip gegeven en daarna terug geflashed naar 7.3 Daarna gewoon weer via het netwerk te benaderen, toen een flash gedaan naar 7.4 waarna alles weer werkte.

Ik heb nog geen reactie op de case op dit moment. Zodra ik hier meer over hoor zal ik mij melden.

Dank voor de tip! Ga dit proberen.

Even voor de volledigheid voor anderen die dit lezen: hoe werkt dat IP-technisch als je de laptop direct aan de paal hangt? Draait er een DHCP-server op de paal die de laptop automatisch een IP-adres geeft, of werkt het via een link-local (APIPA) adres?

Ik neem aan dat de paal zelf een vast IP heeft op die directe verbinding (zag eerder 169.254.1.10 in de ASI), en dat de laptop daar dan automatisch een adres in hetzelfde subnet van krijgt?

[r2504]

Als een DHCP client (je laadpaal) geen DHCP server kan vinden dan neemt die normaal een adres in de APIPA range 169.254.0.1 tot 169.254.255.254

Als je laptop rechtstreeks aan je paal hangt dan kan die dus geen DHCP server vinden (tenzij je die zou draaien op je PC wat niet de bedoeling is). Het lijkt er dus op dat er problemen zijn met de DHCP client van de paal aangezien mensen problemen rapporteren als hij gewoon op het netwerk hangt (en dus wel een DHCP server ziet).

[PizzaPete]

Dat het iets met DHCP te maken heeft, dat gevoel krijg ik ook.

Gisteren direct verbonden met mijn laptop naar de laadpaal. Vervolgens gedowngrade naar 7.3 en toen werkte alles weer. Voor de zekerheid een vast IP ingevuld, de paal een restart gegeven en vervolgens de upgrade naar 7.4 gestart.

Daarna kon ik de paal beheren, maar zag ik dat de paal niet met de HomeWizard P1 meter kon verbinden (dit was eerder wel het geval) en dat OCPP niet werkte (dit was eerder wel het geval). Tevens zag ik in de portal van Tap dat de paal offline was.

Daarna heb ik het vinkje weg gehaald bij de optie Fixed IP en zag ik dat de HomeWizard gelijk begon te werken, maar OCPP nog niet. Vervolgens de paal een herstart gegeven en toen kwam de paal online in de portal van Tap. Maar nu kan ik weer niet meer inloggen op mijn laptop of mobiel op de paal.

Het IP adres dat de paal krijgt is fixed in mijn netwerk instellingen. Na het verwijderen van de instellingen op de paal en het vinkje van Fixed IP zou hij hetzelfde IP moeten krijgen, dat gebeurt ook zie ik in de management console van mijn netwerk. Ik heb het idee dat de management console van de laadpaal niet goed wordt gekoppeld aan het “dynamische” IP adres van de paal.

[V_ger]

Will_M schreef op donderdag 28 mei 2026 @ 20:36:
[...]


Mijn Eve Single Pro draait 7.3.0-4377 en laat in de Eve Connect / My-EVE App niet zien dat er een update beschikbaar is. Is 7.4.0-4401 misschien nog in Bèta?

Normaal gesproken natuurlijk niet, maar ervaring leert dat een nieuwe versie bij Alfen eigenlijk altijd een publieke beta is...Ze staan nou niet echt bekend om hun rock solid, bug free firmware releases.

[mrdop]

despijker schreef op donderdag 28 mei 2026 @ 17:18:
Je had je laadpaal niet op een fixed IP gezet dus en kennelijk je ARP tabellen al opgeschoond. Tja dan kan dit zomaar. Verder geen gekke bugs gezien in 7.4? Werkt P1 communicatie via TCP?

Fixed IP moest ik nog steeds doen. Nu gedaan. En… nu kan ik er dus ook niet meer in…..

Vanmiddag maar even terug naar 7.3

[ Voor 4% gewijzigd door mrdop op 29-05-2026 09:26 ]

[despijker]

Had je het Ip vastgezet in de paal zelf, of op de DHCP server?

[Mighty Giesso]

Rink76 schreef op vrijdag 29 mei 2026 @ 08:15:
[...]

Dank voor de tip! Ga dit proberen.

Even voor de volledigheid voor anderen die dit lezen: hoe werkt dat IP-technisch als je de laptop direct aan de paal hangt? Draait er een DHCP-server op de paal die de laptop automatisch een IP-adres geeft, of werkt het via een link-local (APIPA) adres?

Ik neem aan dat de paal zelf een vast IP heeft op die directe verbinding (zag eerder 169.254.1.10 in de ASI), en dat de laptop daar dan automatisch een adres in hetzelfde subnet van krijgt?

Het beheren,connecteren en flashen werkte bij mij prima in de APIPA range 169.254.0.1 tot 169.254.255.254

[Rink76]

Mighty Giesso schreef op vrijdag 29 mei 2026 @ 10:30:
[...]

Het beheren,connecteren en flashen werkte bij mij prima in de APIPA range 169.254.0.1 tot 169.254.255.254

Dank voor de hulp en de tip! Het is inderdaad gelukt, werkt weer perfect.

Kort de stappen die ik heb gevolgd voor anderen die hetzelfde probleem tegenkomen:

1. 1. UTP-kabel direct van laptop naar laadpaal
2. 2. Laptop krijgt automatisch een APIPA-adres (169.254.x.x range)
3. 3. In ACE Service Installer verbonden via het APIPA-adres van de paal (169.254.1.10)
4. 4. Downgrade uitgevoerd naar 7.3.0-4377
5. 5. Netwerkinstellingen gecontroleerd en fixed IP ingesteld
6. 6. Opnieuw upgrade uitgevoerd naar 7.4.0-4401
7. 7. Daarna weer gewoon via het vaste IP op het netwerk bereikbaar

De paal communiceert de hele tijd wel gewoon via OCPP met de back-office, dus laden bleef gewoon werken. Alleen de lokale service stack startte na de eerste upgrade niet correct op.

[jouwheld]

mrdop schreef op donderdag 28 mei 2026 @ 16:40:
[...]

Eens. Eneco doet 5 jaar niks, en dan deze wel in enen?

Ik kon er eerst ook niet in, EveConnect werkte wel en daar zag ik dat de paal een ander ip-adres (bij mij eentje lager) heeft gekregen/afgedwongen. Dat aanpassen en zonder rebooten weer overal in.

Heb ook een paal van Eneco Mobility, die inderdaad toen ik hem aan mijn netwerk en HA hing, nog de versie draaide van tijdens de installatie. Toch even gekeken en ik draai tegenwoordig blijkbaar 7.3.0-4377 die op 19 mei is gepushed. Versie 7.4 is nog niet gepushed, maar blijkbaar pushen ze inderdaad tegenwoordig updates.

Ik vind het stiekem wel fijn, wilde hem zelf niet updaten om bij een brick niet de discusisie met hun aan te hoeven gaan. De paal komt waarschijnlijk volgend jaar in mijn beheer dus dan draai ik iig een recente versie.

[Mezelf]

Rink76 schreef op vrijdag 29 mei 2026 @ 13:50:
[...]

1. 4. Downgrade uitgevoerd naar 7.3.0-4377
2. 5. Netwerkinstellingen gecontroleerd en fixed IP ingesteld
3. 6. Opnieuw upgrade uitgevoerd naar 7.4.0-4401
4. 7. Daarna weer gewoon via het vaste IP op het netwerk bereikbaar

Ik heb hetzelfde probleem, zal vanavond de fix testen.

Vraag: ipv te downgraden. Als je bij de paal kunt via het APIPA adres, dan kun je op dat moment ook een vast IP zetten terwijl de firmware nog op 7.4 zit. Heeft iemand dat al geprobeerd?

Ik vind het wat tricky om te doen, want als je een vast IP zet, dan zoekt de paal in principe niet meer naar een DHCP server en zal hij ook geen APIPA adres krijgen? En dan werkt de workaround niet meer?

[jouwheld]

Mezelf schreef op vrijdag 29 mei 2026 @ 14:35:
[...]

Ik heb hetzelfde probleem, zal vanavond de fix testen.

Vraag: ipv te downgraden. Als je bij de paal kunt via het APIPA adres, dan kun je op dat moment ook een vast IP zetten terwijl de firmware nog op 7.4 zit. Heeft iemand dat al geprobeerd?

Ik vind het wat tricky om te doen, want als je een vast IP zet, dan zoekt de paal in principe niet meer naar een DHCP server en zal hij ook geen APIPA adres krijgen? En dan werkt de workaround niet meer?

Je zou ook een reservering in je router/DHCP-server kunnen maken, dan krijgt die een vast IP vanuit je DHCP server. Als die dan niet bereikbaar is krijgt die nog een APIPA adres. De meeste providerkastjes kunnen dtit meestal wel.

[mrdop]

despijker schreef op vrijdag 29 mei 2026 @ 09:58:
Had je het Ip vastgezet in de paal zelf, of op de DHCP server?

Op de DHCP-server.

[Mezelf]

Dat is idd mijn setup. Dus de paal staat op DHCP en krijgt een voorspelbaar adres. Maar als het probleem met 7.4 is dat de Alfen zelf op "fixed ip" moet worden gezet, omdat anders de service stack niet draait? Dan zou een downgrade niet nodig zijn.

[ Voor 50% gewijzigd door Mezelf op 29-05-2026 14:59 ]

[elparia]

Mijn upgrade van 7.3 naar 7.4 ging goed met DHCP, echter wel op de router de DHCP lease static gemaakt zodat hij altijd hetzelfde IP adres krijgt.

[NoFate]

elparia schreef op vrijdag 29 mei 2026 @ 15:42:
Mijn upgrade van 7.3 naar 7.4 ging goed met DHCP, echter wel op de router de DHCP lease static gemaakt zodat hij altijd hetzelfde IP adres krijgt.

dat zou niet uitmaken, want dat weet de paal niet, dat hij een MAC reservatie krijgt :-)

Wel vreemd dat 7.4 toch wel wat issues geeft

[elparia]

NoFate schreef op vrijdag 29 mei 2026 @ 15:52:
[...]

dat zou niet uitmaken, want dat weet de paal niet, dat hij een MAC reservatie krijgt :-)

Wel vreemd dat 7.4 toch wel wat issues geeft

Ja precies, raar dat bij mij de upgrade dan gewoon goed ging en paal bereikbaar bleef aangezien het toch wel een probleem lijkt te zijn als de paal op DHCP staat.

[despijker]

Maar resumerend, wat is er nou daadwerkelijk veranderd, vebeterd waar wij als gebruikers baat bij hebben?

[Coffee]

Beste allen, ik probeer een Alfen Eve Single Pro in beheer te nemen. Dit betreft een oud apparaat met Vattenfall backoffice die wij over willen nemen. De paal werkt naar behoren, maar de verbinding met de back-office is niet meer actief. Wij proberen in te loggen op de paal, maar deze wordt niet herkend door de MyEve App. De ACE Service Installer herkent de paal wel, maar geeft een foutmelding:

Failed to communicate with device at IP address 169.254.1.11

Error:

Echter blijft de exacte foutmelding leeg. Ik heb deze foutmelding in deze forumthread gezocht, maar niet terug gevonden. Heeft iemand enig idee?

[Mezelf]

Coffee schreef op vrijdag 29 mei 2026 @ 18:52:


Failed to communicate with device at IP address 169.254.1.11

Sorry als het heel obvious is en je het al hebt gedaan; de paal zonder stroom zetten en weer aanzetten heeft mij al vaak verder geholpen.