> For the complete documentation index, see [llms.txt](https://wiki.inels.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.inels.com/inels-bus/inels-design-manager-idm3/how-programming-works-in-idm3.md). # How programming works in iDM3 *Part 1 — Understand the system. **This is the most important chapter in the manual.*** *** Everything you will ever build in iDM3 — a light switch, a dimmer, a heating schedule, an alarm that texts you — is the same thing repeated with different parts. Learn the shape once here and the rest of the manual becomes lookup. *** ## The shape of every rule ``` ACTOR ACTION FUNCTION CONSUMER what could which event on it what to do what it's trigger this fires the rule about it done to ┌─────────┐ ┌──────────────┐ ┌─────────────┐ ┌─────────┐ │ button │───────▶│ "Short down" │────────▶│ "Digital │───▶│ relay │ │ GSB3-40 │ │ │ │ switch ON" │ │ SA3-02M │ └─────────┘ └──────────────┘ └─────────────┘ └─────────┘ │ ┌──────┴───────┐ │ parameters │ │ delay, time, │ │ level %… │ └──────────────┘ └──────────────────────── one WIRE ────────────────────────────────────┘ ``` Read it as a sentence: > **When** the button called *Hallway switch* gets a **`Short down`**, **do** **`Digital switch ON`** to the relay called *Hallway light*. The whole thing — actor, action, function, consumer — is one **wire**. Creating a wire is how you program. There is no other mechanism.
*** ## The four parts, one at a time ### Actor — what could trigger this The **actor** is the device the rule watches. Buttons, binary inputs, temperature sensors, card readers, timers, counters, time programs, even the central unit itself. An actor does not have to be something a person touches. A timer running out is an actor. A temperature crossing 21 °C is an actor. The system starting up is an actor. ### Action — which event fires the rule One actor can produce several *different* events, and you choose which one you care about. A wall button alone gives you: | Action | In plain words | Fires when | | ------------------- | ----------------- | ------------------------------------------------------------- | | `Short down` | **short press** | the button goes down | | `Short up` | **short release** | it comes back up after a short press | | `Long down` | **long press** | it is still held after roughly 1.5 s | | `Long up` | **long release** | it comes back up after a long press | | `Permanent actions` | — | repeatedly, driven by the central unit, while the state holds | **"Down" means press. "Up" means release.** That is the whole of it, and once you read the labels that way they stop being confusing: ``` press release │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ Short down │ ── quick tap ──────────▶ │ Short up │ └─────────────┘ └─────────────┘ ┌─────────────┐ ┌─────────────┐ │ Long down │ ── held ~1.5 s+ ───────▶ │ Long up │ └─────────────┘ └─────────────┘ ``` This is why one button can do four different things. `Short down` toggles the light; `Long down` turns off the whole floor. Same button, two wires, two actions. Other actor types have their own actions — a temperature sensor has `Sensor high overflow`, a counter has `Counter reached value`, a timer has `Timer elapsed`. [**Appendix A**](/inels-bus/inels-design-manager-idm3/idm3-action-reference.md) **lists all 81 of them** with what fires each one. > **You will see both names.** Older documentation — including the Rev19 installation manual — calls these *Short press / Short release / Long press / Long release*. iDM3 3.5.3 shows **`Short press` / `Short up` / `Long down` / `Long up`**. They are the same four events: down = press, up = release. This manual uses what the software actually shows you. ### Function — what to do about it The **function** is the effect. For a relay output: | Function | Effect | | -------------------------- | ---------------------------------------------------- | | `Digital switch ON` | turn it on | | `Digital switch OFF` | turn it off | | `Digital switch value` | toggle it — on becomes off, off becomes on | | `Digital impulse` | switch it, wait, switch it back (staircase lighting) | | `Digital delay switch OFF` | turn it off after a delay | | `Digital copy` | make it match whatever the actor is doing | Analog consumers (dimmers) get their own set — `Analog set level`, `Analog switch ON w ramp`, `Analog increasing level`, and so on. Heating areas, timers, counters, alarms, and the GSM module each have theirs. [**Appendix B**](/inels-bus/inels-design-manager-idm3/idm3-function-reference.md) **lists all 108** with their parameters. The function type must match the consumer type. You cannot apply `Analog set level` to a plain relay — iDM3 only offers you functions the selected consumer can actually perform, so you cannot get this wrong by accident. ### Parameters — the fine print Most functions take parameters, and this is where the useful behaviour lives. `Digital impulse` on its own is meaningless until you say *how long*. Give it an **impulse time** of 3 minutes and you have a staircase light. Give `Analog set level w ramp` a **level** of 40 % and a **ramp time** of 5 seconds and the light fades to 40 % over five seconds instead of jumping. Common parameters: | Parameter | Used by | | ---------------- | --------------------------------------------------- | | Delay (s) | anything with `delay` in the name — 0 s to 24 h | | Impulse time (s) | the impulse functions — 0 s to 24 h | | Level (%) | analog / dimming functions — 0 % to 100 % | | Ramp time (s) | the "with ramp" functions — how long the fade takes | | Set temperature | heating and cooling functions | ### Consumer — what it is done to The **consumer** is the device being acted on: a relay output, a dimmer channel, a blind actuator, a heating area, a timer, a counter, a system bit. **One wire can have several consumers.** Add three lights to the same wire and one button press switches all three. That is the simplest way to build a scene — though for anything you will reuse, a **group** is better ([Chapter 8](/inels-bus/inels-design-manager-idm3/tutorial-groups-and-scenes.md)). *** ## 2.3 Conditions — making a rule fire only sometimes So far every rule fires every time. Often you want *"turn the light on, but only if it is dark"*. That is what **conditions** are for. In the wire function window there is a **Conditions** section with an **Add condition** button, and two kinds to add: | Button | Compares | | ---------------------- | ------------------------------------------------- | | **Restriction value** | a device's state against a fixed number you type | | **Restriction object** | a device's state against *another device's* state | Each condition uses one comparison operator: | Operator | Meaning | | -------- | ------------------------ | | `=` | equals | | `<>` | does not equal | | `>` | greater than | | `>=` | greater than or equal to | | `<` | less than | | `<=` | less than or equal to | Examples of what that buys you: * *Only if the light is currently off* → **Restriction value**: that output `=` OFF * *Only if it is colder than 18 °C* → **Restriction value**: the sensor `<` 18 * *Only if the hallway light is on too* → **Restriction object**: this output `=` that output The wire fires only when the conditions pass. If they fail, nothing happens — silently, with no error. ### More than one condition Add a second condition and a **Relation** dropdown appears, letting you join them: | Relation | The wire fires when | | ------------- | ---------------------------- | | **AND** (`A`) | **both** conditions are true | | **OR** (`O`) | **at least one** is true | | first | second | AND | OR | | :---: | :----: | :---: | :---: | | false | false | false | false | | false | true | false | true | | true | false | false | true | | true | true | true | true | For more complex logic there is also a **Combination** button, which nests conditions into a group that is evaluated as a unit. > **You will sometimes see** *"In this case is allowed only AND operation"* or *"In this case is allowed only OR operation"*. That is iDM3 telling you the particular combination you are building only supports one of the two. It is a constraint of the structure, not a mistake on your part — restructure the conditions or use **Combination**. *** ## 2.4 The pieces you will meet later Wires alone would get repetitive. iDM3 gives you five more building blocks, all of which plug into the same actor→function→consumer shape: | Building block | What it is for | Chapter | | ---------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- | | **Groups** | Control many consumers as one. Use `GroupDigital…` / `GroupAnalog…` functions. | [8](/inels-bus/inels-design-manager-idm3/tutorial-groups-and-scenes.md) | | **Programs** | Time control — do something at 07:00, or between sunset and midnight. A program can be an actor. | [11](/inels-bus/inels-design-manager-idm3/tutorial-time-control-and-schedules.md) | | **Timers & counters** | Delay things, or count events and act on the total. Both can be actors *and* consumers. | [12](/inels-bus/inels-design-manager-idm3/tutorial-timers-counters-and-conditions.md) | | **System bits & integers** | The system's own memory. Store a state ("holiday mode is on") and test it in conditions. | [12](/inels-bus/inels-design-manager-idm3/tutorial-timers-counters-and-conditions.md) | | **Macros & function blocks** | Save a bundle of functions and reuse it instead of rebuilding it. | [14](/inels-bus/inels-design-manager-idm3/tutorial-macros-and-function-blocks.md) | Notice that timers, counters, programs, and system bits appear on **both** sides. A wire can start a timer; when that timer elapses it becomes the actor of another wire. That is how you chain behaviour together without any code. *** ## 2.5 Worked example: read a real one Here is a four-button glass switch in a hallway, fully programmed. Four wires, nothing more. | # | Actor | Action | Function | Consumer | Result | | - | ------------------------ | ---------------------- | ---------------------------------------- | ------------------ | ------------------------------------------- | | 1 | Hallway switch, button 1 | `Short press` | `Digital switch value` | Hallway light | Press to toggle the light | | 2 | Hallway switch, button 1 | `Long press` | `GroupDigital_SwitchOff` | Group *All lights* | Hold to turn off every light | | 3 | Hallway switch, button 2 | `Short release` | `Digital impulse` (impulse time 3 min) | Outside light | Press for 3 minutes of light | | 4 | Motion sensor, hallway | `Digital IN switch ON` | `Digital delay switch OFF` (delay 2 min) | Hallway light | Motion keeps the light alive 2 more minutes | Read wire 3 as a sentence: *"When button 2 of the hallway switch gets a short press, apply digital impulse with an impulse time of 3 minutes to the outside light."* That is the entire programming model. You now know how iNELS3 works. *** ## 2.6 Check yourself Before moving on, make sure you can answer these. If any is unclear, re-read the section named. 1. What is the difference between an **action** and a **function**? (§2.2) 2. Which one is the actor and which the consumer: a temperature sensor, and a heating output? (§2.2) 3. How would you make one button do two different things? (§2.2, and the worked example) 4. What is the difference between **Restriction value** and **Restriction object**? (§2.3) 5. Can a timer be an actor? Can it be a consumer? (§2.4) *** **Next:** [Chapter 3 — Install iDM3 and start it](/inels-bus/inels-design-manager-idm3/installing-idm3-and-first-run.md). If iDM3 is already installed, skip to [Chapter 4 — The main window](/inels-bus/inels-design-manager-idm3/the-idm3-main-window.md), or go straight to [Tutorial 1](/inels-bus/inels-design-manager-idm3/tutorial-your-first-idm3-project.md) and build the example above for real.