Bonjour,
J’utilise le plugin camera sur un RPI3B / jeedom 4.4.13 (pour une caméra Tp-link Tapo C220.
Dans le choix de la caméra, un post indiquait qu’elle fonctionnait parfaitement avec jeedom.
Cependant : Le flux sur l’application Tapo est fluide (idem sur PC local avec VLC, agent DVR ou autre viewer). J’utilise le flux RTSP en 15 im./s avec la caméra en résolution haute ou basse). Même en basse résolution old school, mais ce n’est pas le but 
sur jeedom seulement, le flux s’arrête, laissant penser à un buffer saturé et une mauvaise gestion de celui-ci (absence de flush quand le buffer est saturé, rejeu d’une video vieille d’une demi-heure !). La caméra ne possède que deux flux RTSP (pas d’URL snapshot a priori). J’ai essayé en mode caméra classique et en mode ONVIF, sans résoudre le problème. Avez vous des pistes pour améliorer le comportement. Un RPI 5 résoudrait-il le pb ? J’ai parcouru le forum sans trouver de solution claire sur une solution autonome sur RPI (sans machine virtuelle pour Motion eye sur une autre machine par exemple / accessoirement motion eye peut-il tourner en // de jeedom).
A terme, je souhaite couper l’accès vidéo au site Chinois, donc m’orienter vers une solution autonome motion eye / scripts / autre , en conservant la video sur réseau local et via internet ? Cela fait beaucoup de questions … Peut-être qu’un tuto de synthèse axé sur les configurations possibles et avantages / inconvénients serait approprié.
Merci par avance.
Bonjour,
Perso j ai motioneye qui tourne en parallèle de mon Jeedom sur mon Rpi, sur port différent. Ca fonctionne mais je sais pas si c’est très recommandé car Motioneye est tres gourmand en ressource.
Il permet en effet d’enregistrer etc… et surtout d’avoir la main sur les paramètres de déclenchement, zone, sensibilité , envoi de mail etc .
Ce tuto de DamDam44 explique même comment intégrer des flux de Motioneye dans le plugin .
Bonjour,
Merci pour la réponse.
En complément : Vous faites tourner motion eye en // de jeedom sur le même RPI. Quelle version de RPI avez vous ?
Sinon, j’avais vu le post (et d’autres) mais il n’est pas clair.
A la question : comment intégrer le stream Rstp, on répond « moi je fais du snapshot » ou « j’utilise une vm sur un serveur ». C’est factuel mais ne permet pas d’avancer. Difficile d’extrapoler.
De plus, concernant le paramétrage des caméras, aucune n’a les mêmes adresses de flux et de snapshot (quand il y en a), donc il ne sert à rien de recopier sur le voisin.
Pour ma caméra, ce qui « marche », ou plutôt qui donne une image, en s’aidant notamment de Se connecter aux caméras IP Tp-link est rtsp://#username#:#password#@#ip#:554/stream1 et ayant renseigné au dessus le user et le passwd, l’adresse IP et en ayant coché le flux rtsp. (stream 2 au lieu de stream 1 baisse la résolution … retour au Paléolithique) … et cela marchotte : Retard et figeage d’image, lecture d’un flux totalement obsolète au bout de qq minutes ou à l’humeur …
En tous cas, le problème n’est pas le Wifi contrairement à ce qu’on peut lire parfois car le flux wifi peut être lu en haute résolution et cadence en // avec VLC + // agent DVR sur un PC puissant. Totalement inutile mais prouve que le pb est côté RPI / jeedom, de ma faute peut-être, dû au RPI que j’utilise et à l’absence d’URL de snapshot de ma caméra (si le snapshot est obligatoire sur ma conf ?).
Merci.
Bonjour,
Mon Rpi est un vieux Pi 2B.
Pour que Motioneye fonctionne et consomme pas trop, j’ai baissé le Frame Rate à 5 img/sec ainsi que tous les réglages que Motioneye defini comme gourmand en CPU .
C est pas le top ni du HD mais ca me suffit.
Bonjour,
Il serait bien de nous montrer la page santé.
On aurait des informations comme la charge, la ram disponible, l’OS et autres
Car là nous ne pouvons pas savoir si votre souci est ou pas un souci de charge ou de configuration
Luis
Bonjour,
Votre réponse me plait bien. C’est rassurant. Je vais tenter le coup avec mon RPI3B, en attendant de réinvestir dans un RPI5.
Je reviendrai vers vous pour le résultat.
Merci encore.
Avec le flux RTSP en 15im./s et en vidéo HD 2k visualisée sur le dashboard.
NB : J’ai désactivé le cron5 sur l’avis d’un post, sans comprendre à quoi cela sert : pas d’impact visuel en tous cas.
Au bout de qq minutes :
avec video figée 2:09/2:09 barre de progression à fond affichage sur pause. si on reforce la lecture, on peut juste relire la vieille vidéo.
Que veut dire « memoire suffisante 0 » ?
En complément, la barre de progression semble afficher par exemple 1:36/1:39 avec le premier chiffre que rattrape le deuxième, puis le 2ème augmente jusqu’à une nouvelle borne. Si le 1er rattrape le 2nd, l’image se fige. Je pense que le buffer est plein et que l’exception est mal gérée (il faudrait au minimum vider le buffer quand il est plein, même si on perd des images)
Petite précision concernant Motioneye et mon Rpi
mon OS boot a partir de la carte SD mais tourne sur un disk SSD.
j ai souvent lu que les cartes SD lachent suite aux accès en lecture ecriture .
Le traitement video consommateur de mémoire ne doit pas arranger ce phénomène connu.
Je suis également sur un SSD externe, et j’ai des sauvegardes journalières et mensuelles automatiques de jeedom sur google drive. Côté charge vidéo, les perfos dépendent évidement du matériel installé mais la video de devrait pas se figer sans récupération automatique. La surcharge CPU persiste avec l’image figée, donc la fréquence CPU peut être amenée à baisser suite à l’élévation de température avec une aggravation du problème. Une dégradation du frame rate ou une perte d’image épisodique serait plus compréhensible.
Bonjour,
En complément, j’ai installé motioneye : Sans résultat probant.
Je pensais qu’en passant par l’URL de snapshot de motioneye recopiée dans l’URL du flux du plugin camera (comme indiqué dans les tutos), la charge RPI serait plus faible et la video plus fluide. J’ai créé une nouvelle caméra récupérant le flux motion eye et j’ai désactivé l’ancienne.
La situation est pire. La video est lue au ralenti (#10 secondes pour afficher 1s).
De plus, la température de mon RPI augmente de façon inquiétante.
Je suis repassé avec la solution sans motion eye et j’ai stoppé le service motioneye.
Je pense réinvestir (ultérieurement) dans un RPI plus puissant.
Merci en tous cas pour votre aide.
Bonjour
En attendant tu pourrais utiliser 1 image par seconde
Pour visualiser sous Jeedom ça suffit amplement et ça consomme nettement moins que 15…
Avis subjectif :
Mais il est clair que jeedom (un RPI) n’est pas un NAS ou NVR.
Il faudrait plutot partir la dessus et y coupler Jeedom (ou avoir un bon RPI dédié avec une extension coral, mais je suis pas expert…
)
La domotique et les cameras c’est complémentaire, mais a chacun son hardware / machine. Puis simplement les faire discuter.
Bonjour,
Il va falloir que je tâtonne un peu pour savoir ou agir efficacement pour baisser le frame rate. Je ne sais pas choisir entre le plugin camera et motion eye, le mieux étant sans doute de baisser la charge au + tôt, sans doute dans motion eye. Cependant, le paramétrage et même l’objet des paramètres est un peu flou, en tous cas pour moi. Il faudra que je fouille dans les tutos. Il faut aussi que je surveille les températures et la charge CPU. J’ai l’impression que le seul fait d’activer motioneye pose déjà problème.
Par ailleurs, je ne souhaite pas multiplier les RPI, ne serait-ce que pour des problèmes de sauvegarde et de maintenance. J’attends des nouvelles de l’adéquation RPI5, jeedom, et plugin avant de me lancer.
Merci en tout cas pour vos conseils.
Epilogue : J’avais arrêté le service motioneye en ssh mais il redémarre systématiquement (maj système et mise sous-tension). J’ai donc désinstallé motioneye : Division par 4 de la charge CPU et baisse de température de plus de 20° ! Motioneye est trop gourmand pour mon RPI3B en // de jeedom.
Bonjour Luis,
Pouvez-vous me dire si vous avez analysé les données que vous avez demandées et ce que vous en avez déduit. Vu le délai, le rapport doit être conséquent et je suis confus de vous avoir donné tant de travail.