Discussion :

[Vincent1358]

Bonjour,

j'habite une vieille maison avec plusieurs petites dépendances. J'ai été victime de cambriolages ces derniers mois, ce qui m'a décidé à protéger mon domicile. J'ai mis en place une alarme avec différents capteurs (détecteur de porte, etc.) et sirènes.

Les solutions du commerce ne me convenant pas pour plusieurs raisons, j'ai dû réaliser moi-même ce système d'alarme avec un raspberry. Il ne protège pour l'instant que ma maison. Maintenant, je voudrais aussi protéger les dépendances qui sont à côté: c'est le problème technique que je veux résoudre. Pardon si le message est long, mais je pense que c'est nécessaire pour bien expliquer la situation.

Je précise que je suis débutant en électronique.

Idée générale

Pour faciliter la mise en oeuvre et la maintenance, mon idée est de mettre un arduino dans chaque bâtiment à protéger de manière à avoir un système modulaire. Chaque arduino devra gérer les capteurs de son bâtiment et être capable de déclencher la sirène de son bâtiment en cas de besoin. Ces arduino devront aussi être capables de communiquer avec un appareil principal (soit le raspberry, soit un autre arduino, peu importe). L'allumage/extinction de l'alarme se fera à partir de cet appareil principal.

La communication sans fil est à proscrire (murs trop épais). J'envisage de réaliser des liaisons filaire à partir de câbles réseau (avantages: 8 fils disponibles, blindage, facilité de sertissage, prises normalisées pratiques). Attention, je ne parle pas d'un réseau ethernet, mais simplement d'utiliser du câble réseau comme fil de connexion. Longueur des liaisons à prévoir: de l'ordre de 50m.

Problème à résoudre: choix d'un mode de transmission de données

Après quelques recherches, je vois qu'il existe de nombreuses manières de faire communiquer plusieurs arduino entre eux:

• liaison série UART. Avec le protocole RS-232 (nécessite un shield dédié sur l'arduino) il semble qu'on puisse atteindre des distances jusqu'à 60m. Mais le protocole ne semble pas très pratique pour relier plus de 2 appareils entre eux (j'ai besoin de 3 appareils en tout à relier à l'appareil principal)
• liaison I2C: protocole qui semble très pratique, mais il semble qu'on puisse au mieux atteindre 30m avec un module LTC4311 -> insuffisant pour moi
• liaison SPI: distance trop courte (1m max?) -> insuffisant pour moi
• liaison CAN: très grandes longueurs possibles, mais ce protocole semble plus difficile à implémenter

Cette liste n'est pas exhaustive et est limitée par mes faibles compétences en électronique. N'hésitez pas à m'en suggérer d'autres qui pourraient faire ce que je veux. Mes critères sont:

• possibilité de relier des appareils à une distance de 50m ou plus
• possibilité de relier jusqu'à 3 appareils "satellites" à un appareil principal
• facilité d'implémentation
• nécessite au plus 8 fils

Également, vu les distances en jeu, je me demande s'il ne faudra pas prévoir une alimentation pour chaque appareil. Cela peut entrer en conflit avec certains types de liaison qui nécessitent de mettre l'alimentation et la masse en série.

Si vous avez des remarques, d'autres suggestions ou même si vous avez dû résoudre des problèmes similaires, n'hésitez pas!

Merci d'avance pour vos retours.

Annexe: quelques mots à propos du système que j'ai déjà réalisé, en lien avec la question plus haut

Le système que j'ai fait (qui ne protège que mon domicile pour l'instant) est basé sur un raspberry. J'utilise le GPIO. Les capteurs sont très simples (interrupteurs de porte, interrupteur marche/arrêt, etc.) de type ouvert/fermé. Ils sont interrogés tous les 0,1 sec via un pull-in. La sirène (12V) est déclenchée avec un relais compatible GPIO. À noter que j'ai utilisé du câble réseau pour tout relier (capteurs, relais) et que j'ai donc des pull-in et un relais qui sont situés à environ 15m du GPIO! Ca fonctionne très bien comme ça depuis plusieurs semaines. Mais je ne pense pas que ça puisse fonctionner sur des distances de 50m. Sans compter que ça multiplierait le nombre de pins sollicités sur le GPIO si je gérais tous les capteurs/relais de manière centralisée. C'est ce qui motive mon idée de mettre des arduino "satellites" en bout de ligne, avec leur propre alim.

