[Store] Volets et stores Somfy (Bridge Connexoon)

[Dom-54]

Maybe Horia …

[Horia]

Update,

With 60 min timer on Master Data,

response is <?xml version="1.0" encoding="ISO-8859-1"?><somfy><resultat>3</resultat></somfy>

Hence, it seems issues are API abuse on Somfy Cloud...

I suggest we set 60 min timers on MasterData and Compteur Devices. I will leave these for a week and see what its doesn't.

Horia

PS: Tested e2e, works again.

[Horia]

My explanation,

Public clouds are sensitive especially if APIs are early days and not properly documented/published.

Our real actions from eedomus on our IO, RTS devices are seldom, but with 1min on MasterData and CompteurDevices, we put pressure on the SomfyCloud,

Not knowing the SLA/PKIs they target, the easiest is to assume we have to relax, hence my suggestion for 60 min synch on MasterData and the DeviceCounter.

I am almost now sure this is where the issues came from, because I did not change passwords, did not touch anything else, but relax the API frequency on the Somfy Cloud.

As you know devices open slow, like a velux a store takes more than a minute....The MasterData was pushing too much on the SomfyCloud, I checked now and for opening or closing, I just get in eedomus start and end states not anymore intermediate states.

The liste.php upgrade was imho a mistake, did not account of the constrains in the Somfy Cloud.


Horia

[Horia]

I will try 60min for 24h, see how happens in history of MasterData, and next decrease to 10 min like the netatmo cloud even they suggest this just because of the base station and the 433MHZ device pool time, because of battery....

Horia

[Horia]

A positive change already,

[Horia]

Probably 30 min pool time on MasterData and CompteurDevice is decent.

Like I said, pooling too often from a cloud is an attack on the cloud, and we should have learned.

IO and RTS devices like stores, windows, etc react very slow so no point to have a master service to monitor their progress, just make sure everything works fine still.

I developed a lot of things in my life, and I think the latest version was a failure, lost my touch.

Horia

[Dom-54]

Very good Horia !
Have a good we.

[Horia]

Better on 60 min refresh, imho

[Horia]

Update:

Everything is very stable with 60 min refresh on MasterData and on Compteur Devices...

No changes in the states for these two objects anymore, and also when rules control the IO devices, no more intermediary states by the local API. Like I said, to open/close a Velux takes a while, and who cares about where is in the process? We should just care that the process is done.

Regards, Horia

[Harzhal]

Bonjour à tous et plus particulièrement à la TeamListSomfy.

Je rappelle que ce plugin me sert uniquement à piloter 5 volets de Velux solaires au moyen d'un bridge Connexoon et c'est pour ça que jusqu'ici, je me suis contenté de rester sur la version V2... MAIS...Depuis hier (hormis que tout est OK à partir de l'appli Somfy Window) tout est out à partir d'eedomus comme le montre la capture ci-après.

Capture d’écran 2021-12-19 à 17.14.07.png (61.1 Kio) Consulté 11007 fois

J'ai vu qu'il y avait une mise à jour Somfy à faire mais ça ne change rien alors je me dis que je vais être obligé de passer à la version V3 parce que la V2 est maintenant complètement obsolète ou est-il encore possible de corriger ce problème de liaison...

Votre avis SVP.

P.S. Vous avez fait un super boulot

[Herric]

Not knowing the SLA/PKIs they target, the easiest is to assume we have to relax, hence my suggestion for 60 min synch on MasterData and the DeviceCounter.

I am almost now sure this is where the issues came from, because I did not change passwords, did not touch anything else, but relax the API frequency on the Somfy Cloud.

Hello @Horia,

sorry to disagree with you but your analysis is wrong.

As I wrote in a previous post : The somfy API is sensitive to the number of logins, not to the number of requests.

The V2 and V3 of the script are based on a single login + a registration to cloud events (fetch requests).
- A login to the cloud is valid for only 2 minutes.
- Fetch requests keep the connection active if they occur during these 2 minutes.

The script polling interval is set to 1 minute because this is the minimum that eedomus accepts. But it could be less without any problem. With the same API, the somfy interface is doing a polling every second.

