myIO – User manual

⤓ Save as PDF In the print dialog, choose “Save as PDF” as the destination. The PDF contains what is shown now (according to the 4.x switch).

This manual explains how to use the web interface of the myIO smart-home controller. myIO is a standalone (cloud-independent) controller: it handles relay outputs, dimmers, push-button inputs, temperature and humidity sensors, with timers, a thermostat function and external integrations (Shelly, BroadLink, another myIO). Everything is configured on the built-in web page – no internet connection or installed software is needed.

Contents

1. Basic concepts

In myIO every controllable thing is an element with its own identifier (ID):

You can give elements a name (description) – the interface shows only named elements, unnamed ones stay hidden. So the first step is always to name the outputs and inputs you use on the settings pages.

2. Login, permissions

You reach the controller from a browser at its IP address (e.g. http://192.168.1.50) or by its network name (e.g. http://myio-nappali.local). The browser asks for a user name and password.

2/A. Installing on the phone home screen

iPhone / iPad (Safari): open the controller in Safari (it also works with an http://… address), log in, then tap the Share icon → Add to Home Screen. A myIO icon with the device name is placed on the home screen, and it opens like an app, full screen (without the address bar). On an unencrypted (http) connection this is the recommended way – iOS does not need https for it.

Android: Chrome rewrites the typed address to https, which the controller does not speak. Solutions: the myIO mobile app (recommended), or Firefox with an http:// address, or in Chrome turn off the Privacy and security → Always use secure connections switch (if needed, also go to chrome://flags and disable HTTPS-First Mode and HTTPS Upgrades). An installable (PWA) version over http is not possible on Android – that would need an https proxy in front of the controller.

3. The menu bar

The same two-row menu bar appears at the top of every settings page. The pages are arranged into four group menus: Control (Outputs, Logic outputs, Input, Groups, Sensors), Link (myIO, Shelly, Broadlink), Apps (Timer, eManager, Dictionary, Files, System diagnostics) and System (General, Network, Users, Log). On older (3.x) controllers the 4.x-only pages do not appear in the menus. On a narrow (mobile) display the menu bar switches to a single row: Auto + Refresh on the left, the Home icon in the middle, the ☰ menu on the right — the menu holds the switches, the four groups and saving. The home page has a simpler row: Refresh, Booster, Home / Chart / Settings buttons, Log Out and the Theme list (home page themes).

4. Help mode

After you turn on the ?Help checkbox in the menu bar:

• Hover (mouse over the element): a bubble shows a short explanation of what the button/field does.
• Click: this manual opens at the relevant chapter.
• In Help mode a click does not execute the function (it does not switch a relay or change a setting) – except the Help checkbox itself, which turns the mode off.

4/A. Setup wizard 3.12+

The wizard guides you through setting up the controller: it asks, you answer, and at the end it shows what it is going to write – it touches nothing until you approve. Start it with the Wizard button in the menu bar. On a new, not yet configured controller it offers itself automatically.

At the bottom of every step it tells you where the same can be set manually – so along the way you also learn the interface. The wizard does not replace the settings pages: it sets up what is most common; fine-tuning stays on the respective page.

The ten chapters

The order is deliberate: every chapter builds on what the previous one named. Any chapter can be started on its own and stopped at any time – settings already written are kept.

Preview, backup

The wizard writes nothing along the way. At the end of the chapter it shows a summary: what it changes, from what, to what. Clicking a row takes you back to the question that produced it, and by removing the tick you can skip individual rows. Before writing – if there is a free slot – it saves the current settings to a separate slot named Before wizard, so you can return to them at any time on the Load page.

Whatever the wizard finds needs no change, it does not write at all: if you run the same chapter twice with the same answers, the second time there is nothing left to do.

Output discovery – “what is connected to this?”

If you don't know which number is which load, the wizard switches on the selected output and asks what you see (it can also blink it if you are watching from further away). Before that, however, it asks – and this is not a formality:

• Is it OK to switch outputs now?
• Is there anything that must not be switched on?
• If so: do you know for sure which one it is?

If any answer is no or uncertain, the wizard switches nothing – you choose from a list. It always skips alarm-flag and just-ON (pulse, typically gate) outputs, and lists which ones it skipped. The switched-on output turns off by itself if you don't touch it, and also when you close the wizard.

Input learning – “press it and I'll recognise it”

In the input chapter you don't need to know the switch number: press it on the wall, and the wizard shows which one it was. This is harmless – the wizard only watches, it switches nothing.

On newer firmware (3.12.7+ / 4.3.12+) it reads the live state of the digital inputs (sens_IO.json): the list continuously shows which input is currently closed, and the state change is the recognition. Since this is a state and not an event, the 2-second polling can miss a very brief button press – that's why the wizard asks you to press and hold the switch. With a (bistable) switch this happens naturally.

On older firmware it shows the input that triggered most recently. Which path it takes is not decided by the version number but by trying: if the controller does not provide the live state, the wizard switches over by itself – so it also works correctly when the inputs are not visible due to permissions.

For the selected switch, all three events can then be set in separate sections: short press (hit), long press (press) and release. The target can be an output, a group or loading a saved state – with a search by name. A section you don't touch stays unchanged; the “Nothing” item clears an existing event. At the end of the chapter you can also turn on the NC contact and Block (shutter stop).

Condition outputs – the “if…then” of myIO

The controller has no rule editor, but it has something that can do the same: a logic output that is not physically wired, switched by a sensor. This is the flag.

The flag becomes a block through a protection pair: the first member of the pair is the flag, the second is the output to be blocked, and with priority turned on the flag wins. As long as the flag is on, the blocked output cannot stay on.

What you should know: protection switches off afterwards, so on the first attempt the blocked output may flash on for a moment; during the cooldown further attempts do not even start. Good for blocking, but it is not “never even tries” semantics.

Example: “The garden lights may only switch on after dark” → create a “Daylight” flag and block the garden lighting relay with it. Likewise: a “Floor is warm” flag blocks the underfloor heating circuit so that it does not overheat.

What the wizard does not do

• It does not delete or rename existing settings without your knowledge – it writes only what appears in the summary.
• You edit timers and network settings on their own pages; the wizard sends you there, and you continue there.
• Managing users and permissions requires admin rights.
• It does not replace the settings pages: the less common fields (delay, invert, mixer, fade) are available there.

4/B. Links panel (right-click)

On a settings page, right-click any row (on a phone, use a long press) to open the Links panel. It answers the question you ask most often while configuring: “what is connected to this element?” – without having to browse through three pages for it.

The panel is available on the Output, Dimmer, Input and Groups pages. On the name, number and drop-down fields the browser's own menu is kept (copy/paste) – to open the panel, right-click anywhere else in the row.

What it lists

On an input the real question is usually not what it switches – that is right there in the row – but whether anything reaches it from outside. That's why on an input the panel lists the Shelly link first: the settings table does not show it, because it lives on another page.

Clicking any row of the list takes you to the referenced setting and highlights that row for a few seconds – so from a group or a protection pair you get with one click to the place where you can edit it.

Quick actions

• ON / OFF: switches the output immediately, for testing. It only switches – it does not change any setting.
• Blink: the output toggles back and forth a few times so that you can see on site which device it is; at the end it returns to the state it started from. The quickest way to check wiring and to name things.
• Name + Save: rename without leaving the panel; the same as the Name field of the table.

4/C. Assistant: Tutor mode and Tour 3.12+

5. Home page – switching

The home page (Home) is where everyday use happens: here you see the named relays, dimmers, groups and the current values of the sensors.

• Relay: click its button to switch it on/off. The button colour shows the state.
• Dimmer (output): set the brightness with a slider or a percentage value; the on/off button switches to the set minimum/maximum level.
• Group: one button switches all members (how it works: chapter 12).
• Sensors: temperature, humidity, consumption – display only.

If you only have read permission for an element, you see its state but cannot switch it.

Home page themes (Theme list)

The Theme list in the home page menu bar (on mobile: in the ☰ menu) selects the look of the home page. The choice is remembered by the browser (separately per browser / device) – it does not touch the controller's settings.

6. Charts (Chart)

The Chart page shows daily charts of the logged sensor values (temperature, humidity, consumption, energy meter). Use the date picker to call up earlier days. The logging interval can be set in the settings; without an SD card the controller logs less often to spare the internal storage (chapter 25).

7. Relay outputs (Output page)

The Output page has one row per relay, with the following settings:

7/A. Finder Opta controller – own relays and inputs 4.5+ (Opta)

On a Finder Opta controller two pages get a separate section:

• Output page – “Opta relays (R1–R3)”: the first three logic relays also switch the controller's own relays (green R1–R3 badge in the row). The fourth own relay (R4) is the READY relay: the system's heartbeat, it cannot be controlled. The remaining logic relays are virtual – they can be used for expander outputs, flow, protections and joiners, just like on the other controllers.
• Sensors page – “Opta I1–I8”: the controller's eight own analog inputs (0–10 V). The live V column shows the measured voltage; with the Active tick the input feeds the matching uSensor (1–8) with a ×10 value (7.5 V → 75), so it can be logged and used in a thermostat and in flow. This is also the way to connect a dry contact: the threshold condition provides the switching signal.

On Opta the wall-switch range belongs entirely to the RS485 expanders (see chapter 20/C): the inputs of the expander with address 1 = switches 1–16.

Front-panel LEDs and the USER button 4.6.1+ (Opta)

• The LED next to the reset button – power indicator: lights continuously from the very first moment the firmware starts. If it is dark, the controller has no power (or the firmware did not even start).
• The LED above the USER button – heartbeat: lights continuously during boot; afterwards its blink pattern shows the state (READY is still indicated by relay R4 and LED4 above it):
  • slow blinking (1 Hz) – running, has an IP address (on LAN, or 4.18.12+ as a WiFi client too), all expanders reachable;
  • fast blinking (5 Hz) – no IP address on LAN nor as a WiFi client (also shown in service-AP mode);
  • double flash every second – an RS485 expander that was already seen during operation has been lost;
  • triple flash – recovery boot (see below);
  • 2.5 Hz blinking while the button is held (after 1 s), then very fast blinking – the long press has been accepted, a restart follows.
• USER button, short press (shorter than 1 s): software restart.
• USER button, held for 5 s: resets the network settings (LAN DHCP + the slot's fixed-IP fallback, WiFi off, default hostname/mDNS) and the users (admin / admin) to defaults, then restarts – for when the IP address or the password has been lost. A Button,LONG-NETRESET line is written to the event log. The serial btnlock command disables/enables this (EEPROM 45); when disabled, the button only logs after 5 s.
• USER button held at boot (3 s, fast blinking meanwhile, then release it): recovery boot – the configuration is not loaded, the outputs and the READY relay stay off, only the network and the built-in /forcefm file manager run (every page redirects there). Use it to repair a damaged configuration or web tree; afterwards use Restart or a short button press. Bootloader mode still requires a double press of the small recessed RST button, not the USER button.

8. Thermostat (sensor activator)

Any relay (and output/PWM output) can be switched automatically based on a sensor value. In the output's row, select the sensor (activator), then enter the ON threshold and the OFF threshold:

• Heating: ON threshold lower than the OFF threshold → the output switches on when the value drops below the ON threshold, and switches off above the OFF threshold. Example: ON=21.0 °C, OFF=22.0 °C.
• Cooling / alarm: ON threshold higher than the OFF threshold → the output switches on above the threshold. Example: ON=28.0 °C, OFF=26.0 °C (fan).

The activator can be: thermometer, humidity sensor, consumption meter, energy meter (SDM) data, sunrise/sunset (the output switches tied to the time of day; an offset can also be set), as well as a universal sensor (activator ID = 300 + sensor ID, chapter 16) 4.x.

On the output pages, uSensors appear in a separate uSensor group of the sensor list; enter the ON/OFF thresholds in the sensor's own unit 4.3+. On the FET mixer and on ON-OFF outputs, uSensor works from version 4.4+ onwards.

Mixer mode – for outputs and PWM outputs: the output does not switch on/off; instead, depending on the sensor value, it settles continuously between the MIN and MAX levels (e.g. mixing valve, stepless fan speed control).

9. Protection (interlock)

Protection makes two outputs mutually exclusive: the two members of the pair can never be on at the same time. Typical uses are shutters (up/down motor direction) and pump/valve pairs.

• Priority: when enabled, on a conflict the first member of the pair always stays on and the other one switches off. Without priority, both switch off on a conflict.
• Cooldown: after the protection intervenes, re-on requests of the losing side are dropped for a few seconds (default 10 s) – so the relay does not “chatter” when the control is faulty.

10. Joiner (follower)

The joiner links one output to another: when element “A” switches on, “B” switches on too; when “A” switches off, so does “B”. Typical example: zone valve → boiler start, or extractor fan → damper.

Follow-ON only (Hold): “B” follows only the switch-on, not the switch-off – for example, the pump's after-run is ended by its own timer.

11. Outputs (dimmers)

On the Outputs page you set up the dimmable (PCA9685) channels. A channel can work in two ways:

• PWM (dimmer) mode – with the PWM checkbox: the channel can be adjusted steplessly between 0–100 % (LED strip, fan).
• On/off mode (without the PWM checkbox): the channel behaves as a plain switch, jumping between the MIN (off) and MAX (on) levels.

12. Groups (Groups page)

A group lets you control several outputs (relays, dimmers, even another group) together. On the Groups page, name the group and select its members.

• Group button on the main page (toggle): if all members are on → it switches everything off; otherwise it also switches on the members that are still off.
• Pull Up mode: if some members are already on, the button switches on the rest (it does not switch off) – for “all lights on” type use.
• Hold (Just ON) members stay on when the group is switched off.
• Staggered switch-on: the members switch on one after another, every 30 ms – this is intentional, to spare the power supply (with a large group a short “ripple” is visible).

13. Inputs (Input page)

Watch buttons 3.12.7+: with the small switch at the left edge of the “Input Settings” header, the page polls the inputs every second: the row of a held input is highlighted live, and the last pressed one stays highlighted, without refreshing – so you can check the wiring by pressing the wall buttons (it catches short presses too). The switch position is kept in the browser; if the controller does not provide the states (old firmware or no permission), the page indicates this and stops.

On the Input page you assign the wall push buttons/switches to the outputs. An input can distinguish three kinds of events:

A separate target can be assigned to each of the three events: relay, dimmer, fade, group or scene (slot load). There is no double-click.

• Enabled: switches the input off/on (e.g. during maintenance).
• NC (normally closed): for switches with inverted contacts.
• Timer cancel (hit block): if the timer of the long press (press) target is running, a short press (hit) stops it – and in this case the hit's own event does not run. Typical use: the long press starts the “Shutter UP” group with a timer, and the short press stops the shutter while it is moving, without also switching on the light bound to the hit. The target can be a relay, an output or a fading output; with a group, too, only the stop happens, as it should 4.3.9+ (previously the group stopped, but the hit event also ran).
• Time limits: the short/long press threshold (ms) is set in common for all inputs (hit and press limit).

13/A. Pixel LED strips (Ledstrip page) 4.3.4+

The humidity sensor connectors on pins D26–D33 can be reconfigured as digital LED strip (WS2812) outputs – a pin is EITHER a DHT sensor OR an LED strip. The pin mode is stored in EEPROM and takes effect after a restart; all other settings apply live. The maximum number of strips and LEDs depends on the device (DLEDQ / DLEDMAX factory setting). The driver is DMA-based: a running effect does not slow down the controller or the response time of the buttons.

Connector numbering: both the UI and the event ID follow the order of the board's connectors (IO1..IO8); the processor pin mapping: IO1=D32, IO2=D33, IO3=D30, IO4=D31, IO5=D28, IO6=D29, IO7=D26, IO8=D27. The ID formula: 3100 + (IO−1)×100 + program – so 3101 = program 1 of the IO1 strip, 3800 = full OFF of the IO8 strip.

• Programs: a program = running effect (fire, rainbow, wipe-in light, disco, strobe…) + its parameters (color, speed, brightness, palette…) + segment + transitions + name. There are 32 programs, and each can be played on any strip. The parameter controls are generated from the effect descriptor, so a new firmware effect appears in the UI automatically. The chase block size and direction, the twinkle decay, and the fire's flame height and placement (segment start/end/both ends) can also be set.
• Phases: playback has three phases – turn-on (e.g. the fire ignites), run (it burns), turn-off (it goes out: turn-on reversed, fade-out, instant, or another program). Transition times can be set in 0.1 s steps.
• Zones: the program runs on its segment (from–to LED). Programs with separate segments run side by side – e.g. the kitchen and living-room sections of a long strip can be switched separately. Starting a program on an overlapping segment replaces the old program; Strip OFF (program=0) stops everything.
• Control from an input: on the Inputs page, under the “Ledstrip” element type, you select a strip+program pair; the event ID formula is 3100 + (IO−1)×100 + program. The same ID alternates ON/OFF (toggle). It can be called from a timer the same way.
• Saving: the settings are saved to the root ledstrip.jsn file (floppy menu – not into a slot); the pin mode is saved by the separate Apply button (EEPROM + restart).

13/A/1. Games on the strip 4.5+

There are five built-in game effects that turn the strip into a game played with wall push buttons: 1D Pong (2 players: left/right paddle button), Reaction duel (2 players: after the flash in the middle the faster one wins, pressing early is a fault), Cyclone (1 player: stop the bouncing light dot inside the shrinking target zone), Twang dungeon (1 player: a 1D dungeon played with forward/backward/fire buttons – enemies, lava fields, levels) and Color snake (1 player: with the red/green/blue buttons, shoot the head of the approaching snake with a projectile matching its color – a wrong color sticks).

• Button teaching: when you select the game program, the game's roles appear on the Programs panel (e.g. “Left player”, “Fire”). Click Teach, and the next wall button press assigns that switch to the role (10 s window); × clears it.
• Button capture: while the game is running, the taught buttons control only the game – the normal event assigned to them (light, shutter…) does not run, and the button presses do not flood the log/MQTT either. When the game stops, the buttons immediately get their normal function back. After 5 minutes of inactivity the game stops by itself (the buttons are released even if someone left the game running).
• Start/stop: the same as for any program – with the Test button, with the event ID (3100 + (IO−1)×100 + program) or from a timer. Several games can run at once on several strips/segments (e.g. in two rooms), each with its own taught buttons.
• Parameters: tunable with the usual controls – Speed = game speed, Intensity = difficulty/acceleration, Length/size = paddle/target zone/attack size, Color 1/2 = the players' colors. After starting, the strip “breathes” in waiting (attract) mode, and pressing any taught button starts the round.

14. Timers (Timer page)

On the Timer page you create calendar schedules. A schedule consists of:

• Date: month + day (“–” / “all” means: every month / every day).
• Days of the week: can be narrowed with checkboxes (e.g. weekdays only).
• Time: hour:minute – or sunrise/sunset: the controller calculates the time daily from the astronomical sunrise/sunset (the geographic location must be set on the General page).
  Offset 4.3.8: in sunrise/sunset mode the hour and minute fields no longer give the absolute time, but the offset relative to the sun event, together with the after / before selector next to them: before starts the schedule this much before the sun event, after this much after it. The offset can be at most 4 hours – in sun mode the drop-downs are narrowed to this, and at 4 hours the minute can only be 0 –, so no meaningless value can be set. Sunrise/sunset schedules created earlier keep running with 0 offset, i.e. unchanged.
• Event + target: what to do – relay/dimmer/group ON or OFF, or load a scene.

Below the list you can see when the next scheduled event is due. The time is synchronized via NTP (an internet time server); its status is shown on the General page.

Time zone and automatic daylight saving time 3.12.35+ / 4.18.9+

On the General page, below the Time Zone row, there is the Automatic daylight saving time (EU) checkbox – on by default. When on, the time zone is the standard (winter) offset (Central Europe: 1), and the controller adds the summer hour by the EU rule: on the last Sunday of March at 02:00 the clock jumps to 03:00, on the last Sunday of October at 03:00 it goes back to 02:00 (both moments are 01:00 UTC). The change takes effect at once: the clock, sunrise/sunset and the next timer are recalculated, and a System,DST,<0|1>,tz=<offset> line is written to the event log. Next to the checkbox you can see whether summer or standard time is in force and the effective offset (e.g. UTC+2).

• Off keeps the old behaviour: the time zone is the full offset and has to be changed by hand in summer (1 → 2). If the EU ever abolishes the clock change, just untick the box.
• After the update, check the time zone: if you had set 2 by hand for the summer, set it back to 1 and save – otherwise it would be UTC+3 in summer. In winter, UTC+1 must be shown next to the box.
• Changing the time zone now adjusts the clock immediately (earlier only at the next time sync), and a manually set date/time is taken as the correct local time.
• In October, timers between 02:00 and 03:00 run twice (the clock goes back); in March, the timers of the skipped hour do not run.

Week view

At the top of the page you can switch views with the List / Week view tabs. The week view shows all timers on the week's 7×24-hour grid: a green block border marks an ON event, a red one an OFF event; a dashed border marks a date-bound row; the ⚠ sign marks a conflict (ON and OFF on the same output within 15 minutes). Today's column is highlighted, and the horizontal line is the current time. Sunrise/sunset timers appear in a separate ☀ lane (the exact minute is calculated daily by the controller), and rows without hour/minute (“all” / “–”) in the strip below the grid. Click any block to edit it in a side panel – saving works the same as in the list. The browser remembers the selected view. On a narrow display, day-selector buttons show the grid one day at a time.

The week view always shows the next 7 days: each column is a specific date (shown when you hover over the header), so timers that are due only later – for example, bound to a given month – appear only in the List view until then (a line below the grid shows how many there are). A row without weekday ticks and with “–” month and day runs every day – the controller and the week view interpret this identically. If several events fall at nearly the same time, they are merged into an “N×” stack block (its caption scrolls like a ticker) – click the stack to choose from a list which one you want to edit. Between an ON event and its matching OFF event, a faint colored band shows from when to when the output will be on – even if the switch-off falls on the next day (the band flows over into the next column at midnight). Right-click an empty part of the grid – or use the New Event button – to create a new timer with that day and time; here you can also choose a duration: then the matching switch-off is created automatically (on the next day if it ends after midnight). The editor dialog opens modally, in the middle of the page. The purple, “F”-marked blocks are the time and sunrise/sunset triggers of the Flow rule engine 4.4+ – they are read-only here; clicking one opens the Flow page.

14/A. Flow – rule engine (Flow page) 4.4+

Flow is automation built from cards: WHEN (trigger) / AND (conditions) / THEN (actions). Example: “When it is morning AND it is cold AND the sun is shining, raise the living-room shutter group.” The rules are run by the controller itself (without a browser or the cloud); the configuration is stored in the root flows.jsn file – it can be saved/copied with the file manager. Division of labor: plain weekly scheduling is the job of the Timer; Flow is for conditional logic. At most 64 flows, with up to 8 AND conditions and 16 actions per flow.

• Cards: the WHEN column holds a single edge-triggered trigger (sensor threshold with hysteresis, sensor compare, output change, time of day, sunrise/sunset, variable, system boot); every level condition in the AND column (sensor, sensor compare, output state, time window, variable) must be true; the actions of the THEN column (relay, group, output/FET dimmer, delay, variable, log, header notification) are executed in order. There is no OR – for that, use two separate flows.
• Sensor compare: the relation of two live sensor values instead of a fixed threshold – e.g. “if the supply temperature is lower than the return temperature”. The Δ offset is added to sensor B (“A > B + 5°” – a classic differential thermostat, e.g. for a solar collector pump), and here too the hysteresis is the re-arm band. If either sensor value is invalid (STALE/missing), the card does not pass.
• Edge triggering: the trigger fires once at the crossing, and does not fire again until the value moves back across the hysteresis band – so a sensor fluctuating around the threshold does not keep switching.
• Delay: the action chain pauses at the Delay card, then continues. While the chain is running, new triggers of the flow are dropped (this is visible in the trace).
• Variables: 32 shared integer variables for state between flows (e.g. away mode); on restart they reset to their initial values.
• Trace: a live list at the bottom of the page shows when which flow fired (or did not fire) and why – which condition failed, which actions ran. Indispensable for debugging automations.
• Webhook 4.4.1+: an outgoing HTTP call as an action – e.g. sent to a self-hosted ntfy instance, it becomes an instant push notification on your phone. The targets (up to 8: name, GET/POST, URL, message template) must be added in the Webhook targets section below the flow list; a target marked ⚠ also fires by itself on ERROR-level log entries. In the message you can use the $dev, $flow, $val, $msg placeholders; the result (HTTP code or error) is visible in the trace.
• Presence simulation 4.24+: while you are away, it switches the selected lights as if you were at home – no alarm panel needed. Up to 4 profiles can be added in the Presence simulation section below the flow list, each with up to 8 outputs (relay, logic output, output, group). There are two modes: random – an evening window (starts around sunset, ends around the configured bedtime ± spread, with different times every day) and an optional weekday morning window; a light stays on for 10–60 minutes, pauses for 5–90 minutes, at most 2 are on at once, and when the last one goes out another one comes on; at the end of the window they go out one by one, 1–5 minutes apart; learned – while the profile is not running, the controller records when you switch the profile's lights by hand, and while you are away it replays the pattern of the same weekday with a ±15-minute shift (on a day without a recorded pattern the random mode runs; it takes a week until every day is covered).
  Starting: in the profile editor the Trigger flows button writes the two flows: switching an unwired “Away” logic output (app tile, wall button) ON starts it, switching it OFF stops it; with an alarm panel, arming away the partition sensor of the SIA receiver starts it and disarming stops it. In flows the Presence simulation card starts/stops/toggles in the THEN column and is a condition (running or not) in the AND column.
  Rules: on stop only the outputs the simulation switched on are switched off; if someone switches a simulated output by hand while it runs, that output is left alone until the stop; after a power cut the simulation resumes and the trigger output is switched back on as well. Add only lights you switch by hand – whatever a timer or flow switches would be learned too. The learned pattern is stored in psim.bin (written at most once a day).
• Safety: flow actions pass through the same protection layer as a button press or switching from the web – protection (interlock) and joiner rules always apply.
• Saving: the Save Immediately button of the 💾 menu writes to flows.jsn, and the engine reloads it immediately – no restart needed. For testing, the manual Fire button starts the chain, skipping the trigger and the conditions.

14/B. myIO Script – PLC-style programs (Script page) 4.10+

A Program is Flow's “big brother”: short text programs that the controller itself runs cyclically – like a PLC. Each program has its own cycle time (e.g. 500 ms or 5 s), and in every cycle it runs from start to end; the state is kept in variables between cycles. What Flow cards cannot do: timed sampling, ring buffers and averages, calculating from two sensors, conditional branches (if … elif … else), edge and timer functions (rising, ton), loading a slot on a condition, publishing a virtual sensor. Programs switch through the same protection layer as a button press or Flow – protection (interlock), the joiner and output timers always apply; a program cannot do more than a button. Division of labor: weekly scheduling → Timer; simple “if–then” cards → Flow; calculation, state machine, sampling → Program. If Flow and a program switch the same output, the last command wins (within one round, the Program runs after Flow).

Files, directives, editing

• One program = one file: prog/1.txt … prog/16.txt in the root of the controller's internal (QSPI) storage (Opta: 1–8). The number is the program's permanent identifier – the card's #N mark shows it, and it also appears in the log. The name comes from the file header.
• Header directives at the beginning of the file, before the first statement (# at the start of a line):

  Directive	Meaning
  #name Text	The program name (at most 23 characters) – shown on the card and in the log.
  #every 500ms	Cycle time: 100 ms … 24 h. Without a suffix it is milliseconds; s, m, h can also be used (#every 5s, #every 10m, #every 1h). Default: 1 s.
  #enabled 0	Disabled program (not run by the scheduler). Default: 1. This is the source of truth – the Enable/Disable switch of the Script page rewrites this line in the file, and it stays in effect after a restart.
  #onboot	After loading (startup, reload) the program runs once immediately, without waiting for the first cycle time; in this run boot() = 1.

  Comment: // up to the end of the line; comments and empty lines do not end the header. The same directive twice: the first one is valid, the others count as comments (the editor also rewrites the first one). A directive after the first statement is a compile error (E02).
• Saving, copies: the SD mirror (sdsync) automatically copies the prog/ folder to the SD card, the ZIP backup on the Save page also contains it (prog/1.txt…), and on a blank QSPI it is also restored from the SD card. The source can be downloaded as a whole: /~q/prog/N.txt.
• Editing: in the built-in editor of the Script page (line numbers, Ctrl+S), or with the text editor of the File manager directly on the prog/N.txt file – after the latter, the card's Reload button (or !progreload*N. over serial) reads it in again. The firmware never writes the program file by itself; the only “writer” is your save.
• Backup: the source can be copied from the File manager, and downloaded from http://<controller>/~q/prog/N.txt – it is worth keeping a copy on your own computer too.

The language in brief

• Values: every value is a number (floating point): temp(12) = 21.37 (°C), out(5) = 0 or 1, hum(0) = 54.3 (%). True = non-zero, false = 0 (true/false can also be written). An invalid value (faulty sensor, no time sync, wrong ID) has its own marker: NaN. It propagates through calculations, every comparison with it is false (!= is true), and it can be filtered with the valid(x) function. Division by zero → NaN (not an error, the program keeps running).
• Variables: only at the beginning of the program, with var: var a, b = 5, buf[10]. The initial value is set once, at load time; after that the variables keep their values between cycles (this is the program's “memory”) – reload and restart reset them. buf[10] is a 10-element ring buffer (at most 64 elements). Undeclared name: error (E10).
• Assignment: x = temp(7) - 0.5; special targets: gvar(3) = x (Flow variable), sens(40) = x (publishing a virtual sensor), pca(2001) = 128 (dimmer value).
• Branching: if condition then … elif condition then … else … end. It can also be written on one line, with several statements separated by spaces: if not valid(t) then off(3) return end. Nesting is limited to 8 levels. return = the cycle ends here (the rest is skipped); there are no loops (for/while) – so the duration of a run is guaranteed to be bounded.
• Operators (from weakest to strongest): or < and < not < comparison (== != < <= > >=) < + - < * / % < sign; parentheses can be used freely. Comparisons cannot be chained (instead of a < b < c write a < b and b < c). and/or always evaluate both sides – so edges (rising) are updated in every cycle even inside a condition.
• Edges and timers: rising(x) / falling(x) / changed(x) signal a transition relative to the previous cycle (true for one cycle; there is no edge in the first cycle). ton(x, s) is true if x has been continuously true for at least s seconds (on-delay, “quiet watcher”); tof(x, s) stays true for s seconds after x is released (after-run). Each such call in the source is a separate “memory cell”, so make sure return comes after the edges – otherwise they are not updated in that cycle.
• Arrays (ring buffer): push(a, x) adds a new sample (if the buffer is full, the oldest one drops out); avg(a) sum(a) min(a) max(a) calculate from the stored values (skipping invalid samples); count(a), full(a), clear(a); a[0] is the latest sample, a[1] the one before it (a sample that does not exist yet: NaN). An element cannot be overwritten directly – only with push.
• Strings may appear in only two places: as a name parameter (out("ping"), loadslot("Safemode") – see names) and in the log message of log("text", x) (at most 47 characters).

Built-in functions – detailed description

IDs are the unified identifiers: relay (logic output) 1–64, group 501–, output (dimmer) 2001–; input 1–, 1Wire thermometer 1–100 (EEPROM ID), universal sensor 0–100. Where the description says so, you can write the name set in the controller in quotes instead of the ID (the controller resolves the name when the program is saved; if there is no such name, it reports an E12 error). Every value is a number; the invalid value is NaN: it propagates in calculations, is false in conditions, and can be checked with valid(x). In the editor's reference panel, hovering over any item shows the same short description.

Readers – outputs, inputs

Readers – sensors

Readers – time and runtime

Math

Commands (only as statements, not in expressions)

Ring buffer (array)

A var a[10] declaration creates a 10-element ring buffer (at most 64 elements, 256 in total per program). Each push discards the oldest element when the ring is full. Use it for moving averages, minimum/maximum monitoring and storing history.

Edge detectors and timers (PLC functions)

These calls have their own hidden state (separate for each call site), which persists between cycles – that is why they work like the rising-edge detectors and TON/TOF timers of PLCs. In the first cycle no edge is signaled. Important: edge detectors after return are not updated in that cycle, and both sides of and/or are always evaluated (no “short-circuit”), so that no edge is lost.

At most 16 commands can be issued in one cycle (the rest are dropped – the card's “dropped commands” counter increases). On a thermostat-controlled (activator) output the command is refused: there the thermostat is in charge (a “refused” entry appears in the trace). A wrong ID returns NaN when read, and is refused as a command.

Names instead of IDs

Outputs, inputs, thermometers and slots can also be referenced by the name set in the UI: out("Ping"), on("Living room lamp"), in("Motion hallway"), temp("Supply"), loadslot("Safemode"). The controller looks up the name in the descriptor files when the program is loaded (output: in relay → group → dimmer order; input; thermometer; slot) – upper/lower case does not matter, nor do spaces at either end of the name. If the name is not found (or there is no such slot), the program stops with an E12 compile error until you fix the name or the source and reload it. So after renaming something, you must reload the program too. Specify the universal sensor (sens) by its number.

Example programs

1. Ping guard – a remote server switches on the logic output named “ping” every 5 seconds; this output has a 5 s output timer. Important fact: switching on an already-on relay again does NOT restart its timer – so despite the pings, the relay can flip off and on (5 s ON, then possibly ~5 s OFF until the next ping). That is why we do not look at the raw state, but at 12 s of continuous silence: ton flips only if the output has been OFF for 12 seconds without interruption. rising makes sure the slot is loaded once, and falling signals re-arming.

#name Ping guard
#every 500ms
// The server sends on("ping") every 5 s; the "ping" relay has a 5 s timer.
// FACT: switching on an already-ON relay again does NOT restart its timer
// -> despite the pings the relay can flip off and on (5 s ON / possibly ~5 s OFF).
// So we watch for "12 s of continuous silence", not the raw state.
var lost
lost = ton(not out("ping"), 12)        // true if there has been no ping for 12 s continuously
if rising(lost) then                   // ONLY at the moment of the transition -> once
  loadslot("Safemode")
  log("ping lost - Safemode")
end
if falling(lost) then log("ping is back") end   // re-armed

2. Average comparison – every 5 seconds it takes a sample from two thermometers and compares the averages of the last 10 samples: if average A is higher, output 5 is ON, otherwise OFF. full() waits until both buffers are full; avg skips faulty samples (NaN).

#name Average compare
#every 5s
var a[10], b[10]
push(a, temp(12))                      // 1Wire thermometer 12 (°C; NaN goes in on error)
push(b, temp(13))
if full(a) and full(b) and avg(a) > avg(b) then   // avg skips NaNs
  on(5)
else
  off(5)
end

3. Heating with hysteresis and fail-safe – the setpoint is the initial value of the var (visible on the Variables panel); on a sensor fault the heating switches off and the cycle ends, otherwise it switches within a ±0.3 °C band.

#name Heating living room
#every 2s
var want = 21.5                        // setpoint, initialized at load time
var t
t = temp(7)
if not valid(t) then off(3) return end          // sensor fault: heating off
if t < want - 0.3 then on(3)
elif t > want + 0.3 then off(3)
end

4. Supply–return difference – publishes the difference of the two thermometers as a virtual sensor (universal sensor 40: visible on the main page, in the chart, in Flow and over MQTT), and switches the pump based on the difference. On a faulty measurement (NaN) it does not switch and does not update.

#name Supply-return delta
#every 10s
var d
d = temp(21) - temp(22)
sens(40) = d                           // usens 40: seen by UI/Flow/MQTT; NaN = no update
if valid(d) and d > 15 then on(9) elif valid(d) and d < 8 then off(9) end

5. Night motion light – between 22:00 and 6:00 the motion sensor (input 17) switches the light on with its turn-on edge; after 3 minutes of quiet, ton switches it off. Without time sync tod() is NaN → “night” is false, and the light does not switch on by itself.

#name Night motion light
#every 200ms
var night
night = tod() >= 22*60 or tod() < 6*60          // no time sync -> NaN -> false
if night and rising(in(17)) then on(12) end     // motion edge: ON
if ton(not in(17), 180) then off(12) end        // 3 minutes of quiet: OFF (idempotent)

6. Gate counter with a Flow bridge – counts the turn-on edges of input 5, writes the value into Flow global variable 7 (Flow var triggers react immediately), resets at midnight, and sends a notification to the menu bar at 100 openings.

#name Gate counter
#every 100ms
var n
if rising(in(5)) then n = n + 1 end
if rising(hour() == 0) then n = 0 end           // resets once at midnight
gvar(7) = n                                     // Flow var trigger sees it immediately
if n >= 100 then msg() n = 0 end

The Script page

• List: one card per program – name, #N, status badge (running / disabled / ERROR / empty), cycle time, number of runs, last run, the longest run (max µs), dropped commands, lag. On an error the card shows the line:column and the error code (e.g. 12:5 E10 ismeretlen nev (var kell): foo – “unknown name (var needed)”).
• Buttons: + New script (from a template, in the first free slot), Edit, Enable / Disable (rewrites the #enabled line and saves), Run now (one cycle immediately – even on a disabled program), Reload, Delete.
• Editor: monospaced font, line numbers, size counter; the directive fields (name, cycle time, enabled) stay in sync with the text; Ctrl+S saves. The Language reference panel lists the functions and the controller's own names (output, input, thermometer, slot) – you can copy the name parameter from there.
• Saving: the 💾 menu (or Ctrl+S) writes the file, and the engine reloads it right away – no restart needed. When you save a faulty program, the card switches to ERROR and the cursor jumps to the faulty spot; the previous version does not keep running (the file and the running program are always identical). The page warns you about unsaved changes. Saving resets the variables.
• Variables (live): the program's own variables and arrays (element count/capacity, latest value), refreshed every two seconds – “setpoint”-type vars can be monitored here. Global variables: the 32 Flow variables, which can also be edited by hand.
• Log (trace): the last 128 events with timestamps: loaded, compile error, command (target ID), log, runtime error, time limit exceeded, enable, manual run, slot loaded, gvar write, refused. With auto-scroll. The same over serial: ?prog..
• Editor: the source is shown with syntax highlighting (comments, keywords, commands, functions, variables, numbers and strings each in its own color); every item of the Language reference panel has a short description, and clicking an item inserts it at the cursor; the book icon opens the language chapter.

Errors, error codes

On an error only the program concerned stops (ERROR state); the others keep running. The M66 message appears once in the menu bar, and a Prog,N,err,… line is written to the event log. After you save the fixed source (or use Reload), the program runs again.

• Compile errors (line:column Exx text): E01 unknown character · E02 directive in the wrong place / unknown directive · E03 name or number too long · E04 missing/expected element (e.g. then, end, parenthesis) · E05 #every out of range · E06 string in the wrong place · E10 unknown name (var missing) · E11 unknown function · E12 the name cannot be resolved (no such output/input/thermometer/slot) · E13 ID out of range · E14 wrong number of arguments · E15 command in an expression · E16 not assignable · E17 reserved name · E18 array/scalar mix-up · E19 var not at the beginning of the program · E30–E39 limits: expression too complex, program too long, expression nested too deep, too many variables, array size, too many edges/timers, too many constants, too many strings, if nested too deep, source too long.
• Runtime errors (Rxx): R01 instruction limit (2000 steps/run) · R02 time limit exceeded (one run over 2 ms, 3× in a row) · R03–R05 internal error (stack, instruction, jump). Not errors, only counters: R06 refused command (wrong ID, activator output, missing slot, slot loads too frequent), R07 command flood (more than 16 in one cycle). NaN is never an error – the program keeps running.

Limits

• 16 programs (Opta: 8); source at most 8 KB (Opta 4 KB); per program 768 instructions (compiled), 48 variables, 8 arrays (each at most 64 elements, 256 in total), 48 edge/timer calls (rising, ton… in the source), 8 levels of if; on Opta the limits are halved.
• Cycle time 100 ms … 24 h. At most one program runs per loop round (completely, without interruption) – many fast programs delay each other; when a program falls behind, skipped periods are not caught up (“lag” counter). One run is limited to 2000 instructions and 2 ms; 16 commands/cycle; log once per second, loadslot once per 10 s, per program.
• No command can be sent to a thermostat-controlled (activator) output (it is refused). The program does not write files, EEPROM or settings; it does not send network requests (hook goes through the webhook targets of Flow). Every command, without exception, acts through the protection / joiner / timer layer.
• Permissions: the Script page and downloading the source require editor/admin rights; do not put secrets in the source.

14/C. MIA – myIO Intelligent Assistant (MIA page) 4.11+

MIA (Settings → Control → MIA) is the caretaker of your house, a self-learning, observing layer: every minute the controller looks at every heating-type thermostat binding (thermometer + logic output, ON threshold < OFF threshold) and learns how the house behaves, zone by zone. As an observer it switches nothing – the thermostat, the timer, Flow and Program work exactly as before; you can switch MIA on and off at any time, and while it is off the learned values are kept. No cloud, no subscription: all data stays on the device. From 4.12 two intervening functions can also be enabled (disabled by default): self-learning pre-heating and pause heating on open window.

What it learns (per zone):

• Heat-up rate (°C/h) and min / 1 °C – how long it takes the room to warm up by one degree;
• Cool-down rate (°C/h) – with the heating off;
• Dead time – how many minutes after switching on the temperature actually starts to rise (the inertia of the boiler and the radiator);
• Overshoot / undershoot – how much it still rises after switching off, and how far it drops below the threshold after switching on;
• Duty 24 h – the percentage of the day the zone was heating; cycle count; Learned (100 % after ~8 heating cycles).

Open window detection: if the zone temperature drops within a short time (default 0.5 °C / 5 min) much faster than the learned cool-down, the zone is flagged “window open?”: a log line (System,AI,WIN,R<n>,open) and a message in the menu bar (M68, at most once per hour). The flag clears when the temperature recovers (+0.2 °C) or after the set time. The flag on its own switches nothing; to pause the heating, enable the heating pause function (4.12+).

Setup: switch MIA on (Enabled), leave the two observing functions on, and wait 1–2 days: the “Learned” column shows how reliable the numbers already are. The “Forget” button deletes the learned values (worth doing after replacing the boiler/radiators or after insulation work). The grey functions marked “coming soon” (overshoot-free control, consumption anomaly) arrive in upcoming releases.

Self-learning pre-heating 4.12+

If the comfort/eco switch is done by the timer (loading a slot's relays.xml: a “Load All” or “Load Logic outputs” event), and the new slot gives a zone a higher ON threshold, MIA uses the learned data to calculate how much earlier it has to start heating: dead time + (target temperature − now) × min / 1 °C, multiplied by a learned correction (k). That much before the switch – at most the set number of minutes (default 120) – it switches on the zone's heating, so the room is already at comfort temperature at the moment of the switch (the equivalent of Loxone's “intelligent heating control” / tado “Early Start”).

• How it switches: for the duration of the pre-heating MIA holds the zone's thermostat – it drives the relay through the existing switching path (like a button press) with the thresholds of the target slot –, and at the switch, when the timer loads the slot, it hands it back to the thermostat, which carries on from the same point. It does not touch the thresholds or the settings.
• What it learns from it: at the moment of the switch it measures how many minutes early or late the target was reached (“last: 3 min early”) and refines k from that. In the first days there may be a deviation of a few minutes; after that, in our experience, it arrives within ±0.2 °C.
• Limits: only at ≥ 50 % learned; it does not start with an open window; per zone at most the set number of times per day (default 3); manual switching (button, app) cancels it immediately and the user's decision is respected; a thermometer dropout or switching the function off hands the relay back to the thermostat immediately.
• When it sees the switch: the timer calculates tomorrow's events after midnight – so for comfort switches in the first hours after midnight, pre-heating can start at midnight at the earliest. The “Next comfort switch in the timer” row shows what MIA sees.
• Excluding a zone: with the table's “MIA may act” checkbox – observing and learning continue there as well.

Log lines: System,AI,PRE,R<n>,start,<min>,<T>,<target>,<hh:mm>, …,done,<deviation min>,<T at target>,<k>, …,abort,<reason>; menu-bar message: M69.

Pause heating on open window 4.12+

Enabled together with open window detection: while a zone is flagged “window open?”, MIA keeps the zone's relay switched off (otherwise the thermostat would start heating immediately because of the sudden cold), and when the flag clears it hands it back to the thermostat. Safety: below 8 °C it releases immediately for frost protection; manual switching cancels it. Log lines: System,AI,WACT,R<n>,hold / …,release,<reason>; menu-bar message: M70.

Overshoot-free control 4.13+

A conventional thermostat switches off at the OFF threshold – but the radiator, and floor heating in particular, keeps heating afterwards (a floor by as much as 0.5–1 °C), and after the ON threshold the room keeps cooling. MIA learns this post-rise and dead time (it measures them during conventional operation too), and when you enable Overshoot-free control it switches OFF or ON earlier, inside the band, so that the peak stays right at the threshold. It never crosses the thermostat's band, needs no hold, and where the estimated gain is below 0.1 °C (a well-sized radiator) it does not intervene.

What you gain: with floor heating 0.6 → ~0.0 °C overshoot (time spent in the band 28 → ~90 %), with radiators 0.3 → ~0.05 °C – the MIA page shows the “before → after” overshoot figure per zone. The number of switchings increases (on a floor ~6 → 12/day); the per-zone min. ON/OFF time (0 = automatic: 10 min, 30 on floor heating) protects the boiler, the pump and the relay. MIA excludes relays with a delay or an auto-OFF timer automatically; any zone can also be excluded manually. It works on (universal) sensors with 0.1 °C resolution, but with more scatter – for a floor-heating zone a 1Wire thermometer is recommended.

15. Sensors

The controller's own sensors:

• Thermometers (DS18B20): up to several dozen digital thermometers on a single wire. They are detected automatically; you can name them on the Sensors page. Their values are accurate to a tenth of a degree.
• Humidity sensors (DHT): humidity + temperature.
• Pulse consumption meter: calculates the current consumption from the pulse output of an electricity/water meter (its unit and the pulse/unit ratio can be set on the General page).

Every sensor is logged and can be viewed as a graph on the Chart page, and can also be used as a thermostat activator.

16. Universal sensors 4.x

A universal (network) sensor is a “receiving slot” into which a value arrives from outside: from a Shelly device (chapter 19), from another myIO (chapter 20) or from any device of your own (via the API). You set it up on the Sensors page:

• Type: a display label only (temperature, humidity, power…).
• Refresh (s): a new value is expected this often (in seconds).
• ± error delta and failsafe: if the sensor is not refreshed in time, its state changes to ERROR and its value oscillates up and down by the ± error delta. As a result, the thermostat relay it controls switches at a duty of about 50% – for heating this means frost protection until the sensor comes back. Set the ± error delta larger than the distance between the thermostat's ON/OFF thresholds!

In a thermostat, refer to the sensor by the activator number 300 + ID (e.g. the activator of universal sensor 3 is 303).

17. Dew point protection (myIO DewPoint) 3.12.3+ / 4.x

The myIO DewPoint card on the Sensors page handles a dew point sensor connected to the serial port: the sensor loads the dew point value into universal sensor 0, and the controller sends the % value of a selected dimmer channel back to the sensor (converted into a 0–10 V output). You can set the output channel sent back and the send interval. It is meant for condensation protection of cooled surfaces (e.g. wall cooling): the dew point value can be used as a thermostat activator (ID 300).

3.12.3+ The DUE (V3) controller has no universal sensors: here you enable it in the “myIO DewPoint protection” block of the Setup page. The incoming dew point value is written into a selected thermo sensor EEPROM-ID (on a ×10 scale: 4095 → 409.50), so it can be used as a thermostat activator with the usual thermo sensor reference. Here you can also choose the source output of the PWM output (only PWM-marked channels) and the send interval (max. 300 s). The settings are saved into the slot's globals.xml (global save).

18. Energy manager (eManager page)

The eManager page handles the SDM three-phase energy meter connected to the serial port: power, voltage, current, power factor etc. can be read and logged per phase.

Consumption levels (load limiting): per phase you can set an UP and a DOWN threshold. If the measured consumption rises above the UP threshold, the controller steps up a level and switches off the output assigned to that level; if it drops below the DOWN threshold, it switches it back on. This way large consumers (water heater, air conditioner, EV charger) can be switched off automatically so that you do not exceed the supply limit.

The SDM values can also be used as thermostat activators (e.g. “if the power of phase 1 is above 2000 W → signal lamp on”).

18/A. Smart Grid — SG-Ready heat pump mode (SG page) 3.12.9+ / 4.4.2+

SG-Ready is a common interface standard of heat pump manufacturers: two potential-free (dry) contacts encode four operating modes for the unit. Two designated myIO outputs (K1, K2) provide the two contacts — each can be either a relay (R1..R64) or an output (P1..) (for an output, ON = the set ON level, OFF = the OFF level):

Setup: on the Smart Grid page (Settings → Link → Smart Grid) select the K1 and K2 outputs (two different outputs; typing in the search field narrows the list — R = relay, P = output), enable the function, and set the EVU lock time limit (default 120 min – the standard's 2-hour ceiling). The mode is changed by a timer (Timer page, “SG-Ready mode” event, target = mode 1..4) or with the manual buttons on the page – so you can split the week into time bands for which mode applies when (cheap night-time electricity → Recommended ON; peak time → Blocked; etc.).

Interlock: the controller re-asserts every minute the correct state of the contact pair, so manual switching or switching from another source lasts at most ~1 minute. The designated outputs are shown with an SG badge on the Logic outputs and Outputs pages.

19. Shelly integration (Shelly page) 4.x

myIO handles Shelly smart devices (relays, dimmers, sensors) on the local network as if they were wired into the controller. On the Shelly page:

• Discovery: Discover scans the network and lists the Shellys it finds; you can add them with one click. A device can also be added manually by IP address.
• Output binding: a Shelly relay channel bound to a myIO element stays in sync in both directions – switching from myIO toggles the Shelly, and vice versa.
• Button binding: a wall switch wired to the Shelly appears as a myIO input (with short/long/release events) – the Shelly reports it with an instant message (webhook).
• Sensor binding: the Shelly's measured data (temperature, power, voltage…) can be bound to a universal sensor.
• Sleeping devices (battery-powered temperature/humidity sensors): with the “battery/sleepy” flag – the controller does not poll these, it only receives the data they send in.
• Polling rate per device 4.3.9+: for each device you can set separately how often the controller reads its state (250–60000 ms, default 1000 ms).

Polling only affects detecting changes coming from outside: pressing the wall switch, switching from the Shelly app and sensor value updates. A command issued from myIO (button, timer, group, protection) goes out immediately regardless.

So it is worth polling important devices – lamp relay, switch – frequently (0.5–1 s), and non-urgent ones – solenoid valve, irrigation, rarely changing sensor – rarely (10–60 s). The controller runs one outgoing request at a time, shared by the Shelly devices, myIO Link and the cloud, so polling the non-urgent devices less often directly improves the response time of the important ones.

20. myIO Link (connecting two controllers) 4.2+

On the Link page two (or more) myIO controllers can be connected over the network:

• Output mirroring: a local element controls an element of a remote controller (e.g. the holiday home's pump from the house).
• Sensor takeover: the remote controller's sensor arrives in a local universal sensor – it can also be used for a thermostat.

Devices are added by discovery or by entering an IP address; you also have to enter the remote controller's username/password. The connection state (online, bad credentials) is visible in the list.

Discovery also finds the older, Due-based (3.x) controllers – these are marked with a DUE badge in the results list and in the server header. The Due does not report a device name, so Test fetches its serial number as the name; a custom name typed into the Name field is kept, Test does not overwrite it. In the link rows, when you type the ID manually, the type and name drop-downs follow the typed ID immediately.

Changes take effect immediately, but until you press the Save Immediately button of the navigation bar they are only runtime changes – without saving they are lost on restart. The link configuration is stored not in a slot but in the root of the SD card (link.jsn), so here the button saves directly, without a slot selector; a ✔ flashing on the button confirms a successful save. (Identifying and deleting a server saves automatically.)

20/A. MQTT client 3.12.31 / 4.3+

On the MQTT page (Link menu) the controller publishes its events and states to an MQTT broker – for example to Home Assistant, Node-RED or any MQTT-based system. By default the client only sends (publish-only); from 4.5 it can also receive, as described in the Subscribe section (control + external sensors).

DUE (3.12.31+): the same topic scheme, Home Assistant Discovery and control as on 4.x – in HA the DUE and the GIGA/Opta controllers appear the same way. Not available on the DUE: TLS, economy mode, universal and external MQTT sensors, RS485 expander; the broker can be entered by IP address only (not by hostname). The settings are saved into the controller's EEPROM (not into mqtt.jsn), so the broker password never ends up on the SD card. The persistent MQTT connection occupies one network (W5500) socket: with MQTT enabled the web server accepts 2 parallel connections instead of 3. On an old W5100 (4-socket) board MQTT only fits if the app port (843) and mDNS are disabled – the page warns you in that case.

• Broker: address (IP or hostname), port (default: 1883), optional username/password. No TLS – keep the broker on the local network.
• Client ID / Base topic: if left empty, derived from the controller's hostname (myio-<name> or myIO/<name>).
• Retain: state messages are retained on the broker (a newly connecting client immediately sees the last state). QoS: 0 = fire-and-forget, 1 = acknowledged (PUBACK).
• Economy mode 4.x: the client does not keep a permanent connection (it does not hold a socket continuously) – it connects when the interval expires or when a change event is pending, sends everything, then disconnects cleanly. The HA availability indication is then only approximate (offline between sends).
• Publish on change: button press (.../button/<id> = H/P/R: short press = H; long press = P, then R on release – the gesture is sent even if no event is assigned to it), output change (.../relay|pca|fet/<id> = 1/0), sensor activator (.../sensact/<id>). For a Shelly-bound switch the Shelly's mode decides: "button (H/P)" mode does not send R, "toggle (P/R)" mode does.
• Publish periodically: the selected classes (outputs, thermometers, humidity sensors, universal sensors 4.x, SDM power) are resent at the given interval (min. 5 s). The values are plain text: 1, 0, 23.50.
• Home Assistant Discovery: on connect the controller registers its entities with retained config messages on the homeassistant/... topics – they appear in HA automatically. A relay/dimmer/PWM only gets an HA entity if it is named (the raw topic of unnamed outputs still works); sensors are created with the unit matching their type (°C, %, W, ...); 4.16.2+ also with state_class (measurement, total_increasing for the kWh sensor), so HA collects long-term statistics, and the kWh sensor can also be added to the Energy dashboard. Availability is indicated by <base-topic>/status (online/offline, LWT).

Changing a field writes the running config immediately – the enable checkbox connects/stops right away. Saving (Save & Apply) writes to the root mqtt.jsn file (on the DUE to the controller's EEPROM) (without it the setting is lost on restart), and reconnects the client with the fresh settings. The connection state and the dropped-events counter are shown in the right column of the page; serial diagnostics: the ?mqtt. command.

TLS encryption 4.4+. With the TLS encryption checkbox the connection to the broker is encrypted (BearSSL, TLS 1.2). The broker is authenticated not by a certificate chain but by a pinned public key: enter the broker's EC P-256 public key into the Broker pinned key field in base64url form (myIO Cloud provides it at pairing; for your own broker it can be derived from the server key). With TLS enabled the port is typically 8883. If the controller cannot obtain a reliable hardware random number, the connection is not established (fail-closed) – better no TLS than sham encryption with weak keys. Encryption can be used both with your own broker (e.g. Home Assistant) and with myIO Cloud.

Subscribe – control and external sensors 3.12.31 / 4.5+

Enabling the Subscribe section lets the client receive as well: after CONNACK it subscribes to the configured topics, and the connection stays open permanently (economy mode has no effect then – the page indicates this). Every saved setting takes effect without a reboot, with an immediate reconnect.

• Control (logic output / output): a message sent to the <base-topic>/relay/<id>/set and <base-topic>/pca/<id>/set topics switches. Relay payload: 1/ON, 0/OFF, T (toggle). Output payload: number 0..255 = brightness (0 = off), or the text ON/OFF/T. The command runs with the permissions of the selected user slot (0 = admin) – with a narrower slot, the controllable set can be limited by the per-element permissions of user management. The result of the switching is reported back immediately on the usual state topic (.../relay/<id> = 1/0).
• HA Discovery with control: with control enabled, named relays appear in Home Assistant as switches (switch), outputs as lights (light, with 0..255 brightness – the brightness on the .../pca/<id>/bri topic); an output without PWM 3.12.34 / 4.18.8+ as an on/off-only light (no brightness slider – it can only be 0 or 255 anyway); after switching the output's PWM mode the entity follows automatically; with control disabled they revert to binary_sensor. The switch-over cleans up the old entity configs automatically.
• Thermostat, cover, RGB in Home Assistant 3.12.31 / 4.17+ (with control, identical to the Homey app's model):
  • Thermostat (climate): every named relay / on-off output that has a thermometer (1Wire) or a temperature/dew-point type universal sensor (4.x only) bound to it. The target temperature is the middle between the switch-on and switch-off thresholds – when you set it, the band width is kept; alongside it a “<name> hysteresis” number entity (0–10 °C) sets the band, keeping the middle. Heating if the switch-on threshold is lower, cooling if it is higher. On/off is still the output's own switch: outside the band the controller overrides the manual command.
  • Cover (cover): every output protection pair (first element = UP, second = DOWN); the name is the common part of the two elements' names (e.g. “R. Kitchen Fix UP/DOWN” → “R. Kitchen Fix”). Up/Stop/Down buttons; on start the opposite direction is switched off first. No position.
  • RGB light: every group whose name starts with “RGB”; among its members the outputs whose names start with R/G/B are the color channels. Color picker + brightness; on switch-on the last color is restored.
  After a rename and when the thermostat/cover/group settings change, the HA entities refresh automatically after 5 s (without reconnecting); manually with the MQTT page's Refresh HA entities button. A removed entity can be deleted manually in HA.
• MQTT sensors (external) 4.5+: in the binding table you can assign a universal sensor slot (1..100) to a topic. The incoming value is written into the slot, so the activator thresholds (sensor ID: 300+slot), protections, freshness monitoring (failsafe) and logging work with it unchanged. The payload is a plain number (21.5) or JSON – for the latter enter the JSON key (e.g. temperature for the zigbee2mqtt message {"temperature":21.5}); ON/true = 1, OFF/false = 0 (as a threshold: 10/0 on the x10 scale). Warning: binding the device's own publish topic creates a self-loop.
• Security: on a broker without a password (anonymous), anyone can control the device who can reach the broker – the page shows a red warning in that case. Never enable control on a public/internet broker; use a password and preferably TLS.

Diagnostics: the right column of the page (received commands/values, denied subscriptions), and the serial ?mqtt. command (subph, cmdrx, senrx, last fields).

20/B. myIO Cloud 4.4+

On the myIO Cloud page (Link menu) the controller connects to the myIO cloud broker, so the myIO app can reach it over the internet as well – without port forwarding, DDNS or VPN. The connection is always TLS-encrypted (with a pinned broker key), and the cloud client runs alongside the own-broker MQTT client, independently of it (both at once only on an Ethernet connection; on Wi-Fi the own-broker client has priority because of the few available sockets).

The essence of the security model: commands are signed not by the cloud but by the user on their phone (ECDSA signature; the private key never leaves the phone). The controller verifies the signature with the public key stored at pairing, and executes the command with the permissions of the user slot selected at pairing – with the same permission rules as the local interface. So even a compromised cloud server cannot forge commands; replay is ruled out by a counter check.

• Broker: address + port (default: 8883), optional username/password, and the broker's pinned public key (mandatory – without it the client does not even start).
• Device ID / Device key: the ID is derived from the factory serial number; the device's own EC key pair is generated at first power-up from hardware randomness (its state is shown on the page).
• Pairing: choose which user slot's permissions the new phone should run with (0 = admin cannot be chosen), give it a name, and start the pairing. A 5-minute window opens, and a QR code appears – scan it in the myIO app (or send the copyable link). The QR carries a one-time pairing token: it is invalid after use or expiry. The QR content is [4.4] encrypted: only the myIO app can read it, a generic QR reader cannot see the broker data (read protection – still, do not publish the QR). The page refresh shows whether the pairing succeeded (the row changes from “pending” to “paired”).
• Revoke / Delete: a paired user can be revoked per key (their commands are not executed until you re-enable them) or deleted permanently.

Changing a field writes the running config immediately; saving (Save & Apply) writes to the root cloud.jsn file and reconnects. Key operations (pairing, revoke, delete) save themselves. Serial diagnostics: the ?cloud. command.

What does the QR contain? The broker address, the device ID, the device's public key, the broker's pinned key, the one-time pairing token and, 4.5+ the app's broker credentials. It does not contain a secret user key – that is created on the phone. The token is valid until the window closes, so you still must not publish the QR.

The app's broker credentials 4.5+ – the two new fields of the Cloud page (App broker username and App broker password). myIO provides these for the controller at installation; the controller only passes them on in the pairing QR so that the phone can connect to the cloud broker at all. You do not need to type them in, and the phone's owner does not need to know about them. Important: this only opens the connection – what the phone may switch is still decided by its own key received at pairing and by the permissions of the user level assigned to it. If the fields are left empty, the phone tries to connect anonymously; the myIO production broker rejects this (the error message: notAuthorized).

Broker update (broker.new) 4.4+ – if the address of the myIO cloud broker changes (relocation, provider change), no new firmware is needed: myIO issues a vendor-signed broker.new file, which you can load on the Cloud page with the Upload button. The controller verifies the signature with the built-in vendor key, and based on the file's sequence number (seq) it rejects an old or replayed file – so it cannot be redirected to a fake address even if the file falls into the wrong hands. After a successful upload the new address takes effect immediately (save + reconnect are automatic), and the page shows the sequence number of the accepted update. If the setting is already exactly what the file contains, the controller indicates this (already up-to-date) – it does not write or reconnect needlessly.

It also recovers by itself 4.4+ – uploading the file manually is not mandatory. If the cloud connection does not recover for a while (a few minutes), the controller first makes sure that there is internet access at all (with a neutral, quick check), and only then fetches the fresh broker.new from the vendor's address, then switches to the new broker by itself. As long as the cloud works properly – or as long as there is no internet – the controller does not contact the vendor's address at all. As a last resort the file can also be obtained by e-mail, and loaded at any time with the Upload button above.

Mirror brokers 4.4+ – if broker.new also contains backup (mirror) brokers, they are listed on the Cloud page. On a connection failure the controller tries the list in order, then connects to the one that worked last, even after a restart. On a new outage it always starts again with the primary broker – in case it has come back in the meantime. The list comes from broker.new and cannot be edited manually.

Vendor notice 4.5+ – while the cloud connection is alive, the controller also listens to a vendor message channel. Through it myIO can address the devices: maintenance, important information, and the broker.new above can also arrive this way (so an address update takes effect immediately, without waiting for the fallback query). The message is signed by the vendor, so not even a compromised cloud server can send a fake message – at most it can suppress one, which is why the automatic query remains as the last lifeline. The notice appears at the top of the Cloud page (the Got it button hides it), and is also written to the Event log.

Messages (history) 4.7+ – a vendor message is not lost when you press Got it: the controller keeps the latest messages (up to 6) on the hidden system volume, and the Messages section of the Cloud page shows them even after a restart. “Got it” only marks a message as read – an unread message is shown in bold with an “unread” label. The user cannot delete a message (and the cloud server cannot revoke it without a signature): whatever the vendor has sent once remains retrievable here until newer messages push it out.

Hiding broker data on production firmware 4.5+ – on production (prod) firmware the Cloud page does not display the broker's address, port, credentials, pinned key and the resolved broker IP: a “hidden” marker is shown in their place, and they cannot be edited either. There is no need to: the address comes from the factory-burned list and the signed broker.new file. So the data does not leak even if someone takes a screenshot of the Cloud page or forwards the page. On development firmware everything is visible and editable. (The pairing QR works regardless – it necessarily contains the address, since the app has to connect using it.)

What does “pinned key” mean? For the TLS connection the controller does not trust certificate authorities (CA), but exclusively this single key: the handshake only succeeds if the other side signs with it. So a man-in-the-middle server or an expired or fake certificate is ruled out from the start, and no certificate store has to be kept on the device. The key is public (not a secret) – it is just operational data, which is why we hide it on prod firmware.

What this channel can NEVER do – this is the most important design decision: a vendor message cannot control anything (relay, output, scene), cannot run a command, cannot query data or logs, and cannot install firmware on its own. Outputs are moved exclusively by your own signed command, authenticated by your phone's private key – the vendor cannot interfere with that. A message of unknown type is dropped by the controller.

License 4.6+ – the License section of the Cloud page shows the purchased features, the expiry of the annual entitlement (with a countdown) and the app-pairing quota (used / allowed). A new or renewed license can arrive in two ways: automatically via the cloud (while the cloud connection is alive, the controller receives and automatically acknowledges it), or as a code received by e-mail, which you paste here into the input field and load with the Apply button – this route works even when the cloud is not reachable. The license is vendor-signed and bound to this single device: the controller rejects a forged code, a code issued for another device, or an older (replayed) one; the latest issue is always the valid one, regardless of which route it arrived by. Important: the actual gate of the annual Cloud entitlement is on the cloud server – local (LAN) operation is not affected by the expiry in any way, and an expired device can receive the renewal the same way.

21. BroadLink / Computherm

On the BroadLink page you can add BroadLink-based Wi-Fi devices (smart plugs, Computherm Wi-Fi thermostats): after discovery and pairing a plug can be bound to a myIO output (bidirectional sync, with a child-lock switch), while a thermostat is managed on the Computherm subpage.

The Enable BroadLink checkbox and the Discovery button are at the top of the BroadLink page (following the pattern of the Shelly and myIO Link subpages – previously enabling was on the Setup page and Discovery in the save menu of the navigation bar). Enabling takes effect immediately, without a restart; with the integration disabled the Discovery button is inactive. The list of paired devices is not stored in a slot but in the root of the SD card (brlink.jsn) – you save it with the Save Immediately button of the navigation bar; without saving, the pairings are lost on restart.

The state of the enable checkbox is written immediately to the controller's non-volatile memory and survives a restart – no slot needs to be saved for it, and switching slots does not overwrite it either. When enabled, the controller automatically re-initializes the pairing keys and starts a discovery, so previously paired devices (e.g. a Computherm thermostat) re-authenticate without any intervention; when disabled, the allocated UDP socket is released immediately.

Reachability indicator and offline protection 3.12.4+ / 4.3.5+ – a green/red dot in the header of every paired device shows whether the device is reachable on the network. If a device does not respond (e.g. it is powered off or has dropped off Wi-Fi), the controller marks it offline, and from then on retries it only once per minute – previously the timeouts of the once-per-second retries noticeably slowed down the whole controller. As soon as the device responds again (or a Discovery finds it), the indicator turns green by itself and normal polling resumes; a switching command issued in the meantime is not lost, it is sent on the retry. The transitions are also written to the event log (BL-OFFLINE / BL-ONLINE lines). In addition, Discovery no longer blocks the controller while it collects the responses (it runs asynchronously): during discovery the button changes to “Discovery in progress…”, and at the end the page reloads by itself – no manual refresh needed. The page also checks the device list in the background every 10 seconds (brstat.json): on a new or vanished device or an authentication change it reloads automatically, otherwise it only updates the reachability indicators in place.

22. Users and permissions (Users page)

On the Users page you create accounts with admin / editor / user level (chapter 2). For a “user” level account, permissions can additionally be granted per element:

• Read (R): sees the element and its state.
• Write (W): can also switch it.
• For inputs: the Short (Hit) and Long (Press) events can be enabled separately.

An element without permission does not even appear on the user's interface or in their app. A group is only visible if the user has permission for every member of the group. With the buttons at the top of the table all permissions can be cleared/granted/inverted at once.

20/C. RS485 expanders and KNX gateway (Expanders page) 4.5+

The Expanders page (System menu) shows the panels attached to the RS485 expander bus in a card list sorted by address, with live online state (how the list works is described in the expander list section). There are two panel types: the Ext16 (16 inputs / 16 outputs) and the Ext-KNX – the latter is a KNX TP1 gateway (the third one, the Ext-DALI gateway, is described below) that interoperates with KNX systems: from the controller's point of view it is “16 inputs + 16 outputs + 16 sensors”, only the channels are mapped not to terminals but to KNX group addresses. So all existing myIO logic (timers, Flow, protection, thermostat, app) works with KNX devices too, unchanged.

• Input row: a KNX switching telegram arriving at the group address (e.g. from a push button) comes in as a button event – the input appears at the index given by the address raster (8 + (address−1)·16 + channel), and can be bound to any output, group or Flow.
• Output row: the panel's virtual output (output channel: on/off + PWM + fade + timer) goes out as a KNX telegram – as DPT 1.x switching or as a DPT 5.001 value (e.g. a dimmed lamp, the value input of a shutter actuator).
• Sensor row: a measured value arriving at the group address (DPT 9.x temperature, humidity… or DPT 5.001) flows into the given universal sensor slot – thermostat, logging and alarms come with it “for free”.

The group address table (48 rows) lives on the panel: “Save to panel” writes it over the bus and commits it, so the panel must be online. Copy the addresses from the ETS project (main/middle/sub, e.g. 1/2/3) – to the KNX bus the panel is a simple bus participant, ETS does not see it as a device, and it does not need to be programmed. Rows marked Init-read are queried by the panel after power-up, so the actual KNX state is applied immediately. The status block shows the KNX bus state and the traffic counters live.

Limitations: the panel can neither read nor write group addresses configured for KNX Data Secure – set the addresses to be integrated to unencrypted in ETS. 16+16+16 channels per panel is the ceiling; several panels with more addresses add up. The same group address can be mapped as an output on only ONE panel (to prevent echo loops).

KNX page – entities, names, binding to a myIO element 4.15+

From 4.15 the KNX part has its own page: Link → KNX. The group address table, the KNXnet/IP ETS interface switch and the KNX device registry moved here; the Ext-KNX card on the Expanders page only keeps the status summary and the link (as with DALI/DMX). Every row of the table is a KNX entity: name (a label only, stored on the controller), group address, direction, DPT and the myIO element, which you pick by name from a drop-down:

• Output row: one channel of the panel's 16-channel output block (P-ID; e.g. channel 1 of panel 3 = P2033). You can name the channel on the Outputs page and give it a timer or Flow – the KNX address follows it, and it also receives the status writes.
• Input row: one of the panel's 16 inputs (e.g. panel 3 channel 1 = input 33). A write arriving at the address presses/releases the input – bind it to an output on the Inputs page (push/release, timer, hold state: this way, for example, a KNX presence detector becomes a lighting control).
• Sensor row: a universal sensor (on the Opta from 9 up: 1–8 are the I1–I8 analog inputs). On save the slot is enabled automatically; the value can be used in the thermostat, the log and alarms.

The source of truth for the table is still the panel (“Save to panel”). The group address is bound to the device object by ETS or by the ETS-free downloader (tools/knx_dl.py, System B).

KNXnet/IP ETS interface – programming KNX devices through the controller 4.14+

A controller fitted with an Ext-KNX panel also works as a KNX IP interface: ETS6 programs the KNX devices over the local network, via the panel's KNX bus (individual address, application download, group and bus monitor) – without a separate USB interface. To enable it: Expanders page → KNX group addresses section → KNXnet/IP interface (ETS). The switch is OFF by default: the KNXnet/IP tunnel has no authentication (this is a property of the standard), so enable it only for the duration of the installation.

• In ETS6: Bus → Interfaces – the controller appears in the discovery as “myIO Ext-KNX #n” (multicast). If the network does not pass multicast (e.g. a virtual machine with NAT), add it manually with type “IP Tunneling” and the controller's IP address (port 3671).
• Tunnel address: ETS gets the panel's own individual address (KNX status, “Own IA”) – this address must not belong to another device in the ETS project.
• Limitations (v1): one ETS connection at a time; standard frames only (max. 15 bytes of data) – so ETS downloads in smaller chunks, an actuator download takes a few minutes; no KNX IP Secure and no routing.
• Status: listening / ETS connected (the client's IP), telegram counters and errors below the switch; the “Drop tunnel” button releases a stuck ETS connection. The panel's own group address mapping (table above) keeps working undisturbed alongside the tunnel.
• Resources: the interface's UDP port runs on the network stack's own channel (it does not take any of the controller's 4 general sockets), so it starts immediately even alongside the web page and Cloud. During an ETS download the expander bus traffic increases, and web pages may be slightly slower.
• KNX devices without ETS: in the same section, the controller's own device list – detecting a device in programming mode, writing the individual address (checking whether the address is free and exactly one device is in programming mode, read-back), reading the type, ping, name. This is addressing only: the application (parameters, group addresses) is downloaded by ETS or from the manufacturer's product file.

Ext-DALI gateway – DALI lamps from the controller (Link → DALI) 4.8.6+

The Ext-DALI panel is a gateway that interoperates with DALI systems: the lamps (drivers) on its bus can be added on the Link → DALI page, and each can be bound to an output channel (P-ID) – to the Outputs page, the app, the timer, Flow and the thermostat a bound lamp is an ordinary dimmer. Per panel the possible targets are 64 short addresses + 16 groups + broadcast; the registry lives on the controller (dali.jsn). The panel also provides a built-in bus power supply that can be disabled with a DIP switch (15 V, ~200 mA); there must ALWAYS be ONLY ONE power supply on a bus.

Commissioning: 1. Scan the bus (the panel queries short addresses 0..63, ~3 s), 2. the found addresses become endpoints with the Add button (the controller reads the driver's parameters immediately), 3. Assign channels: endpoints not yet bound get a free channel from the pool (from–to) – or you choose one manually in the Channel column. Only non-raster channels can be bound: the DALI panel's own 16-channel block and the virtual channels above SQ (raising PCAQ above SQ in genconfig gives more); the pool defaults to the end of the range. On binding, the channel's PWM is switched on. New drivers without an address get short addresses from Addressing (“only unaddressed devices”); the “ALL devices” mode re-addresses everything (the old addresses are lost!).

Group and broadcast = command. Switching the channel of a group or broadcast endpoint always goes out on the bus (OFF even if the channel was already OFF), and the controller writes the expected value into the member lamps' channels, so the Outputs page shows the real state. You set the membership in the Groups row of the short-address endpoints (a difference from the membership read from the driver is shown in orange), and “Write to driver” writes it out. A short-address endpoint sends its channel value on change.

Parameters (they live on the controller; “Write to driver” writes them into the lamp, “Read” loads the lamp's values): fade time (code 0..15 = none…90 s), fade rate, power-on level (brightness after the power returns; the factory default is often 254 = everything switches on – 0 is recommended), system failure level (when the bus fails; 255 = keep is recommended), min/max, dimming curve (log/lin for LED drivers), group membership; read from the driver: device type, physical minimum. Short address change, driver reset and Identify (1.5 s full light) via buttons. Into all lamps at once: the parameters set on the broadcast (or group) row are written by “Write to driver” into all member lamps with a single broadcast command; the member rows take them over and are re-read (a value rejected by the driver, e.g. a MIN below the physical minimum, is shown with an orange marker).

Health poll (switchable per panel): the panel polls the known lamps in turn. In “status” mode it reports lamp failures, and after a power loss (power-cycle bit) it automatically restores the lamp's expected brightness; in “status + level” mode it also reads the actual brightness (in case there is another DALI controller on the bus). The status block shows live the bus voltage, the internal supply, the hiccup, the counters, and the addresses with lamp failure or not answering (“not answering” is flagged after two consecutive missed replies).

Taking over from a foreign controller 4.8.7+: with “status + level” polling the controller requests the lamps' fresh brightness from the panel in the background (every 5 s) – fresh means what the panel has read since the last level command – and if it differs from the channel value (the driver's clamping to MIN/MAX does not count as a difference), it was set by another DALI controller (push-button module, another master): the bound channel value follows it, and no command is sent back to the bus. For 3 s after its own switching, during a fade and on a non-answering lamp there is no takeover. In the endpoint row, “⇐ %” next to the Value shows the driver's fresh level (orange if it differs). The parameters read from the driver (orange “≠” marker) are kept even after a restart.

Limitations: outputs only (DALI-2 push buttons and sensors in a later round); the software PWM fade of a group channel does not go out on the bus (the DALI fade time belongs to the driver); the panel is the only controller on the bus (multi-master only with a DALI-2-capable installation). “DALI” is a trademark of DiiA: the panel interoperates with DALI systems, without certification.

Ext-DMX gateway – DMX512 lamps from the controller (Link → DMX) 4.9.0+

The Ext-DMX panel is a DMX512 gateway: it sits on the RS485 expander bus, and on its own DMX output it continuously (~40 times per second) transmits the 512-slot universe to the attached devices (LED decoders, dimmers, color changers, moving heads). On the Link → DMX page you add the fixtures with their DMX start address (1..512, set on the device with a DIP switch or in its menu) and their type (dimmer 1 channel, RGB 3, RGBW 4, generic 1..16), and bind each of their channels to an output channel (P-ID) – to the Outputs page, the app, the timer, Flow and the thermostat a bound channel is an ordinary dimmer, and its value goes to the slot (start address + channel index). The controller only sends the changes to the panel; the panel holds the image and, on master loss (5 s of silence), either holds it or blacks out, depending on the setting.

What is DMX512? A stage and architectural lighting control bus: an RS-485 signal pair (D+/D−, often a shielded twisted pair), daisy-chained (from device to device, not in a star), with a 120 Ω terminator at the end of the chain; connector: 5- or 3-pin XLR, RJ45 or a terminal block (on the panel a D+ · D− · GND terminal block; for XLR: 1 = GND, 2 = D−, 3 = D+). The bus is unidirectional: the controller transmits, the devices listen – there is no discovery and no feedback; the start address must be set on the device and entered here. A device uses as many consecutive slots from its start address as it has channels (RGBW decoder: 4). The slots of two devices must not overlap.

Commissioning: (1) genconfig: expanders[].type: "dmx" at the panel's address → paired M4+M7 flash (proto v11); (2) the panel is online on the Expanders page; (3) Link → DMX: add a fixture (start address + type) → “Assign channels” or manual binding → the slider moves the lamp; the Test button drives every channel of the fixture to full light for 1.5 s (so you can identify which device is where); Blackout = all 512 slots to 0. The panel settings (slots/frame, BREAK/MAB, failsafe, DE/CON polarity, frame period) are saved on the panel.

Limitations: output only (RDM discovery and read-back in a later round); a DMX channel is 8-bit (0..255 = 0..100 %), 16-bit fine channels are not paired; the DMX panel's own 16-channel raster block and the virtual channels above SQ can be bound (channels of DALI endpoints cannot). The panel prototype can also run on an Ext16 panel (J5 Nextion header + 5 V MAX485 module).

Ext-RS485 Modbus RTU master – meters, inverters, sensors in the controller (Link → Modbus) 4.16.0+

The Ext-RS485 panel (the same hardware as the Ext-DMX, only with a different firmware role) sits as a Modbus RTU master on a Modbus bus with its own galvanically isolated RS-485 port, and polls the attached devices: energy meters (Eastron SDM120/230/630), inverters, heat pumps, industrial sensors. The measured values go into universal sensors – there the thermostat, the log and chart, Flow, the alarm, MQTT and the app see them, exactly like any other sensor – and the controller's outputs can write Modbus registers (coil/holding: setpoint, operating mode). The bus runs at its own pace, independently of the controller: the panel polls, the controller only receives the finished values over the RS485 expander bus.

What is Modbus RTU? An industrial polling protocol on an RS-485 signal pair (A/B, twisted pair, daisy chain, 120 Ω at the ends): one master asks, the addressed slave (1..247) answers. The device's data are held in 16-bit registers and bits (holding/input register, coil, discrete input); the protocol is fully standard, but which register holds what (voltage, power, SOC…) and in what form (16/32-bit integer, floating point, word order, decimal scale) is device-specific – this is described by the register map. myIO treats this map as data: the panel is a generic interpreter, so a new device needs no firmware, only the table rows (from a preset or entered manually).

The table: blocks (one Modbus request each: slave, function, 0-based start address, count, period – several adjacent registers in one request), fields (one value from the block: offset, type, word order, scale ×10^n, optional SunSpec scale-factor register → target universal sensor, with a name), write slots (channel k of the panel's own 16-channel output block → coil/holding: for a relay bit, off/on → off/on value; for PCA, 0..255 → low..high linearly; optional periodic rewrite) and the bus settings (baud, frame, timeout, retries, gap between requests). The table lives in the panel's flash (automatic save 8 s after a change, or immediately with the button); the names live on the controller (modbus.jsn). The preset library (SDM120/230/630, XY-MD02 verified; Deye, Growatt, Huawei, SunSpec as starting points) fills in the rows with one click using the given slave address – then you bind the fields to sensors.

Commissioning: (1) genconfig: expanders[].type: "modbus" at the panel's address → paired M4+M7 flash; (2) the panel is online on the Expanders page (Ext-RS485/Modbus); (3) Link → Modbus: bus settings (according to the baud/address/parity shown on the meter's display), a preset or a manual block + fields → the live value appears at the end of the row → choose the target sensor; (4) the sensor's name/type on the Sensors page. Address scan and Raw request help with troubleshooting. If there is no answer, check: A/B polarity (the A/B marking of Eastron meters is reversed compared to the usual one!), baud/parity, termination.

A/B polarity panel fw 0.2+: selectable in the bus settings – normal (J12.1 = D+ / A, J12.2 = D− / B), swapped (the panel swaps the two wires in software, no rewiring) or automatic: if no device answers, the panel switches polarity and locks on the first valid reply (an exception reply counts too). Once locked it only switches again when every block has gone silent (3 missed rounds) – one missing device on a mixed bus does not trigger it. Needs at least one read block. The live state is shown next to the selector: normal/swapped, searching/detected, number of switches. A factory-fresh panel defaults to automatic; an existing setting is kept on update. Eastron meters (Eastron A = −), fixed wiring: J12.1 → Eastron B, J12.2 → Eastron A.

SDM meter on the Modbus panel 4.18.13+ · panel fw 0.3+: besides a universal sensor, a field's target can be an SDM meter variable (SDM P/U/I/S/Q/PF/φ, L1–L3) – the same values the serial SDM reader used to fill: the energy manager, consumption-controlled outputs (activator 201–221), the PLC engine and MQTT read them. With the SDM120/SDM630 presets the “into the SDM variables” tick sets this up. Automatic detection: when the panel's table is completely empty (no block, field or write slot) and “Detect SDM meter automatically” is ticked (default on), after 5 s the panel looks for an Eastron meter at address 1 – with the current settings, then the usual baud/frame pairs (9600, 2400, 19200, 4800, 38400, 1200 · 8N1/8E1/8N2), with automatic A/B on both polarities. Identification: L1 voltage 50–500 V and frequency 40–70 Hz. When found, the panel writes and saves the table itself: one 42-register block with P/U/I/S/Q/PF/angle of the 3 phases (the phase count comes from the meter's type code, not the momentary voltages: an SDM630 is added with 3 phases even if only L1 is live at start – e.g. a tripped breaker – and L2/L3 fill in when they return; a single-phase type such as the SDM120 gets L1 only), plus frequency and import/export kWh without target; the bus settings switch to the detected baud and polarity. Nothing found: retry after 30 s (a harmless read at address 1). Untick it if you fill the empty table by hand or another device sits at address 1.

Device cards 4.19.1+: the Modbus page groups the panel's table by slave address. At the top the bus card (bus settings, A/B polarity, automatic SDM detection, status, save/re-read/clear, export/import of the panel table) and the capacity bar (blocks 2/16 · fields 24/64 · write slots 0/32 – against the panel's frame, 8/32/16 with older panel firmware; yellow above 80 %, red when full). Below, one collapsible card per device: the header shows the name, the template, the row counts, the block ticks (✓ = last request answered) and 2–3 main live values; inside are the device's blocks, fields and write slots (the field's block selector offers only this device's blocks, the new row is pre-filled with the slave address). The device name (max 24 characters) and template live on the controller (modbus.jsn); an automatically detected meter appears as “Eastron SDM (auto)” until you name it. Actions on the card: Load template onto this address, Save as template, Change address (every block and write slot of the device moves to the new address) and Delete device (with its blocks, the blocks' fields, its write slots and names). The page remembers which cards are open within the browser tab.

Template library 4.19.1+: a template is one device's register map as data (blocks, fields with name/unit/SDM target, write slots; JSON). Three sources in one list: built-in (in the web UI: SDM120/230/630, XY-MD02 verified; Deye, Growatt, Huawei, SunSpec as starting points), CDN (okoslak.hu/ext2/modbus/index.json + one JSON per device – a new device needs no firmware or UI update) and own (the controller's /modbus/*.json files). Add device (on the template card): template + slave address (+ “apply bus settings too”, “into the SDM variables”) → the rows go to the next free places, the device's name and template are set. Save as template (on the device card): the device's rows into a JSON → the controller's /modbus/ folder (own template, listed under “own”) and as a download; the id is the file name (a-z, 0-9, _ -, max 16). An own template can be deleted from the list; the downloaded file can be moved to another controller with the file manager (/modbus/) or submitted to the myIO CDN library. Panel table export/import (on the bus card): the whole table in one JSON (backup, panel replacement) – import clears the current table and loads the imported one, rows beyond the frame are skipped.

Write-slot source – element selector 4.19.1+: the source of a write slot is either the panel's own channel (k < 16: relay bit k on/off, PCA k 0..255 – carried by the controller's output raster) OR any controller element chosen by name: relay / logic output, Output (PCA), FET (on a FET controller). Then the controller pushes the level to the panel (on change and every 10 s) and the mapping is selectable: on/off → off/on value (coil or register), or level 0..255 → lo..hi linearly. A push slot without a source does not write. On older controller firmware the element ID is entered as a number.

Fast block (×0.1 s) and event-driven refresh 4.22+ · panel fw 0.7+: the controller's power regulator (energy manager, consumption-controlled outputs, 0.1 s check cycle) gets the freshest possible meter data. The “×0.1 s” tick in the block row makes the period unit 0.1 s (1..255 → 0.1..25.5 s), and the panel flags every fresh value to the controller immediately: instead of waiting for the 1 s polling cycle it fetches it right away – the regulator has the value ~0.1–0.15 s after the meter updated its registers (it used to be 1.5–3 s). The display (live values on the page) is not sped up, nor does it need to be. A request cannot be shorter than the bus transfer time: at 9600 baud the 42-register SDM block takes ~0.16 s, then the block simply runs back-to-back – either set 38400 baud on the meter, or use a separate small fast block (P L1–L3: FC4 12..17, 6 registers, ~30 ms) at 0.1 s and keep the big one at 1 s. The “fast P” templates (SDM630 / SDM120) are built this way: the P block at 0.1 s, voltage/current at 1–2 s, energy counters at 2–5 s. A fast block does not starve the other blocks (round-robin); the full chain needs panel firmware 0.7+ AND controller 4.22+ (paired M4+M7 flash: with an old M4 the fast block runs but the controller fetches once a second). On older panel firmware the tick is not shown and a template's fast block runs in seconds.

Limitations: 16 blocks, 64 fields and 32 write slots per panel (panel fw 0.4+ and controller 4.19.0+; 8/32/16 with older panel firmware – the capacity bar shows it), max 16 named devices; one bus setting per panel (devices with different baud rates need two panels); the sensor path rounds to tenths (for an energy counter 4.5 significant digits – the exact value is shown on the Modbus page); devices that require a sequence (login, read-modify-write) can be handled with the raw request. The panel prototype can also run on an Ext16 panel (J5 header + M5 Unit RS485 module).

The expander list – who is on the bus? 4.6.2+

The Expanders page speaks the card language of the settings pages: one card per expander, sorted by address (the address is set on the panel's DIP switches). The card header shows the address, the type, the panel's firmware version and the online/OFFLINE badge; clicking it expands the panel's parameters (identity, failsafe/standalone mode, AUX pins, program). The type is announced by the panel itself at login (Ext16, Ext-KNX, later Ext-DALI and Ext-WiSUN), not taken from the controller's config – if the two differ, an orange “config: …” badge on the card warns you (wrong address DIP or outdated config).

The controller remembers what it has once seen online at an address (type, firmware, the panel's unique identifier – UID –, the time last seen, the number of logins), so a dropped-out panel stays in the list even when offline, with the time it was last seen. An address where nothing has ever logged in does not appear – so the list always shows what really is or was on the bus. The card of a removed panel can be removed with the Forget button (only for an offline panel; the address's failsafe/AUX settings are kept, and if the panel logs in again, it reappears). The controller recognizes a panel swap from the UID: a System,Expander,NEW/IDENT/FORGET line is written to the event log.

Ext-RS485 role – DMX512 output or Modbus RTU master on the same panel 4.20+ · panel fw 0.5+

The Ext-RS485 panel carries both of its roles in a single firmware image: DMX512 output (fixtures, Link → DMX) or Modbus RTU master (meters, inverters, sensors, Link → Modbus). The role lives in the panel's flash together with the other role's settings (DMX config, Modbus table) – they survive a switch; a factory-fresh panel defaults to Modbus + automatic SDM detection. On the Expanders page the panel's card has a Role section showing the current one; the selector + Switch (save + restart) button switches it: the panel saves the new role, restarts and logs in with the new type – the controller decides from that at run time (DMX universe / Modbus table, the /dmx and /modbus pages, output badges); the genconfig type (dmx / modbus / the new rs485) is only the starting point until the panel has logged in. With the old single-role panel firmware (DMX 0.1, Modbus ≤ 0.4) the switch is not shown – update the panel to the universal image (the old DMX settings and the Modbus table carry over).

Expander bus on the GIGA: Serial1 (X9) ↔ Ext-RS485 J13 4.21+ · panel fw 0.6+

On the Opta the expanders sit on the RS-485 expander bus. The GIGA V4 has no RS-485 bus port, so there the Ext-RS485 panel's J13 (AUX) terminal is the entry: J13 is the panel's second expbus port (3.3 V TTL, 115200 8N1) and connects point-to-point to the GIGA's X9 terminal (D0/D1 = Serial1): X9.9 TX → J13.3 RX, J13.2 TX → X9.8 RX, GND → GND (J13.1 3V3 and J13.5 P1+5V stay unconnected).

• Config: the fleet expanders[] list can be filled on a GIGA device too – gateway types only (knx / dali / dmx / modbus / rs485), addresses contiguous from 1 (set the panel's DIP address accordingly). The 16/16 IO panel is not supported on the GIGA (native raster).
• Start-up: the controller sends an ID probe on Serial1 at boot. If a panel answers → expander mode: Serial1 belongs to the expander bus, the D0/D1 SDM630 reader, the dps sensor and the DewPoint !pwm output go silent (SDM values come from the panel's Modbus table, see Modbus). If nobody answers → the old serial mode stays and the controller re-probes every 60 s while the line is quiet (no SDM/dps frames) and no DewPoint PWM output is configured.
• Bridge: the panel on J13 forwards frames from the GIGA addressed to other panels onto its own RS-485 bus port and the replies back – so through one J13 link the GIGA also sees the other panels chained on the bus (e.g. a second Ext-RS485 in Modbus role). The "Bus link" line at the top of the /expander page shows where the bus runs.
• Diag: serial ?m4. → explink: mode=… probes=… found addr=…; evlog System,Expander,LINK.

Ext-RS485 J13 (AUX) port mode 4.21+ · panel fw 0.6+

On the /expander page, on the panel's card: auto (default) = J13 is the second master port + bridge; off = the port does not run (e.g. a P1 smart meter or another serial device on the terminal – those modes come in a later round). Switching saves into the panel's flash and the panel restarts after ~0.3 s. The "J13 state" line: enabled / master link active (a frame arrived on J13 within 3 s) / bridge traffic / master on the RS-485 port too (two masters at once = wiring error). If this controller talks to the panel through J13, switching it off is refused. The "J13" badge on the /modbus bus card shows the same state.

1Wire thermometers on the expander (AUX1) 4.5.10+

DS18B20-family thermometers can be connected to the Ext16 panel's AUX1 terminal (5V_AUX – AUX1 – GND) (the 4k7 pull-up is on the panel; parasitic power also works). The panel itself searches for and reads the sensors every second, and the values come to the controller over the bus. The controller gives every sensor a permanent ID based on its ROM code – exactly like on the GIGA/Due's own 1Wire bus: the ID is kept after a panel swap and after moving the sensor to another panel, so “shuffling” sensors because of bus lengths does not upset the config. The ID list can be saved to the sensors.bak file with the “Backup IDs” button and restored when the controller is replaced.

The thermometer goes into the usual thermometer slot, exactly like on the GIGA's own 1Wire bus: you name it on the Inputs page (by ID), it is shown on the dashboard and in the app, it is logged (t_log_ID chart), and it can be used in the thermostat activator (1..100), in Flow, over MQTT and in joiners. A dropped-out (unplugged) sensor is shown in red as “absent” in the list, and its temperature toggles the usual way (±127 °C) after 255 s; the registration can be removed with the “Delete” button (the ID stays reserved, so the others do not shift).

AUX2/AUX3 – 0–10 V outputs 4.5.10+

The two AUX pins of the Ext16 work as 0–10 V analog outputs (mixing valve, 0–10 V LED driver, frequency inverter; min. 10 kΩ load). In 0–10 V mode AUX2 mirrors the panel's Out 15 output and AUX3 its Out 16 output: you configure that output channel on the Outputs page like any dimmer (name, PWM flag, timer, Flow, joiner, mixer thermostat, fade), and the pin outputs the duty cycle as 0–9.9 V (255 = 9.9 V). The Out 15/Out 16 terminal switches along with it, so do not connect any other load there while the AUX is in use. On the Outputs page an orange “AUX2/AUX3” badge is shown next to the affected channels. The mode (0–10 V / later LED strip) can be switched on the Expanders page, and it is also saved in the panel's own memory.

Failsafe and standalone mode – expander settings 4.6+

On the Expanders page, clicking the card of any Ext16 panel expands the panel's settings section. The panel is in failsafe until a master frame arrives after boot, or when the bus goes silent (Bus timeout, default 5 s). Four Failsafe modes are available: hold the outputs (HOLD), all OFF, apply the PRESET image, or standalone mode, in which the panel's own rule table takes over control. Setting Master to “none” turns the panel into a standalone controller (it runs in standalone mode from boot, but still answers on the bus).

The standalone program is derived from the Opta's settings, so you do not need to write it separately: it contains those input bindings (short/long/release → output or group, with timer, delay, dimmer), output thermostats (on the panel's own 1Wire thermometers), protection pairs, joiners and groups whose source AND target are on the same panel (max. 48 rows). After every save the Opta re-derives it and compares it by CRC with the one running on the panel; if they differ, it downloads it. LOCKED (program auto-update disabled) prevents writing: the panel runs its last saved program – a real safe mode, independent of the Opta's settings. You can check the table in readable form with the “Show rule table” button.

On return (relink) the Truth on relink setting decides the outputs: by default the Opta takes over the panel's image (flicker-free); switched over, the Opta forces its own image onto the panel. With the Local engine while linked setting the panel switches immediately on wall buttons even alongside the Opta (faster, but the Opta's decision may override it). A stale sensor in standalone mode results in 50% toggling by default (frost and overheat protection), or this can be switched off. The pin mode of AUX2/AUX3 (0–10 V or digital LED strip) can also be selected here. The panel keeps the program and the settings in its own flash memory (restored after a power cut), and protects itself with an independent watchdog (IWDG, ~1 s).

Availability: if an expander drops off the bus, the outputs, inputs, thermometers and groups on it get an OFFLINE marker on the Outputs/Inputs/Sensors pages and on the main page and an "off":1 field in the JSON, while in MQTT the exp/N/status topic and the Home Assistant discovery availability list indicate it (unavailable). The event log records System,Expander,LOST/BACK/PROG lines; the panel's 1Wire thermometers immediately go into error toggling, so the Opta's thermostat failsafe also kicks in.

20/D. Alarm panel integration (Alarm page) A: all · B: 4.5.8+

An existing (or new) alarm panel can be connected to the myIO in two ways. The A) hardware route works with any panel and every myIO controller, without a protocol; the B) SIA DC-09 receiver is a feature of the 4.5.8+ (GIGA/Opta) firmware: the panel reports to the myIO as it would to a monitoring station, so per-zone and per-partition information arrives as well. The two routes can be used together (state via SIA, arming via a keyswitch zone).

A) Hardware wiring — PGM output and keyswitch zone (any panel)

Every alarm panel has programmable PGM outputs (usually open-collector transistor outputs switching to GND, 50–100 mA) and zone inputs, one of which can be programmed as a “keyswitch” type. These two elements make up the protocol-independent integration:

• State into the myIO (PGM → myIO input): in the panel, program PGM outputs for “system armed”, “alarm (memory)” and “trouble/tamper”, and wire them to the myIO inputs. The myIO inputs expect a contact closing to GND: if the panel and the controller are on a common GND (typically the same 12 V supply, or the GNDs of the supplies tied together), the open-collector PGM can be wired directly to the input. With separate supplies, galvanic isolation (a small relay module or an optocoupler on the PGM) is recommended. On the Input page, name the input “Alarm armed” / “Alarm”, and from then on it can be linked to any output, group, timer or Flow (e.g. “if Alarm armed = ON → all lights OFF, thermostats to economy”; “if Alarm = ON → outdoor lights ON + notification”).
• Arming from the myIO (myIO relay → keyswitch zone): in the panel, set a zone to “keyswitch – momentary” type, wire the zone's end-of-line resistor (EOL) as the panel requires, and close the zone briefly with the dry contact of a myIO relay. Set auto-off on the relay (e.g. 1 s), so the “button” gives a single pulse — this toggles between armed and disarmed. Always take the state feedback from the PGM input, not from the relay position. Build an “Arm alarm” scene or Flow on this relay (e.g. “Leaving” button: lights OFF → 2 s → arming pulse).

B) SIA DC-09 receiver — the panel reports to the myIO 4.5.8+

Alarm panels report to the monitoring station (ARC/CMS) over IP according to the SIA DC-09 standard: simple text frames over TCP or UDP, which the receiver acknowledges. The myIO takes on this receiver role: in the panel's “Remote monitoring / Monitoring station / ARC” settings, enter the myIO's IP address and the configured port (default 7080), as protocol select SIA DC-09 (SIA-DCS or ADM-CID / Contact ID format – it understands both), without encryption. This way every event (arming, disarming, alarm with zone, tamper, AC/battery fault, communication fault, bypass, periodic test) comes in.

• Setup (Settings → Link → Alarm): enable, port, transport (TCP and/or UDP – turn on the one the panel uses: each enabled transport takes one of the 8 network sockets), Account filter (the panel's “account” number; empty = any account), Supervision (if the panel does not report for this many minutes: trouble + menu bar notification — set a periodic test in the panel, e.g. 1–5 minutes, and a larger value here), ACK with timestamp. Changes to the TCP listener and the port take effect after a restart (the page indicates this), UDP changes immediately. Save with the Save button.
• Partition state → universal sensor: for each partition (ri1..) you can assign a universal sensor whose value is the state ×10: 0 disarmed, 10 partial (stay/perimeter), 20 armed (away), 30 ALARM (kept until disarmed). From there all existing tools work: Flow sensor card (≥ 25 = alarm, ≥ 15 = armed), relay/output activator (threshold in tenths, e.g. ON if ≥ 15), MQTT publishing, app display. Binding automatically enables the sensor and turns off its failsafe; the controller re-sends the value every minute.
• Log and notification: alarm codes go into the event log at E (error) level (System,Alarm,<account>,<code>,ri=,z=) — so webhook slots marked err:1 fire as well —, arming/disarming/ bypass/trouble at I level; the periodic test and the heartbeat are only counted. On an alarm a notification appears in the menu bar; likewise on loss of supervision.
• Live status and test: the right-hand column of the page refreshes every 3 s (listening or not, age/sender/raw content of the last frame, counters, troubles, partitions). The Test buttons simulate events without a panel, through the same processing – so Flows and activators can be tried out before installation. Serial diag: ?alarm., simulation: !siasim*Nri1/BA01.

Vendor setup examples (menu names depend on model and version; the essence is the same everywhere: receiver IP + port, SIA DC-09, encryption off):

• Ajax (Hub / Hub 2 / Hub Hybrid): PRO app → Hub → Monitoring station → Protocol: SIA (DC-09), Connection: Ethernet, IP + port, Encryption: OFF, object number = account; the periodic test (“ping”) interval can be set. Ajax only sends events, it cannot be controlled through it – for arming, the hardware route (A) remains.
• Satel INTEGRA / Perfecta (ETHM-1 Plus, INT-GSM): DLOADX → Reporting → Station 1/2 → SIA-IP format, address/port, TCP or UDP, encoding: none, identifier = account. There are two stations: the myIO can be the second one, next to the real monitoring station.
• Paradox (IP150 / PCS module): BabyWare/panel programming → IP reporting → receiver IP/port, SIA or Contact ID over IP, encryption off. Paradox's own encrypted IP150 protocol is not needed here.
• DSC PowerSeries / Neo (TL280 / TL880 communicator): Ethernet Receiver 1 → SIA-IP or Contact ID, address/port, supervision off or shorter than the supervision time.
• Jablotron JA-100: F-Link → Communication → ARC → SIA IP (DC-09) on the LAN (JA-101K-LAN or JA-190Y), IP/port, without encryption.
• Hikvision AX Pro: web → Communication → Alarm Receiving Center (ARC) → SIA-DC09 protocol, IP, port, TCP/UDP; the account goes in the “account” field.
• Texecom Premier Elite (ComIP / SmartCom): Wintex → ARC → SIA IP, address/port.
• Risco LightSYS/ProSYS: Configuration Software → Monitoring station → SIA IP (DC-09), IP/port.

23. Network (Network page) 4.x

On the Network page (on 4.x controllers) you can configure the network connection – changes can be applied without a restart:

• Hostname (mDNS): the device's mDNS name, e.g. myio-nappali → http://myio-nappali.local.
• Wired (LAN): DHCP (automatic address) or static IP (address/mask/gateway/DNS). There is a DHCP fallback even with a static address.
• WiFi mode: Off / Station (STA – joins the home Wi-Fi) / Access point (AP – the controller provides its own Wi-Fi network, e.g. during commissioning). The two cannot run at the same time, but the LAN works alongside either of them. The client (STA) and access point settings are always shown; their header row tells which one is active, which is the fallback and which is unused.
• Service AP without LAN 4.18 Opta: on the Opta the LAN and the WiFi share one network stack with only 4 sockets, so the WiFi is the LAN backup: with a LAN cable the radio is off; without a cable (after about 10 s) it brings up the configured client connection, and if there is none or it fails, the access point above. The Service AP checkbox enables this last step: join the myIO-<name> network with your phone (default password myio12345 – change it!) and the controller answers on 192.168.3.1, for commissioning without a cable. On by default; a 5 s press of the USER button (network + users to defaults) also turns it back on.
• Apply / Save: Apply applies the setting immediately (without saving, for testing), Save also saves it, so it stays valid after a restart.
• Sockets (diagnostics): the right-hand status column shows the current state of the W5500's 8 hardware sockets (local port, state, remote target). ESTABLISHED = live connection, LISTEN/UDP = a service is waiting, CLOSED = free. A socket that stays stuck in the FIN_WAIT / CLOSE_WAIT / TIME_WAIT state indicates a connection leak – in that case web pages may stall and Shelly/Link devices may go offline (the !ethernet init. serial command or a restart may help). The Outgoing HTTP rows show the shared outgoing request slot of the Shelly and Link subsystems: normally “–”; a persistent HDRS/BODY state indicates a stuck request. Refresh with the ↻ button.
• Services (socket saving): the W5500 has 8 hardware sockets, and every enabled service takes one – whatever stays disabled is freed up for outgoing Shelly/Link requests (less stalling, fewer devices going offline). Switchable:
  • App server (:843): this is the mobile app's connection port. OFF by default – while it is off, the mobile app cannot connect until you turn it back on here (the web interface is always reachable on port 80 regardless).
  • mDNS (.local discovery): the myio.local name resolution. OFF by default; not needed with a static IP or if you know the IP address.
  The two switches take effect after a restart (registration happens before the network starts). Due 3.12.6+: on the Due controller the same two switches live in the Advanced Settings section of the Settings page. On old W5100-based (pre-DUEDIN 3.2) controllers both are OFF by default: there are only 4 hardware sockets there, and next to the web server the app server + mDNS can easily hang the network chip. Turning them on takes effect immediately; when the app server is turned OFF, its listener socket is freed after a restart. The UDP of Broadcast and of BroadLink/Computherm can be turned on and off on the Settings page and the BroadLink page respectively: when off, these take no socket either. Time sync (NTP) does not hold a permanent socket: if Broadcast is on, it runs over Broadcast's open UDP; if not, it opens a socket only for the ~half second of the sync and closes it afterwards – 0 sockets when idle. The Socket budget row on the right sums up how many sockets are in use and how many remain free for outgoing traffic.
• Socket manager 4.x: for each service you can tick which interface it may run on (LAN / WiFi column). The main on/off switches stay in their usual places (MQTT on its own page, BroadLink on the BroadLink page, Shelly/Link/Broadcast on Settings, app/mDNS up here) – the colored dot at the start of the row shows the live state; the mask of a disabled service is “dormant” and only matters when the service is switched back on. Rules that the budget guard enforces automatically:
  • The web (HTTP :80) row is locked: it always runs, on every interface – so you can never be locked out of the interface.
  • On WiFi the whole network stack gets 4 sockets in total (in AP mode the built-in DHCP server takes +1), so besides HTTP at most one incoming service (app843 / mDNS / Broadcast / BroadLink) can be ticked for WiFi. The interface does not allow an impossible tick, and the firmware also trims it at load time (even a hand-edited net.jsn cannot do harm).
  • Outgoing services (MQTT, Shelly+Link, myIO Cloud) do not run in AP mode – AP has no internet route.
  • Shelly and myIO Link share a single row, because in the firmware they also share a single outgoing socket: no matter how many Shelly devices and myIO servers you have, only one outgoing request runs at a time, the rest wait in a queue. So there is no point in enabling them separately, and in the budget they count as one.
  • The myIO Cloud row also covers broker self-repair: if the broker's address changes and the client persistently cannot connect, the controller downloads the new broker data (authenticated with the vendor's signature) from the built-in address. This rescue path runs over the cloud's own socket – not the shared Shelly/Link one –, so it works even if you use neither Shelly nor myIO Link.
  Fallback: if the LAN drops and traffic fails over to WiFi, the WiFi column decides exactly: whatever has no WiFi tick quietly pauses (the MQTT/Cloud client sleeps, Shelly/Link does not start requests – and does not mark anything offline because of it), then resumes by itself when the LAN returns. The matrix takes effect with the Save & Apply button (save + restart) or with the runtime apply; on the service pages a small info line shows where the mask allows the given service.

24. Save / load – slots, scenes

The controller's settings can be saved into slots – a slot can be a full backup or a scene (e.g. “Movie mode”, “Holiday”). On the Save page (or with the menu bar's quick save) you choose what to save: everything, or just one category (outputs, inputs, groups, general settings…).

• Boot slot: this is loaded when the controller starts. If you are experimenting, save a well-working state here first.
• Scene loading as an event: loading a slot can also be assigned to a button or a timer – e.g. an “Evening lights” scene on a long button press.

25. Event log (Log page)

The Evlog page shows the controller's event log broken down by day: switching events (who switched: button, web, timer, thermostat…), network events, errors. The log is written to the SD card; without a card, a reduced logging mode runs that spares the internal storage. The log files can also be downloaded from the file manager.

4.x In the 4.x firmware log, every line starts with a level marker: E (Error), I (Info), D (Debug). With the Error / Info / Debug checkboxes below the date picker you can show or hide the lines of each level. The filter only affects the display (the file stays unchanged), and only applies to new, level-tagged logs – old logs starting with a date are not filtered, and the filter bar does not even appear there.

Search and row selection: the search field below the date picker filters the table to the rows containing the typed text as you type (combined with the level filter); the ✕ button clears the search. Click a row to select it: the selected row stays visible even after the filters are cleared or changed, and the page scrolls to it, so the surrounding log lines are easy to check. Click the row again to deselect it.

26. File manager (FM page)

On the /fm page (admin) you can manage the controller's two storages: the internal flash (Q) and the SD card (S). Upload/download files, delete, rename, copy between the two storages. On the 3.12 (DUE) controller only the SD card panel is active (it has no internal QSPI storage). The Opta controller4.5.9 has no SD slot: there both panels show the internal storage, and no SD volume can be selected (not even in the recovery file manager). This is where the interface files, the settings backups and the logs live. Only change things here if you know what you are doing – after deleting the interface files the web page will not load.

Recovery file manager (/forcefm): the /forcefm address always opens the simple file manager built into the firmware – independent of the interface files on the storage. This is the lifeline if the web interface does not load (empty, corrupted or deleted storage): you can upload the interface files from it. The same page also appears at the plain /fm address if the controller cannot find the file manager's interface files.

Selection: clicking a row selects only that item (the previous selection is cleared). By clicking the checkbox column at the start of the row – or with Ctrl/⌘+click anywhere on the row – you can add or remove an item while keeping the existing selection. Shift+click selects a range from the last clicked item (Ctrl+Shift adds the range to the existing selection). The header checkbox toggles everything. Double-click enters a folder, or opens a file for viewing. In a subfolder the first row of the list is the usual .. row: one click takes you to the parent folder (the same as the ⇧ button in the panel header).

Operation window: longer operations (copy, move, upload, delete, zip) run in a pop-up window that opens in the center, with a progress bar and a Cancel button. The window's border shows the state: blue border = the operation is working, orange border = the operation is waiting for you (a confirmation or an overwrite question). If a file with the same name already exists at the destination, the operation asks file by file: Overwrite / Overwrite all / Skip / Cancel. While a folder's list is loading, a ⏳ indicator is shown in the panel header and the panel is not clickable – wait for the list to arrive.

Download as zip: a single selected file is downloaded directly; if you select several files or folders, the 📥 zip button downloads them packed into a single zip file. Selected folders go into the zip with their full content (including subfolders). The packing happens in the browser; the controller is only loaded by downloading the files one by one.

Delete: the selected items are deleted after confirmation. Folders can be deleted together with their full content (the confirmation dialog warns about this separately). Protected QSPI slots (slot_0, the boot slot, or a slot referenced by a timer/button) are still rejected by the controller in this case.

Drag-and-drop upload: you can upload files by dragging them from your computer onto the panel. If you drag the files onto a folder row, they go into that folder. After you drop them, a pop-up window shows how many files go where – the upload starts only after OK.

Date column: the files' modification time (after the size column, at the end of the row). On the SD card it is always shown; on the QSPI flash earlier firmware versions did not store it, so for files written there earlier the date stays empty until the file is rewritten once. In a narrower (tablet) view the date and the time wrap into two lines to leave more room for the file name; in a small (phone) view the column is hidden.

CSV chart: if exactly one .csv file is selected, the 📈 chart button appears in the toolbar. Clicking it opens the file in a pop-up chart view (zoom with the mouse/by dragging, time-range slider at the bottom). CSVs containing numeric time-series data can be plotted – such as the sensor and consumption logs (t_log, h_log, c_log, sdm_log); the event log (ev_log) is text, it is best viewed on the Log page. For a CSV with a header the column names come from the header; without a header the curves appear as C1, C2….

Sync menu (🔄 sync)4.4.3: it combines two functions. (1) QSPI → SD mirror: the controller copies the configuration (slot folders + root xml/csv/jsn/bak) – and, with the checkbox ticked, the htm/js web files too – to the SD card, so that in a possible restore (blank QSPI, self-healing reformat) the current state comes back, not an old backup. The mirror also runs automatically (every 6 hours, config only) and can be started immediately from the menu. Without a card (e.g. Opta, which has no SD slot) the mirror section and the “mirror now?” question after a download do not appear4.5. A foreign card (one with config on it but no mirror.tag) is left untouched by the mirror for protection – in that case the menu offers to adopt it. Secrets (cloud/license files) never go onto the card. (2) Update from HTTP: downloads the web files (js/htm) from a given CDN tree (e.g. https://okoslak.hu/ext2/) and uploads them to the device – done by the browser. Entering the plain tree URL is enough: the downloader automatically tries direct access, then the cors.php helper proxy (if the host does not send a CORS header for static files), and for http also https. If the tree has a files.jsn manifest (created by tools/gen_web_manifest.py), new files are installed as well; without a manifest only the existing files are updated, based on a size comparison. The size listed in the manifest must match the downloaded file: if a file on the tree was replaced without regenerating files.jsn (stale manifest), the downloader reports it as an error and does not write it to the device; the download everything checkbox skips the size check and accepts it. After the download the menu offers SD mirroring, so that the card is up to date as well.

26/A. System diagnostics (Sysdiag page)

The /sysdiag page (on the 3.12 DUE and on every 4.x/GIGA controller) shows the controller's internal state live, with graphs refreshed every second – a clear web version of the serial socket monitor. Panels: W5500 socket monitor (state of all 8 hardware sockets + a 60-second history graph per socket; the colors indicate the state: green = ESTABLISHED, blue = LISTEN, turquoise = UDP, yellow = stuck CLOSE_WAIT/TIME_WAIT, gray = free), memory (free SRAM ring + min. watermark + trend), storage (QSPI flash and SD card usage), M4 co-core (heartbeat + button-scanner error counters), network (link, RSSI, outgoing request queues) and boot & runtime (reset cause, crash phase, uptime, loops/s). On the 3.12 (DUE) controller a smaller set of panels is available (socket monitor, memory, boot & runtime, I2C diagnostics); the M4, QSPI and WiFi panels are specific to 4.x controllers.

Saving resources: the page loads the controller only while it is open and visible. The graph history is built by the browser (there is no background sampling in the firmware), and if the page goes to the background (another tab) or you turn off Auto refresh, polling stops – the controller is “released” a few seconds later. If you leave it open in several browsers, a warning appears in the header, because each of them loads the controller: close the unneeded ones.

27. Recipes – common tasks

Motion-sensor light

Wire the motion sensor's contact to an input, and assign the lamp's relay to its short event. On the relay: Just-ON + timer (e.g. 90 s). Every motion restarts the time.

Roller shutter with two buttons

UP relay and DOWN relay, each with a timer equal to the travel time (e.g. 25 s), and a protection pair for the two. UP button short event: toggle UP relay; DOWN button: toggle DOWN relay. While moving, pressing the other direction safely reverses the direction (the protection first stops the opposite direction).

Thermostat for a holiday home, with a network thermometer 4.x

Link the remote (Shelly H&T or another myIO) thermometer into a universal sensor. On the heating relay: activator = 300+ID, ON=18.0, OFF=19.0. Set a ±2.0 error delta: if the sensor drops out, the heating keeps running at a 50% duty cycle, in frost-protection mode.

Gate opener (pulse output)

Wire the gate motor's start input to a relay: set the relay's timer to 1 s, in Just-ON mode. Triggered from any source (button, app, timer), the relay gives a 1-second pulse.

Evening light at sunset, switch-off at midnight

Two schedules: every day at sunset the “Outdoor lights” group ON; every day at 00:00 the same group OFF. Or: set the output's activator to “Sun” (255) and its action to SunSet – then no schedule is needed at all.

Load limiting with an electric water heater

On the eManager page, for phase 1: UP threshold 5000 W, DOWN threshold 3500 W, and the output assigned to the level is the water heater's relay. While cooking, the water heater switches off automatically, then switches back on when the power becomes available again.

28. Frequently asked questions

I cannot find the device on the network. Try the http://<name>.local address, or check your router's device list. As a last resort, the device is also directly reachable in Wi-Fi AP mode (myIO-… network).

An element does not appear on the main page. Either it has no name (turn on SuperVisor and give it a name), or the logged-in user has no permission for it (chapter 22).

The timers run at the wrong time. On the General page, check the time zone setting and the NTP sync status; for sunrise/sunset, also the geographic coordinates. If the difference is exactly one hour, check the automatic daylight saving time checkbox and the standard (winter) offset (Central Europe: 1).

My sensor is in “STALE” state and the relay keeps switching. This is the failsafe: the sensor did not send data in time. Check the sending device; the switching is intentional (frost protection), and it stops by itself when the sensor comes back.

I changed something and now it is broken. Load back the last good backup on the Load page (this is why it is worth saving before every major change).

29. Programming interface (API)

The controller's full functionality is also accessible from programs over HTTP – you can write your own app, smart-home hub or script for it. The detailed, machine-readable description is in a separate document: Download the myIO API reference (API_REFERENCE.md, currently in Hungarian).

Table of contents