EVEUS to MQTT and Home Assistant with ESP32

27 September 2026 · updated 28 September 2026

This is the complete version of my EVEUS bridge: a classic ESP32 DevKit connects to normal 2.4 GHz Wi-Fi while keeping its own permanent access point for the charger, reads the EVEUS local HTTP API, publishes telemetry to an MQTT broker over TLS, and creates the device in Home Assistant through MQTT Discovery.

Hardware and safety: this build targets a classic ESP32 DevKit (esp32dev), not an ESP32-C3. The tested charger accepts 7–16 A, but you must use the limits of your charger, cable and electrical installation. Configure and test with the vehicle disconnected before issuing charging commands.

Architecture

Home/parking Wi-Fi (2.4 GHz)
             |
        ESP32 station ------- MQTT/TLS :8883 ------- Broker
             |                                          |
     permanent ESP32 AP                         Home Assistant
     eveus-v2 · 192.168.50.1
             |
      EVEUS local HTTP
      DHCP 192.168.50.x

The ESP32 runs in AP+STA mode. Its station side reaches the broker; its access-point side gives EVEUS a private network. The charger therefore does not need the parking router, a static address, port forwarding, or any physical connection to the ESP32. The firmware identifies the charger by Wi-Fi station MAC and learns its DHCP address.

The private network is deliberately not a NAT router. EVEUS can reach the bridge, but it does not receive internet access through it. The AP and station share one radio; when the uplink is connected, its channel takes priority, as described in Espressif's AP+STA documentation. Avoid an uplink subnet that overlaps 192.168.50.0/24.

Download the complete firmware

Download the complete ESPHome source. The archive includes the two YAML files, the local eveus_ap component, an example secrets file and build notes. It contains no real Wi-Fi, MQTT or charger credentials.

The snapshot targets ESPHome 2026.6.5, ESP-IDF and esp32dev. The custom component keeps the private AP alive after the ESP32 joins the uplink; ESPHome's normal fallback AP is unsuitable because it is intended to disappear after a successful station connection.

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_ESP_WIFI_SOFTAP_SUPPORT: "y"
      CONFIG_LWIP_DHCPS: "y"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none
  reboot_timeout: 0s

eveus_ap:
  id: charger_ap
  ssid: "eveus-v2"
  password: !secret ap_password
  charger_mac: "AA:BB:CC:DD:EE:FF"

Prepare and flash the ESP32

Extract the archive and copy secrets.example.yaml to secrets.yaml.
Set the 2.4 GHz uplink SSID and password, a different strong password for eveus-v2, MQTT credentials, and the broker's PEM CA certificate.
Replace mqtt.example.com in eveus-bridge.yaml with the broker hostname. Keep hostname verification enabled.
Replace the example charger_mac in eveus.yaml with the EVEUS Wi-Fi station MAC.
Review eveus_min_current and eveus_max_current. Do not assume the included 7–16 A range applies to another charger.

cp secrets.example.yaml secrets.yaml
chmod 600 secrets.yaml
# Edit secrets.yaml, eveus.yaml and eveus-bridge.yaml.
docker run --rm -v "$PWD":/config \
  ghcr.io/esphome/esphome:2026.6.5 config /config/eveus.yaml
docker run --rm -v "$PWD":/config \
  ghcr.io/esphome/esphome:2026.6.5 compile /config/eveus.yaml
# Replace /dev/ttyUSB0 with the detected serial port.
docker run --rm -it --device=/dev/ttyUSB0 -v "$PWD":/config \
  ghcr.io/esphome/esphome:2026.6.5 upload /config/eveus.yaml \
  --device /dev/ttyUSB0

Keep secrets.yaml and compiled binaries private: firmware images contain credentials. The example exposes ESPHome API, OTA and a local status web server without authentication, so keep the uplink trusted or add authentication before using an untrusted network.

Install the bridge at a parking space

This procedure assumes that the parking space already has an EVEUS charger and a third-party Wi-Fi network with internet access. The third-party network is only the ESP32 uplink: EVEUS connects to the private eveus-v2 AP instead.

Check the third-party Wi-Fi first

It must provide a 2.4 GHz network. A dual-band router is suitable if it accepts 2.4 GHz clients.
You need the exact SSID and password before compiling the firmware. This build has no browser page for changing the uplink at the parking space.
The network must provide DHCP, DNS, and outbound TCP access to the MQTT broker, normally port 8883. No inbound port forwarding is required.
A normal WPA2 shared-password network or a phone hotspot works. A captive portal that asks you to sign in through a browser, WPA-Enterprise, and many hotel or guest networks are not supported by this build.
Treat the example firmware as suitable only for a trusted or isolated uplink until you configure authentication for its ESPHome API, OTA and web server. Do not place its unauthenticated management interfaces on a network shared with untrusted users.
Do not use an uplink whose LAN is 192.168.50.0/24, because that would overlap the ESP32 private network.

