So I I reverted back to 3.2.4 beta.1 and while charging I sent http://192.168.0.192/api/command?action=stop
Here’s the result:
No worries at all try Release v3.2.4-beta.3 — Pulsar Plus Stop + Lock (corrected) · botts7/esp32-wallbox · GitHub
Three fixes:
- Stop - back to par=0 for your Pulsar Plus (my first guess was right). The Stop button will now do what the raw par=0 command does.
- Lock in Home Assistant - the lock entity was only read once at connect, so it froze. It now refreshes every poll and tracks lock/unlock live.
- Lock on the gateway web dashboard - it wasn’t updating over the live connection; now it does.
Flash it and give Stop + both lock displays a final check - if they’re all good, I’ll roll this into a stable release. Thanks again for sticking with it.
Hi @botts
I updated to 3.2.4b3
Lock and unlock state is now correctly displayed in the webui and in homeassistant.
But still can’t Stop charging from webui (or HA), just like in beta1. Command sent but wallbox doesn’t stop charging.
I reconfirmed that charging stops when i use http://192.168.0.192/api/command?action=bapi&met=w_cha&par=0
just to be sure i selected pulsar plus again and rebooted the GW but it didn’t help.
what else can i do?
Great news that lock is fully fixed now! For Stop - it’s genuinely puzzling: the button and the raw w_cha par=0 go through the same dispatch, so either the button is computing a different parameter, or an “already-stopped” guard is skipping it. Rather than keep guessing, I’ve added logging that prints the exact decision.
Diagnostic build: Release v3.2.4-beta.4 — Stop diagnostics · botts7/esp32-wallbox · GitHub (no USB needed)
- Flash it.
- While the car is actively charging, press Stop (web UI or HA).
- Open http://192.168.0.192/logs and copy the line that starts with [CMD] stop: (and any [CMD] … SKIPPED line if present).
That one line tells me exactly what the button sends (par=0 vs par=2) and why - then I can fix it precisely instead of guessing again. Thanks for your patience with this one.
hi @botts
sorry, my logs don’t have any lines with [CMD].
do i need to turn on logging somewhere?
I have already updated to 3.2.4b4
My logs look like this:
Found it - and apologies for the runaround. The gateway has two copies of the command handler (a legacy one and the live one), and every fix I sent was landing in the wrong copy. The live handler was still sending the Max stop value (par=2) to your Plus - which is also why no [CMD] line showed in your logs (the logging went to the wrong file too). Your “no [CMD] lines” observation is exactly what exposed it.
Fixed in the right place now:
Release v3.2.4-beta.5 — Pulsar Plus Stop (the real fix) · botts7/esp32-wallbox · GitHub
Flash it and try Stop - it should finally stop charging (now sends par=0 like the raw command). If you want to confirm, http://192.168.0.192/logs should now show a [CMD] stop: … par=0 line right when you press it. Thanks for the testing.
Glad the Stop and lock are both working on the charger side now!
I’ve just shipped the last piece you spotted - the HA integration not updating the lock/unlock state when you change it from the web UI. That’s fixed in integration v0.31.1 (just released).
What was happening: the Lock switch in HA was inferring lock state from the charger’s status code, which only reflected a lock while the charger was otherwise idle - so a lock/unlock done from the gateway web UI (or the Wallbox app) wouldn’t show up in HA. It now reads the gateway’s direct lock state, refreshed every poll on firmware 3.2.4+. Lock or unlock from anywhere - web UI, Wallbox app, or the charger itself — and HA reflects it within one poll cycle.
I tested it end-to-end here: locked from the web UI → the HA Lock switch flipped to on; unlocked → back to off.
To get it:
-
Make sure you’re on firmware 3.2.4 (you already are).
-
In HACS → Wallbox BLE Gateway → update to 0.31.1. If it doesn’t appear yet, hit the ⋮ menu → Redownload (HACS can take a little while to see a new release).
-
Restart Home Assistant.
Give it a try and let me know it all lines up on your end. Thanks again for the detailed reports and screenshots - they made this one much easier to pin down.
Yes, Stop is fixed for my pulsar plus.
Lock and Unlock state now correctly updated in HA.
You’re a Rockstar!
I feel like I’m asking a question that I should have been able to find in the documentation or this thread, but I failed. So here I am asking. '-)
Is the functionality to have one ESP32 talk to two Pulsar Plus devices available yet? I’m installing two of them in my garage (along with an energy meter) and am starting to figure out what I need to do local control. I have at least a half a dozen ESP32-S3s laying around (side effect of experimenting), so doing two of them isn’t a big deal, but I’d rather do one if I can.
One ESP32 talks to one charger. The firmware holds a single persistent BLE connection to a single Pulsar, so for two Pulsar Plus you’d run two ESP32s, one paired to each. Since you’ve already got more S3s, that’s the easy path.
The good news is the Home Assistant side is built for exactly this: both the add-on and the integration support multiple gateways from one HA. You add each ESP32 as its own gateway, the add-on has a switcher to flip between them, and the integration creates a separate device per charger, so nothing collides or duplicates. Two chargers, two ESP32s, one HA Instance.
On power sharing between the two: Wallbox’s Dynamic Power Sharing is a charger-side feature (needs the two grouped). The gateway does expose a switch to read/toggle it, that’s brand new (shipped this week) and I’ve only been able to verify it’s non-destructive on a single charger. The actual two-charger behaviour hasn’t been tested in the wild yet (I only have one Pulsar here). If you’re up for it, your setup is exactly what’d let us confirm it works end-to-end, happy to dig in with you once you’re running.
One ESP32 > two chargers over BLE proabably isn’t something I’ll chase myself, it’s a chunky change (two simultaneous BLE connections + per-charger state), and honestly two cheap ESP32s is simpler and more robust, if one flakes it only takes its own charger down, not both.
I’ll keep that in mind. The electrician isn’t scheduled to come until the end of September (one of the downsides in living in rural Virginia - good tradespeople are hard to find and tend to be very busy), Once I have them both installed and have the ESP32’s all setup, I’ll check back and see if you still need someone to sort that with you.
Hi @botts! I’m considering picking up one of these because I am having bad luck with WiFi for the gateway. I’m assuming this should be ok, correct? No issue using Ethernet/POE?
Perfect, that’s the base ESP32-S3-ETH - I’ve got a test build ready for it.
Heads up: it’s wired-only (no WiFi - it pulls DHCP over the RJ45). That’s the whole point: BLE gets the ESP32’s 2.4 GHz radio to itself, which should fix the flakiness you were seeing.
Brand-new, untested code - you’d be the first one on it, so treat it as experimental.
Flash it straight from your browser (desktop Chrome/Edge, USB-C):
Then open a serial monitor @ 115200 and watch for:
[ETH] W5500 up (…)
[ETH] DHCP lease 192.168.x.x
If you get a lease, browse to that IP → the gateway web UI → set your charger’s BLE + your MQTT broker there (no captive-portal step on the wired build).
Let me know:
- did it pull an IP, 2. does the web UI load at that IP, 3. does BLE stay connected to the Pulsar?
If there’s no [ETH] line at all, the pins are off for your exact board and it’s a quick fix - but I set them from a tested ESP32-S3-ETH example, so hopefully first try.
Thanks for jumping on that so quickly! But I don’t actually own it yet - I am considering picking one up if my wifi issues don’t improve. I already bought a new wifi M5Stack AtomS3U ESP32S3 from Amazon. I’m giving that a try for a few days first, but if that does not work out then I can return it and buy the POE one.
@botts I might be a step closer to ordering the POE ESP32. But I’m hoping to get your input first. It might be difficult to see in the screen shot, but all of the missing chunks in the history timeline are when the Gateway momentarily became unavailable. It happens all day long. Is that normal, or is that my wifi being dumb?
Not normal, no. Those all day gaps are almost always signal or placement rather than the gateway itself. The firmware already runs WiFi with power-save disabled and an auto-reconnect watchdog, so it isn’t the usual “ESP fell asleep” issue. Before you spend on the POE board, let’s see if the WiFi you have is fixable, because you may not need it.
To pin the cause, grab a number: check wifi_rssi on the gateway (Settings, or http:///api/status) and, if you have the WiFi Signal sensor in HA, overlay it on the same timeline as the gaps. Rough guide: better than -70 dBm is healthy, -70 to -80 is marginal, worse than -80 will drop out. If the gaps track the RSSI dips, that’s your answer.
A couple more things that would help me narrow it:
- Where is the ESP physically, and what is it in or near? Distance to the AP, walls in between, and especially any metal enclosure/junction box or the charger’s own housing, which shields 2.4 GHz badly.
- Which gateway firmware are you on? Please make sure it’s the latest (v3.2.12) so we’re not chasing a reconnect stall that’s already fixed.
Cheap things to try before more hardware: get the ESP out of any metal and into line of sight, add an external antenna if the board supports it, drop a 2.4 GHz AP or mesh node near the garage, and set a static DHCP lease.
So this is interesting - I lined up the WiFi signal, BLE signal, and Status to see if the outages in Status correspond to either of the other two. They don’t. But this exercise made me noticed that the outage regularly occurs every 15 minutes like clockwork. I double checked, and I do not have any automations that would cause this. Thoughts?
And to answer your other questions -
The ESP is in the garage, not far from the charger. It lives in a plastic enclosure, along with a UniFi POE switch, backup battery, and another ESP device. The garage does get hot, but I have added some pretty good fan ventilation.
v3.2.13-rc.2
That “every 15 minutes like clockwork” detail is the useful one. First, an important reframe: the gateway’s HA availability is tied to its BLE link to the charger, not to WiFi. So when your entities go unavailable, that’s the BLE connection to the charger dropping and taking more than 60s to recover, not a WiFi problem. Worth knowing before the POE board, because Ethernet wouldn’t fix a BLE drop on its own.
Two quick checks to confirm that:
-
During an outage, can you still load the gateway’s own web page (http://)? If yes, WiFi is fine and it’s the BLE link. If the page is also dead, then it’s WiFi/network after all.
-
Grab a serial log at 115200 across one of the 15-minute drops. The line [BLE] Disconnected — last GATT err=X tells us whether the charger dropped us, a supervision timeout fired, or it was local. Paste it and I’ll decode the code.
On the 15-minute cadence: it isn’t any timer in the gateway (the BLE keepalive is 30s and clock sync is hourly, neither is 15 min), so it’s coming from the charger or the RF environment. Given your setup, the prime suspect is the other ESP device sharing that plastic enclosure. Two 2.4 GHz radios inches apart, and if that other device does anything periodic (a scan, a transmit burst) it can desense the gateway’s radio, which the AtomS3U’s small onboard antenna makes worse. Easiest test: power that other ESP off for an hour and see if the 15-minute pattern stops.
If it turns out to be RF contention, then wired Ethernet actually would help, since it frees the gateway’s single 2.4 GHz radio to focus entirely on BLE. But let’s confirm with the web-UI check and the serial log first, so you don’t buy hardware for the wrong problem.