ESPBridge

ESPBridge

Someone joins your server. Your ESP32 finds out before you check the tab list.

ESPBridge sends two things happening on your Minecraft server — a player joining
or leaving, and chat — to a small ESP32 device on your local network, so it can
show them on its own display. No account, no cloud service, no port forwarding:
your server and your ESP32 talk directly over your LAN.

How it works

1. Someone joins, leaves, or types in chat.
2. ESPBridge sends a short text — "Nik joined (3 online)",
   "Nik: hey" — as a small HTTP request to an address you configure.
3. Your ESP32 shows it. What it does with that text is up to your own ESP32
   firmware — ESPBridge only delivers it.

That’s the entire feature set. No rule engine, no config beyond one URL — you
get exactly two events and one action, deliberately, so this can be verified
end to end before anything more is added.

What gets sent

Delivered as POST <your-url> with Content-Type: application/json and body
{"text": "..."}.

Setup

1. Start the server once with the mod installed. It writes
   config/espbridge.json.
2. Set esp32Url to your device’s endpoint, e.g. http://192.168.1.50/event.
3. /espbridge reload.
4. /espbridge test hello world to check the connection without waiting for a
   real join or chat message.

Commands

/espbridge status · /espbridge reload · /espbridge test <text> — all
operator level 2.

Built with a live server in mind

• Never blocks the server thread. The HTTP call runs asynchronously.
• Requests are dropped, not queued or retried, if your device is
  unreachable — a message that arrives late is worse than one that never
  arrives.
• A rate limit (5 requests/second by default) protects a small ESP32 web
  server from a chat flood turning into a request flood.

Requirements

• Minecraft 1.21.11
• Fabric Loader with Fabric API
• Server-side only — no client install needed
• Your own ESP32 (or compatible microcontroller) running a web server that
  accepts the POST shape above; ESPBridge does not include or prescribe any
  particular firmware

Honest limitations

This is version 0.1.0, the first release. It has been run against a real
Fabric 1.21.11 dev server (starts cleanly, commands verified over RCON) and
its HTTP delivery has been verified end to end against a stand-in receiver,
rate limit included. What has not been verified is an actual player join,
leave or chat message triggering it — that needs a real client connecting,
which hasn’t happened yet. No real ESP32 hardware has received anything from
it either.

Only two events, on purpose. Deaths, boss kills, advancements and
inventory events are not in this release. The goal was to get one clean,
verified path from a game event to a physical display working first.

No retry or offline queue. If your ESP32 is off or unreachable, events are
silently dropped, not buffered for later.

The ESP32 side

A reference receiver sketch exists (WiFiManager setup portal, a status page,
POST /event parsed onto an SSD1306 OLED) and compiles clean against the
ESP32 toolchain. It has not been flashed to or run on real hardware yet.

Where it is going

• Flash and verify the reference firmware on real hardware
• More events, once join/leave/chat are proven solid against a real player connecting