Wallbox Gateway — local BLE → MQTT / HA for Pulsar Chargers (no cloud, full HA control)

@botts I removed the other ESP for a good hour or 2, but it continued to fail at regular intervals.

Then I waited until a 15-minute increment and started refreshing the gateway page. This popped up at the same time that the integration failed -

So are you thinking it is a wifi issue? And if so, you mean wifi on the gateway ESP rather than in general, correct?

Two things it rules out immediately: your BLE is healthy (connected, -66 dBm, a good signal), so this isn’t a BLE drop, and the page itself loaded (the live BLE header rendered), so WiFi isn’t down either. What actually failed is one specific thing: an HTTP data fetch from the gateway (“Failed to fetch”), while BLE and the live status header kept working.

So to answer your question: it’s not WiFi, and it’s not BLE. It’s the gateway’s own HTTP endpoint briefly not responding, every 15 minutes. And because the Home Assistant integration polls the gateway over that same HTTP, that’s why the integration goes unavailable at the exact same moment.

On the AtomS3U specifically, the prime suspect is memory. It has no PSRAM, and under sustained load a no-PSRAM S3 can periodically fail to allocate a buffer for an HTTP response while BLE carries on. Two checks:

  1. Open /info and note the “Heap min watermark” (the lowest free memory it’s seen). If that’s down in the tens of KB, that’s very likely it.

  2. On the same page, watch Uptime and boot count across a couple of the 15-minute cycles. If the heap runs out completely the gateway can reboot, so if uptime resets we’ll see it (and the boot-reason history will say panic vs restart).

The clincher is still a serial log at 115200 across one outage, it’ll show directly whether it’s a memory/allocation failure, an HTTP handler stall, or a reboot.

If it does turn out to be heap on the no-PSRAM AtomS3U, that’s the strongest argument yet for a board with PSRAM (the S3-DevKitC-1 or S3-WROOM-1U-N16R8 in the README) or the wired board, which have far more headroom. But let’s confirm with the heap watermark first.

Is this what you are looking for?

Also, is there a human behind all of that AI? :slight_smile:

That’s the answer, and the gateway flagged it for us: Heap min watermark 7.9 KB, in red. That’s the lowest free memory it has ever seen, and 7.9 KB is right at the edge of out-of-memory. When free heap dips that low, a larger allocation like the buffer for an HTTP response simply fails, and the browser reports it as “Failed to fetch”. That’s your outage, and why the HA integration (which fetches over the same HTTP) drops at the same instant.

The rest of the panel confirms what it isn’t: it’s not rebooting (your prior-boot history shows uptimes over a day, and BLE/MQTT/WiFi reconnects this boot are all 0), and it’s not a connection drop (BLE is solid at -66 dBm, and those prior BLE blips are hours apart and a few seconds each, nothing like the 15-minute pattern). So it’s purely memory.

The 15-minute clockwork is almost certainly a periodic heavier request: the HA integration polls a few larger endpoints (sessions / charge log / schedules) on a slower cadence, and building one of those responses momentarily spikes memory. With headroom that’s a non-event; on the AtomS3U, which has no PSRAM, it tips over the edge.

So the real conclusion is that the AtomS3U is just too tight for this. A 7.9 KB low-water mark leaves no margin. A board with PSRAM (the S3-DevKitC-1 or S3-WROOM-1U-N16R8 in the README) has megabytes of spare heap and this disappears, and if the POE/Ethernet board you were eyeing is a PSRAM variant (most S3-ETH boards are, worth checking the model) it solves the memory headroom and frees the radio in one go.

I can also look at trimming the peak memory of those heavier endpoints on the firmware side, which might buy enough margin to keep the AtomS3U usable, but on a 7.9 KB watermark that’s a band-aid, PSRAM is the reliable fix. If you want to pin the exact trigger first, a serial log at 115200 across one outage will show the allocation failure and which operation was in flight.

And lol, yes, there is a human here. I built the gateway, own the charger and hardware and make calls on what ships, etc.

Thaks for all the testing and getting us to a fix.

I really appreciate all your time and effort on this. I went ahead and ordered this board -
Waveshare ESP32-S3 ETH Development Board

It is POE, which I prefer over WiFi. Hopefully we can get it to work with the gateway! It looks like it will take a couple of weeks to get here, so look forward to me bugging you again at that time!

It has 8 MB PSRAM, so the heap issue behind your outages is gone, and it’s wired, which frees the radio for BLE.

