Montage DIY Arduino pour commande de portail motorisé

Bonjour,

Si vous avez quelque chose comme ceci :


vous connaissez (ou connaîtrez !) la lassitude des pannes à répétition de la carte constructeur.

Je vous propose de reprendre définitivement le pouvoir, avec l'appui de la milice Arduino.
Le tout pour un approvisionnement de l'ordre de 50 euros et, en cas de panne, la possibilité de remplacer très facilement le module coupable.

Voici une planche du montage. Ainsi que du câblage, partiellement du moins mais le sketch indique toutes les I/O à utiliser sur le Nano.

A noter que l'alimentation à découpage peut être remplacée par un transformateur torique :

  • plus cher et plus encombrant
  • mais moins gros pollueur électromagnétique

Ce montage a le gros avantage sur d'autres propositions de respecter la contrainte réglementaires de sécurité (même s'il n'est pas homologué bien sûr !) pour éliminer les risques de pincement ou "écrasement".

Par contre il n'y a pas de refermeture automatique avec détection infrarouge, feu clignotant et le tralala. Mais c'est certainement assez facile à ajouter ; n'ayant pas la confiance aveugle j'ai toujours préférer commander la fermeture, et la surveiller...
Il n'y a pas non plus d'apprentissage automatique (bien que amusant et pas très difficile à coder mais par expérience je peux prédire que la mise au point, forcément "in-situ" sera fastidieuse, éprouvante pour la mécanique et finalement validée sur son propre portail uniquement... donc sans intérêt).

Le réglage se fait donc manuellement ;

  • chaque vantail et pour chaque sens, il faut définir deux paramètres : force (PWM) et durée du mouvement.
    soient 8 paramètres au total.
  • pour ce faire, au lancement du code, ainsi qu'à chaque reset volontaire ou non, un cycle de paramétrage démarre qui permet d'accéder à chacun des paramètres à tour de rôle, modifiables par pressions successives sur le poussoir. L'écran OLED est là pour visualiser les actions.
    Les paramètres modifiés sont sauvegardés en EEPROM. Si personne n'intervient, le sketch passe en mode opération au bout de quelques secondes (en fait il passe en veille, la télécommande aura pour premier effet de déclencher par interruption le réveil du Nano. En mode portillon ou deux vantaux selon le bouton)
    Sur le synoptique ci-dessous, les deux traits rouge représentent chacun les deux paramètres du mouvement : force (maxi) et durée.
    Le tracé vert représente la façon dont le code traite ces 2 paramètres et en déduit quatre (ou cinq) phases : (délai) accélération, mouvement, ralentissement... puis TIMEOUT d'attente. Si le paramétrage a été bien fait, c'est dans cet intervalle TIMEOUT qu'un capteur de courant détectera que le portail est sur sa butée et coupera le moteur.
    Auparavant, le même capteur surveillera un autre seuil - significatif d'un point dur par obstacle - et coupera dans ce cas les DEUX moteurs. Un ordre par la télécommande les fera repartir, en sens inverse et en marche lente.

En fait cette "courbe" ne représente qu'une référence car en pratique les données de mesure des capteurs de courant moteur sont traitées en continu de façon à moduler les PWM moteur selon les écarts entre mesure effective et valeur attendue et avec un pas de temps beaucoup plus fin (pseudo régulation permettant notamment de compenser les effets du vent, de type intégrale pure, bridée à la hausse)
Ce traitement permet de plus,

  • d'assurer la sécurité obstacle par détection de seuils de courant en seuils absolus (contextuels)
  • (ET/) OU, en fin de mouvement (ralenti) détecter en seuil relatif le contact sur butées

A noter qu'à l'ouverture, les variables "cachées" du code vont prévoir une arrivée en douceur sur les butées.
Par contre à la fermeture, pour que la cinématique des bras assure correctement la fonction de "verrouillage", le final doit être plus vigoureux, ça sera donc normal.

