SOMFY Shutters in Home Assistant: Rolling Code Explained

I have six roller shutters in the house, all SOMFY, all driven by RF remotes. And I’ve burned far too many evenings getting them into Home Assistant. The short version, so you don’t have to repeat my route: rolling code cannot be cloned. Every €15 “universal RF code copier” you find online fails at this, systematically and by design. “Universal”, for a box that can copy exactly one kind of code.

What’s left is essentially two paths: one expensive and boring, one fiddly and genuinely working. In order.

The actual problem: rolling code

An old garage door opener sends the exact same bit pattern on every button press. Record, replay, done — that’s fixed code.

SOMFY RTS does something else. Every remote has an address and a rolling code: a counter that increments on each press and is sent encrypted alongside a checksum. The motor remembers the last counter value it saw and only accepts what comes after it.

The consequences:

• A captured frame is worthless after a single use.
• A replay with the same counter is silently ignored.
• You can’t “listen and imitate”. You have to become a valid transmitter yourself — keep your own counter and pair with the motor.

That’s exactly the point where 90% of the guides on the internet stop and leave you standing there.

Quick clarification: RTS is not io-homecontrol

Two SOMFY radio families that get confused constantly:

• SOMFY RTS — the older, widespread family. Transmits on 433.42 MHz (not 433.92 like almost everything else — a very common source of failure), one-way, no return channel. The motor never tells you where it is.
• SOMFY io-homecontrol — SOMFY’s newer family, bidirectional, encrypted and effectively closed. It lives in the 868 MHz band. There is no realistic DIY path here: official bridge or nothing.

Important: that 868 MHz mention applies to io-homecontrol and nothing else. It has no bearing on garage door handsets or any other 868 MHz gear — none of that is relevant to RTS shutters.

Check this first. If your remote says “RTS”, you have options. If it says io-homecontrol, you can skip the rest of this article and go straight to the official bridge.

The realistic paths compared

Path	Cost	Effort	Reliability	Who it’s for
Official bridge (TaHoma / Connectivity Kit)	~£90–220	One evening	Very high, cloud-dependent	Almost everyone
FHEM bridge with a CUL (SOMFY module)	~£55–80	1–2 weekends	High, fully local	Patient tinkerers

Path 1: The official bridge — the honest recommendation

I earn the least from this recommendation, and it’s still the right one for most people: buy the official bridge.

A TaHoma Switch or a Connectivity Kit pairs with your motors just like an extra Somfy RTS remote*, and Home Assistant ships an official Overkiz integration for it. Setup: add integration, enter your Somfy account, entities appear. After that you have cover.* entities that just work, and will still work in six months.

The price is annoying. The cloud dependency is more annoying — why a shutter needs an account to go up and down, nobody has been able to explain to me. But if your shutters need to open at 7am and your family has no interest in what a rolling code is, this is the option with the best result-per-hour-of-life ratio.

Path 2: FHEM as a bridge — what I actually run

My setup is different, mostly for historical reasons: FHEM drives the shutters via a CUL radio module, and Home Assistant drives FHEM. Sounds like a detour, but it’s the most stable DIY solution I’ve managed to build — and it’s entirely local, no cloud.

FHEM has a mature SOMFY module that manages the rolling code itself. That’s the whole point: FHEM doesn’t clone a remote, it becomes one. Each device gets its own address and its own counter.

define rollo_office SOMFY D10002
attr rollo_office IODev CUL433_DIRECT
attr rollo_office room Shutters
attr rollo_office model somfyshutter

Pairing happens at the motor, not at the computer:

1. Put an existing remote into programming mode (Prog button on the back, hold until the shutter jogs).
2. In FHEM, send set rollo_office prog once.
3. The motor acknowledges with a short jog. Paired.
4. Then test set rollo_office on / off a few times.

Two traps that cost me hours:

• The commands are not open/close. The SOMFY module knows on, off, stop, prog, pos and position. In my setup off = open and on = close — it feels backwards, but that’s the convention.
• pos doesn’t work without travel times. Intermediate positions require you to configure the motor’s run times as attributes. Without that you only get fully open or fully closed.

When a shutter stops responding here, the pairing has almost always been lost (dead remote battery, motor was off the mains). The fix is always the same loop: create a new device with a fresh address, send prog, test, delete the old one. Never try to rescue the broken entry — a new address is faster.

The bridge into Home Assistant is FHEM’s web interface used as a REST endpoint:

# configuration.yaml
rest_command:
  fhem_cmd:
    url: "http://192.168.1.50:8086/fhem?cmd={{ cmd | urlencode }}&XHR=1"
    method: GET

cover:
  - platform: template
    covers:
      rollo_office:
        friendly_name: "Office Shutter"
        open_cover:
          service: rest_command.fhem_cmd
          data:
            cmd: "set rollo_office off"
        close_cover:
          service: rest_command.fhem_cmd
          data:
            cmd: "set rollo_office on"
        stop_cover:
          service: rest_command.fhem_cmd
          data:
            cmd: "set rollo_office stop"

That gives you an ordinary cover entity that behaves like any other in automations, dashboards and voice control:

curl -X POST \
  -H "Authorization: Bearer $HA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"entity_id": "cover.rollo_office"}' \
  http://192.168.1.50:8123/api/services/cover/close_cover

One honest drawback: because RTS has no return channel, the state in Home Assistant is always a guess. If someone uses the wall remote, HA has no idea.

Variant: your own 433.42 MHz transceiver

If you’d rather not run FHEM, the third option is your own radio module tuned to 433.42 MHz — typically a CC1101 on an ESP32 or a Raspberry Pi. The important part here isn’t sniffing either: the firmware has to keep its own rolling code counter and pair with the motor properly. Anything else is wasted time. Effort is roughly on par with FHEM, and in my experience the results are a bit less solid — mostly because the frequency has to be spot on.

What definitely does not work

• Universal cloning remotes from marketplaces. They copy fixed code. With RTS they appear to pair, blink happily and then do nothing. Money gone.
• Code grabbers and replay. The counter is spent after the first transmission. A second attempt with the same frame is discarded by the motor.
• 433.92 MHz hardware for SOMFY RTS. That 0.5 MHz offset from 433.42 costs you so much receive quality you’ll conclude the protocol is wrong. Buy explicitly for 433.42 MHz — or use a CC1101 where you set the frequency in software.
• The pragmatic escape hatch I don’t look down on: a SwitchBot Bot button pusher* sat on the existing remote. Ugly, but done in ten minutes and 100% rolling code compatible — because the real transmitter is doing the transmitting.

If you like the idea of tapping the existing handset itself rather than pushing its buttons with a robot: that is genuinely the cleanest approach, but it suits garage doors far better than shutters. Wiring an original remote’s button contacts to GPIO via a transistor or optocoupler is a topic I cover in a separate article — it doesn’t fit here.

My verdict

If you just want the shutters to follow the sun: official bridge. Yes it costs money, yes it wants an account. It works.

If local control matters more to you than a weekend: FHEM with a CUL and a REST bridge into Home Assistant. That’s been running here stably for months, and the SOMFY module saves you the entire rolling-code problem.

And if you really want to build your own 433.42 MHz module: do it — but build it next to your working setup, not instead of it.