One heads-up: the wired-Ethernet firmware is still experimental and hasn’t been tested on real hardware yet, so you’d be the first to run it. When it arrives, flash the normal WiFi build first to confirm the outages are gone (PSRAM alone should do it), then we can try the wired build, use the browser-flash test page. Ping me when it lands, and thanks again for the thorough debugging.

Which board are you using? Maybe I should just get that one and call it a day.

ESP32-S3-WROOM-1U-N16R8 is the board that I am using

Welp. I bought this and it was delivered this morning -

Lonely Binary ESP32-S3 N16R8 16MB Gold Edition Dev Board + IPEX Antenna

I got it all set up and turned it on, and guess what - It also drops every 15 minutes. And this is while it was in a completely different place in the garage, far from the other ESP board. So something else is going on here. I’ll probably keep it anyway, since I have already 3D printed a case for it. And it is rated for higher temperatures than the previous S3.

But I feel like I have eliminated all of the variables. Are we sure there is nothing in the gateway code that would cause this to reset every 15 minutes?

It’s not your network or the board. It’s a known bug in the Home Assistant integration, and another user just confirmed the fix.

The integration polls the gateway’s charge-log, which is assembled over BLE and occasionally slow. The old code treated one slow charge-log read as the whole device being unreachable, so every entity flapped to unavailable for that cycle, your 15-minute gaps. That same slow read briefly ties up the gateway’s web server too, which is the “Failed to fetch.” BLE stays connected throughout, which is why the signal always looked fine.

Fixed in integration v0.36.0 (just released): charge-log and other non-critical reads now keep their last value instead of taking the device down. Update via HACS and the flapping stops, on any board. Sorry for the heap and network detours, your PSRAM-board test was what ruled out hardware and pointed me back at the software.

Thanks for the update, and thanks for staying on top of this! I just updated and will keep an eye on it.

@botts I updated last night, but unfortunately it looks like it is still happening. It does seem to be not quite as often, but still in 15-minute increments.

