Persistent Issues with Somfy RTS Shades when multiple are controlled together

Devices Shades & Blinds
1

Hello Bond community,

I’m experiencing a persistent issue with my Somfy RTS shades when controlled as a group either through the Bond app or any other client through my Bond Bridge. Here are the specifics:

Setup:

  • 4 Somfy RTS shades (Sonesse 30 WireFree RTS motors)
  • Bond Bridge (perfectly positioned for coverage)
  • 2 Somfy remotes, each with 4 channels
  • All shades and remotes are paired with the Bond Bridge

When I trigger all four shades simultaneously using a group command or through homekit individually all at the same time, the last shade often fails to respond. This only happens when multiple are controlled at once; individual control works fine.

I initially thought increasing the number of signal repetitions (reps) for the commands through the API might help, but I understand this isn’t directly accessible through the API for security reasons with Somfy RTS protocol. /signal is always empty

Questions:

  1. Is there a way to introduce a delay between commands within a group action?
  2. Can the default number of repetitions for Somfy RTS commands be adjusted on the Bond Bridge?
  3. Are there any known issues with Somfy RTS shades in large groups?
  4. Could this be related to the RTS rolling code system, and if so, are there any workarounds?

The problematic shade isn’t always the same one either; it seems random

I’m open to any suggestions or solutions. Has anyone else experienced similar issues with Somfy RTS shades in group control? Any insights would be greatly appreciated!

Thank you in advance for your help!

2

I suggest to switch from Bond-based grouping to remote-base grouping. This reduce the traffic to 1 command per group, problem solved.

3

Hey, I took some time today to just implement what you are asking for:

Look for v4.7.11-beta, due to land in the apps in ~30 minutes.

Then go to bondip/bridge in your browser. Try a delay of 1000 ms to start, and you can try dropping that. Takes effect immediately on Save. There is already a 300 ms delay so this is extra on top of that.

image
image996×568 63.5 KB

1 Like
4

:exploding_head:
Hey Chris!
thanks for implementing that, will test it out and report back. I actually had been watching your YT video for the reps PATCH originally, so this is exciting!

Thanks

5

Two things:

I should point out that @Joachim47 's solution would additionally allow you to make the motors move together.

It’s very surprising to me that you would need extra delays for RTS protocol which is very popular. We added the Extra Delay knob for weird corner cases, but RTS should be solid.

Let us know if the Extra Delay fixes the issue. That would be interesting.

6

Hey Chris!
Did you put the settings page to configure the delay behind a specific URL?

I just updated to the beta but I’m not seeing a way to configure the delay on the root of my bridge’s URL?

7

It’s under /bridge. So if your Bond’s IP is 10.1.2.3, then go to http://10.1.2.3/bridge .

8

Thanks!

My issue is resolved with delays greater than 500ms it seems. You and @Joachim47 are right though, if I make combine all shades as a broadcast signal, that might be better. So I’ll be trying that next!

1 Like
9

So I resetted my shades, learned all four channels again and then added one broadcast channel that would trigger all the shades to go up and down. The only issue I have now, is that the state(s) of my shades are often out of sync since using an individual channel vs the broadcast channel would not update each other.

I guess there’s no real solution for this, but was curious if that’s what @Joachim47 and @merck had in mind?

10

The primary objective of creating a master channel is 2-fold:

  1. reduce communication from the hub
  2. sinking the movements of multiple shades
    In case someone uses the individual control at times, the master channel operation will line all shades at either endpoint so you don’t need to know the actual state of each at any given time.