How it works

Open the box.

Two small Linux containers on your Pi, plus a thin proxy on ours. Below is everything that happens between a Bluetooth packet hitting your antenna and the upstream network receiving it.

The data path.

A BLE device broadcasts. Your gateway hears it, along with whatever other gateways are in range. Whichever gateway forwards the packet first earns the discovery bounty when the bounty program ships. Four hops, three machines, none of them ours except the middle one.

1

BLE device

A tag, an asset tracker, an industrial sensor. The firmware broadcasts an encrypted packet over standard Bluetooth Low Energy.

2

Your gateway

The worker container scans the radio every few seconds, captures any matching packet in range, and POSTs it to us. The ui container is the dashboard you see at port 8080.

3

EE proxy

We check the packet against your EE token, log it for future bounty accounting, and forward it to the right upstream network (Hubble Network today). The encrypted payload never opens.

4

Upstream network

The network's positioning engine combines your packet with thousands of others from satellites and other gateways to fix the device's location.

What runs on your hardware.

worker Scans Bluetooth, queues packets to a local SQLite database, drains the queue to encryptedenergy.com on a one-second poll, and sends a periodic heartbeat so your dashboard says "Active". Runs on the host network because Bluetooth radios live there. No public port.
ui The setup wizard and dashboard at localhost:8080. Reads the worker's status file. Never touches Bluetooth, never makes outbound calls. Pure local read-only dashboard.

What runs on our hardware.

A small Rails service at encryptedenergy.com/api/v1/gateways/*. It checks incoming packets against your EE token, logs activity for your dashboard, attributes each forwarded packet to your gateway for future bounty accounting, and forwards to the right upstream network using our wholesale relationship there. We don't decrypt the packet payload, ever. We can't: the encryption key belongs to the device's owner, not to us.

What you need.

A Pi running Umbrel. Pi 5 recommended. Pi 4 works. The same Umbrel that's hosting your Bitcoin and Lightning node is perfect. The gateway uses about 2 watts idle. Multi-arch images mean an x86 mini-PC running Umbrel works too; the BLE radio just has to be reachable through BlueZ.
Outbound HTTPS. The worker makes outbound calls to encryptedenergy.com. That's the only network requirement. No port forwarding, no public IP, no static address.
Optional: a USB GPS dongle. About $25 for a u-blox-based dongle (GlobalSat BU-353-S4 is the safe pick). Without one, your gateway forwards packets tagged with a placeholder coordinate. With one, every packet carries the live GPS fix from the moment your radio heard it. This becomes the default in a future release.

What you don't need.

  • · An account with the upstream network. We hold the wholesale relationship.
  • · Port forwarding or a public IP. All traffic's outbound HTTPS.
  • · A static address. Your gateway's identified by its EE token, not its IP.
  • · Payment. Free at signup, free forever (see pricing).
  • · A lawyer. The whole thing's GPL-3.0; read every line if you want.

Security, briefly.

Your Pi exposes no public port. The dashboard sits behind Umbrel's reverse proxy and is reachable only on your LAN. Tokens are per-gateway and revocable in one click from your account. If a Pi walks off, revoke its token and the gateway's dead to us within one heartbeat cycle. The entire source for both containers is GPL-3.0 at github.com/Encrypted-Energy/gateway.

Ten minutes from here to forwarding.