Whitepaper · Blippa × Shelly
How Blippa turns a QR scan and a successful Swish or Stripe payment into a physical action – a sauna that heats up on schedule, a door that unlocks – using off-the-shelf Shelly relays, door sensors and Igloohome smart locks, with every device managed centrally.
Pay-per-use saunas on the Norwegian coast and coin-free harbour toilets in Torekov, Sweden – both driven by the same Blippa payment and device-control engine.
Whitepaper · Blippa × Shelly
Blippa is best known as Rexidy’s Digital Product Passport platform: every physical object gets a QR code, and every scan resolves to live data and services. This whitepaper describes a second, increasingly common use of the same platform – letting a scan and a payment operate the object itself.
The building block that makes this possible is the Shelly family of Wi‑Fi relays. A Shelly device is a small, inexpensive, CE‑marked switch that sits in a junction box or behind a wall plate and can open or close a circuit – a control input on a sauna heater, the coil of an electric strike, or, where appropriate, a mains load. Modern (Gen 2 and later) Shelly devices also run user scripts, read digital inputs such as door contacts, and expose a well-documented RPC interface over HTTP, WebSocket, MQTT and the Shelly Cloud. With LoRa add-on modules they also work where there is no Wi‑Fi. Blippa uses all of these.
The result is a pattern we call payment-triggered actuation: the guest scans, pays with Swish or a card via Stripe, and Blippa translates the confirmed payment into a controlled electrical action with the operator’s safety, timing and access rules. Two live deployments illustrate it.
Coastal saunas that switch on after payment, refuse to start while the door is open, pre-heat automatically ahead of a booking, and issue guests a time-limited door code through Igloohome. Shelly scripts are pushed from Blippa, so a fleet of saunas is managed from one screen.
Harbour toilets in Torekov on the Swedish west coast, where a successful Swish or Stripe payment makes Blippa signal the Shelly device at the door, which closes the circuit that releases the electric strike. No coin mechanisms, no keys, full revenue transparency.
Section 3 explains the architecture that is shared by every Blippa–Shelly deployment: the Blippa tag, the payment layer, the control engine, the transport to the device, and the script that runs on the relay.
Sections 4 and 5 walk through the sauna case in detail – the door-sensor interlock, the pre-heat scheduler, the Igloohome code flow and fleet-wide script distribution.
Section 6 covers the toilet case, deliberately simpler: the minimum viable deployment.
Sections 7 and 8 discuss safety, security and offline behaviour, and how to get a first installation running. The paper is written for facility owners, integrators and technically minded operators; no programming background is required.
Unattended assets – saunas, toilets, showers, charging points, lockers – are only profitable when payment, access and equipment control work without staff on site. Blippa makes the QR code the single point of contact for all three; Shelly makes the last metre to the equipment cheap and standard.
Whitepaper · Blippa × Shelly
Every deployment follows the same five-layer chain. Understanding it once makes each case easy to reason about.
Each asset carries a Blippa QR code. The QR code can also be in the GS1 Digital Link format, if required. Scanning it opens a mobile web page served by Blippa – the same page family used for product passports – that shows the asset, its price and its availability. The tag is the identity of the asset in every later step; a sauna, a toilet door and a Shelly relay are linked to it in the Blippa registry.
Blippa integrates natively with Swish for Nordic mobile payments and with Stripe for cards, Apple Pay and Google Pay. Both providers confirm the payment to Blippa server-side through signed webhooks. Only a webhook-confirmed payment can trigger a device action; the guest’s browser never talks to the relay.
The control engine holds the device registry, the rule set per asset (what to switch, for how long, under which conditions) and the schedules (bookings, pre-heat windows, opening hours). It is also where Shelly scripts are stored, versioned and distributed.
Whitepaper · Blippa × Shelly
Blippa connects to the devices exclusively through the Shelly Cloud. There is no VPN, no port forwarding, no local broker and no router configuration at the site, which makes setup remarkably easy: the Shelly device only needs Wi‑Fi and the operator’s Shelly account. Because the devices keep a persistent MQTT connection to the Shelly Cloud, commands reach them very fast – typically well under a second. Blippa takes care of the complicated part of the communication: authentication, command formatting, retries and interpreting the events that come back.
A third option has opened up with Shelly’s LoRa add-on modules: only one Shelly device at the site needs Wi‑Fi access; fitted with the LoRa module it acts as gateway, and the other Shelly devices talk to it over long-range, low-power radio with no network connection of their own. This makes the Blippa–Shelly solution usable in places where reliable Wi‑Fi is rare – boat harbours, piers, bathing jetties and remote saunas – with one connected gateway serving several assets hundreds of metres apart. The device script and the door interlock work exactly as before; only the last hop changes.
Gen 2+ Shelly devices (Shelly Plus 1, Plus 1PM, Pro series, Plus Add-on) run scripts in a small JavaScript-like runtime on the device itself. Blippa uses this to push down a script that owns the local logic: timers, input handling and fail-safe behaviour. The cloud sends intent – “grant 60 minutes of heating for booking 4711” – and the device script decides exactly when the relay closes the heater’s start input. This split is what makes the door interlock in the sauna case reliable.
| Concern | Handled by | Why |
|---|---|---|
| Was the payment real? | Blippa | Only webhook-confirmed Swish/Stripe payments count. The relay is never exposed to the guest. |
| How long, and at what time? | Blippa | Bookings, prices and pre-heat windows are business rules and belong in the cloud. |
| Is it safe to switch now? | Shelly script | Door contact, maximum run-time and overheating cut-off must work even if the network drops. |
| What actually happened? | Both | The device reports switch state and input events; Blippa stores them against the booking. |
Whitepaper · Blippa × Shelly
In Blippa, a Shelly script is a configuration block attached to the asset, not something typed into the device’s own web interface. The block names the device, the script and its code, whether it should start at boot, and any device settings that must be applied alongside it. The screenshot below is taken from a live sauna configuration.
The visible constants show the design: a fallback re-check every minute (also covering the wait for NTP time after boot), a maximum hold time used only if the timer fields are missing, an optional Blippa webhook for notifications, and a pendingEnd timestamp persisted in the device’s key–value store so that a session survives a reboot. Guards such as selfAction and resuming keep the script from reacting to switch events it caused itself.
The device configuration lines matter as much as the code. Switch.SetConfig puts the relay input in detached mode with initial state off and no auto-on/off, so the door contact can never switch the heater directly and the relay always comes up off after a power cut. Input.SetConfig declares the input as a switch-type contact. Blippa applies these with the script, so a replacement device is configured identically.
Whitepaper · Blippa × Shelly
Self-service saunas are a fast-growing business along the Norwegian coast: unstaffed, at the water’s edge, and used in two modes – drop-in, where a guest pays for the next hour, and booked, where the sauna must be warm on arrival.
The heater runs only for paid time; revenue is reconciled in Blippa.
Starting the heater with the door open wastes energy and is a safety issue. No start until the door is closed.
Booked guests expect 80 °C on arrival, not a cold room and a 45-minute wait.
No key handover; codes are unique per booking and expire afterwards.
A Shelly Plus 1 (or Pro 1) is wired to the remote-start signal input of the sauna heater’s own control unit – the same dry-contact input a wall switch or timer would use. Blippa does not switch the heater’s mains supply: the controller keeps its thermostat and over-temperature protection, and the Shelly only tells it when it may run. (Switching the supply directly is possible but less secure, and not recommended.) A magnetic door contact goes to the Shelly input and an Igloohome keypad lock on the door. No PLC, no local server, no payment terminal.
When Blippa grants heating time, the device script checks the door contact. If the door is closed the relay closes immediately; if it is open, the grant is parked and the guest’s phone shows “Close the sauna door to start heating.” The moment the contact closes, the script signals the heater and the paid time begins to count. The guest is never charged for time with the door open before the session, and the interlock works even if the sauna loses its internet connection.
Whitepaper · Blippa × Shelly
A booking in Blippa – made on the sauna’s own Blippa page, or received from a third-party booking system through the API – carries a start time, a duration and a payment reference. From these, the control engine derives a pre-heat window for the specific sauna.
Each sauna has a configured warm-up profile: how many minutes it needs from cold to target temperature, and how much shorter that is when the room is still warm from a previous session. Blippa schedules a grant so that the heater starts at booking start minus warm-up time, and lets it run through the booked slot. The door interlock still applies during pre-heat; if the previous guest left the door open, the heater will wait, and Blippa alerts the operator that the pre-heat is at risk.
Because the Shelly reports every change of its relay and inputs, Blippa knows that the start signal was actually given and when the door was last opened. Where the sauna controller offers a ready or fault output, it can be wired to a second Shelly input so that a heater that failed to start produces an alert before the guest arrives, not a complaint afterwards. Back-to-back bookings are merged into one continuous run so the heater is not cycled unnecessarily.
Igloohome locks generate time-bound PIN codes algorithmically, so a code can be issued through Igloohome’s API without the lock being online – ideal for a timber sauna on a pier. Blippa requests a code for each confirmed booking or drop-in payment, valid from the start (with a small grace period) until shortly after the end. Drop-in guests get a code that works immediately; staff and cleaning codes are managed from the same screen.
Payment confirmed. Swish or Stripe webhook reaches Blippa; the booking moves to paid.
Code requested. Blippa calls Igloohome with the lock ID and the validity window; a unique PIN is returned and stored against the booking.
Guest informed. The PIN appears on the guest’s phone the moment the payment clears and again in the confirmation message; no app installation is needed.
Heater scheduled. In parallel, the pre-heat grant is scheduled for the sauna’s Shelly device.
Everything expires together. When the slot ends, the relay switches off and the PIN stops working. A no-show is handled without any staff action.
Whitepaper · Blippa × Shelly
A single sauna can be set up by hand. Ten saunas across three municipalities cannot – not if every change to the door logic or the maximum run-time has to be applied on ten devices through ten web interfaces. Blippa treats the Shelly script as configuration that belongs to the asset, not to the device.
Rexidy maintains the script templates. For each asset, Blippa holds the parameters that differ – which input the door contact is on, the maximum run-time, the warm-up profile, how the start signal is wired – and renders the final script for that device. Deployment uses the standard Shelly Script.Create, Script.PutCode and Script.Start calls through the Shelly Cloud, with the script set to start automatically on boot.
Every deployed script version is recorded against the device, together with who deployed it and when. An operator can see at a glance which saunas run which version, roll a change out to a test sauna first, and then to the rest of the fleet.
When a Shelly unit is replaced, the technician pairs the new device with the asset by scanning the sauna’s Blippa code with the Blippa installer view. Blippa pushes the script and parameters to the new device, verifies the door input, and the sauna is back in service. No configuration lives only on the hardware.
The same dashboard used in Rexidy Fleet Management shows every sauna: online status, relay state, door state, next booking, script version and open alerts. Alerts are raised for devices offline, start signals not acknowledged, doors left open, and pre-heats that could not start in time.
| Per-asset parameter | Example | Purpose |
|---|---|---|
| Door input | input:0 | Which Shelly input the door contact is wired to; inverted logic supported. |
| Maximum run-time | 180 min | Hard ceiling enforced on the device, independent of the cloud. |
| Warm-up profile | 45 / 20 min | Minutes from cold / from warm; drives the pre-heat schedule. |
| Start signal | dry contact | How the relay is wired to the heater controller’s remote-start input (dry contact or low-voltage signal). |
| Transport | cloud | Wi‑Fi to the Shelly Cloud, or LoRa via a gateway Shelly for sites without Wi‑Fi. |
| Lock | IGK3-… | Igloohome lock ID for code generation. |
Adding an eleventh sauna is a fifteen-minute job: wire the Shelly and door contact, scan the sauna’s Blippa code in installer mode, choose the parameters, deploy. Pricing, booking rules and door codes are inherited from the operator’s existing setup.
Whitepaper · Blippa × Shelly
Paid public toilets have traditionally meant coin mechanisms, cash collection rounds and vandalism. At the harbour of Torekovs Båtsällskap in Torekov, on the Swedish west coast, the Blippa–Shelly version removes all three: a QR code on the door, a Swish or card payment, and an electric lock that releases for a few seconds when the payment is confirmed.
The Shelly relay (a Shelly Plus 1 is sufficient) is wired in series with the electric strike or maglock’s control circuit. Blippa sends a Switch.Set command with toggle_after set to the configured pulse length, typically three to eight seconds. The relay closes, the lock releases, and the relay opens again on its own – even if the network drops mid-pulse. A fail-secure strike stays locked on power loss; a fail-safe maglock can be chosen where fire regulations require it.
The Blippa page opened by the scan (Figure 6) shows the price, a Swish button and a card option backed by Stripe, in the visitor’s language. Only when Blippa receives the provider’s signed confirmation is the pulse sent.
Every opening is a transaction in Blippa with time, amount, provider and door, giving exact usage statistics per facility and per hour. Free access can be granted with a staff code or for specific groups by the same rules engine. A door that has not been opened for an unusually long time, or a Shelly that has gone offline, raises an alert in the fleet dashboard before a visitor reports a problem.
The same pattern serves showers, boat-club shore power and storage lockers – anywhere a small switching action follows a small payment. Changing the price or opening the door free of charge during an event is a Blippa setting; nothing changes on site.
Whitepaper · Blippa × Shelly
Shelly devices are CE-marked and installed by a licensed electrician like any other relay. In the sauna case the Shelly is connected to the heater controller’s signal input, not to its power supply: the controller’s thermostat, over-temperature cut-out and element sequencing remain fully in charge, and Blippa can only permit or withhold a start. Switching the heater’s mains supply instead is possible but bypasses those protections; Rexidy does not recommend it.
The rules that matter for safety – door interlock, maximum run-time, automatic switch-off – run on the device and do not depend on Blippa being reachable. If the cloud connection drops during a session, the sauna finishes its paid time and switches off on its own; if it drops before a session, the guest is told the sauna is temporarily unavailable rather than being charged for nothing.
Swish and Stripe confirm payments through signed server-to-server webhooks that Blippa verifies before any action. A refund before a sauna session automatically cancels the pre-heat grant and the door code.
Igloohome PINs are unique per booking, valid only for their window, stored encrypted and shown only to the paying guest. Staff and cleaning codes are managed separately and logged.
Commands travel over TLS to the Shelly Cloud, and from there over the device’s encrypted MQTT session. Devices are never exposed to the internet, the guest’s phone never addresses a device, and device credentials live in Blippa’s secrets store, not in the script.
Blippa stores only the transaction, the asset and the device events; guests are identified by payment reference, not by name. Data is held in the EU (AWS eu-north-1) under Rexidy’s information-security policies.
| Situation | Behaviour |
|---|---|
| Door opened mid-session (sauna) | Heater keeps running; only the start is interlocked. A long open-door period raises an operator alert. |
| Internet lost during session | Device script completes the session and switches off on time; events are delivered when the connection returns. |
| Internet lost before payment | Blippa shows “temporarily unavailable”; no payment is taken. |
| Power cut at the site | Relay opens (fail-secure). On restore the script autostarts and Blippa re-sends any grant still in its window. |
| Start signal given but heater does not run | Where a ready/fault output is wired back, Blippa alerts the operator and offers the guest a refund path. |
| Device replaced | Installer scans the asset’s Blippa code; the script and parameters are pushed to the new unit. |
Whitepaper · Blippa × Shelly
A first installation – one toilet door or one sauna – is typically live within a week of the decision, most of it waiting for the electrician.
Define the asset in Blippa. Name, location, price model (per use, per hour, bookable), opening hours and the payment providers to offer. Blippa generates the QR code and the guest page.
Install the hardware. Shelly relay on the circuit, door contact on the input where required, Igloohome lock on the door for bookable assets. Rexidy supplies a wiring note per asset type.
Pair and deploy. Scan the asset’s Blippa code in installer mode, select the device, set the parameters. Blippa pushes the script and runs a self-test: relay pulse, input read-back, power reading.
Test a payment. Rexidy provides test modes for Swish and Stripe so the full chain can be exercised without charging anyone.
Go live and scale. Print the QR sign, open the asset, and repeat step 2–3 for the next one. Reporting, alerts and script updates are fleet-wide from day one.
Guest pages, payments, rules, schedules, device registry, script distribution, reporting and API/MCP access.
Gen 2+ relays: Plus 1, Pro 1, Plus Add-on for extra inputs and probes, LoRa add-on for sites without Wi‑Fi.
Keypad and deadbolt locks with offline algorithmic PIN codes, issued by Blippa per booking.
Nordic mobile payment and international cards, wallets, all confirmed by signed webhooks.
The combination of Blippa and Shelly turns an unattended asset into a self-service business with a very short list of parts. The QR code carries identity and payment; the cloud carries rules and schedules; the relay carries the safety-critical last step. The sauna case shows how far this can be taken; the toilet case shows how little is needed to begin. Both run on the same platform, so operators can start simple and add sophistication asset by asset.
We are happy to walk through your site, propose the hardware and set up a pilot asset in Blippa – typically a single door or sauna – so you can test the full flow before rolling out.