Hardware and network requirements

The system is three things: a machine that sits in your network and thinks, a screen that shows, and a network that connects them. Here is what each one actually requires.

The server

The bridge is a Node process in the local network — an ordinary machine (a mini PC or a Raspberry Pi class board), not a cloud. It speaks HTTP and SSE on port 8787 (variable PORT) and listens on all interfaces. It has no external dependencies today and no database: the rules, scenes, rooms, profiles and integrations are JSON files, and the history is JSONL in HISTORY_DIR (by default bridge/history).

Disk space follows the sampling rate: 60 s (HISTORY_SAMPLE_MS) is 1440 rows per day, with retention of 7 days of raw samples · 31 days of log · 13 months of rollups. With many devices hourly.jsonl grows — that is the known remainder for which the own-database decision is still open.

The screen

A tablet with a modern browser, added to the home screen as a standalone app: a manifest with icons and display: standalone, and a service worker that keeps the shell. Kiosk mode runs as a fourth browser task (chrome --kiosk … or msedge --kiosk --edge-kiosk-type=fullscreen --no-first-run https://<kiosk-address>). Autostart and a watchdog are described for Windows Task Scheduler, Linux systemd (two services with Restart=always) and Android — the recipes are written down but have not been executed on real hardware.

Important: without HTTPS the service worker and the PWA install exist only on localhost or behind your own TLS terminator. For an offline shell on a tablet in the LAN you need both.

The network

• Client isolation (AP isolation) on the router — off, otherwise the kiosk cannot reach the server.
• The server address — a static IP or an internal DNS name; there is no automatic discovery of devices or servers in the LAN.
• The access points (Wi-Fi) and the devices on one L2 network; on a congested channel the SSE link drops and the status chip shows retrying.
• For Matter — IPv6 in the LAN and a free UDP port 5540 for the controller; without IPv6 the controller starts but never sees the node.
• For 2.4 GHz radio — a Zigbee channel different from the access point channel (for example 15/20/25 against 1/6/11), and the coordinator antenna away from USB 3.0 ports that noise the same band.

Variables that decide the behaviour

On the server: PORT, BASE_TOPIC, MQTT_URL (set → a real broker, missing → the simulator), MQTT_USER/MQTT_PASS, BRIDGE_TOKEN, CORS_ORIGIN, SIMULATE, HISTORY_DIR, HISTORY_SAMPLE_MS, HISTORY_RAW_DAYS, HISTORY_EVENT_DAYS, HISTORY_ROLLUP_MONTHS, AUTOMATIONS_FILE, SCENES_FILE, ROOMS_FILE, INTEGRATIONS_FILE, USERS_FILE, MATTER, MATTER_DEVICES_FILE, MATTER_STORAGE_DIR, MATTER_PORT, MATTER_SAMPLE_MS, KIOSK_ADMIN_PIN, KIOSK_USER_PIN, KIOSK_GUEST_PIN (the last three are used only when the profile file is created).

On the kiosk: VITE_HOME_DRIVER (mock or bridge), VITE_HOME_BRIDGE_URL, VITE_HOME_BRIDGE_TOKEN, VITE_KIOSK_SW. These are build-time: changing the server IP requires a rebuild — injecting them at runtime is a roadmap item, not a finished feature.

What we do not promise

• Specific device models. We publish no compatibility list we have not tested; the models of the inverter, the heat pump, the cameras and the KNX interface are confirmed during a site survey.
• Our own radio stack. The platform has no radio and does not plan one — 2.4 GHz, Z-Wave, 433 MHz, KNX, RS485/CAN come in only through a gateway, and there is no gateway yet (protocols).
• A voice assistant, a 3D floor plan, a dark theme, notifications outside the home.

For a practical view: how all of this is deployed on site is described step by step in the installer guide.