Runs standalone
The room's whole logic — components, blocks, scenes — executes on the device. No external box has to be alive for a guest to dim the lights.
Room automation firmware
NOESIS
by Roomio
Room automation firmware,
engineered like an operating system.
Noesis turns one controller into the room's brain: hardware I/O and field buses become clean software components, function blocks give them reflexes — with custom JavaScript when the built-ins are not enough — and everything is scriptable over a clean RPC API.
0+protocol stacks
0I/O channels under control
0expansion card drivers
0independent Modbus engines
0multi-function AD I/O ports
0%local autonomy, cloud or not
The runtime
Native on ESP32-C5.
Online or off.
Every room runs its full logic on the device and links up to Roomio's cloud GRMS for property-wide control. The cloud makes the whole estate manageable from one screen; the edge keeps each room running even when the link is gone.
One image, the whole room.
Noesis is a single ESP-IDF firmware build. The C5's dual-band radio keeps the web UI, the API and the cloud uplink responsive even in crowded hotel RF; BLE handles first-boot onboarding from a phone; and the silicon's 802.15.4 radio runs Zigbee today, with Thread and Matter in reach.
- RISC-V core240 MHz
- Wi-Fi 62.4 + 5 GHz
- Bluetooth 5 LEOnboarding
- Zigbee 3.0Native 802.15.4
- Secure boot+ flash encryption
- OTAA/B partitions
Edge + cloud
Cut the uplink. The room doesn't notice.
Roomio cloud GRMSConnectedRoom 214WelcomeRunning
Room 215NightRunning
Room 216Eco · UnsoldRunning
Event journal0buffered
Roomio cloud GRMS
Every controller links up to Roomio's Guest Room Management System: property-wide dashboards, PMS integration, remote config and fleet OTA from one screen.
Fails safe
If the gateway or uplink dies, the room keeps running on local logic and last-synced config — then reconnects and back-fills the event journal when the link returns.
Connectivity
One firmware,
every protocol
in the wall.
Onboard media come up out of the box. Expansion cards are detected at boot and their protocol stacks load as native components — same image, no reflash, no special build.
Onboard
Ethernet
The wired backbone: web UI, RPC, MQTT and Modbus TCP served over one cable, with the radio as fallback.
Wi-Fi 6
Dual-band with WPA3. The 5 GHz side keeps management traffic smooth where 2.4 GHz is a battlefield.
2× RS-485
Two independent buses with their own polling engines and power supply.
Zigbee 3.0
Coordinator on the C5's native 802.15.4 radio — no card needed. Battery sensors and remotes join as input components.
Expansion cards
> boot
Architecture
Layered like
the glass it is
drawn in.
Every capability is a module with a contract. Higher layers only ever talk to the contract below them — which is why a Modbus fan coil, a DALI ballast and an onboard relay all feel identical from a scene, a script or the API.
- Components are contracts
Every relay, input, dimmer or Modbus register block implements the same interface: typed config, live status, events, and its own RPC namespace.
- Blocks compose components
Function blocks subscribe to component events and drive component outputs. They never touch hardware directly, so logic survives hardware changes.
- Scenes orchestrate blocks
One trigger, many coordinated changes. Scenes are declarative data — diffable, exportable, and safe to hand to non-programmers.
- Interfaces are generated
Because every module self-describes, the web UI and the API surface appear automatically for anything you add — including store imports.
05Interfacesweb ui · rpc · mqtt
04Sceneswelcome · night · eco
03Function blockslogic · custom js
02Componentsrelay · adio · modbus
01Hardware & busesesp32-c5 · rs-485 · cards
Components
Hardware,
abstracted honestly.
Each I/O group and each bus device is its own component: isolated, self-describing, individually configurable — and addressable over the API as type:id.
Function blocks
Reflexes,
packaged.
A function block bundles components with behavior: inputs, outputs, parameters, state. Install one from the store, wire it in the flow editor — or write your own, in JavaScript.
CurtainControl
Up/down interlock, travel-time calibration, tilt steps and group commands. Exposes the Cover.* RPC namespace.
in: input:0,1out: relay:2,3
DoNotDisturb
Keycard and switch state drive the corridor DND light, mute the doorbell and flag the room to the PMS over API or MQTT.
in: input:dndout: relay:led, mqtt
MakeUpRoom
Guest requests housekeeping from the bedside; the flag clears at the door and every transition lands in the event log.
in: input:murout: relay:led, event
FanCoilThermostat
Hysteresis or PI control of valve plus 3-speed fan, from any temperature source — an NTC on AD I/O or a Modbus FCU register.
in: adio:5out: relay:0,1 analogout:0
PresenceLogic
Fuses keycard holder, door contact and PIR into one occupancy truth that scenes, HVAC and the minibar can rely on.
in: input:*, adio:*out: sys.occupancy
EnergyGuard
Watches a Modbus energy meter, sheds noncritical loads on threshold, and journals consumption per stay.
in: modbus:meterout: relay:*, event
Script blocks:
bring your own logic.
When a built-in block is not enough, write one. Script blocks run sandboxed on-device with CPU and memory budgets, subscribe to any event on the bus, call any RPC method, and keep state in a persistent key-value store. Publish yours to the store as a signed package when it is good.
sandboxed vmcpu + mem budgetspersistent kvstore-publishable
Scenes
One trigger,
the whole room.
Scenes are named room states. They call components and function blocks in one coordinated move — and because they are data, staff can edit them in the web UI without touching logic.
Scene.ActivateWelcome42 ms
Triggered by
wall switch / keycardschedule + astro clockScene.Activateanother function blockMQTT / PMS
Flow editor
Wire it
visually.
The configurator embeds Svelte Flow: drag components and blocks onto the canvas, connect ports, hit deploy. The graph compiles to the exact same primitives the API drives.
@xyflow/svelte · drag the nodes · swipe to pan · live values ride the wires
Dynamic Modbus
Any device.
No firmware update.
Modbus devices are described, not hardcoded. An electronic datasheet — a signed JSON register map — teaches Noesis a new device at runtime.
- 1Import the datasheet
From the store, from a vendor file, or from a colleague's export. Versioned and signed.
- 2Registers become a component
Typed values with scaling, units, enums and poll groups. Writable registers become RPC setters with validation.
- 3UI and API appear
Tiles show up in the web UI, a
modbus:<name>namespace opens on the API, and changes publish as events. - *.edd.jsonsigned + versionedhot-mounted at runtime
| name | fn | addr | type | scale | unit | live |
|---|
Point-and-click register mapping with live read preview from the connected bus — then export, reuse across rooms, and share.
The store
Install capabilities,
not firmware.
Modbus datasheets and function blocks are packages: signed, versioned, one-click importable from the built-in store — or side-loaded from a file on air-gapped sites.
Configuration
A real app,
served from flash.
The whole configurator is a Svelte single-page app living on the device: components, blocks, flows, Modbus, store and system — live over WebSocket at http://noesis.local.
relay:0 · set by scene:welcomeCeiling light
analogout:1 · ramp 800 msDim zone 1 72%
block:dnd · idleDo Not Disturb
modbus:fcu_12 / t_roomRoom temperature22.4°C
block:curtain · position 100%Curtain
sys.occupancy · PresenceLogicOccupancyguest
Illustrative mockup — not a final UI design.
Svelte SPA — nothing to installlive values over WebSocketrole-based accessworks on the room LAN, offline
RPC API
An API you
already know.
Every component and block exposes methods in its own namespace — callable over HTTP GET, JSON-RPC 2.0 on WebSocket, or MQTT. Status changes push to every connected client as NotifyStatus frames — no polling, ever.
Sys.*Relay.*AnalogOut.*Input.*ADIO.*Cover.*Thermostat.*Scene.*Block.*Modbus.*Schedule.*Store.*
digest authper-role scopesTLS optionalrate-limited
Platform services
The parts you notice
when they are missing.
Schedules + astro
Cron-style timers plus sunrise / sunset from the site's coordinates.
OTA updates
A/B partitions, staged rollout, automatic rollback on a bad boot.
Security
Per-user roles, digest auth, optional TLS, signed store packages.
Backup / restore
The whole room — config, blocks, scenes, datasheets — one JSON export.
Event journal
Ring-buffered log of inputs, RPC calls and block decisions, filterable per component.
MQTT + Home Assistant
Native MQTT client with HA discovery: every component announces itself.
BLE onboarding
First-boot provisioning from a phone: network, room name, admin key.
Watchdog + metrics
Heap, latency and bus-health counters; the supervisor restarts what misbehaves.
Summary
The whole picture.
- Firmware
- Noesis — single ESP-IDF image, edge-first
- Platform
- ESP32-C5: RISC-V @ 240 MHz, Wi-Fi 6 dual-band 2.4 + 5 GHz, Bluetooth 5 LE, native 802.15.4 (Zigbee)
- Networking
- Ethernet, Wi-Fi 6, Modbus TCP, MQTT, mDNS (noesis.local), Roomio cloud GRMS uplink
- Field buses
- 2× RS-485 Modbus RTU, onboard Zigbee 3.0 (native 802.15.4) — expansion cards: KNX TP, DALI / DALI-2, RF 433 / 868 MHz
- Physical I/O
- 4× relay, 4× 0–10 V output, 4× digital input, 8× multi-function AD I/O (analog in / digital in / digital out per port)
- Software model
- Components, function blocks, scenes on an event bus — supervised, isolated, self-describing
- Extensibility
- Custom JavaScript script blocks (sandboxed), electronic Modbus datasheets, signed store packages
- Configuration
- Svelte SPA served on-device, Svelte Flow visual editor, register-map builder with live preview
- API
- RPC API over HTTP / WebSocket (JSON-RPC 2.0) / MQTT, NotifyStatus + NotifyEvent push
- Operations
- A/B OTA, backup / restore, schedules + astro clock, event journal, roles + optional TLS, offline-resilient (survives uplink loss)
- Cloud
- Roomio GRMS — property-wide dashboards, PMS integration, remote config and fleet OTA; each room keeps running locally if the uplink is lost
Put Noesis
in your next room.
Integrators get firmware access, datasheet tooling and store publishing through the Roomio Partner Portal. Operators get a demo room wired to their PMS.
Concept preview. Functionality and specifications subject to change.