Si quelqu'un veut se lancer et le souhaite, je transmettrai le code et j'écrirai volontiers une petite procédure pour faciliter la phase de paramétrage.
EDIT - les fichiers de code se trouvent en post #7
- des indications pour la mise en service et réglages en post #15
- une fonctionnalité Bluetooth est ajoutée au code avec un montage décrit en post#83

Voici une photo ce ce que ça donne chez moi. Je me suis imposé de tout rentrer (au chausse pied !) dans mon coffret d'origine juste un peu adapté.

Pas simple, mais les coffrets du commerce sont soit trop petits, pour le matériel à y mettre, soit trop grands, pour la place disponible. A moins de prévoir un coffret dédié pour l'alim ? Ou bien une alim déportée dans la maison et une liaison en 24V continu ?

Bon amusement !

(encore une tite chose : avec le récepteur radio-fréquence ... universel... de mon choix, les télécommande d'origine ne fonctionneront pas si ce sont des Somfy. Si ce sont des Nice, oui, ainsi que beaucoup d'autres... mais les Somfy niet)

1 Like

Bonjour,
Concernant les protocoles Somfy, il y a RTS et IO-Homecontrol. Le protocole RTS qui a été décrypté sur le forum.
Les deux protocoles
La bibliothèque @etimou : Une librairie Arduino pour commander les volets/stores SOMFY RTS
Et le topic sur le sujet en 2019 : https://forum.arduino.cc/t/rflink-open-source/590818

Bonjour,
Je suis intéressé par tous les détails de réalisation de ce portail. Je suis aussi avec un automatisme Somfy (à vis) en panne et j’envisage de réaliser un serveur ESP32 en mode PA pour commander l’ouverture et la fermeture avec des smartphones (famille).
Mais toute la partie commande des moteurs en PWM avec contrôle de la charge et butées m’intéresse énormément.

Merci d’avance et cordialement
Dominique

Bonsoir,
je vais être ravi de vous aider autant que je pourrai.

"Vis" dites vous : est-ce un portail coulissant ? Il aurait en commun avec le mien au moins le contrôle PWM du moteur et de sa charge en temps réel, le reste serait probablement beaucoup plus simple.

S'il s'agit de bras type vérin à vis, la similitude serait plus grande.
Dans les deux cas, les composants que j'ai utilisés (cf nomenclature) conviendront probablement, drivers PWM et capteurs de courant. A vérifier néanmoins selon la tension/puissance de votre (vos) moteur(s).

Vous parlez de butées : dites moi aussi si votre système dispose de fins de courses. Dans mon cas il n'y en a pas, c'est le programme qui est chargée de détecter les arrivées en butée.

Et parlant de programme, il faudrait que j'ai une idée de votre aisance à coder. Votre vignette suggère un intérêt pour le modélisme ferroviaire... dans ce cas vous devez avoir déjà de très bonnes bases, sinon plus !
Je vous transmettrai évidemment et très volontiers mon code mais il est toujours difficile de rentrer dans le code d'autrui, vous devrez à minima personnaliser, mais il est d'un simple niveau intermédiaire.

Enfin, vous parlez d'EPS32. J'ai monté une carte compatible ESP32 et Nano (double embase + câblage compatible) mais en développant, je suis tombé sur une impossibilité avec l'ESP, j'ai un peu oublié mais je crois que c'était lié à un conflit entre mise en veille profonde et réveil par interruptions... pb aussi dus à une plus grande sensibilité aux perturbations électromagnétiques. Bref, je tourne sous Nano, le code est à peine différent mais demandera néanmoins une adaptation... si vous comptez coder en C++. Etant donné que vous parlez d'ESP, si vous préférez python, vous aurez plus de travail !

Voilà en première réponse. Au plaisir de vous lire
Philippe

Salut @simontpellier et @dominiqueb91 ! :grin:

