Somfy io-homecontrol: A Closed Protocol, Chosen on Purpose

This post may contain affiliate links. As an Amazon Associate we earn from qualifying purchases. Disclosure.

Everything else in this house was picked to avoid exactly what Somfy is: one vendor owning a radio protocol, a hub, and an app. The lighting has no bridge at all. The heat pump talks MODBUS. And then twelve windows got motors from a single French manufacturer speaking a protocol nobody else implements.

TL;DR: io-homecontrol is a closed, two-way 868 MHz protocol. It was chosen for twelve external roller shutters and a Dexxo Smart io garage drive because external shutters are a warranty-and-bricks decision, not a smart home decision. The cost is real: app control goes through Somfy's Overkiz cloud, and these shutters are not yet exposed to Home Assistant at all.

That contradiction is worth explaining rather than hiding, because it is the most common shape a real build takes. You do not get to apply one principle everywhere. You get to decide which system is allowed to be the exception, and this one was made the exception on purpose.

Photo by Pawel Czerwinski on Unsplash

What Is Actually Installed Here

Twelve io-homecontrol motors, and every one of them drives an external roller shutter. Not internal blinds, not awnings. A Dexxo Smart io drive on the garage door. A TaHoma Switch as the hub, with a second hub planned. An iZymo in-wall io transmitter, a Keygo io remote, and a gate motor still sitting in the plan rather than on the pillar.

That inventory matters for reading everything below, because external shutters behave nothing like the internal blinds most shutter articles are quietly about. An external shutter is part of the building envelope. It is mounted in a box above the window opening, it runs in side guides screwed to the reveal, and once the facade is finished you are not swapping the motor without taking something apart.

Why Not an Open Protocol?

This is the question that deserves a straight answer, because the obvious one is wrong.

The obvious answer is "io is better radio". It partly is. io-homecontrol runs at 868 MHz, which penetrates masonry noticeably better than 2.4 GHz, and it is bidirectional, so the hub knows whether a shutter reached 40 percent or stalled at 60. A one-way RTS motor or a cheap Wi-Fi module just fires a command into the air and hopes. For a device you cannot see from inside the house, knowing the actual position is not a luxury.

But that is not why the decision went this way, and pretending otherwise would be dishonest. A Zigbee shutter module, a Sonoff MINI-ZBR3 for instance, will drive a tubular motor perfectly well for a fraction of the price. That module runs elsewhere in this same house. The reason it is not in the shutter boxes is duller and more expensive.

The Real Reason Is Who Warrants the Assembly

External roller shutters were bought as complete units, boxes and guides and motors together, from the shutter manufacturer. The motor is a line item inside that order, not a separate purchase. Substituting a third-party module into that assembly means the person who made the shutter no longer owns the failure.

And shutters fail in ways that are annoying to argue about. A slat jams. The end limits drift. Something binds in the guide after a hard frost. When the whole assembly comes from one supplier with one warranty, that conversation is short. When you have bolted your own controller into it, it is not.

Is that a satisfying engineering answer? No. It is a procurement answer. But a build has a lot of those, and a blog that only reports the engineering ones is describing a house nobody built.

The Part Everyone Gets Wrong: When You Decide

Here is the thing that actually costs people this option, and it has nothing to do with protocols.

Shutter motors have to be specified before the windows are ordered. Not before installation. Before the order.

Photo by Shiola Odan on Unsplash

The box above the window has to be sized for a motor. The 230 V supply has to be chased into the wall and terminated at the box before anything is plastered. The window frame, the box, and the guides go in as one operation. These motors were specified while the windows were still holes in the wall, and that is not a boast about foresight, it is the only time the decision exists.

Miss that window, literally, and the honest options collapse to internal blinds or a visible surface-mounted retrofit. Both are fine products solving a different problem. Neither gives you the thermal and blackout performance that made external shutters worth wiring for in the first place.

What This Means for Your Electrician Conversation

The instruction your electrician needs is not "smart shutters". It is a 230 V circuit terminated in each shutter box, with the boxes on a sensible grouping so that a future hub can address rooms rather than individual windows. That is it. The radio side needs no cabling at all, which is precisely why the wiring decision has to be right first time: nothing about it is fixable over the air later.

