How it works
A technical description for designers and tender participants. The numbers come from our own documents, not from a pitch deck.
Four layers and the override rule
This is the most important table in the whole system. It defines what must never move into software.
| Level | Where it runs | What belongs there | Why there |
|---|---|---|---|
| 1 | hardware, outside the controller | manual-reset safety thermostat, motor and surge protection, pressure relief damper, actuator spring return, fire damper | must work even when the controller does not |
| 2 | controller, on site | internal pressure and its emergency path, wind and snow response, CO and smoke, temperature cascade, start sequences, generator start, ventilation interlock | must work without internet |
| 3 | AERDOMA server | bookings, adaptive pre-heating, weather forecast, energy accounting, access rights, inspection records, notifications | needs outside data, is not time-critical |
| 4 | application | control screens, configuration, reports, customer bookings and tickets | the human |
The override rule: a lower number always overrides a higher one. The server can never allow something the controller has blocked, and the controller can never bypass the hardware path.
What we measure
| Path | Measured continuously |
|---|---|
| Supply | temperature, pressure, air velocity, humidity, CO concentration, smoke detection |
| Extract | temperature, pressure, air velocity, humidity, CO₂ concentration |
| Hall | membrane pressure — operating and emergency sensor, temperature, humidity |
| Outside | weather station: temperature, humidity, atmospheric pressure, wind, precipitation, solar radiation |
Plus the state of the unit: airflow pressure switch, the FAN / LIMIT / LIMIT2 thermostats, flue pressure switch, damper positions, protection devices and phase monitoring relay, motor thermal contact, drive status over Modbus, control power battery status, switchboard and plant room door contacts, lighting feedback, and the full status of the diesel generator including fuel level and running hours.
Control loops
-
Temperature — cascade
Hall temperature is the master loop, supply air temperature the slave. This prevents overshoot given the large thermal inertia of the hall. The temperature the customer paid for stays within the safety limits — checked in the cloud at booking and again in the controller.
-
Internal pressure
By fan speed and damper position. The emergency path on low pressure is hardware and does not depend on the control loop.
-
Wind and snow
Pressure and fan speed raised along a pressure/wind curve. Above the second wind threshold the system cancels bookings and calls for evacuation. The controller switches snow mode on by itself when the forecast reports snowfall, the outdoor temperature is below the threshold and the precipitation sensor is wet — all three at once. The forecast alone does not control the hall; for strong wind it only alerts the manager. Evacuation is triggered by a measured gust above the threshold — immediately, without averaging. The pressure/wind curve only ever raises the pressure, it never lowers it.
-
Lighting
Switched by sector through contactors, with feedback. No dimming — hall luminaires are switched by applying voltage and have no intensity control.
Entry by QR code
The controller does not verify a cryptographic signature. It holds a list of valid entries, which is both simpler and more robust.
- Every 24 hours — and on every change — the cloud sends the controller a list of hashes of valid tickets.
- The player holds the QR code to the reader at the door.
- The controller compares the hash against the list and checks the time window and the sector.
- If it matches and the hall is not in alarm, the lock gets a 3-second pulse.
- The event is logged locally and uploaded to the cloud at the next connection.
Permanent rights — manager, maintenance, service — stay on the list at all times, so staff can always get in. During a longer outage the validity of the last list is extended.
When the player has nothing to show the code on
Flat battery, broken screen, freezing weather. A PIN keypad does not solve it — the PIN would arrive by text message on the same dead phone.
-
Printed or photographed code
The code is an image, and the reader at the door does not care whether it sees it on a display or on paper. Anyone heading out into the cold, or aware of a weak battery, prints it beforehand.
-
A new code on another phone
The code exists nowhere else — the server holds only its fingerprint, so we cannot send the same one again. On another phone the player issues a new one, and the original stops being valid.
-
Opening from a distance
Planned
The operator unlocks from the application and the entry goes into the audit log: who opened, when and for whom. A phone number is on the door.
The hall has no staff, but the operator does exist. Players also usually arrive in twos — two dead phones at once are unlikely.
Interfaces
| Interface | Used for |
|---|---|
| MQTT / TLS | controller ↔ AERDOMA server, telemetry every 5 s |
| HTTPS + WebSocket | control screens served from the switchboard, no cloud needed |
| Modbus TCP / BACnet IP | exposing parameters to the customer building management system |
| Modbus RTU (RS485) | variable speed drives, electricity meter, weather station |
| Modbus TCP to the air handling panel | unit status and faults; writing only within the operator’s scope |
| HTTPS with the hall certificate | daily logs and the nightly controller backup to the AERDOMA server; the hall opens the connection |
| Front panel switches | local operation and manual mode, no display |
| SQL | archive of measured data |
Modbus TCP and BACnet IP are off by default and enabled only where the customer asks for them. When running, they are bound to the switchboard network.
Network and service access
There is always our router in the cabinet. Only what sits on its WAN side changes: our SIM card, or a cable into the customer network.
| Rule | Why |
|---|---|
| The tunnel is always initiated outbound by our router | the customer opens nothing and configures nothing |
| No inbound port | nothing that can be scanned from outside |
| The router does not bridge the customer network and our tunnel | we must not be a door from the internet into the customer network |
| A separate key per hall, /32 route | one hall cannot see the others |
| The tunnel is for service, not for data | operational traffic goes over MQTT; the tunnel is up only for diagnostics |
| The switchboard is its own network segment | if the customer network fails, the hall keeps running |
| Firmware is signed and updated in the night from Sunday to Monday, in the hall's local time, only when there is no booking before the end of the window | the controller accepts no foreign code and does not restart in the middle of a game |
| One signed release serves all halls of the same type; the hall’s identity is in its configuration, not in the firmware | an update reaches all halls at once and a hall never reports under someone else’s name |
| Once a day the controller sends its logs to our server and deletes them only after a verified write | we tune against real operation and the controller’s memory does not fill up |
| Every night the controller sends a backup, and when it does not arrive our service team gets in touch | a failed controller is replaced and restored from the backup |
I/O scope
Indicative, from the reference diagram. Exact counts depend on the number of sectors and air handling units.
| Configuration | DI | AI | DO | Buses |
|---|---|---|---|---|
| 1 air handling unit, 1 court | 46 | 17 | 13 | 4× Modbus RTU, 2× Ethernet |
| 2 air handling units | 73 | 30 | 34 | — |
The electricity meter, weather station and drives sit on Modbus RTU, not on physical inputs. Of the 46 DI, 13 are front panel switches and 13 are diesel generator monitoring.
Archiving
The archive and the live control screen are not the same thing. Mixing them means either a flooded database or an unusable control screen.
| Quantity | Interval |
|---|---|
| Live telemetry to the control screen | every 5 s |
| Temperature, humidity, pressure and air velocity — supply and extract | 15 min |
| Supply fan power, CO and CO₂ | 15 min |
| Outside temperature, humidity, atmospheric pressure, solar radiation | 60 min |
| Hall pressure and wind speed — for tuning the pressure/wind curve | 1 min |
| Phase voltages and mains frequency | 1 min |
| Wind speed and direction | on a change of 1 m/s |
| Precipitation | on occurrence |
| Alarm states and faults | on occurrence |
The controller
A freely programmable controller to IEC 61131. Configurable controllers running a manufacturer application are out of the question — adaptive pre-heating, booking logic and the energy model cannot be put into one.
The controller holds the safety and control logic. The control web interface, the archive, the MQTT bridge and the optional Modbus/BACnet server run on an industrial computer in the same switchboard. The split follows the layer table above.
Alarms
The catalogue has 29 entries across four priorities. Four critical ones shut down or evacuate and require a manual reset. The critical mains and wind gust alarms report and do not shut the hall down.
| Fault | System response | Priority |
|---|---|---|
| Low internal pressure | emergency path, evacuation, manual reset | critical |
| Smoke detected in supply air | immediate burner shutdown, evacuation | critical |
| CO in supply air above threshold | burner shutdown, full ventilation, evacuation | critical |
| Safety thermostat tripped | burner shut down in hardware, restart blocked, service record | critical |
| Wind above the second threshold | bookings cancelled, full pressure, evacuation | high |
| Measured wind gust above the evacuation threshold | instruction to clear the hall immediately, without averaging or waiting | critical |
| Mains failure | lights and heating off, air handling restarts step by step once voltage returns | critical |
| Undervoltage, overvoltage or frequency deviation | report naming the phase, the hall keeps running | critical |
| Loss of switchboard supply | diesel generator start | high |
| Flow / speed deviation | suspected broken belt or blocked filter | medium |
A selection from 29. The full catalogue is part of the datasheet.