Everything worth saying about luminaires and DALI control gear has been said. About sensors and push-button panels, almost nothing — even though they decide how an installation behaves day to day. This series is about them. We start with push buttons.
What is actually hanging on the wall
A typical push-button panel is momentary: you press it, and the button returns to its previous position straight away. The contact closes for a fraction of a second, and the main piece of information available to you is how long it stayed closed. That covers roughly 95% of what you see on site — ready-made panels with the mechanics and the electronics in one housing.
The second option, and a common one on real projects, is an input unit. It has no keys of its own, but it does have several volt-free inputs to which you connect ordinary electrical accessories: bell push buttons, switches, relay contacts from other equipment. The unit turns a closed contact into a DALI event. To bring something into the installation, you don't need to buy a finished panel.
Not everything you connect to such a unit, though, is a push button.
The most common case is a partition wall. In larger buildings a conference room is often split into two or four smaller ones, and the lighting has to behave differently in each of those arrangements. The wall's position is detected by a limit switch wired into an input unit. That limit switch stays closed for hours at a time, until somebody moves the wall. Dry contacts from other systems behave the same way — a relay output from a BMS panel, for instance.
This is completely different information from a push button. From a button, the application controller learns what the user has just done. From a limit switch, what state something is in right now — and it will stay that way until somebody changes it.
DALI has separate events for both cases. A user's press is described by short press and long press. The contact position is described by the raw button pressed and button released, which are sent at the exact moment the contact closes and opens. This is the first decision you make during configuration, and the most common source of silent faults. We'll come back to them at the end.
Nine events, two of which get used in practice
A single button on a panel is a separate instance in DALI: it has its own number, its own event filter and its own set of timers. A four-key panel is one device on the bus and four instances, each configured separately. Button behaviour is set at this level, not at the level of the panel as a whole.
IEC 62386-301 defines nine events for a push button instance: contact closed, contact opened, short press, double press, long press start, long press repeat, long press stop, button stuck and button free.
A typical installation uses two of them. Short press triggers the default action — most often switching to 100% or recalling a scene. Long press is for dimming up and down. The rest are edge cases or diagnostics.
The event filter decides which of them reach the bus at all. Enabled from the factory: short press, the whole long press cycle and button stuck. The raw button pressed and button released are disabled, and so is double press. A panel out of the box therefore behaves exactly as you would expect it to.
An input unit, however, ships with the same default filter — and it is the input unit that has the partition wall limit switch wired to it. There, the raw events have to be enabled by hand, or the application controller will never learn what position the wall is in.
Four timers
| Parameter | What it separates | Increment | Default | Range |
|---|---|---|---|---|
tShort | short press from long press | 20 ms | ≥ 500 ms | up to 5,100 ms |
tDouble | single from double press | 20 ms | 0 (disabled) | up to 2,000 ms |
tRepeat | repeat interval during a long press | 20 ms | 160 ms | 100 – 2,000 ms |
tStuck | time after which a button counts as stuck | 1 s | 20 s | 5 – 255 s |
You don't write a time in milliseconds into these timers, you write a multiplier. The actual time is the multiplier times the increment from the table, so tShort = 800 ms means a multiplier of 40, or 0x28.
As with most configuration functions, changing these parameters goes through the DTR0 register: first you park the value there, then you send the command that picks it up. To set tShort to 800 ms, you send:
DTR0 (0x28)— a special command, frame0xC1 0x30 0x28. The value lands in the register.SET SHORT TIMER (DTR0)— opcode0x00, addressed to a specific device and a specific instance.- The same frame again. This is a send twice command: the device executes it only after receiving two identical frames in a row, with no other frame in between (IEC 62386-101, 9.4). A single frame is silently ignored.
The remaining timers are set identically — only the opcode in step two changes: 0x01 for SET DOUBLE TIMER, 0x02 for SET REPEAT TIMER, 0x03 for SET STUCK TIMER. Reading them back uses the QUERY commands in the 0x0A–0x0F range, where neither DTR0 nor repetition is needed.
If the multiplier falls outside the permitted range from the table, the device rejects the command and keeps the old value. Without reading it back with QUERY, there is nothing to tell you that nothing changed.
Two ways of dimming
You hold the button down and the light glides downwards. To the user this function always looks the same. In DALI it is implemented in two ways, and on the bus they look completely different. Which one you get depends on the application controller — the standard doesn't settle it, because it stops at the input device.
Method 1: the controller repeats. The controller looks only at long press start and long press stop. Having received the start, it begins sending UP or DOWN commands to the luminaires itself, repeating them roughly every 150 ms until the stop arrives. The panel sends two events for the whole operation.
Method 2: the button repeats. The panel sends long press start and then long press repeat cyclically, and the controller translates every repeat into a separate action for the group. The logic on the controller side is simpler this way, which is why you meet this arrangement more often. The cost is traffic: instead of two events for the entire press, the bus gets as many as the press lasts.
With the second method, tRepeat is usually set to 100 ms, the lower limit the standard permits. Not to make the dimming smoother, but to give the controller time to process each event and put an UP or DOWN onto the group.
You don't pick a method by taste — the controller used in the installation decides it for you. But when you are looking for the cause of excessive traffic on a line, you need to know which one is running.
What to watch out for
A DALI push button that doesn't work, or responds with a delay, usually has one of four configuration causes. The first three share one thing: none of them reports an error. Nothing flashes red, nothing lands in a log. The system does exactly what it was configured to do — it was just configured to do something other than what somebody intended. So the first step is realising you need to look there at all. The fourth is the inverse of the others: it reports a fault that physically isn't there.
A disabled instance
An instance can be enabled and disabled separately from the rest of the device. It is enabled by default, but it happens that somebody disabled it during earlier configuration and never restored it. A disabled instance sends nothing — pressing the button generates no frame at all.
How do you spot it? The button does nothing while the rest of the panel may work normally. If the panel has feedback LEDs, the LED often blinks on every press — with the instance disabled, it won't. This isn't a requirement of the standard, just a common manufacturer practice, but in the field it is frequently enough to reach a diagnosis in seconds.
How do you diagnose it? Read the instance state (QUERY INSTANCE ENABLED) and compare it with the other buttons on the same panel. Application controllers usually show this outright anyway — instances carry an explicit enabled/disabled marker in the interface, and a disabled one is easy to pick out of the list.
The filter reports a closed contact instead of a press
Instead of short press, somebody enables button pressed and button released. The panel then starts reporting that a contact is closed rather than that somebody pressed a button — and the controller waits for a short press that will never arrive. This is the same mistake as in the first section, seen from the configuration side.
How do you spot it? Again: you press, and nothing happens. How do you diagnose it? Read the instance's event filter (QUERY EVENT FILTER 0-7) and check whether the short press bit is set. Watching the bus settles it immediately — with a disabled instance nothing is sent after a press, with a wrong filter the frames are there, they just carry a different event type.
Double press enabled
This one turns up rarely but can be the hardest to work out, because the symptom is nothing like the previous ones. Nothing stops working — everything starts working slowly.
tDouble is counted from the release of the button. If another press arrives within that window, a double press is generated. If it doesn't, the short press is only generated once the whole of tDouble has elapsed — the instance has to wait to be sure a second press isn't coming. Enabling double press therefore delays every single press by the full value of that timer.
Users report this as the system feeling sluggish: the light comes on with a noticeable lag. Nobody connects it with a function they generally don't even use.
How do you spot it? The panel, or the whole installation, responds more slowly than it should, with correct wiring and addressing. How do you fix it? If the application doesn't use double press, set tDouble to zero — the delay disappears and nothing changes for the user.
An input closed for hours, or the stuck button that isn't
This case applies to exactly the uses described at the start: a partition wall limit switch, a contact from a BMS panel, anything capable of staying closed for many hours.
A push button instance doesn't know that what sits on the other side of the terminals is a limit switch and not a key. It sees a closed input and counts down tStuck. Once that expires it declares the button stuck: it sends button stuck and sets the instanceError flag. tStuck defaults to 20 s, and the standard permits 255 s at most — under four and a half minutes. A partition wall stands closed for hours, so no amount of adjusting that timer will help. The stuck condition will always occur.
The problem only surfaces on release. The standard is explicit: after a stuck event the instance sends nothing until the button is released, and the release itself generates at most one event — and that event is button free, not button released (IEC 62386-301, 9.4.5 and 9.6.1). An application controller listening only for button released will never learn that the wall was opened. The lighting stays in the arrangement it was in several hours ago.
How do you spot it? The scenario switches correctly when the wall is moved quickly during commissioning, and stops working in normal use, once the wall has been standing longer than tStuck. This is the only case described here that leaves a trace: QUERY INSTANCE STATUS shows instanceError set, and QUERY INSTANCE ERROR returns the stuck bit. The message is misleading, though — it talks about a broken push button, and there is no push button there at all.
How do you fix it? The simplest route is to clear bit 7 of the event filter, that is button stuck and button free. The filter then blocks these events from occurring at all, not merely from being sent — nothing goes onto the bus, instanceError is not set, and button released arrives normally on release. You just have to remember it when commissioning any input that is meant to stay closed for a while. The other route is to handle button free alongside button released in the application controller — worth it if you want to keep stuck diagnostics working on the ordinary buttons of the same device.
This is different work from chasing a bus fault. With push buttons you rarely look for a failure. You look for the gap between what was configured and what was intended — and that is reported nowhere, so you have to go and find it by hand in the settings.
The Inspector module in Pilo One reads the real instance configuration straight from the devices: instance state, event filter and the values of all four timers. So you don't have to trust what the controller's interface shows you. Monitor, in turn, shows what actually goes onto the bus when a button is pressed — which settles immediately whether the problem sits with the panel or with the controller.
Next in the series: light sensors (IEC 62386-304).
