That rules out the dashboards, thanks. Your setup now matches a gateway that runs perfectly, the only real difference is your charger is a Pulsar Plus and the known-good one is a MAX. Two things will tell me what is actually happening at the 15-minute mark, because neither the gateway nor the integration has any 15-minute timer:
From a computer that is NOT your Home Assistant box (a laptop, a phone terminal), run this and leave it going across two or three of the 15-minute marks.
while true; do date; curl -m 6 -u admin:YOURPASS http://GATEWAY-IP/api/status -o /dev/null -w " %{http_code} %{time_total}s\n"; sleep 5; done
If that direct call also stalls at the same moment HA logs the timeout, it is the gateway and I will chase it there. If it stays fast while only HA logs the error, the stall is on the Home Assistant side.
3. What other integrations and automations do you run in HA, and do any of them poll or trigger on a 15-minute schedule?
I think that is the same test we already performed earlier today. I’ll repaste my results again here. The error message did coincide with an outage…
Here is a snippet of the curl output. It has “Operation timed out after 6007 milliseconds with 0 bytes received” at the time of the outage
Fri Sep 11 15:15:38 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1064 100 1064 0 0 13379 0 --:--:-- --:--:-- --:--:-- 13468
200 0.079524s
Fri Sep 11 15:15:43 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1064 100 1064 0 0 377 0 0:00:02 0:00:02 --:--:-- 377
200 2.816424s
Fri Sep 11 15:15:51 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:06 --:--:-- 0
curl: (28) Operation timed out after 6007 milliseconds with 0 bytes received
000 6.007073s
Fri Sep 11 15:16:02 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1063 100 1063 0 0 449 0 0:00:02 0:00:02 --:--:-- 449
200 2.365703s
Fri Sep 11 15:16:09 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1064 100 1064 0 0 14698 0 --:--:-- --:--:-- --:--:-- 14777
200 0.072390s
Fri Sep 11 15:16:15 EDT 2026
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1064 100 1064 0 0 8021 0 --:--:-- --:--:-- --:--:-- 8060
200 0.132642s
I have a short diagnostic build that will show me exactly what happens inside the gateway at the 15-minute mark. It is here, marked as a pre-release:
Install it the same way you normally update the gateway (web installer, or upload the firmware.bin under Settings). It is the same as v3.2.18 with one extra read-only page that records memory and Bluetooth activity every second.
Then, from the same machine you ran the curl test on, run this so it captures automatically across the stalls (no need to watch the clock):
while true; do date -u +%FT%TZ >> heaptrace.log; curl -s -m 8 -u admin:YOURPASS http://GATEWAY-IP/api/diag/heaptrace >> heaptrace.log; echo >> heaptrace.log; sleep 30; done
Leave it running past two or three of the 15-minute stalls, then send me heaptrace.log. It will show whether the gateway’s memory craters at that instant and what Bluetooth is doing when it does, which tells me the actual cause.
When you are done, update the gateway back to the latest normal release. This build is diagnostic only.
I found it, and I am confident this is the real cause. Your Pulsar Plus talks over a different Bluetooth module (BGX13P) than the chargers that were fine, and its responses arrive as a live stream. A bug in how the gateway reassembled that stream meant a single dropped or stray byte could make it buffer forever, slowly using up memory until the gateway briefly could not accept a new connection, which is your 6-second stall every 15 minutes. Fixed in v3.2.19. It affects all chargers but the Plus was by far the most exposed.
To confirm it on your gateway, here is a build with the fix plus the same memory trace as before:
Install it, run the same capture loop across two or three of the 15-minute marks, and send me the log. If it worked, memory stays healthy through those marks and the stalls are gone. Then switch to the normal v3.2.19 release.
@botts! I think you fixed it! I was going to install the diagnostic release this morning, but then I saw you had a follow-up (v3.2.19). I installed.19 nearly 3 hours ago and so far there has not been a single disconnect. I will continue to monitor it and let you know how it goes, but so far we are looking great! Thank you so much for all of your hard work!
But dumb question - Why has memory been an issue if I have the board with PSRAM?
I guess I spoke too soon. After I installed the update this morning, it did have a nice long block without failures. But now it is back to failing almost every 15 minutes.
I almost feel like - If you can’t beat em, join em. Instead of trying to fix this, is there some way to add an extended timeout or do something that will essentially just ignore the error?
Great news that .19 gave you a long clean stretch, that tells me the fix addressed a real part of it. The failures coming back means there is a second cause, and I have not nailed that one yet, so I have done two things.
First, the practical one you suggested: I have released integration v0.36.2 that rides through a brief stall instead of flapping everything to unavailable. If the gateway goes quiet for a few seconds, the integration now holds the last values and only reports a problem if it stays down for about half a minute. Update the integration to v0.36.2 and the entities should stop dropping out, even while I chase the underlying cause.
On your fair question, why is memory an issue with a PSRAM board: the 8 MB of PSRAM is a separate pool from the small internal memory that the WiFi and Bluetooth stack use for their live buffers. The network stack cannot put those buffers in PSRAM, so when that small internal pool gets tight, new connections stall regardless of how much PSRAM the board has. PSRAM helps big application data, not the radio plumbing.
To find and fix the real cause, I still would love one capture from the diagnostic build (v3.2.19-diag1). My leading theory now is that your Plus briefly loses its Bluetooth link when the charger does its own periodic sync, and the gateway favours Bluetooth to recover it, which starves WiFi for a few seconds. The diagnostic will confirm or rule that out. If you would rather just run v0.36.2 and be done, that is completely fine too, it should make the problem invisible.
This is great! Since I updated to this version over 12 hours ago I have not had a single issue with the integration. I did have something weird happen, but I will chalk it up to coincidence for now - My Wallbox unit (not the gateway but the charger itself) went completely offline. I had to power cycle it to bring it back up. You don’t think anything in the gateway could have caused this, do you? I’ll keep an eye on it.
If you don’t mind, I am going to hold off on testing the diagnostic version. I’ve spent a lot of time troubleshooting this integration and am pretty happy now that it seems to be working correctly.
@botts — I think the Pulsar Plus Stop issue from posts 104–107 is still alive on the MQTT command path.
Setup: Pulsar Plus (prj08-pulsar-plus, FW 6.7.43), Zentri TruConnect radio (dual-char), gateway v3.2.22, model set to Custom (Zentri UUIDs), HA via MQTT discovery (no HACS integration).
Web UI Stop works — and logs the decision as expected:
MQTT Start is skipped right after a Stop, while the charger is actually stopped:
[MQTT] Received: wallbox/wallbox/cmd/charging = start
[CMD] charging start skipped — already in target state
Workaround that works: publishing {"met":"w_cha","par":0} / {"met":"w_cha","par":1} to wallbox/wallbox/bapi stops/resumes reliably. Charge Control Owner made no difference.
Looks like the MQTT cmd/charging handler doesn’t go through the dispatch fixed in beta.5. Happy to test a build.
You were exactly right. The MQTT stop handler was picking the stop parameter from the statically configured model instead of the charger’s own runtime project report, so your custom model configuration made it send par=2 (the MAX hard-stop) to your Plus, which the Plus acknowledges but ignores, so it kept charging. The Web UI and the direct {"met":"w_cha","par":0} both worked because they use the runtime detection. And you were right that the MQTT path doesn’t go through the same dispatch, which is why the [CMD] line was missing.
Fixed in v3.2.23: the MQTT stop (and the resume-schedule defensive stop) now use the runtime chg_project self-report, same as the web/api path, so the stop parameter matches your actual charger regardless of the configured model. Update to v3.2.23 and MQTT stop should work. Thanks for the clear report and the offer to test, let me know how it goes.
