I'm not using the add-on. I thought that was optional only if you want a dashboard within HA? My screen shot of the (partially working) dashboard was from directly from the UI on the ESP32 gateway.
The integration is on v0.18.0. There is no password set up in the gateway. When configuring the integration, I tried leaving user name blank and also leaving the default "admin". Neither worked.
Here are the HA logs:
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 119, in _async_update_data "charger_status": (charger or {}).get("status", {}).get("r", {}), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'get'
Question: This screen of the setup is only if you are using MQTT in HA, right? If I am using the integration, I can leave this blank?
@_Mike — your log nailed it, thank you. It wasn't the username or the host at all (your log shows the integration reached the gateway fine) — the coordinator was crashing on an empty status cache:
AttributeError: 'NoneType' object has no attribute 'get' (coordinator.py)
Your gateway returns {"status": null, …} (the same marginal-BLE thing as your blank dashboard boxes), and the coordinator didn't guard against null, so it crashed and took every entity down — which reads exactly like "won't connect." Fixed in integration v0.18.2 (release (Release v0.18.2 — fix coordinator crash on empty status cache · botts7/hass-wallbox-gateway · GitHub)) — update in HACS and it should come straight up. Pair it with firmware v3.2.0-beta.9 (adds a poll retry so the cache is less likely to be empty).
Your question — yes, correct: that MQTT screen is only for the MQTT-discovery path, which is an alternative to the integration. Using the integration (it polls over HTTP), you can leave the gateway's MQTT settings blank — no broker needed.
While everyone's here — the latest matched set is out. If you've hit anything odd, please update all three:
Integration no longer crashes on an empty status cache — a null status from the gateway was taking down every entity (thanks @_Mike for the log).
Multiple chargers from one setup — charger switcher + per-gateway MQTT topics, so two chargers stop cycling values into each other's entities.
Charge Assistant "link unavailable" — config bridge now on the HACS default channel; clear "update to vX" message instead of a vague error.
get_config HTTP 400 — hardened.
Marginal BLE link — status poll retries once so the dashboard/HA don't stay blank.
Timezones — Europe/Tallinn + other Baltic/EET zones.
EM340 / Power-Boost per-phase reporting confirmed working (was a wiring fix on the reporter's side).
Updating: Integration via HACS → restart HA · Firmware OTA the .bin via the gateway's OTA tab · Add-on via the store (only if you use it; if you sideloaded it and see "Assistant link unavailable", uninstall → reinstall).
Then hard-refresh (Ctrl/Cmd-Shift-R). @andypnz@mo-harry — this set should fix what you each ran into too; give it a go and let me know. If anything's still off, post your charger model + a screenshot.
switch.halo_standby — dim-the-ring-when-idle on/off (the on/off you wanted)
number.halo_brightness — 0–100 %
Automate them freely — nothing fights you. The integration only reads the halo to display it; it never re-writes on its own, so an automation "owns" the setting and it stays put. (One behavioural note: standby on = the charger's own dim-when-idle. If you want a fixed brightness, set standby off in your automation too.)
A Halo LED card with a standby toggle + brightness slider, if you like driving it by hand.
The gateway's own web UI already has it (Tools → Halo LED — brightness, standby, timeout).
All tested end-to-end against a my charger (the dashboard slider genuinely changes the ring). Update the integration in HACS + restart HA and the two entities will appear. Enjoy automating your LED!
WiFi self-recovery — if WiFi drops after long uptime, the gateway now restarts its WiFi stack (5 min) then reboots (30 min) on its own, instead of needing a power-cycle.
MQTT backoff — an unreachable broker no longer retries every 5s forever (backs off to 60s). If you use the integration/add-on, you can just turn MQTT off in the gateway Settings.
Halo LED control everywhere — switch.halo_standby + number.halo_brightness in the integration, and a Halo card in the add-on dashboard.
Marginal-BLE status-poll retry, and the earlier Charge-Assistant / multi-charger / integration-crash fixes.
Update: Integration via HACS → restart HA · Firmware OTA the .bin via the gateway's OTA tab · Add-on via the store. Then hard-refresh (Ctrl/Cmd-Shift-R).
@botts Thank you for your AMAZING work! This is great!
If you (or anyone) are interested, here is my use case for the automation:
I only want the Halo LED to be on when the car is plugged in. If it is not plugged in, I don't want a bright LED shining in my garage. So On when plugged in, and Off when not plugged in.
For whatever reason, Wallbox thinks the only 2 options for the light should be Always On or Always Off (The only exception is when Standby Mode is off, the light will turn on for a few seconds when you first plug it in). I think that is a huge miss on their part. Thanks to this integration, I am able to set it up the way I have always wanted it!
- id: wallbox_charger_halo_standby_control
alias: 'Wallbox Charger Halo Standby Control'
initial_state: true
mode: restart
triggers:
- trigger: state
entity_id: binary_sensor.wallbox_charger_car_connected
action:
- choose:
- conditions:
- condition: state
entity_id: binary_sensor.wallbox_charger_car_connected
state: 'on'
sequence:
# If the car is connected, turn on the Halo LED (Standby mode off)
- action: switch.turn_off
entity_id: switch.wallbox_charger_halo_standby
default:
# If the car is NOT connected, turn off the Halo LED (Standby mode on)
- action: switch.turn_on
entity_id: switch.wallbox_charger_halo_standby
@botts Time for my next question! Sorry if I am being a pain in the butt. My intention is to be helpful!
Is there a way to add an Update entity to the integration? The idea is: When a new release for the gateway, HA can provide an Update notification and allow the user to automatically perform an OTA update from there. Rather than manually downloading the new bin and then uploading it through the gateway. Thoughts?
Awesome development! I'm on the suggested versions and the home assistant link error is gone. So that part is working. Looking great!
Still issues with the sessions. I removed the addon and reinstalled it, but to no avail. Below the screenshots of the current status. First image is from the addon. Second image from the gateway through (android chrome) browser.
Nailed it — thanks for the two screenshots, they pinpointed it. The totals were right but every session showed 0.00 kWh with an empty heatmap. Cause: the add-on read per-session energy from the charger's r_log, which returns 0 energy on some firmwares (I reproduced it on my own unit). Your gateway's charge-log does have the real energy — that's why the totals were correct.
Fixed in Add-on v0.43.0: the session list, heatmap and CSV now use the same charge-log ground-truth the totals use. Update the add-on (0.43.0), open Sessions, and the kWh + heatmap should populate. No gateway/firmware update needed for this one. Let me know how it looks!
It's pushed to the add-on repo now (v0.43.0). Home Assistant caches the add-on store, so you need to nudge it to pick up the new version:
Settings → Add-ons → Add-on Store
Top-right ⋮ menu → Check for updates (or just reload the page)
Open the Wallbox BLE Gateway Manager add-on — it should now offer Update to 0.43.0
Click Update, then reload the Sessions page
If it still shows 0.42.0 after "Check for updates", give it a minute (HA polls GitHub on a delay) and refresh again. No need to remove/reinstall this time — it's an in-place update. Your kWh + heatmap should populate once you're on 0.43.0.
Thanks to everyone reporting issues — this round is largely driven by your feedback. Here's what's new across the three components.
New: update the gateway firmware straight from Home Assistant
Integration v0.20.0+ adds a Firmware Update entity. When a new gateway release drops, HA shows it under Settings → Updates, and one click downloads it and OTAs it to your gateway over the LAN (the gateway needs no internet — HA is the middleman). Manual-trigger only; it never auto-flashes.
Channel toggle under Configure → Firmware updates: Beta (default — the current 3.2 line) or Stable.
Picks the right release by version and the binary matching your board.
So the whole stack now updates from inside HA: integration + add-on via HACS/Add-on Store, and gateway firmware via this new entity.
Fixes
Gateway firmware (v3.2.0-beta.11 / beta.12):
Blank status boxes when MQTT isn't connected — fixed. The dashboard and the HACS integration were served null on any gateway without a working MQTT broker, even though BLE was polling fine. Status now works with or without MQTT. (thanks ManuMaxGit)
WiFi now self-recovers from a wedged stack after long uptime, instead of needing a power-cycle. (thanks peter-mcc)
Exposes the build target so the new HA Update entity fetches the right image.
Add-on (v0.44.0):
Sessions showed 0.00 kWh and an empty heatmap on some chargers — fixed. Per-session energy now comes from the firmware charge-log (the same source the totals use), so the list, heatmap and CSV are correct. The weekly heatmap now matches the gateway's exactly. (thanks mo-harry)
Integration (v0.20.2) — Charge Assistant:
No more surprise charges. If your car's SOC sensor briefly dropped out, the assistant could start a grid charge on a full battery at evening peak. It now requires a known, below-target SOC to start, and the "keep charging past the window" (overrun) option only extends a running charge — it can't initiate one outside your cheap window.
Commute target is now clear and consistent. The commute-target sensor could display a value that wasn't actually being enforced. One resolver now drives both, so what you see is what's charged (single-car: your global commute toggle wins; multi-car: per-car opt-outs are honoured).
Install button no longer shows a spurious error during a flash (v0.20.1).
How to update
HACS → ⋮ → Update information, then update Wallbox BLE Gateway to the latest, and restart HA.
Update the Add-on from the Add-on Store.
Then Settings → Updates will offer the gateway firmware — one click to flash.
All of the Charge Assistant logic is covered by a 171-case test suite (including an all-modes scenario matrix), and this batch was verified on my hardware. As always, shout if anything looks off.
Thanks for flagging this, @andypnz - two things were keeping it hidden: the sensor was disabled by default, and even enabled it only read r_sta.max_charging_current, which the Plus doesn't report (the dashboard uses r_dat.cur). Fixed in v0.22.1: enabled by default + falls back to r_dat.cur. Update via HACS → restart HA and it should populate.
Ah, I know why — thanks for testing. This is a Home Assistant quirk rather than the fix itself: v0.22.1 made the sensor enabled by default, but HA only applies that to newly created entities. An entity already registered as disabled under the earlier version stays disabled after an update — HA never retroactively re-enables it. So your chargers' "Max charging current" sensors are still sitting disabled from before.
Enable it now (no need to wait): Settings → Devices & Services → Wallbox → your charger's device page → you'll see "+N entities not shown" → find Max charging current → open it → settings (gear) → toggle Enabled. Do it for both chargers; it should populate within a poll.
Or wait for the next update: I've added a one-time migration (v0.23.1) that auto-re-enables it on update — but only if it was disabled by the old default, so it won't touch anything you've deliberately turned off.
Once enabled, could you confirm it shows a value matching the gateway dashboard's "Max charge current"? That confirms the Plus fallback (r_dat.cur) reads right on your units — if it's enabled but blank, ping me and I'll grab the raw field.
I did exactly as you proposed. But the problem still persists. The version of Wallbox firmware is 3.7.5. During the pairing with genuine wallbox application there is no need to enter PIN. Below are logs from esp WEB tools:
Gateway firmware → v3.2.0-beta.9 — release + OTA .bin (
HACS Integration → v0.18.2 — release (
HA Add-on → v0.41.0 — release (
Halo LED — brightness, standby, timeout).
Known-good set — updated (firmware v3.2.0-beta.10)
New: update the gateway firmware straight from Home Assistant
Fixes
Thank you