Hello @FabEY@Lionel31
J’ai une question à vous soumettre comme vous soutenez bien les tests du plugin
Pour la gestion de la commande info existante heartbeat, fonctionnement actuel : 1 quand caméra OK, 0 quand caméra HS. J’avais fait ça pour que ça soit plus compréhensif pour le commun des mortels. Les devices hik remontant une alarme à 0 pour dire que c’est OK et à 1 pour dire que ce n’est pas OK, j’ai donc inversé la commande dans le plugin.
Je pensais que sur les caméras cette commande videoloss n’était utilisé que pour signalé le heartbeat. Hors il s’avère, et c’est logique, qu’elle est utilisée sur les NVR pour informer que la caméra est déconnecté du NVR le cas échéant. Merci @Lionel31 d’avoir remonté ça.
Cette alarme spécifique n’est donc pas géré actuellement suite à mon implémentation ci-dessus. On va pas dire que c’est un bug mais ça me pose souci qu’elle soit pas gérée.
J’ai donc plusieurs solutions pour corriger et je voulais vos avis :
Soit je casse ce que j’ai fait, qui potentiellement peut avoir un impact chez les gens si ils utilisent cette commande. Je l’inverse pour remettre dans les clous en fait et ça règle le problème du channel sur les NVR. (0 pas d’alarme ou pas de perte vidéo et 1 = alarme perte de connexion ou perte vidéo. Le problème c’est que je sais pas évaluer si c’est utilisé par beaucoup de personnes…
Soit je crée une commande spécifique sur reception de videoloss active mais potentiellement mon démon peut envoyer videoloss active lors de la perte de la connexion avec le device (c’est moins qui génère cet évènement) donc c’est pas gégé si lors du démarrage du plugin on a une perte de connexion qui peut potentiellement inversé le truc. J’exclue donc cette solution bricolée.
Soit je renomme ma commande actuelle heartbeat qui ne serait plus un videoloss à proprement parlé mais qui serait une commande spécifique propre au plugin et à la présence du device (le démon derrière gerera avec le videoloss). Je gère via le démon les évènements spécifiques up/down qui sont en fait des connexion OK ou KO.
Puis je gère les alarmes videoloss active comme les autres (pour rejoindre la solution 1)
EDIT : je suis en train de me dire que ça va être compliqué car va falloir tester le fait si on est sur NVR ou pas pour gérer ça. Ce qui potentiellement peut poser sur certains types de caméras qui ont une double optique…
Du coup j’hésite entre 1 et 3 sachant que 3 c’est plus de boulot…
J’aurais tendance à dire 1 mais il va falloir prévenir les gens…
Alors clairement je préconise la solution 1. Pour plusieurs raisons (pour mon cas) :
J’affiche les informations Videoloss et Hearbeat mais je ne les historisent pas. Si la caméra est KO je priviligie l’alerte IP via le plugin Network. D’ailleurs, lorsque la caméra est de nouveau en ligne la notification disparait automatiquement. Clairement Videoloss et Heartbeat ne sont pas des informations utiles pour moi. Si la caméra est hors ligne je le sais. Si la caméra est en ligne mais que je ne reçois pas le flux vidéo (mauvais paramétrage par exemple) je le sais aussi via l’image depuis le plugin Caméra.
Si toutefois ces informations sont utilisées par d’autres utilisateurs, il existe un outil très simple pour connaitre la redirection (onglet commande de l’information, roue crantée, onglet informations, utilisé par …). Si on prend un cas très large, pour une personne qui utilise ce plugin avec 10 caméras, cela fait 20 commandes à ajuster. Franchement ça va. Tu le signales, déjà c’est bien Si tu indiques une attention particulière à ce sujet dans le changelog je pense que les gens sont assez grands pour faire cette petite modification.
Installation actuelle du plugin = 26. ça va Si c’était 200 ce serait peut-être plus délicat (et encore).
Mon avis, il vaut mieux le faire tout de suite que dans 6 mois, choisir cette solution qui me parait aussi la plus simple, et te concentrer sur les points qui restent à développer et qui me paraissent nettement plus intéressant
Merci de nous proposer en tout cas ce choix.
Bonne journée
Pour ma part je pense que le 1 serait la meilleur solution et de plus comme le dit @FabEY
il vaut mieux le faire tout de suite que dans 6 mois
De plus on reste dans la logique du fabriquant alarme qui passe 1 quand on a problème
Après dans un second temps (quand tu le pourras et si c’est nécessaire/demandé) il sera toujours
temps de développer la solution 3 car pour ma part rajouter les cam comme le fait @FabEY
dans le plugin NetWork me parait une solution viable
Et effectivement prévenir les utilisateurs, afin anticiper ça
Ok je vais faire les modifs pour la solution 1
Après il y #plugin-monitorsensor aussi qui est bien.
Peut être qu’on pourrait demande a son dev de rajouter les checks sur ce plugin ?
Je pense que ça doit marcher aussi de gérer une notif si perte de communication avec les paramètres avancés de l’équipement
J’ai oublié de précisé que je virtualise toutes les informations de mes équipements dont j’ai besoin.
Dans la partie virtualisation on peut inverser l’état. Donc pour moi ça ne change rien.
Merci pour l’info sur le plugin sensor
effectivement il a l ai intéressant notamment pour le Z-wave
car actuellement je contrôlai ça avec un bloc code trouvé sur la communauté
Le plugin est mis à jour en beta avec la correction du heartbeat Solution 1
Normalement @Lionel31 ça va regler ton probleme de perte vidéo sur ton NVR si tu débranches une cam.
Doc et changelog mis à jour
Le fonctionnement à partir de maintenant de la commande info heartbeat (videoloss)
0 si OK et device présent
1 si problème, déconnexion réseau ou perte vidéo sur les NVR
pour info J’ai mis à jour le plugin avec activation / désactivation de la détection. La fonction tant attendue.
Si vous voulez échanger par rapport à ça, autre fil ou en MP (si c’est juste pour remonter un probleme ou OK)
Est-ce qu’il est du coup également possible de supprimer les alertes « chan heartbeat KO » pour quelles ne soient plus dans les logs. j’ai une info comme ca toutes les secondes, et pourtant les caméras fonctionne super bien. si je supprime le « chan heartbeat KO » il revient tout seul.
Alors je pense pas , cela vient d’une latence que tu dois avoir sur ton réseaux et/ou ton Jeedom
il m’arrive de l’avoir également quand je surcharge mon réseaux
Il faudrait voir si on peux plutôt intégrer un paramètre dans la conf du plugin avec un temps
de contrôle. 1s, 2s 5s … @loic69 qu’en penses-tu ? est-ce possible ?
Oui c est possible mais moyennant du temps.
Aujourd’hui des que le heartbeat remonte comme ko dans l’api je le remonte egalzment sans me poser de questions.
Je cherche des dev d’ailleurs pour me donner un coup de main techno nodeJS et PHP.
Je ne m en sors pas seul d’autant que je suis parti en parallele sur un projet de station meteo avec un ESP32 car je galere avec ma sonde rfxcom exterieure
Si tu indiques une attention particulière à ce sujet dans le changelog je pense que les gens sont assez grands pour faire cette petite modification.