Forum Domoticz en français

Bonjour,

J'ai débuté en Juillet dernier la découverte de Domoticz avec le projet de fabriquer une alarme filaire à l'aide d'un Raspberry. (Pour ensuite développer d'autres utilités domotiques)

Après une très longue pause, je m'y remets, le détecteur d'ouverture fonctionne parfaitement, et j'ai acheté un capteur de vibration pour déclencher des avertissements préventifs, si jamais quelqu'un venait à vouloir forcer la serrure de la porte, ou bien si jamais nous oublions de désactiver l'alarme avant d'entrer.

J'ai créé plusieurs scripts DzVents de déclenchement sur détection de vibrations, genre le premier choc actionne un buzzer de 5 bips, le deuxième choc actionne la sirène de deux bips très brefs, le troisième, 2 bips sirène plus longs, etc... avec des actions associés, notamment envoi sms à plusieurs contacts, etc...

Maintenant je souhaiterais mettre tout ça en musique, c'est à dire intégrer l'ensemble dans une plage de temps, l'idée étant d'éviter que si un voisin claque sa porte toutes les heures ça n'active que le buzzer, mais si un cambrioleur mets 3 coups de masse en 10 secondes, ou installe un arrache-cylindre, que ça d’éclanche rapidement la sirène avant même qu'il ne puisse ouvrir la porte.

Vu la météo d'aujourd'hui, j'ai passé une bonne partie de la journée sur le wiki lua et DzVents, j'ai parcouru les commandes, les notions de timer et autres, afin de tenter de trouver la meilleure approche, pas évident pour un novice !

Vous m'aviez également évoqué en Juillet une piste sur la notion de minute glissante, j'ai parcouru la bibliothèque du forum sans trop de succès.

Sauriez-vous m'aider et m'indiquer des pistes à explorer ou des scripts à découvrir ?

Merci d'avance
Cdt

Sisiphe a écrit : 27 sept. 2020, 20:00 l'idée étant (...) que si un voisin claque sa porte toutes les heures ça n'active que le buzzer, mais si un cambrioleur mets 3 coups de masse en 10 secondes, ou installe un arrache-cylindre, que ça d’éclanche rapidement la sirène avant même qu'il ne puisse ouvrir la porte.
(...)
Vous m'aviez également évoqué en Juillet une piste sur la notion de minute glissante, j'ai parcouru la bibliothèque du forum sans trop de succès.

Note que sonner le tocsin permettrait d'éduquer le voisin bourrin! Bon, il faudrait quand même éviter les plages horaires nocturnes quand même!

Pour les histoires de "minute glissante", ce devait venir de moi.