@dominiqueb91 est, il me semble, le créateur de locoduino (voir son profil) ou alors en fait partie. Vu la qualité des articles, je pense que oui :wink: mais ce n'est qu'une hypothèse. (@dominiqueb91 c'est vous ça ?)

Bonne journée
Cordialement
Rémi

1 Like

C’est vrai, je fais partie du staff Locoduino depuis presque 10 ans.

Pour les « vis » il s’agit de vérins à vis qui fonctionnent très bien sous 24v plein pot et plus lentement sous 12v.

Je compte les alimenter à partir d’une batterie de 18/20v d’appareils electro-portatifs avec son chargeur, donc un suivi de tension et recharge si nécessaire par relais.

Je n’ai pas de capteurs de butées donc je dois utiliser la mesure du courant pour détecter les butées et un obstacle éventuel. C’est sûrement délicat notamment en cas de vent. L’apprentissage est important.
Ces mesures de courant sont habituelles dans les centrales DCC pour détecter les court-circuits sur un réseau ferroviaire miniature.

Donc ça me simplifiera la vie de partir de votre réalisation sur Nano en C++.
D’autant que j’ai l’habitude d’associer plusieurs microcontroleurs.

Par quel moyen les échanges de documents peuvent se faire ?

Cordialement
Dominique

1 Like

Hello MONSIEUR Dominique !

Démasqué par Pandaroux (bien vu !).
Je vais être d'autant plus heureux d'apporter un petit retour d'ascenseur car je ne connais rien qui arrive à la cheville de Locoduino pour, partant de zéro comme c'était mon cas, progresser dans tous les domaines, programmations, matériels, capteurs etc. Et je "plussoie" pour ce qui est de la rigueur, clarté, qualité rédactionnelle. L'ensemble constitue une "somme" inégalée !

Revenons à nos portails.

Dans mon cas, les bras sont articulés. Avec des avantages/inconvénients par rapport à des vérins ; dans l'optique d'une carte DIY, il me semble que les vérins seront un avantage du fait d'un mouvement nativement plus doux et régulier.

Je joins mon code qui devrait s'adapter très facilement.

Concernant l'alimentation : mes premiers essais ont été fait sur batterie de perceuse et ça marche très très bien, avec une endurance surprenante (au final une alim sur secteur m'a paru moins contraignant et moins cher)