Motor Sizing for Heavy External Shutters

Internal blind guidance does not transfer here, and the numbers are not close.

An external aluminium shutter over a wide opening is genuinely heavy, and the load the motor sees is dominated by the weight of the curtain plus friction in the guides. Undersize it and the motor runs hot, the end limits start creeping, and the thing that fails is inside a sealed box. Somfy's own S&SO RS100 io family sits at the sizes that suit domestic external shutters, and one of those is documented in this build.

The sizing rule that matters: take the largest opening in the house and specify the motor for that, then accept the small overspend on the narrow windows. Mixing four different motor torques across twelve windows to save money creates a spares problem in year eight that dwarfs what you saved.

Wind Sensors Are Mostly Not Your Problem

Somfy sells wind sensors and plenty of articles treat them as mandatory. For external roller shutters in side guides, they largely are not. The curtain lies flat against the facade and the guides carry the load, so wind does not get the leverage it would need. Wind sensors earn their keep on awnings and fabric screens, which are cantilevered out into the weather and can be destroyed by a gust.

The genuine environmental threat to a guided external shutter is frost. Water gets into the guides, freezes, and the motor pulls against ice. The automation worth building is a temperature interlock, no scheduled movement below freezing or after freezing rain, and it is a rule almost nobody writes about because they are busy writing about wind. Sun sensors are planned here and not yet fitted, so that automation is still a design rather than a running system.

Where Overkiz Hurts

Now the honest accounting, because this is the part the protocol choice actually costs.

Somfy's cloud platform is Overkiz. Control the shutters from the vendor app and the request leaves your house, reaches Somfy's servers, and comes back to the hub sitting fifteen meters away on the same Wi-Fi. That round trip is why app control feels a beat slower than a remote, and it is why a Somfy outage is a thing that can happen to your windows.

Three consequences follow, and they are not equally bad.

• Latency you can feel. A press-to-move delay of a second or two. Irritating, not serious.
• A dependency you did not choose. Somfy's uptime becomes part of your house's uptime for anything going through the app.
• A privacy surface. The times your shutters open are a reasonable proxy for when you get up and when you leave.

Newer TaHoma hardware exposes a documented local API, and that is the escape hatch. The Home Assistant Overkiz integration can talk to it directly on the local network, which removes the cloud round trip from everything you automate yourself. The vendor app keeps using its own path regardless.

One thing I will not claim: as of writing, these shutters are not connected to Home Assistant. The TaHoma Switch runs them, the physical remotes run them, and the local API integration is the next task rather than a finished one. Anything you read anywhere about sun and outdoor temperature closing shutters before the air conditioning fights them describes what the platform can do. In this house it is a plan.

The Gradient Nobody Writes About

The most useful thing io bought here is not a feature, it is the ability to spend differently room by room.

The living areas get proper wall controls. The garage gets an iZymo, an in-wall io transmitter that sits behind an ordinary light switch and costs a fraction of a touch panel. Same protocol, same automation, same hub, wildly different spend, and the physical switch on the wall keeps working exactly as a switch.

That gradient is only possible because every one of those devices speaks the same radio. Guides that sell you one standard for the whole house are describing a budget nobody has. Real builds decide per room, and the protocol either lets you do that cheaply or it does not.

Would I Do It Again?

For external shutters and the garage, yes, and without much hesitation. The closed protocol is the price of buying the shutter and its motor as one warranted object, which is the right trade for something buried in a wall for twenty years.

For anything I could reach with a screwdriver, no. Lighting here is unbranded Zigbee straight to a USB coordinator, with no bridge and no vendor account, and that was the right call for exactly the opposite reason: a ceiling light is replaceable, so nothing about it should be tied to a company.

The rule that falls out of this is narrower than "avoid lock-in", and more useful. Accept a closed system where the hardware is structural and the vendor warrants the assembly. Refuse it where the hardware is a consumable. Then make sure the layer above both of them is yours, which is the whole argument for keeping Home Assistant at the top of the stack.

Twelve motors is enough to have opinions about. It is also enough that changing my mind would cost more than the house's entire lighting budget, so the opinions had better be right.