If you set le master Data polling to more than 1 minute (let's say 15 or 60 minutes) , this will lead to perform a login at every polling + a full setup of every devices, and no registration to cloud events.
That is, in fact, a come back to the V1.

You wrote :

I am almost now sure this is where the issues came from, because I did not change passwords, did not touch anything else, but relax the API frequency on the Somfy Cloud.

This is because you were blaklisted by the somfy cloud. When blacklisted, it's difficult to comme back to normal, even in current V3.0.0.
Setting the polling to 60 min can be usefull, just as turning off your eedomus or you box for 60 minutes.
But turning off the box is more efficient because you prevent any eedomus device or rule to perform any request.

V3 is far more resistant to being blacklisted by the somfy cloud, but there are still a few cases that can occur. You may have experienced such a case.

This is why we are still working on the script (even if I'm not so frequently active on the forum).

I you are not yet in V3, I highly recommand to migrate and let the polling 1 min.
Doing so, you will be ready if a new version is released.

I hope this post helped understanding how it works.

[Herric]

J'ai vu qu'il y avait une mise à jour Somfy à faire mais ça ne change rien alors je me dis que je vais être obligé de passer à la version V3 parce que la V2 est maintenant complètement obsolète ou est-il encore possible de corriger ce problème de liaison...

Bonjour @Harzhal,

effectivement, la V2 n'est pas blindée contre un blacklistage dû à une mise à jour somfy.
La V3 est plus "résistante" mais il y a encore quelques améliorations à apporter. Notamment en gérant ces blocages en local pour "garder la main".

Je recommande donc de passer en V3, car en plus les mises à jour seront plus simples à effectuer.

Mais avant, comme tu est blacklisté, après avoir fait la mise à jour + vérifié tes accès via l'appli ou le web somfy, coupe ta box pendant 1h.
Une fois la situation redevenue normal en V2, tu pourras passer en V3.

bonne soirée.

[Herric]

Dommage que les personnes compétentes soient plutôt … absentes pour essayer d’aider les utilisateurs de LEUR développement!

Bonjour, désolé d'avoir une vie ...

quelques précisions sur le fonctionnement du Master data :

- 0 SOMFY OFF : cet état ne survient que sur un échec de l'identification au cloud SOMFY, c'est à dire plus techniquement si le cloud a répondu autre chose que success == 'true' ET role = 'ENDUSER' ET un ID d'abonnement aux événements.
Il s'agit d'une REPONSE du cloud SOMFY. Cet "autre chose" peut être entre autre :
a- problème d'identification (changement de mot de passe)
b- problème de black list (comportement identique à a-)
c- attente de mise à jour qui bloque l'abonnement (on a vu cela le 14 juillet 2021 pour ceux qui se rappellent)
d- ou tout autre raison pour laquelle le cloud SOMFY refuse l'identification ...

- 1 SOMFY ON / Tahoma OFF et 2 Vériffier devices en erreur : c'est le cloud SOMFY qui génère un événement que nous captons (GatewayDownEvent / DeviceStateChangedEvent). Il s'agit donc d'une information envopyée par SOMFY, le problème est donc à chercher côté SOMFY.

Concernant les discussions récentes, il doit y avoir un cas (je pense à demande de mise à jour de la Tahoma) qui entraîne un black listage si on continue à lancer des requêtes. Dans ce cas il faut vérifier avec l'appli somfy si tout est ok, puis déconnecter eedomus afin de sortir de la black liste

Faire un reset ne sert à rien dans ce cas.

Une nouvelle version est en test, qui donnera plus d'infos en cas de problème d'identification. Mais je veux qu'elle soit bien stable avant de la proposer à la communauté ... d'où mon silence ces temps-ci.

[Dom-54]

Bonsoir,
Oui comme nous tous Herric
Merci pour ton retour qui nous éclaire un peu plus sur ces différents états … surtout le cloud OFF !!! On va donc attendre avec impatience cette nouvelle version du plugin !
Bon courage !!
Bonne nuit.

[Harzhal]

Mais avant, comme tu est blacklisté, après avoir fait la mise à jour + vérifié tes accès via l'appli ou le web somfy, coupe ta box pendant 1h.
Une fois la situation redevenue normal en V2, tu pourras passer en V3.

Salut Herric.
J'ai coupé une heure comme tu me l'as demandé et effectivement la connexion est revenue entre Somfy et eedomus. Je passerai à la V3 début janvier car en ce moment, je n'ai pas trop le temps, c'est l'approche des fêtes

[Horia]

Hi Heeric,

I understand and I use v3.

Meanwhile what can cause the blacklisting in the somfy cloud?

Since I updated the polling time to 60 min I did not see any blacklisting nor any changes on the master data or devices counter nor any issues for control, including the dashboard in the somfy app.

Further more when I had the 1 min polling, the status for the somfy cloud/box in the history was flapping constantly, hence not sure you are right with your theory that the 2 min login and unlimited API calls. It kind of proves that the number of logins is not relevant but the number of API calls is. In my case I have 24 from the master data and usually below 10 per day for the device control.

Last, in my view, any public API, has to be authenticated on each request, the challenge of any cloud is not the authentication which is normally internal, but the API gateway scaling, which is rather the amount of API calls it can take simultaneously.

With v2 I never had ANY issue, with v3 until I reduced the polling time as I said, multiple times. Imho, whatever you do with the script in the future do not try to abuse API requests, and no need for state correlation. Like I said a velux from open to close goes through many eedomus states, who cares? I just want to see it in the final state. The aggressive 1 min polling many times, were showing fractures on the states and the final state was updated later.

You can command a public cloud by API, and generally it confirms the request, trying to pull agresivly the intermediate states will trigger the blacklisting imho.

Thanks, Horia

Not knowing the SLA/PKIs they target, the easiest is to assume we have to relax, hence my suggestion for 60 min synch on MasterData and the DeviceCounter.

I am almost now sure this is where the issues came from, because I did not change passwords, did not touch anything else, but relax the API frequency on the Somfy Cloud.

Hello @Horia,

sorry to disagree with you but your analysis is wrong.

As I wrote in a previous post : The somfy API is sensitive to the number of logins, not to the number of requests.

The V2 and V3 of the script are based on a single login + a registration to cloud events (fetch requests).
- A login to the cloud is valid for only 2 minutes.
- Fetch requests keep the connection active if they occur during these 2 minutes.

The script polling interval is set to 1 minute because this is the minimum that eedomus accepts. But it could be less without any problem. With the same API, the somfy interface is doing a polling every second.

If you set le master Data polling to more than 1 minute (let's say 15 or 60 minutes) , this will lead to perform a login at every polling + a full setup of every devices, and no registration to cloud events.
That is, in fact, a come back to the V1.

You wrote :

I am almost now sure this is where the issues came from, because I did not change passwords, did not touch anything else, but relax the API frequency on the Somfy Cloud.

This is because you were blaklisted by the somfy cloud. When blacklisted, it's difficult to comme back to normal, even in current V3.0.0.
Setting the polling to 60 min can be usefull, just as turning off your eedomus or you box for 60 minutes.
But turning off the box is more efficient because you prevent any eedomus device or rule to perform any request.

V3 is far more resistant to being blacklisted by the somfy cloud, but there are still a few cases that can occur. You may have experienced such a case.

This is why we are still working on the script (even if I'm not so frequently active on the forum).

I you are not yet in V3, I highly recommand to migrate and let the polling 1 min.
Doing so, you will be ready if a new version is released.

I hope this post helped understanding how it works.

[dommarion]

Meanwhile what can cause the blacklisting in the somfy cloud?
Since I updated the polling time to 60 min I did not see any blacklisting nor any changes on the master data or devices counter nor any issues for control, including the dashboard in the somfy app. In my case I have 24 from the master data and usually below 10 per day for the device control. Thanks, Horia

Dear Horia, I am dommarion part of the TeamListeSomfy for the V3 Somfy plugin.
From V2 to V3, the plugin has evolved a lot, and you mentioned "velux opening and closing command/state", while the Somfy is handling many detectors (movement, smoke, opening,...), alarm states, and much more. As you can understand your point of view of "60 min information feedback" is unacceptable for that equipment. That is one of the reasons why the polling has been setup on 1 min (and as Herric mentioned if we could have setup less we will do).
Now to come back on the IT architecture of the Plugin, and Somfy API, I think it is important to understand what Herric is explaining and the reason why we have chosen to go for event fetching with a centralized MasterData and distribute the information to all eedomus devices instead of the classical programming way that is "each eedomus device is calling the API". That means the API call is identical whatever number of devices you have (I have 21 devices).
We have monitored the eedomus CPU, and the V3 is far less consuming CPU than the V2.
On top of that, I want to mention that it is the responsibility of the API builder to "protect" its API against what you call "aggressive 1 min polling", by putting in place "Over Quota protection".
I hope my explanation helped.
To come back to the "blacklisted by the Somfy cloud", we are studying this and we will solve it.
Kind regards,
dommarion

[dommarion]

Sorry duplicate

[dommarion]

Sorry duplicate

[dommarion]

Bonjour à toutes et à tous,
Je viens d'effectuer la mise à jour Tahoma, avec la version V3.1 du Plugin Somfy.

Tout s'est passé à merveilles:
10h36 lancement MaJ Tahoma (via apli smartphone)
10h39 MasterData "Cloud ON/Box OFF"
10h39 les équipements sont passés en état "connexion" sur eedomus
10h41 MasterData "Cloud ON/Box ON"
Tout est redevenu 100% normal, les équipements ont repris leur état d'avant la MaJ Tahoma.

On analyse avec Herric des "dump" de données avant et après mise à jour.

Bonne journée, et bonnes fêtes de fin d'année.
dommarion