Wi-Fi client isolation is usually acceptable because the ESP32 only makes outbound connections to the broker. If you use a phone hotspot permanently, that phone must remain powered and within range. Using a second phone for setup is easier because the setup phone will switch between the internet, eveus-v2, and the EVEUS service AP.

Bring these items

the flashed and tested classic ESP32 DevKit;
a stable 5 V USB power supply, a data-capable USB cable, and a spare cable;
a non-metallic enclosure suitable for the parking environment, with strain relief and protection from condensation;
the third-party Wi-Fi credentials, the eveus-v2 password, and the EVEUS service-AP credentials;
a phone or laptop with an offline copy of this guide.

The ESP32 needs only USB power. Do not connect its pins to the charger, place it inside a mains compartment, or modify EVEUS wiring. Mains installation and weatherproofing must follow the charger's instructions and local electrical rules.

Parking installation sequence

At home, compile the firmware with the parking Wi-Fi credentials and MQTT settings, flash it over USB, and verify that eveus-v2 appears.
At the parking space, finish any charging session. Power the ESP32 from its USB supply and wait about one minute.
From the internet side, confirm that retained eveus/bridge/status is online, or that Home Assistant shows the bridge online. This proves the ESP32 can use the third-party Wi-Fi and reach the broker.
If the bridge stays offline, do not reconfigure EVEUS yet. Check the uplink SSID, password, 2.4 GHz coverage, DNS and outbound port 8883. A network with a browser login cannot be fixed by waiting.
Join eveus-v2 from the setup phone and choose to remain connected when it warns that the network has no internet. Open http://192.168.50.1/ and confirm the ESP32 status page loads.
Now connect the phone to the EVEUS service AP and configure the charger for eveus-v2 as described in the next section.
Reconnect to eveus-v2. Verify that EVEUS Private IP shows 192.168.50.x, then return the phone to mobile data or another internet connection.
Request a non-retained MQTT refresh and confirm fresh voltage/state telemetry in Home Assistant or your MQTT application. Do not use allow or a current change as the first connectivity test.
Power-cycle the ESP32 while the charger is idle and repeat the online, private-IP and refresh checks. Only then perform an agreed charging test at the permitted current.

Place and power the board

Mount the ESP32 where it has a usable signal to both the third-party access point and EVEUS. Keep its PCB antenna away from metal, cable bundles and the enclosure wall; do not put the antenna inside a closed metal cabinet. Close the final enclosure before the last signal and reboot test, because its position can change Wi-Fi performance.

Use continuous power: after an outage the ESP32 must restore its uplink, private AP, MQTT connection and EVEUS DHCP address without manual action. A lost uplink removes remote monitoring but does not guarantee that an active charging session stops.

Connect EVEUS to eveus-v2

Finish any charging session first. Power the ESP32, then connect a phone to the charger's service Wi-Fi. On the tested unit its name is tesla-eveus and its page is http://192.168.4.1/; confirm the details for your model.

Open Local WiFi configuration, select eveus-v2, enter the ESP32 AP password, leave Wi-Fi enabled, disable BSSID binding, and save. On the tested charger this setting is reached from the main page; requesting /config directly returns an error.

Reconnect the phone to eveus-v2 and open http://192.168.50.1/. The EVEUS Private IP diagnostic should change from blank to a 192.168.50.x address. The firmware then polls POST /main every 15 seconds. Moving the prepared pair to another site does not change this private link; only the ESP32 uplink credentials may need rebuilding.

What the bridge publishes

The ESPHome HTTP client captures the EVEUS JSON response and checks HTTP status before parsing it. The bridge exposes charger availability and state, voltage, current, power, current setpoint, session and lifetime energy, enclosure and plug temperatures, plus current and charging-inhibit controls.

The broker connection uses TLS on port 8883 with a CA trust anchor and hostname verification. ESPHome's MQTT component publishes discovery data and the entity states, while these stable application topics are useful to other clients:

eveus/bridge/status — retained online/offline birth and last will;
eveus/status/raw — fresh, non-retained JSON from /main;
eveus/command/refresh — publish refresh for an immediate poll;
eveus/command/current — an integer within the configured safe range;
eveus/command/charging — exactly allow or stop;
eveus/command/result — validation, HTTP or network result.

EVEUS uses inverted permission semantics: evseEnabled=1 inhibits charging and evseEnabled=0 allows it. The firmware hides that inversion behind stop/allow. A successful result means the local HTTP request succeeded; confirm the new state in fresh telemetry. Publish commands with retain=false so an old command cannot replay when the bridge reconnects.

Connect Home Assistant