Rien en bibliothèque/wiki ou autre et je n'utilise pas dzvent: Resté à du Lua de base +python en services externes interfacés à Domoticz, via l'API HTTP/JSON (car ce fut pour l'essentiel codé avant le framework python, mais c'est pas cela qui gère le coeur du système d'alarme).

L'idée de base s'inspirait néanmoins du wiki alarme anglophone, pour les règles de nommage (préfixes extraits par le script device identifiant un type de capteur sans s'occuper du capteur précis) des détecteurs.

L'ajout, c'est d'associer à un type de capteur (identifié par son préfixe) un poids et d'avoir ces poids additionnés dans une variable utilisateur sur 1mn.

Le coeur du système tiens en 2 scripts "device" Lua (pas énormes, autour de 200 lignes au total):
-Un script alarmPanel qui va gérer surtout l'interaction au security panel Domoticz, cad activation/désactivation (avec les arrêts immédiats alarme en cours si désactivation tardive vs déclenchement, ça arrive), délai éventuel pour certains capteurs (genre portail/garage) pouvant déclencher avec quelques secondes d'avance sur la désactivation...
-Un script alarmTrigger qui va gérer les poids/déclenchements alarme (sirènes).

Pour ma part, j'ai 2 seuils de poids cumulés qui font déclencher:
- Poids > 15 pour un déclenchement court de 5s.
- Poids > 30 pour un déclenchement long de 5mn.

Niveau types (associés à un préfixe) de capteur j'ai de base:
- "Mvt", pour mouvement (PIR intérieurs à la maison), avec un poids de base de 32 (=> alarme immédiate si déclenchement).
-"Opn", pour open/ouverture: Capteurs (reed+aimant, généralement) d'ouvrants (volets/portes...), donc du fiable sans distinction interne/externe, même poids de base de 32.
-"Prm", pour extérieur/périmétrique (qqsoit la techno, généralement des capteurs PIR ou optiques/franchissement), avec un poids de base de 6 (c'est des capteurs moins fiables/extérieurs, un piaf/chat ou autre peut passer devant de temps en temps => il faut plusieurs déclenchements rapprochés, d'un même capteur ou de plusieurs, pour faire sonner).

Donc pour les déclenchements, tout est affaire de dosage de poids et de seuils (je n'ai que deux, mais il pourrait y en avoir plus). L'intérêt étant qu'avec ces règles de nommage et les poids de base associés, le jour ou on ajoute à un "OpnPorte" existant un nouvel "OpnFenetre" les scripts ne changent pas d'un caractère.

Bonjour,

@lost: Merci beaucoup pour ton temps pour m'expliquer ton approche de la minute glissante adaptée à ton besoin.
Je retiens que tes règles de nommage des # capteurs sont très bien organisées, et que ce principe, ajouté à la notion de poids dans un temps fixé permets de bien adapter la sensibilités des capteurs de mouvements, etc, afin d'éviter de déclencher sur les piafs et autres greffiers affamés !

J'ai essayé de creuser le sujet cette semaine, mais j'avoue ne pas avoir avancé d'un pouce, je manque clairement de compétence dans cet environnement.

En fait, n'ayant qu'un capteur de vibration qui va envoyer un événement, je pensais plutôt à une approche de type comparaison de temps, mais idem, je ne sais pas avec quoi (DzVents; Lua, Phyton), ni par ou commencer...

Mon idée de base était de comparer des dates, par exemple:

Première détection vibration => on enregistre la date => date1 et 2 bips du buzzer
Deuxième détection vibration => on enregistre la date => Date2 => on compare les dates => comparer1 = Date2 - Date1
Si comparer1 < 5 sec alors => 2 bips courts sirène
Si non => 2 bips du buzzer
Et Si => Troisième détection vibration => Date3 => on re compare, comparer2 = Date3 - Date 2
Si comparer2 < 5 sec alors => 2 bips longs sirène
Si non => 2 bips du buzzer

etc etc
et si il ne se passe plus rien au bout d'un moment, on efface tout.

Il y a très très longtemps, j'avais utilisé le même genre de principe en VB pour sécuriser l'accès à une base access, si dans une plage de temps, une IP se rate avec 3 login/mdp erronés, attente de x mn, mais bon... c'était une autre époque.

Pour le moment je ne sais pas trop par où rechercher. Est-ce possible ? Qu'en pensez-vous ?
Merci d'avance pour vos pistes.
Cdt

En lua, tu peux essayer d'utiliser la fonction _lastupdate. Faudrait alors que ton capteur mette à jour une uservariable. A la deuxième détection, tu peux vérifier la date de mise à jour de la uservariable (uservariables_lastupdate['yourvariablename']) et ensuite la mettre à jour avec la nouvelle détection.

Sinon en Dzvents (c'est du Lua orienté pour DomoticZ), tu peux analyser l'historique d'un capteur.

Keros a écrit : 03 oct. 2020, 04:57 En lua, tu peux essayer d'utiliser la fonction _lastupdate.

Pour ma part, j'avais pas fait ainsi pour assurer mes comptages (utilisant eux une variable utilisateur) sur 1mn. J'ai un switch virtuel "fenêtre de comptage" qui, si à off, est mis à on pour une minute (via une commande on for...).

Jamais publié ces scripts (parfois de courts extraits sur des demandes précises), car fait un peu rapidement quand j'ai démarré avec Domoticz et ils n'intègrent pas la création (si inexistants, au 1er appel) des switch/variables utilisateurs qui sont hélas le seul moyen d'avoir des infos qui "survivent" entre deux appels des scripts Lua sous Domoticz. C'est d'ailleurs un peu pénible de ne pas avoir plus simple et la raison pour laquelle tout ce qui est plus complexe est codé en python sous forme de services externes (gestion des captures des caméras IP, détection de présence des membres de la famille via le bluetooth des smartphones... pour ce qui est lié à l'alarme), car je ne suis même pas certain que le framework python permette plus de choses que Lua (en prime de potentiellement pouvoir bloquer tout le système d'event de Domoticz, problème lié à la conception même du langage Python).

Bref, c'est fiable et satisfait à mon besoin, mais cela nécessiterait trop de support en l'état. J'ai toujours en projet de faire en sorte que leur installation puisse se résumer à une recopie de fichier (prêt à servir après intégration, respectant les nommages, des capteurs et autres), mais le temps que j'aurais à y consacrer passe jusque là plutôt dans l'ajout de fonctionnalités (dernière en date: Filtrage d'appels ligne fixe, vu que bloctel ou rien c'est pareil)...

Sisiphe a écrit : 02 oct. 2020, 20:57 Première détection vibration => on enregistre la date => date1 et 2 bips du buzzer
Deuxième détection vibration => on enregistre la date => Date2 => on compare les dates => comparer1 = Date2 - Date1
Si comparer1 < 5 sec alors => 2 bips courts sirène
Si non => 2 bips du buzzer
Et Si => Troisième détection vibration => Date3 => on re compare, comparer2 = Date3 - Date 2
Si comparer2 < 5 sec alors => 2 bips longs sirène
Si non => 2 bips du buzzer

etc etc
et si il ne se passe plus rien au bout d'un moment, on efface tout.

AMHA, c'est une manière un peu trop compliquée de faire, surtout que l'on ne peut pas récupérer simplement des variables/structure de données avec les horodatages de déclenchement, persistente entre 2 appels d'un script device ou autre avec Domoticz.

Peut-être que dzVents le permet, mais ça doit se faire via interrogation de la base de données de Domoticz: A chaque fois une recherche/extraction en base, ce qui doit être un peu lourd (et de plus en plus au fur et a mesure qu'on rajoute des capteurs), faute de pouvoir stocker soit-même facilement ses seules infos persistantes utiles.

Dans mon cadre, le 1er déclenchement (le switch virtuel suivant étant alors à off) va mettre à on pour 1mn un switch virtuel "fenêtre de comptage de poids" et mettre dans la variable utilisateur "poids cumulé" le poids du capteur venant de déclencher... puis tous les autres qui pourront déclencher pendant la minute à on du switch virtuel.

Si c'est un capteur externe, au 1er déclenchement on n'atteint pas le seuil de déclenchement court et il ne se passe rien... mais s'il y en a d'autres dans la minute, le seuil court puis éventuellement le long sont potentiellement atteints avec les durées de déclenchement sirène associés.

Je pense que ça pourrait s'adapter comme principe, avec 3 seuils. Ce qui pose pb, c'est de faire sonner un truc ou l'autre. Avec 1 seul capteur, le last-update pourrait être utilisé comme discriminant mais ca ne passe pas facilement à l'échelle ultérieurement (sauf à le gérer en exception pour ce seul capteur ou tu y trouverais un sens).

J'avoue ne pas trop comprendre l'intérêt de ce buzzer+sirène en usage simultané. L'un ou l'autre (par exemple selon le seuil atteint... ou selon alarme active ou non: Buzzer pour être informé que qqun secoue ta porte quand tu es présent sans devenir sourd et sirène sinon) serait plus simple à gérer.

C'est bien de vouloir éviter les faux positifs et veiller à ne pas trop emmerder le voisinage, mais quand ça doit sonner il faut AMHA que ça sonne direct. Un truc discret renseigne aussi très précisément et sans risque un cambrioleur malin sur les seuils et durées d'attaques possibles de ta porte.

En prime, certains capteurs ont une durée de déclenchement (réglable, ou non): Genre une fois déclenché, il faut 10s avant qu'ils le puissent de nouveau. Alors se baser sur des durées de quelques maigres secondes ne fonctionnera pas avec tout.

Peut-être que dzVents le permet, mais ça doit se faire via interrogation de la base de données de Domoticz: A chaque fois une recherche/extraction en base, ce qui doit être un peu lourd (et de plus en plus au fur et a mesure qu'on rajoute des capteurs), faute de pouvoir stocker soit-même facilement ses seules infos persistantes utiles.

A priori non, c'est plutôt stocké dans un fichier JSON nommé __data_<nom_du_script>.lua, stocké dans <racine_Domoticz>/domoticz/scripts/dzVents/data/, ce qui est moins gourmand.

D'ailleurs, en créant une variable persistante historisée et stockant 1 dans l'historique à chaque déclenchement, on obtient le nombre de sollicitations dans les 5 dernières secondes par un sumSince('00:00:05') à partir duquel il est facile de décider quoi faire.

La déclaration pourrait être du style : Lors du déclenchement : Pour action :

Flying Domotic a écrit : 05 oct. 2020, 10:38 A priori non, c'est plutôt stocké dans un fichier JSON nommé __data_<nom_du_script>.lua, stocké dans <racine_Domoticz>/domoticz/scripts/dzVents/data/, ce qui est moins gourmand.

En effet, c'est mieux ainsi... surtout si on fait en sorte que ce répertoire data soit monté dans un petit tmpfs en ram (à la fois pour être certain que ce sera en mémoire quand on en a besoin et éviter des écritures uSD). J'avais d'ailleurs pensé à me faire une petite bibliothèque Lua faisant cela sur le /tmp quand j'avais été confronté à ce problème mais au final mon besoin étant simple j'avais biaisé!

En effet, c'est mieux ainsi... surtout si on fait en sorte que ce répertoire data soit monté dans un petit tmpfs en ram (à la fois pour être certain que ce sera en mémoire quand on en a besoin et éviter des écritures uSD). J'avais d'ailleurs pensé à me faire une petite bibliothèque Lua faisant cela sur le /tmp quand j'avais été confronté à ce problème mais au final mon besoin étant simple j'avais biaisé!

C'est une bonne idée, tant qu'on ne souhaite pas conserver les valeurs entre 2 lancements de Domoticz, ce qui est un peu l'objectif de la persistance

Flying Domotic a écrit : 10 oct. 2020, 00:35 C'est une bonne idée, tant qu'on ne souhaite pas conserver les valeurs entre 2 lancements de Domoticz, ce qui est un peu l'objectif de la persistance

Pour ma part, il s'agissait surtout de garder des infos entre 2 appels d'un script (device ,time). Garder un horodatage de certains évènements sur un uptime précédent n'est dans ce cadre alarme pas utile. Attention par contre à l'initialisation au 1er appel!