Pour ma part, ayant démarré avec Domoticz pour gérer la baraque tout juste achetée il y a 7 ans et le gros consommateur que représente un chauffage tout électrique... j'avais rapidement étendu à l'alarme même si c'est normalement pas le même rayon.
L'avantage, c'est que les capteurs de mouvements qui peuvent servir à déterminer si une pièce est vide/occupée et adapter chauffage et autre en conséquence peuvent aussi servir à l'alarme.
Par contre, rien n'est dispo de base... mais ce soft domoticz était (et reste probablement, avec les ajouts de python et plugins depuis) le plus complet en matière de possibilités de script intégrée (blockly, pour des trucs simples en mode newbie que j'ai pas utilisé. Et surtout Lua, pour des choses plus chiadées).
J'ai donc codé le coeur de mon truc en Lua, de manière assez générique (utilisant un prefixage/convention de nommage selon le type de capteur et/ou localisation intérieure extérieure déterminant les poids de base, cf la suite, ce qui permet une intégration de nouveaux sans changer son code tant qu'on respecte la convention de nommage) et utilisant un système de poids additionnés sur une minute glissante.
Grossièrement, un capteur intérieur va avoir un poids déclenchant l'alarme longue (cf la suite) immédiatement et un capteur extérieur ce sera une fraction du seuil d'alarme courte (i.e. plusieurs déclenchements d'un même capteur et/ou de plusieurs requis pour que cela commence à sonner court, puis long si ca insiste).
Ce cumul est comparé à 2 seuils: Alarme courte déclenchant sirènes pour 5 secondes sans notifications (manière de signifier à un intrus n'ayant déclenché que des capteurs externes qu'il a été vu, sans emmerder le voisinage avec une sirène qui sonne longtemps sur le faux positif d'un chat qui passe). Puis alarme longue pour 5 minutes renouvelées au besoin.
Le but étant que cela s'arrête avant même qu'un volet/porte/fenêtre soit forcé, car ensuite en qq minutes c'est foutu donc sonner sur ouverture/capteur intérieur qui tilte insuffisant.
Au début, je n'avais que des capteurs réels (PIR, installés en intérieur et extérieur ou capteurs d'ouverture). J'ai depuis cumulé avec des caméras IP (modèles Dahua peu chers mais complets avec des sensi nocturnes bonnes, installés en extérieur et garage uniquement).
Pour les intégrer, domoticz permet un truc pas mal: La possibilité de faire des switchs/senseurs virtuels! L'intégration est alors aisée: On fait des PIR virtuels qui sont déclenchés quand les caméras génèrent des captures via leur motion intégré.
Ici c'est un service écrit en python (j'aime pas trop ce langage, mais la richesse des imports m'a permis de faire pas mal de choses que je ne détaillerais pas niveau traitement des captures, envois notifs/mails) qui surveille le FTP des caméras toutes les 5 secondes et "déclenche" les PIR virtuels via l'API HTTP/JSON fournie par Domoticz.
J'ai d'ailleurs d'autres services en python s'intégrant ainsi à Domoticz, pas écrits sous forme plugin (je les ai écrit avant que les plugins n'existent): Détection de qui est présent/absent via le BT des smartphones (permet de pallier aux oublis d'activation alarme des enfants en sortant, sachant qu'ils n'oublient jamais leurs téléphones!), filtrage (par décroché/raccroché) du spam téléphonique recyclant un vieux modem voix USB avec la fonctionnalité caller ID.
L'avantage des plugins, c'est que cela intègre les interactions sans devoir passer par l'API HTTP/JSON et la génération d'une page de cconfiguration directement intégrée à l'UI domoticz tandis que je gère mes fichier yml séparés.
Niveaux interactions externes, il y a le support https (via domaine no-ip+certif let's encrypt pour moi) pour l'interface... basique vs d'autres solutions mais efficace et fonctionnant bien même sur un mobile Android pas bien véloce. Permettant aussi de servir ses propres "custom pages" au besoin (mes services python cam IP et filtrage tél en génèrent d'assez simples via yattag par exemple: Assemblage des dernières captures cam permettant une levée de doute rapide et peu gourmande en bande passante, qui fonctionnera même sur un AP surchargé de loc de vacances au besoin d'un côté ; liste d'appelants+raison filtrage éventuel de l'autre) pour ajouter ce qui peut manquer.
=> Il faut se retrousser les manches, car au delà de l'intégration du matériel et gérer les protocoles de com courants en domotique + gestion des évènements associés et présentation (fixe+mobile) il n'y a pas grand chose (mais c'est déjà un gros morceau!)... mais les possibilités de script bien foutues/intégrées + API externes offrent une grande liberté permettant de faire des trucs qu'on ne trouverait pas dans le commerce: Une solution plus Geek que Michu.
Niveau script, j'ai appris à apprécier Lua car il est stable et me fout une paix royale (coucou Python!): Une seule ligne à modifier en 7 ans sur une MAJ domoticz qui incluait un upgrade de l'interpréteur Lua intégré. Les déclencheurs type time (toute les minutes) ou device (un changement d'état sur un interrupteur/capteur...) sont suffisants et l'interaction avec les états/séquenceur d'event bien foutue à partie de tables prise à l'appel/modifiée par le script/restituées en sortie pour déclencher les actions...
Au dessus de Lua, il y a un dérivé spécifique nommé dzVent: Arrivé après que j'ai écrit l'essentiel de mes besoins, pas utilisé mais apprécié de la majorité des utilisateurs.
Et Python (dispo en plus du reste niveau scripts depuis ~3ans, passage obligé pour les plugins): Je conseillerais pour ma part d'en rester à Lua/dzVent côté scripts (stabilité, quasi impossibilité de planter Domoticz avec une erreur dans un script ce qui n'est pas le cas de Python) plutôt que Python (sauf besoin plugin).
2 possibilités pour écrire les scripts: Intégrée à l'UI ou pas (fichier dans domoticz/script/lua par exemple, respectant la convention de nommage selon déclencheur time|device). Je conseille la seconde, car si par malheur un script plante Domoticz dans le 1er cas il est sauvegardé dans la BDD de domoticz. Pouvoir redémarrer n'est alors pas aussi simple que le faire après avoir bougé/renommé le fichier problématique car il faut éditer la BDD ou relancer domoticz manuellement, event system désactivé, pour pouvoir virer ou éditer le script problématique. Par contre, en cas de réinstallation complète, il faut penser à récupérer ses scripts en plus de la seule BDD.
C'est aussi la seule solution codée en C++ et (cross-)compilée native donc fatalement plus économe en ressources que des Jeedom/Home-Assistant... La seule vraie verrue qui m'emmerde (mais ce sera aussi le cas ailleurs), c'est la gestion zwave qui arrive: OpenZWave (librairie C++, la stable 2023.2 domoticz est la dernière à l'intégrer) étant abandonné/déprécié, il faut en passer par le genre de tas de merde "moderne" qui m'exaspère: zwavejs.
Que des mecs aient pu écrire un truc destiné à gérer du matériel (à travers une pseudo liaison série pour gérer le protocole radio derrière) en javascript, obligeant à traîner un interpréteur de plus, ses dépendances, pour conseiller en plus de coller cela en conteneur car satisfaire ces dépendances avec des OS variables tiens de l'alignement des planètes... puis interfacer cela en MQTT (un serveur à ajouter doublonnant l'event system intégré) à un auto-discovery côté domoticz.
Bonjour la prise de tête vs un truc intégré jusque là nativement.
Mon conseil pour qqun qui démarre: Partir sur du zigbee (même type de réseau radio maillé basse conso, même si en 2.4GHz plus chargé que le 868MHz, périphériques ayant un minimum d'intelligence via configuration), même s'il faut faire attention à ce qu'on achète car l'interopérabilité entre fabricants n'est pas au niveau de ce qu'imposait zwave (c'est moins cher, mais pas de process de certification assurant l'intéropérabilité en zigbee!). On a un plugin ZigbeeForDomoticz qui permet d'éviter MQTT&Co écrit en python et bien suivi.
[^] # Re: Que choisir comme alarme pour un libriste ?
Posté par lym . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 3.
Pour ma part, ayant démarré avec Domoticz pour gérer la baraque tout juste achetée il y a 7 ans et le gros consommateur que représente un chauffage tout électrique... j'avais rapidement étendu à l'alarme même si c'est normalement pas le même rayon.
L'avantage, c'est que les capteurs de mouvements qui peuvent servir à déterminer si une pièce est vide/occupée et adapter chauffage et autre en conséquence peuvent aussi servir à l'alarme.
Par contre, rien n'est dispo de base... mais ce soft domoticz était (et reste probablement, avec les ajouts de python et plugins depuis) le plus complet en matière de possibilités de script intégrée (blockly, pour des trucs simples en mode newbie que j'ai pas utilisé. Et surtout Lua, pour des choses plus chiadées).
J'ai donc codé le coeur de mon truc en Lua, de manière assez générique (utilisant un prefixage/convention de nommage selon le type de capteur et/ou localisation intérieure extérieure déterminant les poids de base, cf la suite, ce qui permet une intégration de nouveaux sans changer son code tant qu'on respecte la convention de nommage) et utilisant un système de poids additionnés sur une minute glissante.
Grossièrement, un capteur intérieur va avoir un poids déclenchant l'alarme longue (cf la suite) immédiatement et un capteur extérieur ce sera une fraction du seuil d'alarme courte (i.e. plusieurs déclenchements d'un même capteur et/ou de plusieurs requis pour que cela commence à sonner court, puis long si ca insiste).
Ce cumul est comparé à 2 seuils: Alarme courte déclenchant sirènes pour 5 secondes sans notifications (manière de signifier à un intrus n'ayant déclenché que des capteurs externes qu'il a été vu, sans emmerder le voisinage avec une sirène qui sonne longtemps sur le faux positif d'un chat qui passe). Puis alarme longue pour 5 minutes renouvelées au besoin.
Le but étant que cela s'arrête avant même qu'un volet/porte/fenêtre soit forcé, car ensuite en qq minutes c'est foutu donc sonner sur ouverture/capteur intérieur qui tilte insuffisant.
Au début, je n'avais que des capteurs réels (PIR, installés en intérieur et extérieur ou capteurs d'ouverture). J'ai depuis cumulé avec des caméras IP (modèles Dahua peu chers mais complets avec des sensi nocturnes bonnes, installés en extérieur et garage uniquement).
Pour les intégrer, domoticz permet un truc pas mal: La possibilité de faire des switchs/senseurs virtuels! L'intégration est alors aisée: On fait des PIR virtuels qui sont déclenchés quand les caméras génèrent des captures via leur motion intégré.
Ici c'est un service écrit en python (j'aime pas trop ce langage, mais la richesse des imports m'a permis de faire pas mal de choses que je ne détaillerais pas niveau traitement des captures, envois notifs/mails) qui surveille le FTP des caméras toutes les 5 secondes et "déclenche" les PIR virtuels via l'API HTTP/JSON fournie par Domoticz.
J'ai d'ailleurs d'autres services en python s'intégrant ainsi à Domoticz, pas écrits sous forme plugin (je les ai écrit avant que les plugins n'existent): Détection de qui est présent/absent via le BT des smartphones (permet de pallier aux oublis d'activation alarme des enfants en sortant, sachant qu'ils n'oublient jamais leurs téléphones!), filtrage (par décroché/raccroché) du spam téléphonique recyclant un vieux modem voix USB avec la fonctionnalité caller ID.
L'avantage des plugins, c'est que cela intègre les interactions sans devoir passer par l'API HTTP/JSON et la génération d'une page de cconfiguration directement intégrée à l'UI domoticz tandis que je gère mes fichier yml séparés.
Niveaux interactions externes, il y a le support https (via domaine no-ip+certif let's encrypt pour moi) pour l'interface... basique vs d'autres solutions mais efficace et fonctionnant bien même sur un mobile Android pas bien véloce. Permettant aussi de servir ses propres "custom pages" au besoin (mes services python cam IP et filtrage tél en génèrent d'assez simples via yattag par exemple: Assemblage des dernières captures cam permettant une levée de doute rapide et peu gourmande en bande passante, qui fonctionnera même sur un AP surchargé de loc de vacances au besoin d'un côté ; liste d'appelants+raison filtrage éventuel de l'autre) pour ajouter ce qui peut manquer.
=> Il faut se retrousser les manches, car au delà de l'intégration du matériel et gérer les protocoles de com courants en domotique + gestion des évènements associés et présentation (fixe+mobile) il n'y a pas grand chose (mais c'est déjà un gros morceau!)... mais les possibilités de script bien foutues/intégrées + API externes offrent une grande liberté permettant de faire des trucs qu'on ne trouverait pas dans le commerce: Une solution plus Geek que Michu.
Niveau script, j'ai appris à apprécier Lua car il est stable et me fout une paix royale (coucou Python!): Une seule ligne à modifier en 7 ans sur une MAJ domoticz qui incluait un upgrade de l'interpréteur Lua intégré. Les déclencheurs type time (toute les minutes) ou device (un changement d'état sur un interrupteur/capteur...) sont suffisants et l'interaction avec les états/séquenceur d'event bien foutue à partie de tables prise à l'appel/modifiée par le script/restituées en sortie pour déclencher les actions...
Au dessus de Lua, il y a un dérivé spécifique nommé dzVent: Arrivé après que j'ai écrit l'essentiel de mes besoins, pas utilisé mais apprécié de la majorité des utilisateurs.
Et Python (dispo en plus du reste niveau scripts depuis ~3ans, passage obligé pour les plugins): Je conseillerais pour ma part d'en rester à Lua/dzVent côté scripts (stabilité, quasi impossibilité de planter Domoticz avec une erreur dans un script ce qui n'est pas le cas de Python) plutôt que Python (sauf besoin plugin).
2 possibilités pour écrire les scripts: Intégrée à l'UI ou pas (fichier dans domoticz/script/lua par exemple, respectant la convention de nommage selon déclencheur time|device). Je conseille la seconde, car si par malheur un script plante Domoticz dans le 1er cas il est sauvegardé dans la BDD de domoticz. Pouvoir redémarrer n'est alors pas aussi simple que le faire après avoir bougé/renommé le fichier problématique car il faut éditer la BDD ou relancer domoticz manuellement, event system désactivé, pour pouvoir virer ou éditer le script problématique. Par contre, en cas de réinstallation complète, il faut penser à récupérer ses scripts en plus de la seule BDD.
C'est aussi la seule solution codée en C++ et (cross-)compilée native donc fatalement plus économe en ressources que des Jeedom/Home-Assistant... La seule vraie verrue qui m'emmerde (mais ce sera aussi le cas ailleurs), c'est la gestion zwave qui arrive: OpenZWave (librairie C++, la stable 2023.2 domoticz est la dernière à l'intégrer) étant abandonné/déprécié, il faut en passer par le genre de tas de merde "moderne" qui m'exaspère: zwavejs.
Que des mecs aient pu écrire un truc destiné à gérer du matériel (à travers une pseudo liaison série pour gérer le protocole radio derrière) en javascript, obligeant à traîner un interpréteur de plus, ses dépendances, pour conseiller en plus de coller cela en conteneur car satisfaire ces dépendances avec des OS variables tiens de l'alignement des planètes... puis interfacer cela en MQTT (un serveur à ajouter doublonnant l'event system intégré) à un auto-discovery côté domoticz.
Bonjour la prise de tête vs un truc intégré jusque là nativement.
Mon conseil pour qqun qui démarre: Partir sur du zigbee (même type de réseau radio maillé basse conso, même si en 2.4GHz plus chargé que le 868MHz, périphériques ayant un minimum d'intelligence via configuration), même s'il faut faire attention à ce qu'on achète car l'interopérabilité entre fabricants n'est pas au niveau de ce qu'imposait zwave (c'est moins cher, mais pas de process de certification assurant l'intéropérabilité en zigbee!). On a un plugin ZigbeeForDomoticz qui permet d'éviter MQTT&Co écrit en python et bien suivi.