Hi everyone,
I'm currently redesigning part of my home automation stack and I'm running into an architectural question related to REST API design, authentication boundaries, and distributed message flows between FHEM nodes.
Setup looks like this:
- Main FHEM instance running on a Raspberry Pi 5 (Debian Bookworm, Perl 5.36)
- Secondary automation layer on a Pi Zero W doing lightweight event preprocessing
- A custom REST API endpoint exposed via a Python microservice (uvicorn / FastAPI)
- MQTT bridging between both Pis, with FHEM subscribing to upstream processed topics
- Some devices running ESPHome publishing events directly into the same namespace
The part I'm unsure about is the best practice for securing the API endpoint when the request origin may vary (local LAN, remote workflow triggers, or internal FHEM modules).
I've been reading about different authentication strategies (header-based tokens, asymmetric signatures, short-lived session keys, pre-shared HMAC tokens injected at the edge), and I'm trying to understand what makes most sense when:
- FHEM acts as both consumer and event generator
- The API needs to differentiate automation-triggered calls from user-triggered calls
- The traffic is mostly local but should still follow proper isolation rules
- A fallback mechanism is needed when the preprocessing Pi becomes unreachable
- The workflow must remain consistent even if FHEM rebuilds the event queue
I found a technical explanation of REST fundamentals that helped clarify the stateless flow and the way headers should be structured for modular systems:
https://networklessons.com/cisco/ccna-200-301/introduction-to-rest-api
https://networklessons.com/network-automation/rest-api-authentication
https://pingmynetwork.com/network/ccna-200-301/rest-api
https://en.wikipedia.org/wiki/REST
Before I over-engineer the whole thing, I'd like to know what other FHEM users do when they expose REST endpoints beside the core FHEM modules.
Thanks in advance
Dorian
Hi,
I am a bit confused as to how exactly the data flows in your setup and which service is running on which device/which device needs to access which other device (or service/endpoint).
Could you maybe provide a step-by-step example on
- how the endpoint you are trying to secure is interacted with, and,
- afterwards, what data flows to which point?
Don't make this theoretical, just take something your endpoint is actually used for (e.g. receiving temperature readings from some sensor).
Also, as you already seem to have noticed, this doesn't really relate to FHEM, but rather (only) to the Python microservice (feel free to correct me if I got this wrong).
So basically you can do whatever you want, as long as the devices using the endpoint are able to handle the auth implementation you choose. Tbh I wouldn't necessarily overcomplicate this and just use something already available within the microservice's stack that is also supported by your clients.
Thanks, here's a concrete example to make the flow clearer.
Pi Zero receives a raw temperature reading → normalizes it → publishes to MQTT → FHEM picks it up and triggers a POST to the FastAPI endpoint to persist the updated state. In parallel, some ESPHome nodes may hit the same endpoint directly when the preprocessing layer is unavailable.
What I'm evaluating now is whether a rotating HMAC per node (salted at deploy time) gives better isolation than a static bearer token, especially during situations where FHEM rebuilds its event queue or when the Zero drops out and traffic patterns shift. The goal is to keep the API stateless but still differentiate automation-triggered updates from user-initiated calls without overengineering the whole thing.