Overkiz integration: confirm whether Somfy TaHoma Zigbee group entities are commanded as true groups or expanded to individual covers

Third party integrations
1

Overkiz / Somfy TaHoma Zigbee Groups - How Are Group Commands Handled?

I’m trying to better understand how the Overkiz integration handles Somfy Zigbee group entities and whether the integration preserves Somfy’s intended group behavior.

Environment

  • Home Assistant Core 2026.x
  • Overkiz Integration
  • Somfy TaHoma Hub
  • Somfy Sonesse 40 WireFree Zigbee battery motors

Background

Within Home Assistant, the Overkiz integration exposes both individual shade entities and what appear to be dedicated Somfy Zigbee group entities.

Examples in my installation include:

  • Dining Group (6 shades)
  • Kitchen Group (4 shades)
  • Family Patio Group (3 shades)
  • Family TV Group (3 shades)

These group entities are separate from Home Assistant cover groups that I create myself.

When I control the group entities exposed by Overkiz, performance is noticeably better than sending commands to individual shades or using a Home Assistant cover group. This suggests that some type of grouping is being preserved.

What I’m Trying to Understand

When I call:

service: cover.open_cover
target:
entity_id: cover.some_somfy_group

or

service: cover.close_cover
target:
entity_id: cover.some_somfy_group

what actually happens behind the scenes?

Specifically:

  1. Does Home Assistant simply send the command directly to the TaHoma group object?
  2. Does the Overkiz integration translate the command into multiple individual shade commands?
  3. Has anyone verified whether these exposed group entities represent true Somfy Zigbee groups?

Why I’m Asking

I have been discussing synchronization behavior with Somfy support. Their explanation is that dedicated Zigbee groups were created specifically to allow multiple motors to move in unison and are only exposed through third-party integrations.

Before I spend more time troubleshooting synchronization behavior, I’d like to understand whether Home Assistant is preserving the Somfy group object exactly as intended or whether there are any known limitations in how Overkiz exposes or handles these entities.

I’m not reporting a bug at this point. I’m simply trying to understand the architecture and expected behavior.

If anyone familiar with the Overkiz integration or its implementation can provide insight, I’d appreciate it.

2

Already discussed 1:1 via another channel, adding my reply here for full transparency.

Today, Home Assistant will sent each command as a single Action in an Action Group. This means that every device command will end up in a single execution.

This is the reason why you might see a small delay between executions, when you use a scene or group in Home Assistant. For 16 devices, it will create 16 executions. The limit of a Somfy gateway is ~10 executions, thus we do retry here on errors. You should be able to see this in the log when you turn on debug mode in HA.

If you create a scenario in your TaHoma app, all device commands will be grouped in a single Action Group, thus there should be no delay. If there is a delay, that is due to the communication between your gateway and your devices.

We are working on a new feature where we look at requests executed in a very short timeframe in Home Assistant, and we combine multiple commands in a single execution.

You can give this a try: Commands lost when controlling multiple covers simultaneously via Local API (execution queue full) in Overkiz · Issue #169923 · home-assistant/core · GitHub, to see if it solves your issues.

3

Hi Mick,

I have a question and wanted to get your thoughts before I continue expanding my Somfy installation.

I’m currently running a single TaHoma hub with 16 Zigbee shades and several Zigbee routers (Somfy smart plugs, IKEA plugs, and recently a Legrand Netatmo in-wall outlet). The local Overkiz integration in Home Assistant continues to work well.

Today I noticed something odd:

  • Home Assistant (local API) continues to communicate with the hub normally.
  • I can still see device states through the local integration.
  • However, the official TaHoma app started showing errors on multiple Zigbee routers and some device states stopped updating correctly.

This made me wonder whether the issue is in the Zigbee network itself or somewhere between the hub and the TaHoma cloud/app, since the local API appears unaffected.

Separately, I’m planning to expand to approximately 44 Somfy Zigbee shades and am considering using two (or possibly three) TaHoma hubs to segment the installation.

I found your comments regarding multiple gateways and wanted to ask:

  1. Does the Home Assistant Overkiz integration support multiple local TaHoma hubs (each configured with its own local host/token)?
  2. Is there anything in the current integration that would prevent this architecture?
  3. Does the behavior above (local API working while the TaHoma app reports errors) suggest a cloud/app issue rather than a local gateway issue?

Thanks again for all your work on the integration. It’s been extremely helpful throughout this project.

4
  1. If you can add them to your Somfy app, we can support it in the Overkiz integration.
  2. Not that I am aware of.
  3. The app doesn’t use the Local API, thus it could indeed be indeed an connectivity issue.

When you only use ZigBee devices, why wouldn’t you link them directly to Home Assistant via ZHA/Zigbee2mqqt?

5

Thanks, Mick. That makes sense and is helpful.

For my own home, I would absolutely use ZHA or Zigbee2MQTT.

This installation is actually my in-laws’ home. I originally built the Zigbee network using an SMLIGHT MR3 PoE coordinator with Zigbee2MQTT, and it worked well overall. The challenge was that when something occasionally went off the rails, it required troubleshooting, restarting services, or adjusting the network. For my family, I was looking for something that is more appliance-grade and requires less ongoing maintenance.

I actually just brought up ZHA on the MR3’s second radio for another project because I wasn’t completely satisfied with the stability of my Thread network. In fact, I’m now considering migrating my own Zigbee network from Zigbee2MQTT to ZHA to simplify things and hopefully improve long-term stability.

For the shades, though, I intentionally wanted a manufacturer-supported solution while still integrating it locally into Home Assistant through the Overkiz integration.