Controle d'un portail battant Came

Bonjour,

Ma maison de campagne est équipée d’un vieux portail motorisé Came dont les télécommandes sont en RF433 à roling code, je n’ai pas trouvé de moyen de récupérer les info d’une télécommande que ce soit avec Rflink ou RfxCom.

Ce portail est commandé par un carte ZF1 dont on trouve les schémas sans difficulté avec Google.
Dans un premier temps j’ai « piraté » une télécommande en soudant un contact sec d’un Shelly UNI aux bornes du switch de la télécommande. Et paramétré un time out de 0,8 secondes pour le canal 1 du Shelly UNI. Ça simule parfaitement l’appui sur le bouton de la télécommande. Un petit virtuel avec 2 actions :
Une pour envoyer la commande d’ouverture seule (qui sera suivie automatiquement par la fermeture, l’autre pour envoyer la commande d’ouverture suivie 20 secondes plus tard (une fois le portail ouvert) par un second envoi pour interrompre la procédure s’arrête (entendez par là que le portail ne se referme pas).

Ce bricolage est fonctionnel mais nécessite 2 alimentations : une pour le Shelly UNI et 2 piles pour la télécommande. J’ai donc consulté le PDF trouvé par google.
La carte ZF1 présente 3 borniers:
Le premier L1,L2 pour l’alimentation de la carte en 230V AC
Le second U,V,W,X,Y,E pour les commandes des moteurs et gyrophare monophasés en 230 V AC
Le troisième 5,C1, 7, 2, 1,11,10,ES,ES ou on trouve en 10 et 11 du 24V AC pour alimenter des ‹ accessoires › et 2 et 7 pour commander l’ouverture (qui fonctionne comme la télécommande)

J’ai donc connecté les fils rouge et noir du shelly UNI aux bornes 10 et 11 (c’est de l’AC donc pas de prise de tête pour le fil vert et le bouton rouge), et le contact sec du chanel 1 de l’UNI sur les bornes 2 et 7.
Le Shelly UNI enfermé dans une boite en plastique pour éviter tout court circuit et on peut refermer le boitier du moteur.
Ça marche tout aussi bien, permet de s’affranchir de la surveillance des piles, de récupérer une alimentation 12V et d’ajouter une sonde de température DS18B20 ou Temp/hygro DHT22.
Bien sur il faut que le boitier Came soit à portée du wifi,

Le module Shelly UNI se pilote avec le plugin Shelly ou en MQTT.

Petit ajout : La carte Came ZN2 a un bornier 10,11,E1,2,3P,5,7,2,C1,C3,C7,C8,TS dont le descriptif ressemble (pour les bornes communes) à celui de la carte ZF1. En cas de coupure de courant la carte passe sur alimentation en DC et le 24V AC devient du 24 V DC, je n’ai aucune idée du comportement du Shelly UNI dans ce cas et de toutes façons s’il n’y a plus de courant il est probable qu’il n’y ai plus de Wifi non plus, dans ce cas : retour à la télécommande d’origine.
La carte ZN2 semble offrir des fonctions supplémentaires intéressantes mais comme je n’ai qu’une ZF1 je vous laisse les étudier éventuellement pour une utilisation d’un Shelly Plus UNI. (Rechercher Came ZN2 sur google)
La carte Came ZM3e semble suivre la même logique pour son bornier.
Vous pouvez trouver tout plein de descriptifs sur https://www.sonepar.fr > Communication et sécurité > Communication et sécurité > Accessoires d’automatisme d’ouverture

Bonjour,

Quelques compléments sur ma commande de portail.

Le Shelly UNI installé dans le boitier à décidé de n’en faire qu’a sa tête, la RH en accord avec la direction l’a mis en pré-retraite. Il a donc été remplacé par un Shelly Plus UNI.
Le plugin shelly ne gère pas le coté « Plus », je suis donc passé en mqtt avec un petit script pour récupérer des commandes déposées sur le serveur. MQTT.

Au passage j’ai modifié le principe de fonctionnement pour l’ouverture permanente en activant des timers sur le shelly.
Lors de son activation le second switch active le premier (qui se coupe après 0.8s activant l’ouverture), et lance un timer de coupure de 20s, une fois ces 20s écoulées il se désactive et lance une seconde activation du premier switch ce qui interrompt la séquence ouverture/fermeture.

En complément j’ai ajouté une ampoule ILS et un aimant à la jonction entre les 2 portes du portail ce qui permet de remonter un état « fermé » au Shelly qui le remonte au serveur MQTT.

Je vous pose ici le script Shelly Plus en vous demandant la plus grande mansuétude sur mes capacités de développeur (c’est mon premier script en µJS)


let CONFIG = {
  shelly_id: null,
  shelly_mac: null,
  shelly_fw_id: null,
  ha_mqtt_ad: "UNI",
  device_name: "VIRTUAL_SWITCH",
};


Shelly.call("Shelly.GetDeviceInfo", {}, function (result) {
  CONFIG.shelly_id = result.id;
  CONFIG.shelly_mac = result.mac;
  CONFIG.shelly_fw_id = result.fw_id;
  initMQTT();
});

function initMQTT() {
  MQTT.subscribe(buildMQTTStateCmdTopics("switch","0")+ "/#", MQTTCmdListener);
  MQTT.subscribe(buildMQTTStateCmdTopics("switch","1")+ "/#", MQTTCmdListener);
}

function buildMQTTStateCmdTopics(hatype, topic) {
  let _t = topic || "";
  if (_t.length) {
    _t = "/" + _t;
  }
  print(CONFIG.shelly_id + "/" + hatype + _t);
  return CONFIG.shelly_id + "/" + hatype + _t;
}

/**
 * @param {string} topic
 * @param {string} message
 */
function MQTTCmdListener(topic, message) {
  print("MQTT Cmd LISTENER");
  print("T: " + topic);
  print("M: " + message);
  if ( topic === (buildMQTTStateCmdTopics("switch", "0") + "/command")) {
    print("Chanel 0 selected");
    sel_chan="0";
  } else if (topic === (buildMQTTStateCmdTopics("switch", "1") + "/command")) {
    print("Chanel 1 selected");
    sel_chan="1";
  } else {
    print("Message non supporté");
    sel_chan = "";
  }
  if (sel_chan ) {
    print("Turn chanel " + sel_chan + " " + message);
    let _sw_state = message === "on" ? true : false;
    print(_sw_state);
    try {
      Shelly.call("Switch.set", {'id': sel_chan, 'on':_sw_state});
    } catch(err) { 
      print("Err T: " + topic);
      print("M: " + message);
    }
  }
}

1 « J'aime »

Bon…
Il me reste un « petit problème », il faut que j’aille faire le forcing chez mon opérateur mobile pour que la 4G passe devant mon portail sinon le navigateur internet de ma voiture est infoutu de charger la page qui me permet d’activer tout ca !
:stuck_out_tongue_winking_eye:

Pourquoi avoir modifié une télécommande alirs qu’un module avec contact sec sur les bornes 2et 7

Pourquoi des tests sur une pauvre télécommande qui n’avait rien demandé ?

4 raisons à ça, le boitier du portail était infesté de toiles d’araignées, j’avais des télécommandes en pagaille, mon installation wifi passait mal les murs et la ZF1 à grillé un fusible avant même que je regarde comment s’ouvrait le boitier.

Et si tu relis mon premier post, autour du milieu du post, j’explique que j’utilise désormais les bornes 10 et 11 pour l’alimentation du Shelly UNI et les bornes 2 et 7 pour les commandes.
Le passage d’un l’électricien professionnel connaissant les vieux portails Came m’a rassuré quand à la faisabilité d’un remplacement de fusible par mes soins. (En plus il a passé un coup de chiffon :stuck_out_tongue_winking_eye: )

La télécommande à retrouvé son fonctionnement nominal au fond du tiroir avec ses consœurs surnuméraires.

Prochaine évolution : l’utilisation de la borne 5 pour remonter que le portail bouge
Avec la borne 10 qui semble servir de commun, elle est utilisée pour allumer une lampe témoin 24VAC

Seul souci les entrées sont prévues pour des switches, il y a bien une entrée analog (voltmètre) mais je craint d’une part que en connectant une des bornes 24VAC (5 ou 10) au GND du shelly je déclenche un joli court-circuit et d’autre part rien ne précise que l’entrée analog supporte le courant alternatif…

J’ai donc prévu un relais 24VAC (finder 40.52.8.024.0000)
Mon proto se comporte bien à condition de veiller à éloigner la sonde DTH22 de la bobine du relais qui a tendance à chauffer (rien de bien alarmant elle n’est sous tension que 20 secondes).