Dans mon code il n'y a pas de fonction d'apprentissage

  • chez Somfy version bras articulé, il est brutal, limite destructeur vu la façon bâclée dont la liaison bras (fonte d'alu) sur axe moteur (acier trempé) est conçue.

  • de plus Somfy ignore les caractéristiques du portail client et ne peut donc pas viser un paramétrage au plus fin.

  • d'ailleurs, dans mon cas, comment mettre au point un algorithme d'apprentissage universel en ne disposant que d'un unique portail !

En revanche, j'ai au final un paramétrage tip top. Et qui pourra je pense être rapidement trouvé sur une configuration différente.

Le code n'a rien de sorcier, la seule difficulté a été de trouver un algorithme de compromis entre entre détection-butées/détection-obstacle/effets-vent. Au bout de bien des tâtonnements, ça marche à merveille, avec même, une compensation du vent ! (qu'il pousse ou qu'il freine... hors rafale!)

Les fonctions correspondantes se trouvent dans la feuille "monitoring"

Deux autres feuilles traitent la logique des mouvements, l'une pour le seul vantail "piéton", l'autre pour les mouvements à deux battants.

L​e .ino, outre setup et loop, contient la fonction de paramétrage (force et durées de mouvement) qui à chaque setup, volontaire ou non, lance une séquence et permet d'effectuer ou modifier les réglages. Ou se clôture sans modification en l'absence d'action.

​Une feuille de notes trace plus ou moins la genèse du truc, mais c'était à usage perso et j'y apporterai les compléments qu'il faudra en fonction des questions.

Bonne réception !
Philippe
controlePortail_NANO_BLT.ino (13,3 Ko)
Globals.h (6,0 Ko)
Monitoring.h (10,5 Ko)
Mouving1G.h (8,9 Ko)
Mouving2G.h (15,4 Ko)
notes.h (9,0 Ko)
Settings.h (7,8 Ko)

Merci Philippe,

J'ai bien récupéré les fichiers et ça se compile bien pour un Nano.
Maintenant je vais regarder de plus près.

On peut échanger par MP.

Cordialement
Dominique

Ici, on aime bien quand tout le monde peut bénéficier des conseils et tuyaux :grinning:

Continuer ici est pas mal aussi.

pas faux

donc : pour compléter le package :

Pour la mise en point des paramètres et pour limiter le nombres d'essais, surveiller le processus en temps réel par des Serial.print ne serait ni pratique ni efficace. A la place, une fonction "recording" permet d'enregistrer les données des mouvements en EEPROM.

Pour les analyser à postériori, un gros Serial.print restitue l'intégralité des données collectées. Une fois copié collé dans le tableur openOffice (compatible excel) joint, on a une bonne visualisation du déroulé du film.

Le tableur joint contient un bon exemple d'un réglage concluant et du comportement du code. Il suffira de vider les champs de données de la feuille data pour l'utiliser.

record_V13_050823_GREAT!.ino (376,8 Ko)
(/!\ il faudra le renommer en .ods... format que le site n'accepte normalement pas)

1 Like

Bonsoir à tous

Excusez ce hors sujet, mais OUI, LOCODUINO est ce qui se fait de mieux pour appréhender le "monde Arduino" et merci à @pandaroux007 pour en avoir démasqué le maître :wink: et de par là, permis de le remercier chaleureusement.

Bonne soirée
Cordialement
jpbbricole

1 Like

Merci d'avoir partagé vos fichiers. Je suis intéressé par ce projet car mon
Somfy Kit S200-II vient de tomber en panne.
Les scripts sont ils utilisables tel quel ?
L'utilisation d'un autre Rx de télécommande implique t'elle une modif du soft ?
Merci et bravo !!!

Bonjour et bienvenue ici,

utilisable tel quel ? peut-être !
mais pas sûr... car il y a un certain nombre de paramètres à caler

  • ceux qui contrôlent les mouvements sont ajustables par la séquence qui se lance à chaque mise sous tension ou reset, sans qu'il soit besoin d'accéder au code. On règle ainsi les durées de mouvement et la force appliquée par le moteur.
  • ces réglages une fois effectués, il se peut que le code fonctionne MAIS il faut savoir que d'autres paramètres "cachés" entrent en jeu, déduits des paramètres de réglage. Des surprises pourraient venir des caractéristiques de votre portail qui pourraient obliger à quand même aller y regarder. C'est notamment le code qui détermine les seuils de déclenchement, sur butée ou de sécurité. Or à la différence de Somfy dont la carte doit faire fonctionner n'importe quel portail, s'agissant d'un portail précis (le mien !) les seuils sont déterminés au plus fin.
    Si mon aide est nécessaire, ce sera avec plaisir.

Concernant les télécommandes : le modèle de récepteur visible sur l'illustration a l'avantage d'accepter un grand nombre de types de télécommande, grâce à une batterie de micro-contacts à configurer selon l' émetteur (hors les Somfy qui ont un protocole exotique)
Tout autre modèle de récepteur devrait pouvoir être également utilisé sans besoin de modifier le code, du moment qu'il délivre un signal par fermeture d'un contact NO... or je ne vois pas comment il pourrait en être autrement. Donc pas de souci à attendre de ce côté là je pense.

Bon courage et tenez nous au courant !

Bonsoir,
J'ai commencé à regarder le code et localisé les différentes PIN in et out.
Mis à part un problème sur la librairie Arial_14, la compilation est OK.
Pour infos les commentaires en début du fichier Globals.h ne correspondent pas
aux déclarations des lignes 70 à 73.
J'ai déjà des platines dispos et le reste est en commande.
Avez-vous une procédure à suivre lors de la première mise en service ?
Y a t'il des possibilités de poursuivre éventuellement en MP ?
Merci et bonne fête de fin d'année.

Bonsoir,
Pour la mise en service, si vous avez un S200 la liaison mécanique du bras : fonte d'alu contre acier trempé, via un petit méplat ridicule et une vis même pas freinée, est un non-sens, à ménager en tous cas !
Les essais ont donc tout intérêt à être beaucoup moins violents que le cycle d'apprentissage mode Somfy.
Les moteurs sont surdimensionnés (mon portail est pourtant très lourd). Donc, estimez le temps raisonnable pour le mouvement des battants - à mon avis 10 à 12s, et entrez le au moment de la phase de configuration (ou en pré-écriture directe dans l'EEPROM) et calez la puissance moteur à 30% à l'ouverture, 20% à la fermeture (sur l'échelle PWM 0-255)
Logiquement, le portail ne devrait pas avoir le temps de terminer le mouvement. En cas contraire, ou si erreur dans la valeur entrée, soyez prêt à tout couper (*) avant les butées.
Puis augmentez peu à peu la puissance jusqu'à ce que le portail vienne mourir sur les butées (à l'ouverture **).
Pour la fermeture, l'arrivée sur butée doit être plus ferme pour que les bras prennent bien leur position de verrouillage.

Le fonctionnement des détections :

  • bien calées, les moteurs doivent couper instantanément dès l'arrivée sur les butées (à la différence de Somfy ou les moteurs forcent une à deux secondes)
  • les fonctions d'enregistrement en EEPROM des séquences sont très utiles éviter de tâtonner et plutôt analyser sur la durée des cycles et loop par loop les puissances appliquées avec les mesures correspondantes de courant (peu corrélées si le portail présente beaucoup d'inertie) et les déclenchements par atteinte des seuils.

(*) en plus du poussoir à impulsion qui sert aux réglages, j'ai sur ma carte un bouton ON/OFF bien pratique, qui coupe l'alim de la carte. Précaution en cas d'orage, cas d'urgence, besoin de faire un reset... c'est mieux de le prévoir.
(**) dans mon cas, j'ai dû régler les puissances de fermeture plus bas que pour l'ouverture. Peut-être du fait de la géométrie des bras ?
Les puissances gauche et droite sont également différentes, mais là c'est dû à des résistances différentes de mes charnières à l'ancienne.

L'incohérence dans la feuille "globals" ? C'est plutôt un "cadavre", merci d'avoir relevé, qui mérite explication.
Car la note en en-tête concerne le pinout pour un ESP32. J'avais en effet souhaité avoir une carte pouvant fonctionner soit avec un ESP soit avec un Nano, avec deux socles et un routage mixte. Pour y parvenir, les numéros de pins utilisés n'étaient pas les mêmes selon le MCU.

Pour les questions d'ordre et d'intérêt général, je vous propose que vous poursuivions dans ce fil.
Mais oui, pour les questions plus pratiques, de mise au point, assez spécifiques à votre installation, discutons en en MP !

Bonsoir,
Merci pour votre réponse très complète. Comme vous le dites le S200--II est très léger au niveau
des bras articulés. Je continue dans ce projet car je n'aime pas savoir mon portail ouvert !
Les composants étant en commande je vais travailler sur l'intégration de l'ensemble dans le boitier d'origine.

Vos conseils seront bien sûr suivis à la lettre.
Merci et bonne fête de fin d'année.

Bonjour,

Lorsque vous parlez du Moteur M1:

  • ATTENTION : ce code est prévu pour une implantation avec le moteur maître (M1) à DROITE
  • De ce fait en ouverture le moteur tourne "Clock Wise" (CW - sens horaire)
  • Inversement, le moteur M2 en ouverture tourne "Counter Clock Wise" (CCW - sens anti-horaire)

Je suppose que c'est vue de l'extérieur ?
Merci!

Bonne question car je me suis planté !! Car le code est prévu avec le moteur maître à gauche... vu de l'intérieur bien sûr (ou à droite vu de l'extérieur, mais quand on installe pas commande pour le faire de dehors !) donc mes excuses !

Ok merci pas de souci!
Project in progress .......

Bonjour SImontpellier,

Le projet avance bien. Toujours en attente de l'alimentation 24V.
L'afficheur Oled affiche bien la phase d'init puis s'éteint. Tout semble OK
Pour info je vous joins mon synoptique. Si vous trouvez des erreurs merci de me les signaler.