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.
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
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).
Grosse fatigue hier soir 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:
La consigne est une valeur numérique pouvant être le résultat d’un calcul.
La valeur est une valeur numérique pouvant être le résultat d’un calcul.
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.
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.
Une anomalie est remontée si la valeur absolue de la différence entre la consigne et la valeur est supérieure à la limite.
La détection d’anomalie peut être désactivée en fonction de la valeur de l’état.
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, 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.
Je ne comprend pas
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.
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 ?
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.
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)
J’essaie d’utiliser ça pour supposer la santé de la pompe.