Awesome. Got the Grid Power readings in the MQTT environment. They did not appear in the HACS one.
Btw:
my setup is Pulsar Max + EM340-MID + P1 Powerboost
Quick correction from me — you're on a Pulsar Max (I'd mis-said Plus earlier, my bad). On the HACS one not showing Grid Power: those entities existed but were disabled-by-default, so they only appeared via MQTT. Fixed in integration v0.14.4 — update it in HACS and the Grid power L1/L2/L3 will show like the MQTT ones do. Thanks for flagging the MQTT-vs-HACS difference.
Hi.... Amazing addition to Wallbox control 
Thank you!
I have a Pulsar Plus - is V3.0.4 appropriate?
I also have a second Pulsar Plus - it is 100m from the first, so will require a second ESP32... anything to watch for in the configuration of the second esp32? Can I have two gateway tabs setup in HA?
Any thoughts on this? I installed from the HA 'Apps' tab (was add-ons I think in previous releases...)
Thanks again!
I have WallBox Pulsar, basic version with only BT connection, no WIFI. Wallbox uses the ZentriOS chip .
I wonder if this Wallbox Gateway can works. I have installed, but it looks that there is a problem with PIN pairing. No matter if enter PIN or not in panel config of gateway
The configuration under tab advanced is below:
Custom
Service UUID: 175f8f23-a570-49bd-9627-815a6a27de2a
Char UUID: 1cce1ea8-bd34-4813-a00a-c76e028fadcb
TX/Notify Char UUID: cacc07ff-ffff-4c48-8fae-a9ef71b75e26
Any other configuration also does not working.
Logs are below. Is there any chance that this old pulsar could work with this Gateway?
regards,
blazki
[OTA] Running from: app0 (0x10000)
[Health] Boot reset reason: software (ESP.restart)
[Health] Boot attempt #1 for this firmware
[Config] Loaded from NVS:
WiFi SSID: 'mikimouse_2.4G' (len=14)
WiFi pass: len=13 (masked)
MQTT host: '192.168.1.29' (len=12) port=1883
MQTT user: '*************' (len=10)
MQTT pass: len=20 (masked)
MQTT cid: 'wallbox-gw'
BLE addr: '4C:55:CC:1F:B5:DA' (len=17) pin=set
BLE svc: '175f8f23-a570-49bd-9627-815a6a27de2a' (len=36)
BLE chr: '1cce1ea8-bd34-4813-a00a-c76e028fadcb' (len=36)
BLE txchr: 'cacc07ff-ffff-4c48-8fae-a9ef71b75e26' (len=36)
chg_model: 'custom'
auth: en=0 user='admin' pass_len=0
polls: status=10000ms realtime=30000ms
HA: prefix='homeassistant' devid='wallbox-pulsar'
[BLE] TX power: +9 dBm, IO cap: KeyboardOnly
[Radio] Coexistence: BALANCE, WiFi PS: OFF
[WiFi] Connecting to 'mikimouse_2.4G' (ssid_len=14, pass_len=13).......
[WiFi] Connected: 192.168.1.44
[OTA] Firmware validated (WiFi OK)
[mDNS] http://wallbox-gw.local (IP: 192.168.1.44)
[Web] http://192.168.1.44/ (async on :80, sync retired)
[WS] AsyncWebSocket attached at /ws on :80
[Web-async] Listening on :80 (production, post port-swap)
[OTA] Password: wb-f19edc (use web auth pass, or shown here for espota)
[OTA] Ready
[BLE] Target: 4C:55:CC:1F:B5:DA
[BLE] State-machine task started on core 1
[Main] Setup complete
[BLE] Scanning for 4c:55:cc:1f:b5:da...
[MQTT] Connecting...
[MQTT] Connected
[MQTT] Subscribed to wallbox/cmd/#
[MQTT] HA discovery armed — publishing one entity per main-loop tick
[MQTT] HA discovery published (64 entities)
[WS] client 1 connected from 192.168.1.41
[BLE] Found! RSSI: -76 dBm Name: WB062971 Type: 0
[BLE] Connecting (RSSI: -76)...
[BLE] Using scan address (type 0)...
[BLE] Connected, stabilizing...
[BLE] GATT topology: 5 service(s)
[BLE] svc 0x1801
[BLE] chr 0x2a05 [I]
[BLE] svc 0x1800
[BLE] chr 0x2a00 [R]
[BLE] chr 0x2a01 [R]
[BLE] svc 0x180a
[BLE] chr 0x2a29 [R]
[BLE] chr 0x2a26 [R]
[BLE] chr 0x2a24 [R]
[BLE] chr 0x2a28 [R]
[BLE] svc 175f8f23-a570-49bd-9627-815a6a27de2a
[BLE] chr 1cce1ea8-bd34-4813-a00a-c76e028fadcb [Ww]
[BLE] chr cacc07ff-ffff-4c48-8fae-a9ef71b75e26 [RNI]
[BLE] chr 20b9794f-da1a-4d14-8014-a0fb9cefb2f7 [RWwNI]
[BLE] svc b2e7d564-c077-404e-9d29-b547f4512dce
[BLE] chr 48cbe15e-642d-4555-ac66-576209c50c1e [WwNI]
[BLE] chr db96492d-cf53-4a43-b896-14cbbf3bf4f3 [Ww]
[BLE] chr 66bd7ef2-c449-4e84-b203-fa5915709826 [WwNI]
[BLE] chr b3f86901-61cc-48f1-aa20-8e8b59d49d40 [R]
[BLE] Using dual-char mode (separate notify characteristic)
[BLE] Initiating SMP encryption (proactive pair)...
[BLE] secureConnection() failed (err 0x07) — continuing unpaired; writes may be rejected
[BLE] Notifications enabled
[BLE] Device: / / FW
[BLE] Checking PIN status...
[BLE] No read_pin response — probing r_dat to confirm channel...
[BLE] r_dat also silent — channel may be broken or auth-gated
[BLE] Connection lost (detected before r_sn_)
[BLE] Ready
@botts My Atom S3 Lite arrived today and I started setting it up. I can see it is connected to my Pulsar Plus, but nothing is working. Status, Charging Power, etc are all blank, and the Start/Stop buttons are not working. And the log is showing some errors. What other info can I provide to help debug?
===== UPDATE =====
FYI I just tried 1. v3.2.0-beta.4 to see if that would resolve the issues but unfortunately it did not help
The "Assistant link unavailable" is almost always transient — HA Core was mid-restart when the page loaded, so Supervisor returns a 502 (it's not a lost permission, despite what the message implies). A hard-refresh once Core is back clears it. I've opened an issue to make that banner say "Core is restarting, retrying…" and auto-retry instead of suggesting a reinstall. For the heatmap/sessions not registering — could you post a screenshot plus your charger model + firmware, and check whether sessions show on the gateway's own web page (http:/// → Sessions)? That tells us whether it's the Add-on not receiving the data or the charger not reporting it.
Thanks for the detailed log — good news is the basic (Zentri) Pulsar is supported as of v3.1+, so secureConnection() err 0x07 is a pairing/bond hiccup, not "unsupported hardware." Three things to try: (1) make sure nothing else is connected over BLE at the same time — the Pulsar allows only one link, so close the Wallbox app; (2) clear the existing bond (forget the charger's Bluetooth in the app) and reboot the ESP, then let it re-pair; (3) tell us your firmware version (Info page) and whether a BLE PIN is set. I've opened a tracking issue (esp32-wallbox #19) to harden this path and make the failure message clearer.
"Connected but every value blank + Start/Stop dead" almost always means the BLE notify subscription didn't complete, so no data flows back — usually a pairing/PIN step rather than a bad connection. Could you grab the serial log at 115200 baud right after boot (it prints the pairing/CCCD steps) and paste it? And two quick checks: does your charger have a BLE PIN set in the Wallbox app, and is anything else (phone/app) connected to it over BLE at the time? The Atom S3 Lite is fine hardware-wise, so this is almost certainly the pairing handshake. Tracking as esp32-wallbox #19.
@botts There is a BLE PIN set in the app. I may have still had the app open when I first connected. Should I try again with the app fully closed?
I'm not sure how/where to see this? Is the below helpful?
============================
Wallbox BLE Gateway v3.2.0-beta.4[OTA] Running from: app1 (0x200000)
[Health] Boot reset reason: software (ESP.restart)
[Health] Boot attempt #1 for this firmware
[Config] Loaded from NVS:
WiFi SSID: 'redacted' (len=13)
WiFi pass: len=10 (masked)
MQTT host: 'redacted' (len=17) port=1883
MQTT user: '' (len=0)
MQTT pass: len=0 (masked)
MQTT cid: 'wallbox-gw'
BLE addr: '94:34:69:04:A5:67' (len=17) pin=set
BLE svc: '331a36f5-2459-45ea-9d95-6142f0c4b307' (len=36)
BLE chr: 'a9da6040-0823-4995-94ec-9ce41ca28833' (len=36)
BLE txchr: 'a73e9a10-628f-4494-a099-12efaf72258f' (len=36)
chg_model: 'plus'
auth: en=0 user='admin' pass_len=0
polls: status=10000ms realtime=30000ms
reminder: lead=10min
mains_v: 208V (phase-current power fallback)
HA: prefix='homeassistant' devid='wallbox_pulsar_max' discovery=off
[BLE] TX power: +9 dBm, IO cap: KeyboardOnly
[Radio] Coexistence: BALANCE, WiFi PS: OFF
[WiFi] Connecting to 'redacted' (ssid_len=13, pass_len=10).
[WiFi] Connected: 192.168.1.22
[OTA] Firmware validated (WiFi OK)
[chargelog] loaded 0 stored charge intervals (last 0Wh)
[mDNS] http://wallbox-gw.local (IP: 192.168.1.22)
[Web] http://192.168.1.22/ (async on :80, sync retired)
[WS] AsyncWebSocket attached at /ws on :80
[Web-async] Listening on :80 (production, post port-swap)
[OTA] Password: wb-f6b104 (use web auth pass, or shown here for espota)
[OTA] Ready
[BLE] Target: 94:34:69:04:A5:67
[BLE] State-machine task started on core 1
[Main] Setup complete[BLE] Scanning for 94:34:69:04:a5:67...
[MQTT] Connecting...
[BLE] Found! RSSI: -59 dBm Name: WB814836 Type: 0
[BLE] Connecting (RSSI: -59)...
[BLE] Using scan address (type 0)...
[BLE] Connected, stabilizing...
[BLE] GATT topology: 5 service(s)
[BLE] svc 0x1801
[BLE] chr 0x2a05 [I]
[BLE] chr 0x2b2a [R]
[BLE] chr 0x2b29 [RW]
[BLE] svc 0x1800
[BLE] chr 0x2a00 [R]
[BLE] chr 0x2a01 [R]
[BLE] svc 0x180a
[BLE] chr 0x2a29 [R]
[BLE] chr 0x2a24 [R]
[BLE] chr 0x2a26 [R]
[BLE] svc 331a36f5-2459-45ea-9d95-6142f0c4b307
[BLE] chr a9da6040-0823-4995-94ec-9ce41ca28833 [WwN]
[BLE] chr a73e9a10-628f-4494-a099-12efaf72258f [wNI]
[BLE] chr 75a9f022-af03-4e41-b4bc-9de90a47d50b [RWwNI]
[BLE] svc 169b52a0-b7fd-40da-998c-dd9238327e55
[BLE] chr 902ee692-6ef9-48a8-a430-5212eeb3e5a2 [W]
[BLE] chr 503a5d70-b443-466e-9aeb-c342802b184e [Ww]
[BLE] chr 12e868e7-c926-4906-96c8-a7ee81d4b1b3 [R]
[BLE] Using dual-char mode (separate notify characteristic)
[BLE] Initiating SMP encryption (proactive pair)...
[BLE] SMP auth complete: encrypted=1 bonded=1
[BLE] Encryption established
[BLE] Notifications enabled
[BLE] BGX mode char found, current value: 0x01
[BLE] BGX already in STREAM_MODE
[BLE] Device: Silicon Labs / Bluetooth Xpress / FW BGX13P.1.2.2045.0-1261-2045
[BLE] Checking PIN status...
[BLE] TX read_pin
[MQTT] Connecting...
[BLE] RX raw (16): 7b 22 69 64 22 3a 31 2c 22 72 22 3a 7b 22 70 69 |{"id":1,"r":{"pi
[BLE] RX raw (16): 6e 22 3a 22 36 36 30 34 38 35 22 2c 22 76 65 72 |n":"660485","ver
[BLE] RX raw (9): 73 69 6f 6e 22 3a 31 7d 7d |sion":1}}
[MQTT] Failed, rc=-2
[MQTT] Connecting...
[MQTT] Failed, rc=-2
[BLE] RX read_pin (41 bytes)
[BLE] PIN is set (version=1)
[BLE] Authenticating with PIN...
[BLE] TX set_pin
[MQTT] Connecting...
[MQTT] Failed, rc=-2
[Health] Marked healthy — boot counter cleared, OTA validated, boot recorded
[MQTT] Connecting...
[WS] client 1 connected from 192.168.1.84
[MQTT] Failed, rc=-2
[BLE] RX set_pin (25 bytes)
[BLE] PIN authenticated
[BLE] TX r_sn_
[MQTT] Connecting...
[MQTT] Failed, rc=-2
[MQTT] Connecting...
[MQTT] Failed, rc=-2
Re: Assistant link unavailable - this remains the case for me despite restarting, etc
Yep — a BLE PIN set in the app plus the app still connected is very likely the whole problem: the Pulsar only allows one BLE link at a time, so while the Wallbox app holds it the gateway can pair but never gets a clean notify subscription (→ connected, all values blank).
▎
Do this in order:
-
Force-close the Wallbox app (swipe it away, not just background) — ideally turn the phone's Bluetooth off for a moment so it drops the link.
-
Power-cycle the ESP32 so it re-pairs from scratch.
-
If it still won't take, remove the bond: in the Wallbox app forget/unpair the charger, and clear the gateway's stored bond (re-flash or the "clear pairing" option), then let the gateway pair fresh with the PIN.
On the serial log: it prints over USB at 115200 baud. Easiest is the browser tool at ESP Web Tools → Logs, or Arduino IDE / pio device monitor -b 115200, with the board plugged in over USB right after boot. The snippet you pasted helps — paste the first ~40 lines from power-on (it prints the pairing / CCCD subscribe steps, which is exactly where 0x07 shows up).
Thanks for confirming it's not the transient case — if a hard refresh after Core is back didn't fix it, then it's not a mid-restart 502, it's the homeassistant_api permission not actually being active. Two things that cause the persistent version:
-
Sideloaded add-on — the permission is granted at install time, so a restart isn't enough; it needs a full uninstall → reinstall (from the store/repo) for Supervisor to hand the add-on its SUPERVISOR_TOKEN.
-
Older add-on build without homeassistant_api in its manifest.
Could you tell me: (a) the add-on version you're on, and (b) the exact detail line in the banner (it echoes the underlying error — "SUPERVISOR_TOKEN not set" vs a 401/404)? That'll pin which of the two it is.
And — directly relevant to your two-charger setup — v0.40.0 adds multi-gateway support to the add-on: you can now list both Pulsars in the add-on config and a charger switcher appears in the header, so one add-on manages both. Rolling out shortly; I'll ping you when it's live.
A quick post-mortem on the "Assistant link unavailable" issue - and how I'm preventing it going forward
A few of you hit the Charge Assistant showing "Home Assistant link unavailable" and reinstalling didn't help. I dug in - the message was misleading and the real cause was on me. Here's the honest version.
What actually went wrong
The Charge Assistant is driven by the integration, but configured from the add-on. For that to work, the add-on calls two services the integration provides (get_config / set_config). The problem: those services had only ever been published on the integration's beta channel. The stable/default HACS version didn't have them.
So the common setup — add-on installed, integration installed normally (stable) — gave you an add-on expecting a bridge that the integration didn't expose. The add-on then showed a generic "link unavailable" that wrongly pointed at permissions. Reinstalling couldn't fix a version mismatch.
What I've shipped to fix it (today)
- Integration v0.18.0 — promoted to stable. The bridge is now on the HACS default channel; no "show beta versions" toggle needed.
- Add-on v0.40.0 — matched release. If it ever detects an integration older than 0.18.0, it now says exactly that: "Update the Wallbox Gateway integration to ≥ 0.18.0" — instead of the vague link error.
- (Bonus in the same release: multiple chargers from one add-on via a header switcher.)▎
→ Update BOTH to the versions above and the Charge Assistant will connect. (Full update steps are in my previous post.)
What I'm changing so this doesn't recur
1. Matched-pair releases. The add-on and integration ship together, and each release states the minimum version of the other it needs. No more one side racing ahead of the other on a different channel.
2. No add-on feature depending on a beta-only integration service. If the add-on relies on something in the integration, that something goes to the stable channel first.
3. Honest, actionable errors. Failures now name the cause — "integration too old," "add-on can't reach the charger (check IP/password)," "HA restarting" — instead of one catch-all banner.
4. A documented compatibility table in both READMEs so you can always see which add-on pairs with which integration.
Thanks to everyone who reported it with logs and screenshots — that's exactly what let me trace it to the version split rather than guessing. Sorry for the runaround; this pairing should make it "install both, done." 
Hi
Updated to:
and
I get this:
The gateway is working:
I also tried adding a second Gateway - I dont get a second gateway tab on the sidebar:
(Solved this one.... needed to 'add' both, rather than 'save' one and 'add' one.... Now can access both in the tab on the sidebar)
Best I can see, the entity ID's are different for both chargers in HA (and unique mqtt names). The MQTT messages are unique - but (and I don't quite understand it!) there are messages from 'wallbox_esp-shed' and 'wallbox_esp_dg' (as I have set these ID's) but also 'wallbox_pulsar_max' (no idea where the mqtt messages with this name are coming from)....
Even with these unique entity ID's, (and perhaps because the names are identical?) - I get cycling of the values displayed in HA (showing alternatively each charger value under the one entity name)
And this is from teh gateway log:
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:09] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:09] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:09] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:09] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:10] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:10] "GET /api/sched?met=r_schs&par=null&wait=6000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:10] "GET /api/ha/config HTTP/1.1" 502 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:11] "GET /api/notifications?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:13] "GET /api/sess?met=g_tzn&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:13] "GET /api/charge_log?gw=0 HTTP/1.1" 502 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:13] "GET /api/sched?met=r_schs&par=null&wait=6000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:19] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:20] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:29] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:30] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:30] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:30] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:30] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:30] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:31] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:39] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:39] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:40] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:40] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:40] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:40] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:41] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:49] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:49] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:50] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:50] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:50] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:50] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:51] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:27:59] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:00] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:00] "GET /api/health?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:00] "GET /api/diag/disconnects?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:00] "GET /api/charger?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:00] "GET /api/sess?met=r_lse&par=null&wait=4000&gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:01] "GET /api/meter?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:09] "GET /api/addon/config?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:09] "GET /api/status?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:09] "GET /api/notifications?gw=0 HTTP/1.1" 200 -
INFO:werkzeug:172.30.32.2 - - [03/Jul/2026 12:28:09] "GET /api/health?gw=0 HTTP/1.1" 200 -
And still see this:
I completely wiped the ESP32 and reinstalled - And it worked! I can see the dashboard now.
BUT - The HA integration isn't working. 
Logger: custom_components.wallbox_gateway.coordinator
Source: helpers/update_coordinator.py:434
Integration: Wallbox BLE Gateway (documentation, issues)
First occurred: 5:16:55 PM (13 occurrences)
Last logged: 5:25:19 PMUnexpected error fetching wallbox_gateway (Wallbox 00814836) data
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 434, in _async_refresh self.data = await self._async_update_data() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/custom_components/wallbox_gateway/coordinator.py", line 102, in _async_update_data "charger_status": (charger or {}).get("status", {}).get("r", {}), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'get'
*** UPDATE ***
I take that back. It is only partially working. The dashboard screen shows nothing. But if I go to Settings > Charger I can successfully make changes like configuring the Halo LED.
*** UPDATE 2 ***
And I take it back back. I updated to the latest beta and now it does seem like the dashboard is working. Kind of. The energy flow section is correct. But the status section below is empty:
And HA is still getting the same errors.
Tracked it down and it's fixed in firmware v3.2.0-beta.8. The cause: every gateway was publishing to the same MQTT topic (wallbox/status), so with two chargers each one's "Max Charging Current" (and other values) cycled into the other's HA entity — exactly the 17 A ↔ 10 A flip-flop you saw. The new firmware namespaces topics per gateway (wallbox//…), so each charger is fully independent.
Please OTA both ESP32s to v3.2.0-beta.8, then in each gateway's Settings give them a distinct "HA Device ID" (e.g. wallbox_shed / wallbox_dg — you already did this 
). HA entities re-point automatically. The cycling should stop immediately.
On the "no second gateway tab": multi-gateway isn't a second sidebar panel — it's a charger dropdown in the top-right of the add-on header (appears once you list 2+ gateways in the add-on Config). Pick one and the whole UI follows it.
Great news that the wipe-and-reflash fixed the BLE side — that confirms it was the stale pairing/bond. 
For the get_config HTTP 400 on the Charge Assistant: add-on v0.41.0 hardens that call (some HA versions were rejecting the response request) — update the add-on and hard-refresh. If it still 400s, could you grab the full HA Core log entry behind it (Settings → System → Logs)? That'll show the real reason. Also confirm the integration is on v0.18.0+ and that its host/password (Settings → Devices & Services → Wallbox Gateway → Configure) match your gateway.
Your gateway's perfect (that screenshot is its own UI). The two add-on issues are separate connections, both now easier to fix:
1. Blank sessions in the add-on → set the charger IP + password in the add-on's Configuration tab (blank password is the usual cause — the add-on then can't authenticate to the gateway).
- "Assistant link unavailable" → update to integration v0.18.0 (stable) + add-on v0.41.0, and if you sideloaded the add-on, do a full uninstall → reinstall (the HA-API permission is only granted at install). The add-on now also shows a clear "update the integration" message if versions are mismatched.