lors de la configuration initiale, tu saisis les infos permettant à l’intégration d’établir une première connexion avec la centrale.
L’intégration utilise notamment cette première connexion “manuelle” pour récupérer ta grille de codes auprès de la centrale, et elle la stocke ensuite en local (chez moi, dans /config/.storage/core.config_entries … chercher “somfy_protexial”), pour utilisation lors des connexions suivantes.
Lors des connexions suivantes, l’intégration a juste à venir lire le code demandé par la centrale.
La limitation potentielle : si tu configures une nouvelle carte de codes via l’interface web de la centrale, l’intégration continuera d’utiliser celle récupérée au moment de sa configuration, et la connexion ne se fera pas.
Merci à @the8tre pour cette superbe intégration ! J’en ai bien profité avant 2025. Par contre à partir de 2025 l’intégration se déconnecte de mon système somfy.
La raison : HTTPS only se coche automatiquement sur mon système somfy dans les réglages réseaux. Si je le décoche, l’intégration fonctionne à nouveau, mais il fini par se cocher à peine quelques heures plus tard. Je n’ai pour l’instant pas trouvé de solution à ce problème.
Pour info mon système somfy date de 2013.
Merci @David7 pour cette réponse précise. Effectivement tu as raison, la grille est consultée puis stockée à la première connexion dans ce fichier. Je comprends mieux maintenant Merci encore pour ces éclaircissements.
Hélas, sur ma Protexiom je n’ai pas les remontées des capteurs.
Soit j’ai mal configuré (mais ça a l’air assez simple quand même), soit ma version d’alarme est trop ancienne.
J’ai une Protexiom 400 de 2008… Et visiblement pas de possibilité de mettre à jour le firmware. J’ai l’impression qu’il faut carrément changer l’EEPROM. Pratique.
Toujours est-il que mes éléments n’apparaissent pas. Est-ce qu’il y a autre chose à faire ?
J’ai vu que les capteurs devaient apparaître sous “Diagnostics”. Mais je n’ai pas cette zone.
Merci de ton retour
Nous allons essayer de débuguer ensemble.
J’ai fait deux fork de cette intégration :
le premier (v 1.2.6) qui ne remonte que l’opérateur et la force du signal.
le second (v 2.0.0) qui remonte les éléments de l’alarme.
Peux-tu vérifier que tu es bien en version 2.0.X ? On peut le voir sur la page de l’intégration.
Pour récupérer les éléments, l’intégration va parser le tableau de la page « /u_plistelmt.htm » de “utilisateur”. Il s’agit de la version imprimable de la liste des éléments.
La page http://@IP_de_l’alrme[:port]/fr/u_plistelmt.htm existe-t-elle sur ta centrale ? Si oui, l’URL est-elle bien la bonne. Si non, pourrais-tu regarder si une page équivalente existe. [port] est facultatif si tu utilises le port 80.
Chez moi, elle ressemble à cela :
Pourrais-tu m’envoyer en MP les logs de l’intégration ?
Pour cela, sur la page de l’intégration active le débug avec les trois points en haut à droite, recharge l’intégration et désactive le débug. Récupère le fichier.
Tu devrais voir, à minima les deux lignes suivantes : 2026-02-16 08:48:38.284 DEBUG (MainThread) [custom_components.somfy_protexial.protexial] Call to: http://@IP_de_l’alrme[:port]/fr/u_plistelmt.htm 2026-02-16 08:48:41.192 DEBUG (MainThread) [custom_components.somfy_protexial.protexial] Response path: /fr/u_plistelmt.htm
Merci Aurore pour ce fork avec l’état des éléments, c’est vraiment top.
Je l’utilise avec une protexion 400 avec le Micrologiciel : 2013 (v10_3). Il me semble que la durée de la mise à jour de la remontée de l’état des éléments est très variable. Parfois presque immédiat, parfois plusieurs minutes, parfois jamais (???).
Y a t’il un moyen de controler et de corriger de problème ?
Bonjour,
Le rythme de mise à jour des capteurs est défini par l’intégration (voir capture ci-dessous) et va de 05 à 3600 secondes. Plus le délai est cours, plus les piles de la centrale se vident vite (l’alimentation électrique n’alimente pas la centrale, elle sert juste à détecter une coupure d’élec).
J’ai aussi remarqué que la centrale à tendance à planter si on la sollicite trop souvent et qu’elle ne réussit plus à voir les changements d’états (même en dehors de HA). L’interface web est antédiluvienne.
Personnellement, je fais un polling toutes les 3 minutes, ce n’est pas parfait mais c’est mieux que rien (et avec la fin de la 2G et donc de l’envoi de SMS c’est toujours mieux que rien).
Merci pour ton retour. J’ai bien l’état des détecteurs d’ouverture qui remontent mais pas les détecteurs de mouvement. Je pense que l’intégration remonte l’état au moment ou il se connecte. Si le détecteur d’ouverture est ouvert c’est bon si il a été ouvert puis refermé, rien n’est détecté. Pour le détecteur de mouvement, qu’en penses tu ?
Pour les détecteurs de mouvements (avec ou sans prise d’images) impossible de faire le test avec l’alarme coupée, leur état ne change jamais sur l’interface web ou l’appli officielle complètement moche et d’une autre époque (c’est le thème avec Somfy).
J’ai donc testé en activant l’alarme :
s’il y a un mouvement détecté, le statut change selon le délais de pooling de l’alarme. Mon automatisation a fini par me notifier (au bout des 3 minutes configurée) d’un problème.
une fois la source du mouvement supprimée, le défaut reste que ce soit sur HA ou dans l’interface web (ou l’appli). Pour reset le capteur, je dois armer puis désarmer l’alarme. C’est vraiment nul…
Pour les détecteurs de mouvements, je fais le constat suivant : leur état passe correctement d’ouvert à fermer à ouvert en fonction des mouvements de mon ouvrant (modulo le fameux délais de pooling). Mon pooling étant configuré à 3 minutes, si j’ouvre 10 fois dans ce laps de temps avant de refermer, rien ne se passe. Par contre, si j’ouvre 4 minutes, je vois bien l’état changer.
Contrairement à une intégration “moderne”/classique qui envoie les données à HA, ici c’est HA qui va récupérer les données tous les x temps, il y a donc forcément des ratés. L’idéale serai de pooler toutes les secondes mais là l’interface web de l’alarme plante complètement et il faut la reset…
Somfy ne proposera pas de mise à jour ou de solution autre que “tout racheter” avec l’arrêt de la 2G (et donc de l’envoi de SMS par la Centrale). Je crains qu’une meilleure solution existe (mais je suis ouverte à toute meilleure idée).
Pas facile de faire du vrai temps réel avec cette ancienne alarme somfy protexiom mais on va faire avec. En tout cas, merci pour votre (@the8tre et @AuroreVgn) partage.
Une petite question bonus, savez vous si il est possible de déclencher une sirène somfy protexiom directement. Je souhaite pouvoir déclencher la sirène avec home assistant en utilisant un autre déclencheur.
Pour le déclenchement de la sirène, je ne vois pas comment faire… Cela voudrait dire que HA envoie une info d’intrusion ou de mouvement à la centrale et ainsi déclenche la/les sirènes. Très franchement je ne vois absolument pas comment faire d’autant plus qu’on ne peut pas le faire nativement depuis l’interface web ou l’appli. Désolée.
J’ai un rfxcom433, je vais essayer de tester si je peux réussir à déclencher l’alarme avec. Mais je crois que les modules d’alarme ont des codes tournants. on verra bien.
L’intégration fonctionne très bien mais depuis l’installation j’ai une consommation importante des piles de la centrale qui passe de quelques années à quelques semaines.
Avez vous constatez le même phénomène et y a t’il un moyen de rétablir cela ?
Comme pour toute intégration custom, il faut dans un premier temps installer HACS qui le dépôt d’intégrations non-officielles. La doc de HACS : User documentation - HACS
N’utilise pas le lien “Open to HACS” mais plutôt : HACS Intégrations Menu ‹ … › Dépôts personnalisés > Dépôt: https://github.com/AuroreVgn/somfy-protexial > Catégorie: Intégration
Merci encore pour ces éclaircissements.
Et visiblement pas de possibilité de mettre à jour le firmware. J’ai l’impression qu’il faut carrément changer l’EEPROM. Pratique.
d’autant plus qu’on ne peut pas le faire nativement depuis l’interface web ou l’appli. Désolée.
Intégrations