Nouvelle version du plugin "defauts"

La version 1.2.1 du plugin Défauts a été publiée.

Le plugin Défauts permet de détecter des incohérences entre un état et une valeur mesurée.

Exemples de détections possible:

  • Lampe allumée mais pas de puissance consommée (ampoule défectueuse?).
  • Lampe éteinte mais puissance supérieure à zéro (erreur de l’état retourné?).
  • Chaudière enclenchée mais température trop basse.
  • Pompe enclenchée mais pas de débit.

La documentation est accessible depuis le Market.

7 « J'aime »

Intéressant car il y a tellement de truc à surveiller en domotique.

Est-ce que le plugin est adapté pour surveiller (en masse) des retours d’état de modules (Z-Wave) par rapport à un ordre envoyé ?

Exemple : on envoie un ordre pour modifier la consigne du chauffage et on modifie la consigne de référence dans un virtuel, le plugin peut-il comparer la consigne idéale et la consigne réelle (retour d’état venant du module) pour vérifier que l’ordre a finalement bien été transmis ?

Je n’ai pas essayé ce genre de configuration. Ma domotique est encore relativement simple (quelques lampes à la cave et vers l’entrée avec des capteurs de luminosité et de présence.

Le plugin compare un état binaire et une valeur analogique. La valeur analogique doit pouvoir être le résultat d’un calcul (j’avoue que j’ai uniquement testé avec une valeur mesurée type consommation d’une lampe). J’imagine donc que la mesure peut être la valeur absolue de la différence entre la consigne de référence et la consigne réelle.

Tu pourras alors configurer la surveillance pour qu’une anomalie soit remontée si la valeur calculée n’est pas passée sous une valeur seuil un certain temps après que l’ordre a été donné.

Attention,il faut que l’ordre reste à 1 au minimum durant la période d’attente. Si ton ordre est un impulsion de 2 secondes et que la consigne réelle nécessite 5 secondes pour atteindre la valeur cible, tu n’auras jamais une détection d’anomalie.

J’ai fais une simulation et le résultat est presque concluant:

1. Création d’une lampe virtuelle

J’ai créé un virtuel avec qui simule une lampe avec un état et une puissance:


image

2. Création d’un slider

J’ai ensuite créé un slider pour la valeur de comparaison:


image

3. Création d’une surveillance

J’ai alors ajouté une surveillance dans un eqLogic qui existait déjà:

  • L’état pour la surveillance est la commande de type info qui indique si la lampe est allumée
  • La mesure pour la surveillance est le calcul de la valeur absolue de la différence entre la puissance le la lampe et la valeur du slider
  • Le paramètre Hors est désactivé
    ’ ’ ’
    abs(#[niveau3][lampe][Puissance]#-#[niveau3][slider][Etat]#)
    ’ ’ ’

Résultat

Une anomalie est déclenchées lorsque la lampe est allumée depuis plus de 5 secondes et que la différence entre la puissance de la lampe et la consigne est supérieure à -10 et inférieure à 10. En d’autre termes. il y a une anomalie lorsque la valeur correspond à la consigne et une situation normal lorsque la valeur ese éloignée de la consigne :upside_down_face:

Je vais ajouter une option aux commandes surveillance dans le plugin pour inverser le test (anomalie lorsque le résultat du calcul est supérieur à la limite).

1 « J'aime »

Grosse fatigue hier soir :upside_down_face: En fait. il suffit de cocher inverser dans la config de la surveillance pour avoir l’effet attendu lorsque l’état est à 1.

Par contre, la question de @Domatizer me fait réaliser que ça ne fonctionne pas si l’on veut surveiller la différence entre une consigne et une valeur quelque soit l’état. Je vais donc créer un nouveau type de surveillance pour ce cas de figure.

Les règles de ce nouveau type de surveillance seront les suivantes:

  1. La consigne est une valeur numérique pouvant être le résultat d’un calcul.
  2. La valeur est une valeur numérique pouvant être le résultat d’un calcul.
  3. La limite est l’écart maximum toléré entre la consigne et la valeur. elle peut être configurée en valeur absolue ou en pourcentage de la consigne.
  4. L’état est une info binaire. Il peut ne pas être défini, dans ce cas, la détection d’anomalie est activée en permanence.
  5. Une anomalie est remontée si la valeur absolue de la différence entre la consigne et la valeur est supérieure à la limite.
  6. La détection d’anomalie peut être désactivée en fonction de la valeur de l’état.
  7. La détection d’anomalie est désactivée durant un temps configurable après chaque changement de valeur de l’état.

En voyant la description de ton plugin, j’avais en tête ce problème ci

Certaines personnes étaient intéressées pour surveiller le retour d’état d’une commande par rapport à une commande RF envoyée : comparaison entre l’état réel et l’état idéal après exécution une commande et ré-exécution de la commande en cas d’échec

Oui, c’est effectivement des soucis avec mes modules z-wave qui m’ont poussé à faire ce plugin. Pour le moment, le plugin ne fait que détecter les incohérences. Il n’est pas prévu pour relance ses ordre d’une manière simple.

Actuellement, il faudrait configurer deux surveillances par switch:

  • une pour surveiller l’état 0 et renvoyer un ordre si la puissance est supérieur au seuil.
  • une pour surveiller l’état 1 et renvoyer un ordre si la puissance est inférieure au seuil.

Cette solution ne me convient pas.

  • Trop lourd.
  • Difficile de coordonner les répétitions d’ordre avec la ordre contraire qui pourrait être déclenché par une commande manuelle ou venant d’un scénario,

Pour le moment, je travaille sur la mise en place de la surveillance pour les différences entre une valeur de consigne et une valeur mesurée.

Je verrai ensuite si le plugin peut évoluer pour envoyer des ordres correctifs ou s’il sera préférable de créer un nouveau plugin pour ça.

Perso, j’associe toujours un virtuel à mes équipements. C’est ensuite le virtuel est affiché dans mes dashboards et qui interagit avec mes scénarios. L’avantage est que le remplacement d’un équipement physique est simple en cas de panne. Peut-être qu’il faudra prévoir un plugin qui viendra à la place de ce virtuel et qui intègre la répétition d’ordre si nécessaire.

Oui, il ne faut le faire que pour les commandes critiques comme le chauffage.

Après faut voir la demande derrière, si le besoin est réellement là.

:+1:

Bonjour @ktn et @Domatizer (merci pour l’alerte sur le plugin).

Du coup l’idée serait alors :

  • d’être alerté quand il y a incohérence entre une action et son résultat grâce au plugin
  • de déclencher une action dans ce cas (est-ce possible ?) pour renvoyer l’ordre par scénario ?

Oui, c’est ce que fait le plugin. Une info binaire associée à chaque surveillance de cohérence entre un état et une mesure. Il est possible, par exemple, de récupérer cette info dans un scénario.

Le problème est que la même info binaire est activée par la surveillance s’il a y une incohérence à l’allumage ou à l’extinction. Il est possible de contourner ce problème en utilisant les options En et Hors pour ne surveiller que l’enclenchement ou le déclenchement.

La version 1.3.0 est disponible.

J’y ai ajouté un type de commande pour la surveillance de consigne.

Je vous laisse consulter la documentation.

1 « J'aime »

Bonjour,
Merci pour ton plugin que j’aimerais essayer
Mais impossible d’accéder à la documentation

Je ne comprend pas :thinking:
J’ai cliqué sur le lien ci-dessus, sur le lien du market et sur le bouton de la page de configuration du plugin. Je suis arrivé à chaque fois sur la page de documentation du plugin.

L’url est https://ktn001.github.io/defauts/fr_FR/index.html

Peux-tu me donner plus de détails ?

Hier ça ne fonctionnait pas sous chrome mais c’était ok sous edge
aujourd’hui c’est ok avec les 2 navigateurs comprend pas non plus

Par contre je n’arrive pas à faire fonctionner le plugin

Je voudrais par exemple surveiller cet équipement :

encore merci pour ton aide

Le plugin est prévu pour vérifier la cohérence entre un état et une mesure.

Pour ton équipement, l’état sera la commande 1007 mais je ne vois pas de mesure pour vérifier la cohérence.

Chez moi, j’utilise de plugin pour surveiller des switches z-wave qui ont une commande qui indique la puissance consommée. Je peux donc vérifier si la consommation est supérieure à 2 watts lorsque la lampe est allumée et inférieure à 2 watt lorsqu’elle est éteinte.

Si ton équipement ne t’indique pas la puissance, tu as peut-être une autre mesure qui peut être utilisée.

Tu peux, par exemple, utiliser un capteur de luminosité pour vérifier que la luminosité est supérieur 100 lux lorsque la lampe est allumée. Tu ne pourras pas vérifier la cohérence lorsque la lampe est éteinte si elle se trouve dans un local avec une fenêtre, il faudra donc désactiver l’option Hors.

Je viens de voir ce plugin dans la news Jeedom sur LinkedIn.
Donc je viens faire un tour !

Pour le moment, j’utilise des virtuels qui font le même travail, mais ce plugin rendra surement plus propre.

Exemple de surveillance que j’ai : la pompe de relevage
Je combine alertes et infos importantes

  • Date/heure de dernier déclenchement (info)
  • Flag de dernière exécution (booléen si pas de déclenchement depuis plus de x heures - sûrement qu’elle ne marche plus)
  • Nombre de déclenchement de la journée (info)
  • Flag de nb de déclenchement (booléen si trop de déclenchements sur un court délai)

Je vais regarder le plugin mais j’aimerais bien également que chaque test ait un niveau de criticité. Certains tests sont plus urgents que d’autres : info, warning, urgence ?

1 « J'aime »

Est-ce que la création de plusieurs équipements (un pour info, un pour warnig et un pour urgence) peut être une solution?

Mais je ne suis pas sûr que tes exemples correspondent ce qui est prévu par le plugin. Il est prévu pour surveiller la cohérence entre un état et une mesure. Dans le cas de la pompe de relevage, il faudrait, par exemple, une mesure du niveau. Tu pourrais alors prévoir une alerte si le niveau est toujours supérieur à une valeur limite alors que la pompe fonctionne depuis un certains temps.

Bonjour,

Je n’ai malheureusement pas de contrôle du niveau lié à la pompe de relevage.
Et le flotteur seul ne permettrait pas d’indiquer que la pompe se déclenche trop souvent (problème de clapet anti-retour)

En revanche depuis le garage j’ai un relevé de consommation de la pompe et le contact sec de l’alarme (un second flotteur au cas où le flotteur normal ne se serait pas déclencher)

Capture

J’essaie d’utiliser ça pour supposer la santé de la pompe.