One landing page for the VELUX side of the ecosystem: the roof-window actuators, the control pads and hubs that make good key sources, the wired bridges, and the products controlled over 1W.

What works

Device	Status
INTEGRA roof-window actuator	✅ Confirmed — open, close, position, ventilation
KLR 200 two-way control pad	✅ Confirmed as a key-extraction source
KLR 300 two-way control pad	✅ Confirmed as a key-extraction source (one community tester)
KLF 200 gateway	✅ Key extraction succeeded (one reporter) — use SEARCH FOR PRODUCTS, and repeat it while armed if it finds nothing
KIG 300 hub	⚠️ Partial — one extraction succeeded, one stalled
Devices behind an extracted key	✅ Confirmed, with low_power: true
MSU 100100 solar awning screen	⚠️ Partial — open and close work; stop has no effect while it moves
SSL solar roller shutter	⚠️ Partial — Discover & Pair, open, close, position and status work; stop reaches it mid-travel, but not on every attempt
INTEGRA SOLAR blinds	📣 Reported, no capture
SML electric roller shutter, 1W enrollment + control	✅ Confirmed — Gear on the KLI, wait for the ready sequence, then Enroll, low_power: false
SML electric roller shutter, two-way	📣 Reported (one reporter) — Discover & Pair after Gear, with a short discovery preamble; open, close, stop mid-travel, set position and status
Interior blinds behind a KLI 312, 1W enrollment + control	✅ Confirmed — enrollment_classes: [vertical_interior_blind, interior_venetian_blind], low_power: true
FSC solar pleated blind, 1W enrollment + control	📣 Reported (one reporter) — reset, pair the KLI, Gear, wait for the ready sequence, then Enroll; enrollment_classes: [vertical_interior_blind, interior_venetian_blind], low_power: true. Discover & Pair got no answer

Onboarding routes

Key extraction, essentially always — when there's a two-way hub. VELUX installations almost all have a control pad or hub already, and that hub is what you extract from. Against a KLR 200 this succeeded end to end on the first attempt, including the node verification round that follows it.

On a KLF 200 gateway, arm the hub's Recover System Key switch, then open the KLF 200 web interface, go to the Products page and press SEARCH FOR PRODUCTS. The gateway also checks the products it already knows during that search, so it can end with "No product was found" without taking the ESP. Press the search again while the switch is still armed: in issue #195 it took several searches to deliver the key, and with it Scan Paired Devices found all the reporter's motors. COPY PRODUCTS is not a route: the gateway sends nothing a Discover & Pair could answer.

Once you hold the key, press Scan Paired Devices rather than pairing each device. Every device that trusts the key answers with a ready-to-paste snippet.

For an installation with no hub at all — only a 1W wall switch or remote, or a device fresh out of the box — key extraction has nothing to extract from. If a KLI remote already drives the product, try 1W enrollment, the route confirmed on an SML roller shutter and on KLI 312 interior blinds: press the Gear button on that remote, wait for the product's ready sequence to finish, then press the hub's Enroll button. It gives open/close/stop without status (see Sending 1W commands). An SSL solar roller shutter pairs two-way directly instead; see SSL solar roller shutter below. An SML roller shutter has been reported to pair two-way too; see the SML section below.

SSL solar roller shutter

The SSL pairs two-way directly with Discover & Pair. It needs no hub to extract a key from, only a motor-side reset.

1. Tuning. No tuning is required: the default discovery goes out behind a short preamble, which the motor answers (it ignores a 1024-byte one), and pairing uses the same length for every frame it sends to the motor afterwards. The reporters' setup also set these two lines; they are not known to be required:

home_io_control:
  tuning:
    pairing_discovery_destination: "0x00003F"   # confirmed setup; not known to be required
    pairing_discovery_ack_capable: true         # confirmed setup; not known to be required

2. Reset the motor. An SSL ships registered to its KLI wall switch. Pair it right after a reset, which clears the motor's registrations and opens a registration window (10 minutes on the P-button motor). The gesture depends on the motor:

Motor with an I/O switch and a P button (under the top-casing cover): set the switch to 0 for 10 seconds, back to I, then hold P for about 10 seconds until the shutter moves. Repeat the gesture if the window lapses.
Switchless motor with a single button ("4V" type): hold the button for about 7 seconds until the motor buzzes three times, wait a few seconds, then press it once briefly. The shutter moves to confirm.

3. Pair. Wait until the shutter has stopped moving, then press Discover & Pair. Repeat it if the first attempt finds nothing. The motor doesn't answer the optional settings frame at the end of pairing; the log says so, and the pairing is complete anyway. Add the printed snippet with low_power: true:

cover:
  - platform: home_io_control
    name: "Roller Shutter"
    io_device_id: "BE2142"          # from the pairing log
    io_device_type: "roller_shutter"
    io_subtype: 0
    low_power: true

