utp, but installer placed it. I think I can pick up the utp cable coming in my home, connect it there to the laptop (with DHCP), and see if it helps. will try a couple of things over the weekend and report back here
Yeah that’s what I do as well. Remove the cable from my router, plug it into my laptop and then back into the router.
I ran a connectivity test and weirdly enough I did not have a disconnect this evening, it’s still working. One thing I found with ACE is that the “wired” network profile has an incorrect back-office URL configured. I see that in the charger logs where it tries to connect (as wired is priority #1) and then falls back to the 2G mobile connection which does have a proper URL configured.
So a hunch is that it might try those network profiles, fail on the wrong URL, decides to treat that network profile as faulty and thus also disables any further communication on that interface. Again, it’s nothing more than a hunch and might be completely wrong. I’ve asked Eneco if they can update the profile and set the right URL. Seems I’m locked out from changing that myself as long as the charger is backoffice connected.
Hmmm, I checked but couldn’t find the settings in there either. They do show in ACE, but as read-only.
Would there someone be willing to share their logs with me? Specifically for a Eve Single Pro cable which is backoffice connected via 2G and UTP connected as well? I’d like to compare my logs to yours. I see quite a lot of lines with things like “ERROR:modem.c:2156:Check modem response failed”. Seems like a problem, comparing my charger to one that functioning well might rule that out.
i will try tomorrow and check when i am trying to get the webserver running again
I’m trying to load my vehicle only using solar surplus. I use the card ‘zet manier van laden op 100% Groen’.
At this moment my solarpanels produce approx. 600 Watt but my charging station keeps on charging at 1.3 kW (so it’s importing power). I would expect the charging station to pause as soon as the solarpanel-production is lower than the minimum which the charging station need.
In My Eve app it says ‘opladen met zonne-energie’ and radio button ‘Groen’
What am I doing wrong? Am I using the correct card?
I’m experiencing the same. Both when using the flow card as well as using the Eve app. I now have a built in to my flow that when for x time/every x minutes if there stil is a x amount surplus/less then x power is surplus, then pause (by setting power to 1.0 A). To prevent import.
I did some testing and changing the percentage groen to 100% stopped charging immediately. Don’t know if it will start tomorrow again. Will monitor that
I used both. First I only used the second one to have the charger using solar-surplus. That caused the issue which i described earlier. After using the first card as well, charging stopped immediately
It looks like it’s working
. This morning charging started automatically as soon as there was a surplus.
Nice! I’m gonna try this!
I Tried, but I’m running into another funny thing, to run normally I need to use “Doelvermogen” to bring charging back to full power, if it was on reduced power earlier. Howerever to start solar charging somehow I suspect I need to use this card. Because solar power doesn’t trigger charging I suspect this came around to corner when i started tot try “100% green”. Anybody experiencing the same?
I succesfully installed my Alfen Eve Single Pro in Homey and managed to start a charging session using Homey. However, after an hour or so, the charging stopped where the app of my car (Audi) indicated that a technical error occurred (never had this before). Disabled the Alfen app in Homey and restarted the charging session using the Eve app - this succesfully started a new charging session. Any idea what could be causing the issue when using the connectivity with charger using Homey (I know about the API limitation of not being able to use the Homey app and the Eve app at the same time, this was not the case when generating the error)?
UPDATE: it appeared that on the background, the EVE app was still running (…). Have closed the app and tried again. Seems to work without errors.
Hi Robert, thanks a lot for this app — it’s working great for monitoring my chargers.
I’ve been trying to read which RFID card is used for the active charging session, and after digging into the source I wanted to check something with you.
What I found:
I noticed the chargeid capability maps to property 0x206300, which in the code is commented as “Plug & Charge ID”. So if I understand correctly, that field is the (settable) Plug & Charge identifier, not the RFID card / idTag of the person currently charging. That matches what I see: it’s always empty in my setup, both on Plug & Charge and on RFID-mode chargers.
Looking at the polled property list (temperatureInternal, stationLimit, authMode, chargeID, operativeMode, plus metering/status), I don’t see a property that returns the idTag of the active session.
My questions:
- Am I right that
chargeid(0x206300) is the Plug & Charge config ID, and not the RFID card of the running session? - Do you happen to know if the local WebAPI (
/api/prop) exposes the active session’s RFID/idTag at all — under some property id — or does that information only travel over OCPP to the backoffice and never appear locally? - If such a property does exist, would it be possible to expose it as a read-only capability? Even just the raw card token would be enough for my use case.
Why (context):
I have a small network of Alfen S-line chargers and I’d like to notify the right user when their car is done charging, so a charger doesn’t stay occupied unnecessarily. Detecting “session finished / charger free” already works nicely via evcharger_charging_state. The only missing piece is who is charging, so the notification can go to the right person instead of being generic. If the idTag simply isn’t available over the local API, that’s a completely valid answer too — then I’ll stop looking for it locally.
Thanks again for the great work, and no worries if this isn’t feasible!
I’ll leave this here for those of you that are interested. ![]()
Damn! Did not know it came available! Thnx!
That’s interesting! Up till now I’ve used MQTT to connect EVCC with Homey. Works well for over 3 years now. But a Homey app will simplify things.
It definitely makes things a lot easier! Since nobody had created one yet, I offered to build it myself, with EVCC’s permission of course haha, and now everyone can use it.
It will keep improving over time, and feedback is always greatly appreciated, as it helps speed things along!