Thanks for the update. That it’s less frequent means the charge-log fix (#8) is working, but you’re right that something on the 15-minute grid is still getting through — a separate cause that fix didn’t touch. It only lets non-critical reads degrade; the core status read can still take the device down if the gateway’s web server stalls for a moment.

There’s no newer build that fixes this — v0.36.1 only adds a status label, and no firmware release targets it. I genuinely don’t know the cause yet, so rather than guess again, two quick readings during a dropout will pin it:

  1. Gateway /info page → the “Longest loop iteration” value. If it’s up in the seconds (not ~100 ms), the gateway’s main loop is stalling and starving the status read (a gateway-side bug I can fix). If it stays low, the loop is fine and it’s the network path.

  2. In HA, add custom_components.wallbox_gateway: debug to your logger, and when it drops grab the coordinator log line — it names the endpoint that failed (status / charger / charge_log) and the time. If two drops are 15 min apart, note both timestamps.

Also, which gateway firmware are you on now (/api/status → gw_fw)?

Between the loop-iteration number and which endpoint fails, I can point straight at the cause instead of guessing.

Hi @botts -
Thanks again for your help. I am on firmware v3.2.15.

Here is a screen shot from my info page -

It will not allow me to attach a log here, so I am pasting a smaller portion of it here. I am seeing errors in the log in the 15-minute increments, so hopefully that will be helpful to you.

2026-09-08 21:45:30.331 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.743 seconds (success: True)
2026-09-08 21:45:41.883 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.295 seconds (success: True)
2026-09-08 21:45:52.561 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.972 seconds (success: True)
2026-09-08 21:46:06.596 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-08 21:46:06.596 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Full error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 558, in start
    message, payload = await protocol.read()  # type: ignore[union-attr]
                       ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 705, in read
    await self._waiter
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/wallbox_gateway/api.py", line 62, in get
    async with self._session.get(
               ~~~~~~~~~~~~~~~~~^
        url,
        ^^^^
        auth=self._auth(),
        ^^^^^^^^^^^^^^^^^^
        timeout=aiohttp.ClientTimeout(total=timeout),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ) as resp:
    ^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 1693, in __aenter__
    self._resp: _RetType_co = await self._coro
                              ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 858, in _request
    resp = await handler(req)
           ^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_middlewares.py", line 36, in single_middleware_handler
    return await middleware(req, handler)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 70, in _ssrf_redirect_middleware
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 836, in _connect_and_send_request
    await resp.start(conn)
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 553, in start
    with self._timer:
         ^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/helpers.py", line 759, in __exit__
    raise asyncio.TimeoutError from exc_val
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/wallbox_gateway/api.py", line 81, in get
    raise GatewayUnreachable(
        f"timeout on {path} after {timeout}s ({type(e).__name__})"
    ) from e
custom_components.wallbox_gateway.api.GatewayUnreachable: timeout on /api/status after 4s (TimeoutError)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 441, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/wallbox_gateway/coordinator.py", line 157, in _async_update_data
    raise UpdateFailed(f"gateway unreachable: {err}") from err
homeassistant.helpers.update_coordinator.UpdateFailed: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-08 21:46:06.602 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 4.014 seconds (success: False)
2026-09-08 21:46:15.321 ERROR (MainThread) [homeassistant.components.broadlink.updater] Error fetching Ben's Room BroadLink (RM4 mini at 192.168.22.111) data: [Errno -4000] Network timeout: No response received within 10s
2026-09-08 21:46:20.591 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 4.003 seconds (success: False)
2026-09-08 21:46:33.305 INFO (MainThread) [custom_components.wallbox_gateway.coordinator] Fetching wallbox_gateway (Wallbox Charger) data recovered
2026-09-08 21:46:33.305 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.717 seconds (success: True)

Found it, and it is neither your network nor the board. Your /info screenshot was the key: loop iteration 28 ms (healthy), zero WiFi, BLE and MQTT reconnects (nothing actually dropped), but Heap min watermark in red at 5.3 KB. The gateway was running out of internal memory.

Home Assistant polls several endpoints at once every 10 seconds. The old firmware built and copied each of those responses in memory at the same time, and the charge-log one was large on a gateway that has been up a long time (the log had grown to its full size). That burst briefly exhausted the small internal-memory pool, so the status request could not be served and timed out after 4 seconds, and every entity went unavailable for that cycle. That is why it looked like a network blip when nothing had disconnected. Your box is affected and most are not precisely because it is so stable (long uptime, full charge-log), which is what makes the burst big.

The 8 MB PSRAM does not help this. The memory that runs out is the small internal pool WiFi and HTTP use, not PSRAM. So it was a firmware bug, not your hardware.

I reproduced it on the bench with a full charge-log: the old firmware collapsed to about 6 KB free (essentially your 5.3 KB), and the new firmware holds about 26 KB and the status read never fails. Fixed in firmware v3.2.17 (responses now stream instead of being copied, the heavy endpoints briefly back off if memory is tight so the status read is never starved, and the charge-log is handled without duplicating it). Update the gateway (Settings, or the web installer) to v3.2.17. After a day, check /info; the Heap min watermark should stay well clear of the red and the flapping should be gone. If you can report the new heap-min figure that would confirm it. Thanks for the screenshot and the patience, that is what cracked it.

Thanks @botts. I updated, but unfortunately I am still getting errors in 15-minute increments. Here are logs from this morning after the update -

2026-09-10 06:46:15.294 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 07:01:34.295 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 07:15:48.295 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 08:01:16.295 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 08:16:49.296 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 08:46:41.294 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 09:30:54.295 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/status after 4s (TimeoutError)
2026-09-10 09:42:13.105 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.813 seconds (success: True)
2026-09-10 09:42:26.065 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.773 seconds (success: True)
2026-09-10 09:42:36.939 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.645 seconds (success: True)
2026-09-10 09:42:47.877 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.584 seconds (success: True)
2026-09-10 09:42:59.039 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.746 seconds (success: True)
2026-09-10 09:43:09.997 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.702 seconds (success: True)
2026-09-10 09:43:21.100 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.808 seconds (success: True)
2026-09-10 09:43:33.879 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.586 seconds (success: True)
2026-09-10 09:43:45.041 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.748 seconds (success: True)
2026-09-10 09:43:56.076 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.782 seconds (success: True)
2026-09-10 09:44:07.033 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.741 seconds (success: True)
2026-09-10 09:44:18.234 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.941 seconds (success: True)
2026-09-10 09:44:28.991 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.699 seconds (success: True)
2026-09-10 09:44:42.670 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 3.375 seconds (success: True)
2026-09-10 09:44:53.010 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.718 seconds (success: True)
2026-09-10 09:45:03.985 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.693 seconds (success: True)
2026-09-10 09:45:15.129 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.836 seconds (success: True)
2026-09-10 09:45:26.019 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.726 seconds (success: True)
2026-09-10 09:45:37.043 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.751 seconds (success: True)
2026-09-10 09:45:49.434 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.142 seconds (success: True)
2026-09-10 09:46:00.024 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.729 seconds (success: True)
2026-09-10 09:46:11.366 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.074 seconds (success: True)
2026-09-10 09:46:25.297 ERROR (MainThread) [custom_components.wallbox_gateway.coordinator] Error fetching wallbox_gateway (Wallbox Charger) data: gateway unreachable: timeout on /api/charger after 4s (TimeoutError)
2026-09-10 09:46:25.297 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Full error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 558, in start
    message, payload = await protocol.read()  # type: ignore[union-attr]
                       ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/streams.py", line 705, in read
    await self._waiter
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/wallbox_gateway/api.py", line 62, in get
    async with self._session.get(
               ~~~~~~~~~~~~~~~~~^
        url,
        ^^^^
        auth=self._auth(),
        ^^^^^^^^^^^^^^^^^^
        timeout=aiohttp.ClientTimeout(total=timeout),
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ) as resp:
    ^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 1693, in __aenter__
    self._resp: _RetType_co = await self._coro
                              ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 858, in _request
    resp = await handler(req)
           ^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_middlewares.py", line 36, in single_middleware_handler
    return await middleware(req, handler)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 70, in _ssrf_redirect_middleware
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client.py", line 836, in _connect_and_send_request
    await resp.start(conn)
  File "/usr/local/lib/python3.14/site-packages/aiohttp/client_reqrep.py", line 553, in start
    with self._timer:
         ^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/aiohttp/helpers.py", line 759, in __exit__
    raise asyncio.TimeoutError from exc_val
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/wallbox_gateway/api.py", line 81, in get
    raise GatewayUnreachable(
        f"timeout on {path} after {timeout}s ({type(e).__name__})"
    ) from e
custom_components.wallbox_gateway.api.GatewayUnreachable: timeout on /api/charger after 4s (TimeoutError)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 441, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/wallbox_gateway/coordinator.py", line 157, in _async_update_data
    raise UpdateFailed(f"gateway unreachable: {err}") from err
homeassistant.helpers.update_coordinator.UpdateFailed: gateway unreachable: timeout on /api/charger after 4s (TimeoutError)
2026-09-10 09:46:25.303 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 4.010 seconds (success: False)
2026-09-10 09:46:36.070 INFO (MainThread) [custom_components.wallbox_gateway.coordinator] Fetching wallbox_gateway (Wallbox Charger) data recovered
2026-09-10 09:46:36.070 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.775 seconds (success: True)
2026-09-10 09:46:47.103 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.836 seconds (success: True)
2026-09-10 09:46:59.517 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.225 seconds (success: True)
2026-09-10 09:47:07.259 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.902 seconds (success: True)
2026-09-10 09:47:18.113 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.821 seconds (success: True)
2026-09-10 09:47:28.967 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.674 seconds (success: True)
2026-09-10 09:47:37.055 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.696 seconds (success: True)
2026-09-10 09:47:48.115 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.822 seconds (success: True)
2026-09-10 09:48:00.404 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.110 seconds (success: True)
2026-09-10 09:48:11.258 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.966 seconds (success: True)
2026-09-10 09:48:22.337 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.045 seconds (success: True)
2026-09-10 09:48:33.111 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.819 seconds (success: True)
2026-09-10 09:48:44.026 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.734 seconds (success: True)
2026-09-10 09:48:55.190 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.897 seconds (success: True)
2026-09-10 09:49:07.374 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.082 seconds (success: True)
2026-09-10 09:49:18.024 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.732 seconds (success: True)
2026-09-10 09:49:28.920 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.628 seconds (success: True)
2026-09-10 09:49:40.078 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.786 seconds (success: True)
2026-09-10 09:49:51.612 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.319 seconds (success: True)
2026-09-10 09:50:02.590 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.296 seconds (success: True)
2026-09-10 09:50:15.401 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 3.108 seconds (success: True)
2026-09-10 09:50:25.917 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.623 seconds (success: True)
2026-09-10 09:50:36.995 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.703 seconds (success: True)
2026-09-10 09:50:48.036 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.744 seconds (success: True)
2026-09-10 09:50:58.990 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.698 seconds (success: True)
2026-09-10 09:51:10.050 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.757 seconds (success: True)
2026-09-10 09:51:22.892 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 2.599 seconds (success: True)
2026-09-10 09:51:34.114 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.822 seconds (success: True)
2026-09-10 09:51:45.175 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.881 seconds (success: True)
2026-09-10 09:51:56.028 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.736 seconds (success: True)
2026-09-10 09:52:07.845 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 1.552 seconds (success: True)
2026-09-10 09:52:19.170 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 0.876 seconds (success: True)
2026-09-10 09:52:32.380 DEBUG (MainThread) [custom_components.wallbox_gateway.coordinator] Finished fetching wallbox_gateway (Wallbox Charger) data in 3.087 seconds (success: True)


Thanks for testing, and sorry it is still going. The memory fix is in the gateway FIRMWARE, which updates separately from the Home Assistant integration, so first I need to be sure we are on the same build:

  1. Open the gateway web page, go to /info, and read the version at the very bottom (“Wallbox BLE Gateway vX.Y.Z”). I need it to say v3.2.17. If it still says v3.2.15, the firmware did not update (the earlier step updated the integration, not the gateway), and that is the whole answer. Update it via Settings or the web installer.
  2. If it already says v3.2.17, grab a fresh /info during or right after a drop and tell me three numbers: Heap min watermark, Longest loop iteration, and the reconnect counters (a screenshot is ideal). That tells me whether memory is still collapsing or whether it is now something else.
  3. One clean test to separate the gateway from Home Assistant. From a computer that is NOT your HA box, run this across a couple 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. If it stays fast while only HA logs the error, the stall is on the HA side and we chase it there.

Also: does anything else in your setup run on a 15-minute schedule (a backup, another integration, a large automation)? The dead-on 15-minute spacing is a strong hint.

Hi @botts
Correct, I had updated the gateway to v3.2.17

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:14:26 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  15758      0 --:--:-- --:--:-- --:--:-- 15880
 200 0.067518s
Fri Sep 11 15:14:31 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  13045      0 --:--:-- --:--:-- --:--:-- 13135
 200 0.081561s
Fri Sep 11 15:14:36 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  13206      0 --:--:-- --:--:-- --:--:-- 13135
 200 0.080569s
Fri Sep 11 15:14:41 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0   2801      0 --:--:-- --:--:-- --:--:--  2807
 200 0.379785s
Fri Sep 11 15:14:46 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  15776      0 --:--:-- --:--:-- --:--:-- 15880
 200 0.067441s
Fri Sep 11 15:14:52 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0   3951      0 --:--:-- --:--:-- --:--:--  3955
 200 0.269284s
Fri Sep 11 15:14:57 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  23481      0 --:--:-- --:--:-- --:--:-- 23644
 200 0.045313s
Fri Sep 11 15:15:02 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  13240      0 --:--:-- --:--:-- --:--:-- 13300
 200 0.080362s
Fri Sep 11 15:15:07 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0   3913      0 --:--:-- --:--:-- --:--:--  3926
 200 0.271863s
Fri Sep 11 15:15:12 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  12708      0 --:--:-- --:--:-- --:--:-- 12819
 200 0.083726s
Fri Sep 11 15:15:18 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  16026      0 --:--:-- --:--:-- --:--:-- 16121
 200 0.066391s
Fri Sep 11 15:15:23 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  16113      0 --:--:-- --:--:-- --:--:-- 16369
 200 0.066033s
Fri Sep 11 15:15:28 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  12750      0 --:--:-- --:--:-- --:--:-- 12819
 200 0.083447s
Fri Sep 11 15:15:33 EDT 2026
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1064  100  1064    0     0  15356      0 --:--:-- --:--:-- --:--:-- 15200
 200 0.069286s
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

Two more updates and three questions, because your setup has a clue in it.

First, v3.2.18 is out. It hard-caps how many of the gateway’s own web pages (dashboard / info / sessions) can be built at once, which is a memory-heavy operation. If you have wall panels or browser tabs showing the gateway dashboard, that is a likely part of the drop-outs, and this bounds it. Update to v3.2.18.

Now the clue: another user runs the exact same combination you do, the Add-on and the integration together, and has zero drop-outs over days of uptime. So the Add-on plus integration combo is not the cause by itself. Something else on your setup is heavier. Three quick things to pin it:

  1. What is your integration poll interval? Settings, the Wallbox integration, Configure. The default is 10 seconds. If it is lower, that is a prime suspect.
  2. How many things have the gateway open at once: its own dashboard on any wall tablets, extra browser tabs, or HA dashboards that embed its page? Each open page holds memory on the gateway.
  3. What is your charger model, and is it single-phase or three-phase / Power Boost with an external meter? A three-phase meter sends more data per read.

With those three answers I can compare your setup against the known-good one and point straight at the difference.

Hmm… When you say add-on, are you referring to the custom integration or an actual HA add-on (now called Apps). I am not running an add-on; only the gateway running on the ESP32 S3 and the custom integration.

10 seconds

I don’t have any wall tablets and rarely run the gateway directly. I have a dashboard in HA with some of the wallbox entities but I only look at that a few times a day.

Pulsar Plus, with the latest firmware. I don’t know about phase but I am assuming single?

I updated to the latest version of the gateway. Fingers crossed that helps!