A companion, room server, or repeater-role board — none of them with a LoRa radio of their own — that tethers to a Trifecta repeater over ESP‑NOW or a direct encrypted IP link instead of a second LoRa hop. It can't work on its own — it always needs a paired repeater running the bridge — but that's the point: you already decided where that repeater goes, this is how everything else reaches it.
Three real setups this covers:
No mesh in the area yet. Put one Trifecta repeater somewhere with real coverage, then add companions and a room server over ESP‑NOW without buying a second LoRa radio for each one.
You already have a repeater on the roof. A LoRa companion in the basement doesn't need a real RF hop just to reach it ten feet through a floor — that's airtime spent for no reason. WiFi already reaches; let it.
A companion or room server that isn't anywhere near its repeater's WiFi — a different building, a different network entirely — can skip ESP‑NOW and connect straight over IP instead, the same TLS‑PSK link a repeater-to-repeater IP bridge uses. Anywhere that board's WiFi reaches the repeater's address is enough.
The honest concern with any kind of bridging: does it let traffic behave worse than it would over real RF? Two things specifically address that for ESP‑NOW:
Local and ESP‑NOW-bridged traffic both funnel through the same duty-cycle-based transmit budget on the host repeater's real radio. Nothing bypasses it by arriving over ESP‑NOW.
Broadcast-domain controls already in MeshCore (region/transport-code scoping) sit in the same receive pipeline whether a packet arrived over LoRa or over ESP‑NOW. An operator can turn the bridge into a hard broadcast boundary with existing CLI config alone — nothing new to learn.
A Sidecar has no LoRa radio at all, so it never has to choose between RF and IP the way a repeater's own IP bridge does. That mechanism — and what it costs when it gets that choice wrong — is covered on the Trifecta overview instead.
A Trifecta repeater running its ESP‑NOW and IP bridges together already has real network time from NTP. It shares that time with anything tethered to it automatically, so a Sidecar board with no other time source — no LoRa adverts to pull a timestamp from, no battery-backed clock — doesn't drift to a bogus default. Nothing to configure.
Ready to attach a companion, room server, or second repeater?
Setup & config →