[f-leb]

Bonjour,

J'ai peu d'expérience sur de longues distances, mais une liaison série RS485 pour la couche physique, et du Modbus pour le protocole me semble très bien pour une communication maître (Raspberry pi) et quelques esclaves (Arduino). Tu trouveras assez facilement des librairies et des modules rs485 pour les deux.
Et 50m c'est très raisonnable pour ce genre de bus de terrain, c'est quasiment du niveau industriel.

[umfred]

En "UART", tu peux définir toi même ton protocole par exemple Début|AdresseEmetteur|AdresseRecepteur|longueur|Commande|Paramètres|Checksum
Et le faire passer par du RS485
Et il te faut forcément une alimentation à chaque carte, vu les distances
Après pour les différents protocoles, il y quasi assurénent des librairies existantes pour faciliter la vie (si il y a un module/shield, il y a quasi toujours sa librairie associée, ou une libraire existante)

[Vincent1358]

Effectivement je viens de lire quelques notices techniques et RS485 semble parfaitement adapté à mon usage. Merci beaucoup!

Pour ce qui est du protocole je ne suis pas encore décidé. C'est le dilemme: lire et assimiler des dizaines de pages de doc pour comprendre un protocole existant ou implémenter le sien (faisable ici car le système sera très simple). Mais je peux toujours décider ça plus tard.

[f-leb]

Si tu passes par une librairie (comme MinimalModbus en Python sur Rapsberry Pi), c'est la librairie qui gère le protocole pour toi. Un peu de configuration et tu programmes le Pi pour demander à lire ou écrire tel registre sur tel esclave, c'est la librairie qui prépare la trame et gère l'envoi selon le protocole. Il y a aussi des librairies sur Arduino (voir https://docs.arduino.cc/libraries/modbusrtu/).

Comme l'a suggéré umfred, tu peux aussi écrire sur la liaison série à coup de "print" sur la liaison avec des trames de ton cru. C'est plus simple mais forcément moins robuste, pas standard et il faut gérer des choses manuellement (timing, erreur de transmission, évolutivité...). C'est aussi très faisable en prototypage avec quelques esclaves. A voir... c'est aussi un bon moyen de tester la communication avant de passer à quelque chose de plus standard et plus robuste.

[sevyc64]

Je pense que tu as oublié un type de liaison dans ta liste, celui qui est sans doute le plus simple à mettre en œuvre dans ton cas, c'est simplement le réseau Ethernet, puisque tu parle de tirer des câbles Ethernet justement.

Propage ton réseau dans tes dépendances, il pourra en plus te servir à bien d'autres choses en plus de l'alarme.

Et oui, il te faudra une alimentation de chaque coté, car tout alimenter depuis ton point central peut avoir des limites.
Par contre, il te faudra, partout, sur chaque élément, des alimentations secourues car les voleurs, généralement la première chose qu'ils font quand ils visitent un logement protégé, ils font disjoncter le compteur. Une prise avec à l'intérieur une petite résistance entre la terre et chacune des autres bornes, c'est rapide et y a pas beaucoup de compteurs qui y résistent.

[Vincent1358]

Oui, c'est vrai qu'il y a la solution d'étendre ethernet partout. Dans ce cas il faut que je prévoie un switch en plus, voire plusieurs. Et peut-être que dans ces conditions le plus simple serait de mettre des raspberry avec GPIO pour commander mes capteurs/relais plutôt que des arduino. À voir en termes de coût, mais je retiens l'idée!

En ce qui concerne l'alimentation de secours, déjà le simple fait de recevoir une notification push sur le téléphone en cas de détection serait bien (c'est ce que fait mon raspberry actuel). Pendant le dernier cambriolage, ma femme était toute seule à la maison. Elle ne les a pas vus ni entendus fracturer un local à côté de la maison...

[sevyc64]

En ce qui concerne l'alimentation de secours, déjà le simple fait de recevoir une notification push sur le téléphone en cas de détection serait bien (c'est ce que fait mon raspberry actuel)

Oui, mais pour qu'il puisse le faire, il faut qu'il reste alimenté. Et pour que les arduino(ou Rpi) dans les locaux annexes puissent communiquer avec le RPi central pour qu'il envoie la notif, il faut que les arduino restent alimentés, que le RPi central reste alimenté, mais aussi tous les éléments qui permettent la liaison entre les 2, s'ils ont besoin d'électricité (switch par exemple) doivent aussi rester alimentés.

