J’ai détecté que lorsque mon VTO perd le réseau et le récupère plus tard, il est toujours reçu comme s’il y avait eu un appel sur l’appareil.
C’est ennuyeux parce que ce sont de faux appels. Mais cela se produit toujours après la récupération d’une perte momentanée de réseau. des idées ?
[2025-03-31 17:13:28] DEBUG : Message received from the daemon: {"devices":{"664":{"calling":1}}}
Essaye de faire un redémarrage automatique de la sonnette dans sa configuration (je crois que ca s’appelle maintenance) depuis la page web.
Je n’ai plus de faux appel depuis qu’elle redémarre tout les jours a minuit.
mais les faux appels ne sont générés que par le plugin. Ni le vth ni l’application ne génèrent d’appels
Avant j’avais des faux appels et la sonnette ne remontait plus le bouton appel au bout de deux jours…
Depuis le redémarrage tout les jours, je n’ai plus de problèmes
peut-être que je ne m’explique pas bien. C’est uniquement le plugin qui génère l’appel, pas l’interphone vidéo. Cela déclenche pour moi des scénarios sans que la sonnette n’ait sonné. Tout simplement parce que le plugin déclenche un appel sans en avoir un. Je ne sais pas si c’est une question de caches propres au plugin ou quelque chose comme ça.
J’avais déjà une maintenance en cours.
Si je comprend.
Mais j’ai eu aussi ce problème, et en faisant ça… Je n’ai plus de problème.
Il est bien activé ?
mon interface graphique est différente. Probablement parce qu’il s’agit d’un ancien VTO.
Bonjour,
Il est possible et facile de mettre à jour le firmware.
Bonsoir,
Même problème avec un VTO 2202-F. Après un peu de debugage, le ¨faux appel" provient de la trame json decodée par le daemon juste après son lancement… curieux tout de même, cela laisse à penser que cela vient du VTO et pas du plugin…
Donc la solution consiste à ne pas traiter le json dans les secondes suivant le lancement du daemon !
Bonjour,
merci pour l’info.
Du coup comment as tu fait pour ne pas traiter le json dans les premières secondes suite au lancement du daemon ?
Bonsoir,
Il y a plusieurs solutions, un simple time.sleep(10) au début du script python du demon… pas très élégant…
J´ai opté pour une boucle qui attend 10 secondes après l´heure de démarrage du daemon avant d’exécuter la suite.
Dans le fichier /plugins/dahuavto/core/class/dahuavto.class.php
Rajouter cette ligne pour capturer l’heure de démarrage du plugin:
config::save('lastDaemonStart', time(), 'dahuavto');
Au début de la fonction public static function deamon_start()
Ensuite dans le fichier /plugins/dahuavto/core/php/dahuavto.php, rajouter les lignes suivantes (entre les //)
require_once __DIR__ . '/../../../../core/php/core.inc.php';
if (!jeedom::apiAccess(init('apikey'), 'dahuavto')) {
echo 'Clef API non valide, vous n\'etes pas autorisé à effectuer cette action';
die();
}
if (init('test') != '') {
echo 'OK';
die();
}
// --- Début ajout temporisation démarrage du daemon
// --- Attend qq secondes après le démarrage du daemon pour ne pas provoqier de fausse sonnerie ---
$lastDaemonStart = config::byKey('lastDaemonStart', 'dahuavto', 0);
$delayInSeconds = 10;
// On vérifie s'il y a un temps de démarrage enregistré ET si ce temps est dans les 10 dernières secondes.
if ($lastDaemonStart != 0 && (time() - $lastDaemonStart) < $delayInSeconds) {
// Si l'appel arrive trop tôt après le démarrage
log::add('dahuavto', 'debug', 'Callback ignoré. Le Démon a démarré il y a moins de ' . $delayInSeconds . ' secondes.');
die();
}
// --- Fin ajout temporisation démarrage du daemon
$result = json_decode(file_get_contents("php://input"), true);
Voilà, testé en relançant manuellement le plugin, je surveille pour voir s’il n’y a pas d’autre cas de fausse sonnerie…
note: l’info sonnerie arrive 2 secondes après le démarrage du daemon chez moi, j’ai mis 10 secondes dans la tempo pour être large !
Ok merci beaucoup ! Je regarderai ca des que possible.
Bon, oubliez ma solution qui n’est qu’un bout de sparadrap - j’ai d’autres cas d’usage pour lesquels ça ne fonctionne pas.
Du coup, j’ai creusé un peu plus et trouvé que le VTO envoie un statut de toutes ses commandes lors de l’établissement de la communication avec le client. Et le plugin ne regarde que l’information d’appel et le déverrouillage de porte sans traiter ce « cas spécial » de l’initialisation. Du coup la vraie solution sera de modifier cela.
A suivre…
Du coup j’ai mis la tempo pour ignorer les messages reçus directement dans le démon, cela devrait couvrir tous les cas de (re-)connexion. C’est en cours de test…