4. Register the wall remote again. The reset removed it. Short-press the motor's button (P on the I/O-switch motor; the switchless motor then moves three times, so wait until it stops). Then press the remote's recessed registration button with a paperclip, and close the shutter fully with the remote's down button. The remote and the hub then both work. Use a short press here: the long hold from step 2 resets the motor again and removes the hub as well.

In use: open, close, set position and status work from rest. A command can take up to three tries to reach a sleeping motor. A stop sent while the shutter moves reaches it, and so do the status polls that follow (the one right after the stop makes up to three tries), so the shutter halts and its real position arrives about a second later. It does not land on every attempt — press stop again if the shutter keeps moving, or use the wall remote.

SML electric roller shutter

The mains-powered SML takes either route. 1W enrollment gives open, close and stop without status, as described under Onboarding routes above. Two-way pairing, reported by one user on an SX1262 board (issue #230), gives status, position and a working stop mid-travel as well.

Two-way pairing. The shutter needs a short discovery preamble, as the SSL does, and the default is short: 48 bytes on an SX1262, where the reporter paired at 32. The reporter also set this line, which is not known to be required:

home_io_control:
  tuning:
    pairing_discovery_ack_capable: true

Press Gear on the shutter's own KLI 310 for about one second; the shutter starts to jog. While it jogs, press Discover & Pair. Press it again if the first search gets no answer: in the report the second search found the shutter. Pairing ends the registration window, so the shutter stops jogging. No motor reset is needed, and the KLI remotes and a 1W enrollment of the same shutter keep working. Discover & Pair found nothing in issue #17, which ran with a 1024-byte discovery preamble; the reporter of issue #230 paired with a 32-byte one. It is not known yet whether pairing_discovery_ack_capable matters.

Once paired, the shutter answers status reads while it moves, with the time left to its target, so the position in Home Assistant follows the move. Stop mid-travel works, set position lands within a few percent, and a press on a linked KLI shows up as described in Linked remotes.

Several shutters on one KUX 110 run one at a time. A shutter commanded while another one on the same KUX 110 moves accepts the command and starts when the first has finished. While it waits, it reports that it waits for power, and the hub follows it: Home Assistant shows the cover opening or closing toward its target, Active Issue reads NODE_WAITING_FOR_POWER, and the position follows once the motor runs. The hub follows a cover for 4 minutes after the command, which covers two shutters one after the other. This is experimental: the waiting state was captured in a main-parameter status read of an SML shutter, not yet in an ordinary status read (see Position and state). The group KLI moves the shutters one after the other.

Working YAML

home_io_control:
  # ... radio pins ...
  node_id: "810BAB"        # recovered from the KLR 200
  system_key: "…"          # recovered from the KLR 200
  scan_paired_devices_button: true

cover:
  - platform: home_io_control
    name: "Roof Window"
    io_device_id: "6544C6"
    io_device_type: "window_opener"
    io_subtype: 0
    low_power: true

io_device_type: "window_opener" is what generates the Ventilation Position button, which moves the window to its predefined air-exchange opening rather than fully open.

Known quirks

low_power: true is usually required for directed commands. VELUX actuators are frequently solar or battery powered and sleep between commands. Without this the hub addresses them with the wrong preamble. scan_paired_devices does not consult this property — its low-power pass is built specifically to reach a sleeping device and pre-fills low_power: true in the ready-to-paste snippet when it hears one — but a directed command (open/close/stop, status polls) still needs the property set to reach the device once it is registered. If a known device's scan result shows a hint: line, follow it: that means the registered YAML and the device's self-reported power class disagree.
A moving VELUX solar product answers only the short start preamble. It ignores the 1024-byte wake-up burst that reaches the same motor at rest, so the hub leads with the short preamble whenever it has reason to believe the motor is awake — see `low_power_wake_belief`. On the SSL solar roller shutter that is what lets a stop, and the status polls after it, land mid-travel; it does not land on every attempt, so press stop again if the shutter keeps moving. A status poll that goes unanswered while the shutter's own remaining time says it is still travelling does not switch the hub to the wake-up preamble; the read at the predicted end of travel leads with it (experimental: not yet confirmed on a solar shutter). Leave low_power_wake_belief on: with it off, every stop goes out with the long preamble and never lands mid-travel. The boot log states it (Low-power wake belief: on). At rest the SSL answers only the wake-up preamble, and only on about half the tries; if commands to a resting shutter often need a second press, try a longer `low_power_wake_preamble`. There is no such result for the MSU solar awning screen, so expect a mid-travel stop to do nothing there and use the product's own wall remote.
1W enrollment is a Gear press on the existing KLI, not a button on the product. Press the Gear button ("open for registration") on the KLI that already drives the product for about 1 second. Not the Pair button: that one is for a new control, which the hub's Enroll button stands in for, and Gear followed by Pair on the same switch deletes all its products. The product then runs a ready sequence that can take half a minute on a shutter (travel to about 10% closed, several jogs, back to the start); once it has finished, press Enroll on the hub. If the cover ends up fully closed, the closing step at the end of Enroll shows no movement, so check with Open afterwards. The enrollment classes must match the remote: the default fits a KLI 310/313 (exterior shading, e.g. an SML roller shutter), while a KLI 312 interior blind needs enrollment_classes: [vertical_interior_blind, interior_venetian_blind]. The remote's own 0x2E log lines after Gear name the classes. Confirmed in issue #74 (see Sending 1W commands).
The KUX 110 powers the products; each KLI pairs with each product directly. It feeds 24 V DC to mains-powered products such as SML roller shutters, and the io-homecontrol receiver that the hub and the KLIs talk to is in each product's own motor. The KUX 110 also has an RF unit of its own according to its instructions, and products on one KUX 110 run one at a time (see the SML section above); what that RF unit does is not known. An SML can equally be powered from an electric roof window with no KUX at all. If several products share one supply, a reset that works by interrupting power resets every product connected to it — including their pairings with the hub. Disconnect the others first if only one should be reset.
One Gear press can open several products at once. Gear opens registration on every product that KLI drives, and each of them then registers whatever control is enrolled next. For one Home Assistant cover per product, enroll one identity per product and press Gear on a control that drives only that product.
VELUX uses a different 1W enrollment gesture from Somfy, and a different priority byte on CMD_EXECUTE. Set manufacturer: velux on any 1W identity aimed at these devices — see Sending 1W commands.

Roof window travel speed

A VELUX control pad moves a window with a short command that carries no speed, and the window travels at its own speed. The hub asks for the fast profile unless told otherwise, so a window it moves runs faster and louder than from its pad: a full travel of one roof window took 44.5 s from its KLR 200 and 26.5 s from the hub (issue #205). Set travel_speed: default on the window's cover for the pad's speed, or silent for the slowest, about 65 s; see Travel speed.

Rain protection

A VELUX window with a wired rain sensor limits its own opening while it rains and then refuses to open past its ventilation position. The rain sensor talks only to the window, so the hub learns about rain only by asking. Set rain_sensor_poll_interval on the window's cover to read the window's opening limit on a schedule; the hub then generates a <Cover Name> Rain sensor binary sensor that is on while the window's minimum limit is 89 % or more:

cover:
  - platform: home_io_control
    name: "Roof Window"
    io_device_id: "123ABC"
    io_device_type: window_opener
    rain_sensor_poll_interval: 15min

This is hardware-validated on a VELUX INTEGRA roof-window actuator with a wired rain sensor (issue #98). The reading is as fresh as the interval and uses transmit time on a shared band, so pick the interval with Polling for rain. VELUX KLF 200 API specification v3.18 (section 8.1) describes the same arrangement: a gateway learns of rain only by asking the window.

How it relates to Active Issue

The two entities answer different questions and work independently:

Rain sensor says the window reports an opening limit right now.
Active Issue shows LIMITATION_BY_RAIN while the last move was ordered by the rain sensor, or while an open stops short soon after the window last reported the rain sensor. The hub works this out from the status replies it already reads, with no extra radio traffic, so it only updates on the next command or status poll. It clears after the next open that reaches its target.

Other signs of a rain closure, without the poll:

Last Command Source shows rain_sensor(0x02) after a poll that follows a rain closure.
The cover stops at the ventilation position (about 93 % closed on the INTEGRA window that reported this) instead of opening fully.

The same read is available once as the limitation diagnostic probe, for checking what a window reports without enabling the sensor. Field data comes from issue #98.

A rain closure moves the window without telling the hub, so the cover keeps its old position until something reads it; so does a KLR 200 command the hub did not overhear. Set status_refresh_interval on the window's cover to read it at rest on a schedule; see Refreshing the status at rest.

Evidence

Corpus captures across the family: 5 for the INTEGRA roof-window actuator (probe replies, a dry and a rain-limited limitation read, and private-function sweeps dry and in the rain state, from issue #98), 1 for a KLF 200 gateway polling nine devices at 868 MHz (issue #98), 1 for the successful KLR 200 key extraction (node 810BAB, issue #80), 2 for a KLR 300 extraction and the node verification round after it (node E2D1FF, a community tester), 4 for the KIG 300 hub (node BEFEDB), 3 for KLR200 ↔ KUX100 bridge traffic, 3 for the KLI 310 and KLI 313 remotes, and 6 for the SSL solar roller shutter (a TaHoma pairing it; this hub pairing it, with the long preamble ignored and the short one answered; a set-position ack; a stop and status polls that go unanswered while it moves).

Field reports: #17 (SML discovery), #74 (SML roller shutter, KLI 312 blind and FSC pleated blind 1W enrollment), #80 (KLR 200 extraction), #87 (roll-call preamble), #95 (MSU screen stop), #98 (INTEGRA probes), #112 and #114 (SSL solar roller shutter), #195 (KLF 200 extraction), #205 (roof window travel speed), #230 (SML two-way pairing, shutters queued on one KUX 110).