@botts I’m not sure if this is a hardware issue or a software issue, but my gateway keeps going offline. Almost daily. Unplugging it and plugging it back it gets it back up and running.
Granted, it is in my very hot FL garage in the middle of summer. So maybe it is overheating (which obviously is not a gateway issue). But I do have a second S3 module right next to it which remains online.
Thoughts?
Hey @_Mike — appreciate the report. You’ve probably already got a theory here, and the “identical S3 right next to it stays up” detail is a great control — that alone points away from the ambient environment and toward something specific to this unit or its load.
Best move is to let the gateway tell us what happened rather than me speculate. Next time it drops, before you power-cycle (or right after — it’s persisted either way), the reset reason is at:
http:///api/boot/history
That’ll say brownout / task-watchdog / panic / power-on, which basically splits it for us — brownout leans power (and heat makes a marginal supply worse, which would also explain why the lighter-load neighbor is fine), watchdog/panic means it’s on me and there’s a crash breadcrumb in that same output I can dig into. If it just shows a clean power-on but it was unreachable, that’s a WiFi-wedge story instead.
Only other thing worth checking — what firmware are you on (top of /info)? The 3.2 line has an escalating WiFi watchdog that restarts a wedged stack / reboots a true hang, so if you’re behind that and it’s the “never comes back on its own” flavour, an update might just sort it.
One gap on my end: I don’t currently expose the S3’s internal temp, so the heat is invisible in HA right now. Happy to add it as a diagnostic sensor if that’d help you see what it’s actually doing in that garage.
Thanks @botts. The S3 (along with an AP and some other equipment) are in a plastic electrical box in the garage. I have fans in there, but it still gets several degrees warmer than the rest of the already-hot garage. I left the door to the box open yesterday and the S3 never crashed. Maybe a coincidence, but I will keep an eye on it. If it crashes, I’ll run the diagnostic you suggested. Exposing the temperature sensor to HA could be interesting. If it’s not a lot of effort.
@_Mike Good news on the temperature: it’s basically already there. The gateway exposes the S3’s on-die temperature as a “Gateway Temperature” diagnostic sensor (in HA via both the integration and MQTT), landing in v3.2.0 - so you’ll be able to graph it and line any crashes up against temperature spikes, which should confirm or rule out the thermal theory pretty quickly. If it does crash, the boot-history diagnostic + that temp graph together will make it obvious.
One caveat: it reads the die temp (warmer than the box air), so treat it as a relative early-warning trend rather than an exact ambient reading.
Hi @botts - Somehow I ended up with an orphan gateway instance. I am able to disable it, but there is no option to delete it. Any suggestions? Thanks!
Hi Mike — that orphan is a leftover HA device from before the integration had read your charger’s serial number (it briefly keyed the device off the config entry, then re-homed everything to a serial-keyed device once the serial came through). It’s harmless disabled, but the reason there’s no Delete is a gap on my side: the integration wasn’t telling HA it’s OK to remove its devices.
Fixed in v0.30.0 (just released). Update via HACS, then open the orphan device’s page and the ⋮ menu will have a Delete option — it’ll only let you remove the stale one, never your live gateway. 
That did the trick! Thank you!!
Wallbox Gateway firmware v3.2.2 is out - reliability + polish
Hi all - pushed v3.2.2, mostly a reliability release. The headline:
Killed the rare random reboot. A handful of you (and my own box) saw the very occasional unexplained reboot - no crash log, just gone and back. I finally pinned it down: it always traced to one specific BLE read (r_lse, the solar/session-energy read) whose round-trip can spike to ~1 second on a marginal Bluetooth link, which was tripping the ESP32’s interrupt watchdog. The gateway was doing that read every poll cycle - now it’s throttled to once every 30s (the data barely changes that fast anyway). My box has run 69 hours crash-free on it, where before it’d fall over within a day. If you’ve had mystery reboots, this is the one.
Better WiFi recovery. If your AP blips for a minute (router reboot, etc.), the gateway used to occasionally wedge its WiFi stack and sit there offline for a full 30 minutes before recovering. Now it retries a full stack-restart every 3 minutes and only falls back to a reboot at 10 minutes - so worst case you’re offline ~10 min, usually much less.
Halo LED now works from Home Assistant. The halo brightness/mode select was silently doing nothing - the command format was wrong. Fixed, and the state now reflects the charger’s real config.
Also: cleaner BLE error messages in the log (human-readable instead of raw codes), an eco_smart capability flag so the Add-on greys out solar/eco options correctly on chargers that don’t support them, and a crash-breadcrumb that survives reboots (helps me diagnose any future watchdog resets).
Updating: OTA straight from the gateway’s web UI (or the Update entity in HA if you’re on the integration). No re-flash needed.
(Separately - integration v0.30.0 just went out too, which lets you delete leftover/orphaned gateway devices that previously had no delete button. Update via HACS.)
hi @botts , I’m not sure if i missed something… I can see the charger status on the dashboard and i am able to change the charging current. I can also Start charging and Lock the charger.
However I cannot Stop and I cannot Unlock the charger. It shows that the command was sent but the charger does not respond.
When setting up the wallbox-gw, i did go to advanced and selected my wallbox model (Pulsar Plus). But i do not know what the TX/Notify Char UUID is.
I selected charge control owner as None and turned off MQTT.
Are there any other settings that i should change?
Any ideas?
BLE GW is an ESP32-S3 N16R8. BLE signal is around -70dbm
Wallbox BLE Gateway v3.2.3
Wallbox Pulsar Plus FW 6.7.41
Thanks.
i found that even though i chose pulsar plus, after save and reboot it gets switched back to pulsar max by itself. could this be the problem?
Thanks Kenneth - pinned it down, and there’s a test build ready for you.
Root cause: your Pulsar Plus (on FW 6.7.41) presents the Max-family BLE service, so the gateway auto-detects “Max” for the transport — that part’s correct, and it’s why status/start/lock/current all work. But it also made the gateway treat your charger as a Max for commands, so Stop sent the Max stop parameter (w_cha par=2), which a Pulsar Plus acknowledges but ignores. That’s your exact symptom: “sent, no response.” (The “reverts to Pulsar Max” you saw is the same auto-detect - leave it; it’s the transport, not a mistake.)
Fix: the Stop parameter now follows your charger’s own model report (Pulsar Plus → par=0), regardless of the BLE transport. Test build here:
Release v3.2.4-beta.1 — Pulsar Plus Stop fix (test build) · botts7/esp32-wallbox · GitHub
Two ways to flash it:
Via HA (easiest): integration Configure → set Update channel to Beta, then the gateway’s Firmware Update entity will offer v3.2.4-beta.1 → Install.
Or directly: download firmware.bin from that release and upload it on the gateway’s Config page (firmware update section).
Then please try Stop and let me know if it works. Two more things that’d help:
Paste http:///api/status - I just want to confirm your chg_project reads pulsar-plus (belt-and-braces).
Unlock is a separate issue I’m still chasing — when you press Unlock, does anything happen at all (does it re-lock itself, or just nothing)? Any detail helps.
Note: the device will still display “Pulsar Max” — that’s cosmetic (the BLE transport label) and doesn’t affect the fix.
hi @botts
i installed v3.2.4-beta.1, unfortunately Stop still doesn’t work. Same as before, command sent but charging doesn’t stop, no response from the charger.
same thing when i press unlock, the Command Sent acknowledgement pops up but nothing happens with the charger.
how can i check whether the stop parameter was correct?
here’s the api/status:
Thanks Kenneth - your chg_project is pulsar-plus, so the beta is now sending the Plus stop parameter. But your status shows charging_now: false, which points at the real issue: the Stop is probably being skipped before the parameter is even sent, because the gateway isn’t recognising your charger’s “charging” state.
To check exactly what’s happening - while the car is actively charging (dashboard showing power > 0), open this in a browser:
http://192.168.0.192/api/command?action=stop
Look at the JSON it returns:
Either way, please also paste — while actively charging - the output of:
http://192.168.0.192/api/charger
I need the st and charger_status values; that tells me which code your PM3 reports for “charging” so I can teach the gateway to recognise it.
On Unlock: your charger currently reports lock_state: 0 (already unlocked), so there’s nothing for Unlock to do - that’s why “nothing happens.” To really test it, Lock first (that works), then Unlock - does it release?
Hi @botts
Ok, sorry - earlier i sent you the api/status when the charger wasn’t charging. I get a better idea how to use it now.
Here is the API status when the charger is charging:
here is the output of api/charger while charging:
strangely unlock and lock now seems to work however i noticed that chg_lock_state is always 0, even when the wallbox is locked. i confirmed via wallbox app and status ring color.
Perfect, this nails it down. Good news: the gateway correctly sees you charging (st=1), so Stop isn’t being skipped, and it is sending the Plus stop parameter (par=0). The problem is your PM3 ignores it - and it ignored par=2 before too. So your charger needs a stop command neither the Plus nor Max convention sends, and I need your help to find which one works.
While the car is actively charging, try each of these in your browser, one at a time, and tell me for each: (a) the JSON it returns, (b) does charging actually stop, and (c) if it stops, does it start again by itself after ~10–30s:
http://192.168.0.192/api/command?action=bapi&met=w_cha&par=2
http://192.168.0.192/api/command?action=bapi&met=w_cha&par=0
http://192.168.0.192/api/command?action=bapi&met=w_cha&par=3
(These are the normal charge-control command - safe to try.) Whichever one actually stops the charge, I’ll wire in for your charger.
Also glad Lock/Unlock work now — the earlier “nothing happens” was because the charger was already unlocked. Separately, I can see your lock_status always reads 0 even when it’s locked; that’s a display bug I’ll fix once we’ve got Stop sorted.
Hello @botts
The par=2 command worked. Charging stopped (and didn’t restart itself, I waited about 2 mins).
The output from the command:
The other 2 commands didn’t work. The here are the JSON result after running the commands:
Two things:
Two fixes, both straight from your data — thanks, genuinely great debugging on your end:
New build: Release v3.2.4-beta.2 — Pulsar Plus Stop + Lock fixes (test build) · botts7/esp32-wallbox · GitHub — flash firmware.bin (or Beta channel via HA), then both Stop and Lock state should behave. (Your charger showing as “Pulsar Max” is expected and correct — it uses the Max BLE stack.)
hi @botts
I’m so sorry - actually your first guess was correct. I’m so sorry!
I must have messed up my screenshots or something.
I messed up bad, I’m really sorry for being an idiot.
http://192.168.0.192/api/command?action=bapi&met=w_cha&par=0 is the right command for my pulsar plus, you were correct on your first guess. So i’m not really sure why in Beta.1 it didn’t work.
as for the lock and unlock, http://192.168.0.192/api/charger does switch lock_state between 1 and 0 and the wallbox locks and unlocks correctly.
however the webui still does not reflect the lock/unlock status, and neither does the homeassistant integration. in the integration, switching on the lock switch does lock the wallbox but the switch still appears to be locked.
