Mentivira Flows is the platform's automation engine, in development: you compose the rule on a visual canvas, and the engine is designed to run it on the gateway inside the building — including when the internet is down.
Product in development. The complete Mentivira solution will be available in 2028.
Mentivira Flows is a visual canvas editor: you drag activities from a palette, wire them together and build a rule. The version in our test environment holds 17 activities — the event trigger, branches and loops, reads from equipment, commands to equipment, notifications, an HTTP call. Conditions are assembled in a visual builder, from lists and fields.
There is no field where you type code. The condition builder produces a data structure, not an expression evaluated at run time, and the activity catalogue is closed: the engine interprets exactly the blocks the user placed. That is deliberate — an engine that evaluates user-written text would become an attack surface inside the building itself.
A rule is versioned. You work on a draft, run it in a test panel that shows step by step what would happen without commanding anything, then publish it; the published version becomes immutable, and every execution is journaled with its steps and its outcome. The editor is used from a computer; the phone app stays for operating and monitoring.
These figures describe the engine as implemented today and its design limits — not performance measured at a customer site, because we have no customers.
In a typical system, the automations are the ones the manufacturer foresaw. If you need logic nobody anticipated — a hotel sequence tied to the front desk, a heat-source priority specific to your installation, a store schedule with the display window switched separately — you join a waiting list for a future release, or you pay for development.
Flows is designed to move that authority to the customer. The building manager, or the partner who did the installation, will compose the rule, test it in the test panel and publish it — without going through us and without waiting for a release cycle. Logic built once for one building will be reusable on the next one as a starting point.
Authoring will be scoped, not open to everyone: flows will belong to one end customer, and the right to write them will be separate from the right to operate the building. A partner will see their own buildings and nothing else.
Illustrative examples, with example data. These are not real installations — they are the automations you build yourself, by dragging blocks and linking them.
The unoccupied room is the most expensive one in the building: fully conditioned, with lighting and the courtesy socket live, for nobody. At check-in, a symmetric flow prepares the room before the guest goes up.
The surplus goes to the grid at midday, cheaply, and in the evening the same energy is bought back expensively. Here the decision block is visible: two branches on the same threshold, with no line of code.
Lighting and climate set back across all public zones, through a single loop. Zones are defined once, at commissioning, and the same automation applies identically across every location in a chain.
Someone stays late. They press the ordinary wall switch, wired to a dry input, the zone comes back for a set interval, then sets back on its own. Nobody has to remember to switch it off.
The engine is designed to run on the gateway installed in the building. It will not be a reduced copy of logic that lives in a cloud, nor a narrow set of canned rules: it will be the same engine, with the same catalogue of 17 activities, packaged inside the gateway's system image.
The practical consequence is simple. If the connection drops, the rules will keep executing: time schedules, per-zone setback, large loads started on photovoltaic surplus, wall-switch overrides — all decided locally, on locally read data. What stops is remote access from outside the building, synchronisation with the platform and notifications sent outward; they will resume by themselves when the link is back.
The second effect is latency: the decision will not travel to a data centre and back. The design target for the local loop is under 200 ms from trigger to command. That is a target, not a figure measured at a customer site.
A no-code editor that can command electrical circuits has to be bounded by construction. These are the actual limits, not a marketing formulation.
At most 1000 steps and 30 seconds per run, a pause of at most 60 seconds, mandatorily bounded loops (at most 500 items per iteration, a declared maximum on conditional loops) and at most 10 HTTP calls per run. A badly composed rule stops and is journaled; it does not lock up the gateway and does not hold the building hostage.
Two rules commanding the same relay fight each other and produce exactly the behaviour nobody can explain. The system flags the conflict when a device is commanded from independent sources, and every binding has a minimum interval between commands. The design rule is simple: one actuator has one owner.
Flows can trigger one another through events, which means a careless composition could start a storm. An event chain is capped at depth 8, and a flow cannot call another flow deeper than 4 levels. When the cap is reached, execution stops and it shows up in the journal.
The HTTP activity starts with no permitted destination at all: each customer explicitly declares the addresses their flows may reach. On top of that sit protection against requests aimed at internal addresses, rate limits (at most 30 requests per minute per flow and 120 per customer) and a secrets vault — keys are never written into the flow and are masked in the journal.
Flows is a control layer, not a safety layer. The loops that installation integrity or human safety depend on will not execute in Flows, nor even on the gateway: they will execute in the firmware of the module in the wall, on local dry inputs, with no network component in the loop.
The reference case is the wood-burning fireplace boiler. If the water goes over the threshold, the module will start the circulation pump and open the valve through its own local logic — even if the gateway is off, the local network is down and the internet is gone. The same category covers pulse commands for gates and the hardware mutex between the two directions of a blind: to be applied in firmware, not through rules.
The separation is correct precisely because Flows can be rewritten by the user. A layer that changes with two clicks cannot at the same time be the layer safety rests on. And where a standard requires a mechanical element — the thermal discharge valve on the fireplace boiler — it remains mandatory and is not part of Mentivira. We do not present Mentivira as a certified safety system.
CE conformity and the cybersecurity requirement of the Radio Equipment Directive (RED, Art. 3.3, through the EN 18031 standards) are conformity objectives we are working towards, with a security dossier in progress — not certifications already held. When we obtain them, we will show them.
Rules do not call one another directly. They emit and listen for named events within the customer's own domain — which keeps automations independent and replaceable.
An event is a name you choose: pv.surplus.start, room.status.changed, schedule.closing. It can be emitted by a telemetry rule with a band and hysteresis, by a time rule, by the heat-demand evaluator or by another flow. Whoever listens need not know who emitted it, so you can replace the source without rewriting the consumers.
For simple cases you do not need a flow at all. You bind an event straight to an equipment command — pure configuration, with a source filter and a minimum interval between commands. This is the tier usable by someone who never opens the visual editor.
A state device is memory without hardware: no relay, no sensor, but a flow can write a value into it. The write goes down the normal telemetry path, so you get history, a chart and a dashboard widget with no extra work. This is where you keep the compressor's last start time, the expiry of an override, or the state you believe the building to be in.
The three examples above are spelled out so the mechanism is visible. In practice the list is open — here are scenarios the platform is designed to allow, the ones most often asked for by people who already have a building with ordinary wiring.
A sensor at the bottom of the stairs triggers step-by-step lighting in the direction of travel, then switches off behind. Two floors are usually 16–18 steps, so two low-side switching modules are used.
When the outside temperature drops below a threshold, unused zones are not switched off entirely but held at a minimum temperature. Protects the installation without heating empty rooms for nothing.
In summer, when irradiance is high and the room is already above its target, the blinds come down before the air conditioning starts. It is the cheapest form of cooling: it consumes nothing.
A flood sensor under the washing machine or in the plant room closes the solenoid valve on the main pipe and sends a notification. The valve is driven high-side, with the dedicated module.
A window contact stops heating in that zone only, not in the whole house, and resumes automatically when it closes. A banal idea, but impossible with a single thermostat for the whole building.
A carbon-dioxide probe on the analogue input starts ventilation when the concentration exceeds the threshold. Indoor environmental quality monitoring becomes a regulatory requirement for non-residential buildings upon transposition of Directive (EU) 2024/1275, whose deadline expired on 29 May 2026.
The modules are designed to measure current on every channel (a function still being designed). If a circuit draws outside its usual range you will get a notification — a heater left on, a pump running dry, a fridge that no longer cycles off.
The watering schedule is skipped if the rain sensor was active in the last few hours. Irrigation solenoids are driven by the same module as the heating valves.
The gate command is issued as a fixed-duration pulse, configured per channel in firmware, and an end switch confirms it actually opened. If it does not confirm, you get a notification instead of an unnoticed jammed gate.
While you are away, lighting and blinds repeat a pattern close to the usual one, with variation, instead of the fixed schedule that is immediately recognisable from the street.
The engine and the visual editor are built and demonstrated in our development environment: the 17-activity catalogue, the execution limits, the test panel, the run journal, named events, direct bindings and virtual state devices. Mentivira is not commercially launched, is not in production and has no customers; nothing you read here is presented as an installation at a customer site.
The complete Mentivira solution will be available in 2028.
We keep measurements and estimates strictly apart. Measured directly: radio coverage of −95 dBm through three reinforced-concrete floors, in a maximum-sensitivity configuration on development boards; 72 hours of continuous operation with 17,698 frames and zero integrity errors; about 405 days of battery life on the wireless thermostats. Estimated: the 15–25% reduction in wasted energy, which depends on the building and is to be confirmed in the pilot programme.
Estimated: the 15–25% energy saving is an estimate, dependent on the building's profile, to be confirmed by measurement in the pilot programme. We do not guarantee it. We would rather say what we have not yet proven than lose the right to be believed once we have the figures.
The complete Mentivira solution will be available in 2028. Leave an address and you get a single e-mail, at launch.
No marketing, no sold lists. One e-mail, at launch.
The address is used only to notify you at launch, by ZYONARA SRL. You can withdraw it at any time by writing to [email protected]. Details in the privacy policy.