Savoir si le flux RTSP d'une caméra est disponible ou non

[537719]

Bonjour,

J’ai une ring doorbell wired configurée en docker avec ringmqtt gérée par jmqtt et par le plugin caméra.
Au bout d’un temps variable, de quelques heures à quelques jours go2rtc se met en erreur (timeout) et je n’ai plus d’image (une camera barrée grisée est affichée.

Il me suffit de relancer le container pour que tout refonctionne pour un moment.
Avec le plugin docker2 c’est simple et efficace.

La seule difficulté est de trouver comment savoir si le flux est actif ou non. J’ai regardé dans les informations brutes de l’équipement caméra mais je n’ai rien trouvé qui semble correspondre à mon besoin.

En attendant, j’ai placé un bouton pour redémarrer le container par dessus l’image de la caméra dans mon design mais, ce n’est pas automatique.

Voici la configuration de la camé"ra sans le plugin :

Si quelqu’un a une idée, je suis preneur.

Merci d’avance.

[Tonio16]

Salut

Et ai tu lances un renouvellement automatique par scénario ? Une solution par défaut je suis d’accord.

Antoine

[537719]

Merci, j’ai déjà pensé à cette solution, mais comme il peut ne se passer que quelques dizaines de minutes avant plantage, ça ne résoudra pas tous les cas même si ça limite les effets indésirables.
La difficulté étant de déterminer la fréquence de ce redémarrage pour optimiser les résultats.

[defmy]

Et tu vois le timeout dans les logs ?

[537719]

Je le vois dans les log du container, pas facile d’accès depuis Jeedom.

J’ai essayé de mettre une alerte sur communication dans la caméra, ça m’a bien passé le timeout dans les infos à 1 mais il y est resté depuis.

Peut-être qu’avec un scenario je pourrai remettre cette information à zéro après le redémarrage du container ?

[defmy]

Oui tu peux forcer à 0 avec event dans un scénario, c’est plus simple. Sinon tu peux créer une vérification directement sur le serveur, si l’erreur est détectée tu envois une info à Jeedom en HTTP ou MQTT pour indiquer un problème et tu exécutes un scénario suivant l’état de ton virtuel

[537719]

J’ai tenté ça :

$cam003=eqLogic::byId(263); // cam003
$timeout=$cam003->getStatus('timeout');
if($timeout==1) {
  log::add("_537719","warning",$cam003->getName().' : '.$timeout);
  cmd::byId(6628)->execCmd(); // redémarre le container ring2mqtt
  $cam003->setStatus('timeout',0);
  log::add("_537719","warning","Redémarrage du container ring2mqtt"); 
  log::add("_537719","warning",$cam003->getStatus('timeout'));
  message::add("ChkCam003","Redémarrage du container ring2mqtt");
}

Lancé une fois la valeur du timeout passe bien à 0 mais elle revient toute seule à 1.

Programmé toutes les 5 mn, le log donne :

0082|[2024-09-30 11:45:02]WARNING : CAM003 : 1
0083|[2024-09-30 11:45:15]WARNING : Redémarrage du container ring2mqtt
0084|[2024-09-30 11:45:15]WARNING : 0
0085|[2024-09-30 11:50:03]WARNING : CAM003 : 1
0086|[2024-09-30 11:50:16]WARNING : Redémarrage du container ring2mqtt
0087|[2024-09-30 11:50:16]WARNING : 0
0088|[2024-09-30 11:55:02]WARNING : CAM003 : 1
0089|[2024-09-30 11:55:15]WARNING : Redémarrage du container ring2mqtt
0090|[2024-09-30 11:55:15]WARNING : 0
0091|[2024-09-30 12:00:03]WARNING : CAM003 : 1
0092|[2024-09-30 12:00:20]WARNING : Redémarrage du container ring2mqtt
0093|[2024-09-30 12:00:20]WARNING : 0

Et le scenario redémarre le container à chaque fois, ce qui n’est pas le but recherché…

Le lastCommuncication est fantaisiste (ou du moins pas mis à jour régulièrement)…

[defmy]

Étrange, même en forçant un refresh sur ton end-point ?

[537719]

Désolé je ne saisis pas ce que tu veux dire… Je vais tenter de mettre à jour la date de dernière communication en même temps (ou à très peu près) que le timeout, histoire de voir.

[defmy]

Je voulais dire rafraichir le noeud Docker, je ne sais pas s’il y a une option pour ça, je n’utilise pas ce plugin.

[537719]

J’ai bien l’impression que la lecture du flux rtsp n’est pas prise en compte comme une communication ce qui pose problème pour ce que je voulais tester.
Je vais regarder du côté des logs du container…