Home Assistant does not connect to the ESP32 native API in this design. Both Home Assistant and the bridge connect independently to the same MQTT broker, so they can be on different networks.

In Home Assistant open Settings → Devices & services → Add integration → MQTT.
Enter the same broker hostname and TLS port, but preferably use a separate Home Assistant username and password.
Under the advanced certificate settings, keep broker certificate validation enabled. Use automatic trust for a publicly trusted certificate or upload the broker CA for a private certificate.
Leave MQTT Discovery enabled with the default homeassistant prefix.
Restart the ESP32 or wait for it to reconnect. The EVEUS Bridge device and its entities should appear automatically.

These steps follow Home Assistant's current MQTT integration and discovery documentation. MQTT client IDs must be unique. At the broker, allow the ESP32 to publish its eveus-bridge/#, telemetry, result and homeassistant/# discovery topics and to subscribe to command topics; allow Home Assistant to read discovery/state topics and write entity command topics. Use the broker's exact ACL syntax rather than copying a generic example blindly.

Verify without starting a charge

Confirm retained eveus/bridge/status = online.
Confirm the Home Assistant EVEUS Available entity is on.
Publish non-retained refresh to eveus/command/refresh.
Check that a new non-retained message arrives on eveus/status/raw and the Home Assistant measurements update.
Only after that, with the installation owner present and the correct current limits confirmed, test a control and verify the result in fresh telemetry and at the charger.

Troubleshooting

No eveus-v2 AP: check ESP32 power, antenna clearance and that the esp32dev build was flashed.
EVEUS Private IP stays blank: check the AP password saved in EVEUS and the configured charger MAC.
Private IP exists but EVEUS Available is off: inspect the local HTTP error and charger state; the bridge does not guess another client's address.
MQTT stays offline: check DNS, outbound TCP 8883, broker hostname, credentials, ACLs, CA chain and device time.
Home Assistant has no device: verify its MQTT integration uses the same broker and discovery prefix, then check that the ESP32 may publish homeassistant/#.
The AP briefly disconnects after changing uplink: AP and STA share a channel; reconnect after the ESP32 follows the uplink channel.

A lost broker connection removes remote visibility but does not itself stop an active charging session. Treat the bridge as monitoring and supervised control, not as a safety interlock.

Which ESP32 board should you use?

For this firmware, my first choice is a classic ESP32-DevKitC fitted with an ESP32-WROOM-32UE module and an external 2.4 GHz antenna. It keeps the same classic ESP32/ESP-IDF architecture while letting you place the antenna outside an enclosure or away from metal. Espressif lists WROOM-32UE as a supported ESP32-DevKitC module and documents its U.FL-compatible external-antenna connector in the ESP32-WROOM-32E/32UE datasheet.

Choose the 32UE external-antenna version, not the visually similar 32E version with a PCB antenna. The module is normally supplied without an antenna: use a suitable 2.4 GHz, 50 Ω U.FL/I-PEX antenna and keep its cable short. A good antenna position is usually more valuable than choosing a newer ESP32 chip. Because this bridge uses no GPIO connection to EVEUS, moving the existing configuration to another classic ESP32 DevKit is comparatively simple, but still compile and test the exact board before installation.

If Ethernet is available

The most robust redesign is an Olimex ESP32-POE-ISO-EA: it combines a classic ESP32-WROOM-32UE, an external antenna and galvanically isolated Power over Ethernet. Ethernet can carry MQTT and power while Wi-Fi is used only for the private EVEUS AP, removing dependence on the parking Wi-Fi for the uplink.

This is not a drop-in replacement for the downloadable firmware. It needs the board's Ethernet pin configuration, interface routing and new hardware testing. ESPHome documents simultaneous Ethernet and Wi-Fi through a network.priority list in its Ethernet and multi-interface networking references; that support arrived after the ESPHome 2026.6.5 version used by this snapshot, so upgrade and retest the whole bridge before choosing this route.

What I would avoid

Do not replace the current board only because another board is physically smaller. Enclosure position and antenna design matter more than PCB size.
Do not buy a tiny ESP32-C3 board as an assumed range upgrade. This source targets classic esp32dev, and a C3 requires a different build and fresh validation.
Avoid boards with an onboard antenna when they must sit inside a metal cabinet. Use an external-antenna model or move the entire non-metallic enclosure outside the RF shadow.
Avoid a loose ESP32 plus a separate Ethernet module connected with long Dupont wires in a permanent installation; use an integrated Ethernet/PoE board.

In short: keep the present classic DevKit if both links are reliable; choose a WROOM-32UE DevKit with an external antenna when Wi-Fi placement is the problem; choose an isolated Ethernet/PoE design only when a cable is available and you are ready to maintain a separate firmware variant.