Skip to content
Dan Roberts edited this page Jan 16, 2026 · 1 revision

FAQ

Why not connect to the BedJet over BLE directly?

This bridge intentionally offloads BLE complexity to BedJetWebSchedule.

Benefits:

  • BLE stack and BedJet protocol live in one place
  • the bridge stays small: Matter + HTTP + parsing
  • easier to deploy multiple bridges or move controllers around without reworking BLE

If you want a single-device BLE + Matter solution, you can merge the BedJet BLE client into this firmware—at the cost of RAM, flash, and complexity.

Do I need two ESP32s?

Typically yes:

  • one ESP32 runs BedJetWebSchedule (BLE -> HTTP)
  • one ESP32 runs this Matter bridge (Matter -> HTTP)

You can run BedJetWebSchedule on another platform if it provides the same HTTP endpoints.

What happens if BedJetWebSchedule is down?

  • The bridge will fail to poll /api/state and will not update Matter values.
  • Commands will fail because the HTTP POST requests won’t succeed.

Why does the bridge print the pairing code repeatedly?

When not commissioned, the bridge prints the manual pairing code periodically so you don’t need to reboot or dig through earlier serial logs.

What ports are used?

  • Matter stack: uses standard Matter networking on your LAN
  • Status page: HTTP port 80 on the bridge
  • BedJetWebSchedule: whatever port it’s running on (default HTTP)

Can I expose this to the internet?

You can, but you shouldn’t.

  • No auth on the setup/status endpoints
  • commands are plain HTTP

If you want remote access, use a secure overlay (VPN) and proper segmentation.

Clone this wiki locally