Updates a few minuten ago automaticaly. Let see! I Know see the ID.
How do you limit charging, because the “Stel Doelvermogen in” doesn’t do the trick at my end to limit power.
It creates a profile just like the Eve app does. Do you have one or two sockets?
1 Socket. I used to use the amperage controle, wich worked perfectally.
When my flow sets “Doelvermogen” to e.g. 5000 Watts. I see that it sets, but, within serveral seconds (even before actually wind down), switch back to max (11kW).
Hm, that is strange, it does work on my charger (better than the amp, because that could actually overload the charger because it set the safety limit of the charger). Wondering why it doesn’t stick for your charger. Can you maybe try to switch it, wait a couple of seconds and then sent a crash report of the app to me so that I can check and see if I can find anything in there?
Sure!
Started my washing machine, wich triggers a flow to charge the car to max 9a (via Doelvermogen thus 6210w). It triggers, and within seconds doelvermogen switches back).
Report: 4f2fcffe-3668-4c38-8256-016523c73d95
You can see the drop in de insights. Active loadbalancing limit shows the same graphic.
Thanks, checked the log, but there is no actively write in there.
What happens when you change the target power through the device itself? So with the slider, you can change the target power, does it work through that?
Slider seems to do the trick. But that doens’t work in a flow
That is strange, the card is a native card from Homey, just as the slider is a native capability. I added one thing now in the new test version, I’m rounding the input value to the closest step of 230w (as with the slider you can select anything in the card), but maybe an invalid value isn’t parsed properly… Hope this works, otherwise noooo clue, and have to search further 
Hi, the results regarding laadpas-id are the same. Sometimes it’s available at the beginning, sometimes after 30 seconds but most of the time it’s not available.
Alfen 50Five: out-of-memory reboots every ~4–4.7 h, coinciding with the app’s 30 s polling
Hi MrDutchFighter,
Setup: Alfen 50Five (NG9xx), Homey Pro, your app (com.alfen) v2.1.1. Firmware is now 7.3.0-4377. It was 7.4.5-4415 on 30 Sep, and I don’t know when or why it changed. The charger also reads the P1 from a HomeWizard itself.
What I see in the charger’s service log: one admin login and logout every ~30 s (2,994 in 22 h). The charger reboots via watchdog (“Out of memory… SW Watchdog triggered”) every 4h03–4h40, about 5 a day. The boot counter went from 6459 (30 Sep) to 6535 (15 Oct), so the same cadence on both firmware versions.
Test: I disabled the app on 15 Oct at 23:16. The charger then ran more than 11 hours without a reboot, with stable heap (39.7 kB free, min 14.9 kB). The P1-lost errors also stopped that night, but I switched another thing off at the same time, so that is not proof. I re-enabled the app on 16 Oct at ~07:50 to see whether the reboots return, and will report back.
Questions:
Is the polling interval configurable? Could it be 2–5 min, or a lighter mode?
Does each poll do a full login and logout? Could the app reuse one session or use lighter calls?
Can the app back off when the charger answers slowly or the login fails (the web server allows one connection and has ~160 kB heap)?
Do you know of problems on 7.3.0 or 7.4.x, and which firmware do you advise?
I can share a masked log excerpt (login cadence, boot dumps, heap trace).
Test: with the app disabled (15 Oct 23:16 to 16 Oct 07:49) the charger ran 13 h 11 min without a reboot (previous intervals 4h03–4h40) and heap was stable. After I re-enabled the app at 07:49, it rebooted again at 09:22 (boot #6540, watchdog, “Out of memory”, free 4.4 kB), 1 h 33 min after polling resumed. So the reboots follow the polling in two trials. Free heap is down to a minimum of 4.2 kB again.
I encounter very frequent issues with charging sessions. Liasing with Alfen Support one of their comments made is that they see very frequent connections being made to the charger, suggesting that this could cause issues with the charge session. Is this an issue that other users experience as well? If so, would it be possible to introduce the possibility to allow the user to reduce the frequency (currently set at 30 seconds if not mistaken)?
had this as well, and so often that it would reboot 4 -5 times per day. for now switched over to HA, as this led to instability unfortunately…
@MrDutchfighter , I think this is the basis of issues on my side as well. the Alfen reboots often (also seen by PowerD, whom manages my alfen), and according to the logs this could very well have to do with the frequent log ins, currently set at 30s.
when I disable the alfen app in homey, the reboots go quiet…
in HA I think this is set to 900s? the challenge there is that it doesnt release the unit at all, so using the EVE app is not possible, unless I disable the alfen app in HA.
so there is some kind of balance we need to try to find here…
thanks for your help!
I think the issue is (re)introduced with the scanning of the active charge card. This uses a quite intensive query to scan the logs of the device, which is probably not cleared by Alfen if that is requested frequently and thus resulting in a time-out. It is probably a matter of either removing that functionality or accepting a reboot every once in a while, because using for instance 900s won’t solve the fact that the charger will get an out of memory exception, it will just postpone it… and as Alfen has 0 effort in collaborating and exposing proper API functions I think I’ll have to make a decision here to revert the changes and remove the Active Card ID functionality (or put it behind a feature toggle so people can choose if they want it and accept the reboots :))
the other option is to as HA log in and not release it. the issue there is that you have to disable the alfen app temporarily when you want to drive it with the eve app. maybe add a toggle?
built the below in a fork, can share if you want:
for the disconnects:
| Position | Behaviour |
|---|---|
| Off - no login | Homey logs out, doesn’t poll, and refuses writes, so Eve can log in. Lasts at most the setting “Max time Off” (5-60 min, default 60), then switches to the next position. |
| On - login per poll | Logs in and out at every poll, as before. |
| On - stay logged in | One login stays open and is never dropped unless you change the picker. (like in HA) |
- The poll interval is 30-900 s and applies to both On positions.
- the chosen position survives an app restart.
- After the 60 minutes, it goes to “On - login per poll”, not back to “stay logged in”
various other small additions
- The wallbox returns at most 32 properties per request; chunked reads fix the missing P1 L2, L3 and P1 power. (currently it only reads the first phase)
- Start/Stop and target-power guard. - there would remain a 0A lock, nothing could then drive the alfen anymore. (I have HA and Homey working together
- No repeated writes of the same value. - to reduce reads and associated reboots
- New flow cards: wallbox rebooted, charge type is, charging blocked by profile, waiting for disconnect, P1 feed lost, login released, release, reconnect. (some extra logging)
- New capabilities: boot count, boot reason, uptime, and a charge-mode status line. (used in my own flows)
- Optional read of the active charge tag
will test the forked version for the next 24 hours and can then share in github. i have never coded before, did this with claude, so don’t shoot me if it is ai slop 
This is very interesting, I’m looking forward to what you find. Based on what you’ve posted I dove into the logs of my charger (Alfen Single Line Pro) and found something similar. The network stack seems to crash after 911 logins from the homey app (what’s in a number…). This seems to be consistent throughout at least the last 3 crashes.
A difference is that, in my case, memory doesn’t seem to be part of the issue. The memory heap keeps looking healthy (38-42% free, minimum ~30%). So I can only assume that maybe some other resource is starving, but the logs contain no evidence of such a thing.
If the app could keep the connection open and re-use it, I’d gladly test that to see whether it helps for my situation as well.
This might well be an issue with the charger software. I would say that you’d want that to be resistent enough so that outside clients cannot break it. But in the meantime, as long as it does break, a workaround from the app side would be great!
You can try my fork. Worked stable last night and no reboots
I’ll see if I can carve out some time tonight to get that set-up 