C'est la raison pour laquelle les alarmes possèdent toutes une (ou plusieurs) batteries, et qui représentent d'ailleurs une part non négligeable du cout total. Les capteurs sont généralement aussi autonomes. Les sirènes aussi ont généralement leur propre batterie, etc ...

[Vincent1358]

Oui je suis d'accord sur le principe des batteries et j'envisage d'en mettre à terme. Mais je n'ai pas de prise de courant en extérieur, rien qui permette de faire disjoncter facilement. Sauf à intervenir directement sur le boîtier EDF du quartier, quelqu'un qui voudrait faire disjoncter mon installation devrait entrer à l'intérieur des locaux, serait détecté par le système, et je serais prévenu même s'il fait sauter le disjoncteur dans les 5 secondes après être rentré. Pour commencer, ça me semble déjà pas mal.

[f-leb]

Après, en sans fil tu peux envisager LoRa. Cela peut transmettre sur quelques kilomètres en milieu urbain, on peut supposer que sur 50m cela fonctionne même avec des murs épais, éventuellement avec des antennes extérieures.

Le débit est faible mais pour transmettre quelques octets en cas d'intrusion cela reste suffisant. En plus tu n'as plus besoin de fonctionner en maître-esclave comme avec Modbus. La liaison est bidirectionnelle et en cas d'intrusion, ton Arduino peut transmettre spontanément un message au raspberry Pi sans attendre une requête du maître. C'est en plus très économe en énergie.

[sevyc64]

Exact.

Un autre réseau auquel j'avais pas pensé non plus et qui portant existe déjà en natif dans tout bâtiment, c'est simplement le réseau électrique en utilisant les courants porteurs (CPL). Plus besoin de tirer de cables, tout est déjà en place. Bon après, faut voir ce qui existe en shields pour le CPL, il n'y a peut-être pas grand choses.

[edgarjacobs]

Un autre réseau auquel j'avais pas pensé non plus et qui portant existe déjà en natif dans tout bâtiment, c'est simplement le réseau électrique en utilisant les courants porteurs (CPL).

Sauf que Vincent1358 précise bien que les dépendances à équiper ne disposent pas d'une alimentation électrique

[Vincent1358]

Oui effectivement, une seule sur les 3 a un raccordement au réseau électrique pour l'instant et c'est celle que je voudrais protéger en priorité.

Mais j'ai prévu de tirer des cables pour équiper les deux autres. D'où mon idée initiale, quitte à devoir tirer des cables, de mettre du câble réseau dans une gaine parallèle. En tout cas, l'idée du CPL est intéressante également car elle pourrait m'éviter de tirer 30m de cable réseau supplémentaire.

En tout cas merci f-leb pour la suggestion de LoRA. Les performances ont l'air bluffantes pour des consommations ridiculement basses.

[Vincent PETIT]

Pour Ethernet, il y a le PoE qui permet d'alimenter à distance l'appareil dans la dépendance, par le câble.

Pour le RS-485 j'ai déjà vu du PoB (power of bus). On peut alimenter les esclaves distants par le maître dans la maison.

Pour le CPL s'il y a une coupure de courant plus rien ne fonctionne.

[Vincent1358]

J'aime bien l'idée du PoE voire PoB. Ca simplifierait la réalisation d'une protection de l'alimentation en cas de coupure de courant (possibilité de centraliser l'alimentation en un seul point).

Suite aux nombreuses suggestions qui ont été faites dans cette discussion (et au passage, dont je vous remercie encore!) je pense pour l'instant partir sur l'un des deux systèmes suivants:

1. 1 raspberry en maître dans la maison, 3 arduino en esclaves. Liaison série RS485, protocole ModBus
2. 4 raspberry (un par bâtiment), reliés entre eux par un switch ethernet

Dans les deux cas les liaisons se feraient en rj45.

La proposition 1 est moins chère, mais nécessite je pense un peu plus de travail de mise en place (pour moi, étant donné mes faibles connaissances en électronique).

La proposition 2 est plus chère, mais aussi plus proche de ce que je sais déjà faire (faire communiquer des ordinateurs entre eux par le réseau, il suffit d'écrire le code!)

Les 2 propositions devraient permettre, à terme, d'inclure une protection de l'alimentation centralisée (PoB ou PoE).