Bonjour à tous,
Je vais me lancer dans la modification du module caméra pour ajouter des fonctionnalités et avant de commencer j’ai quelques questions :
j’ai vu dans les articles de blogs qui parlent de la V4 que Gladys supporte les caméras USB, j’ai vu nul part dans l’interface ou la doc comment procéder, c’est vraiment pris en compte ?
j’aimerais ajouter un bouton sur la box camera du dashboard qui nous enverrai vers le flux en temps reel de la caméra, il y a un moyen de créer des pages supplémentaire dans gladys? (si il y a un exemple de module qui le fait je suis preneur )
Je vais également ajouter en natif le support du module photo/caméra officiel de la raspberry, pour l’instant je vois différentes façon de le faire mais je n’ai pas encore étudier en détail ces possibilités :
un container docker qui lance (à la manière du container mqtt) un serveur rtsp avec le flux de la camera, l’avantage est qu’on récupère simplement le flux video de /dev/video0 donc on pourrait utiliser d’autres caméra (usb, CSI, …)
Si vous avez d’autres idées sur le module caméra n’hésitez pas à les donner, une fois que je connaitrai bien ce module ça ira plus vite
ps: je risque d’être assez lent pour faire ces modifications, je fais seulement du python depuis maintenant 2ans et j’ai par moment des grosses périodes d’indisponibilité à cause de mon doctorat.
Bonjour @Exilon62,
Dans la doc, j’ai mis ça il y a quelque temps : Caméra USB
Finalement j’ai débranché ma caméra USB Logitech car Gladys plantait régulièrement.
Avec l’aide de la communauté, on a trouvé que le problème venait de la caméra qui devait demander trop de courant à mon Raspi. Depuis qu’elle est débranchée, ça tourne sans problème.
Je voulais tester avec un hub USB alimenté en 220V, mais je ne l’ai pas encore fait.
merci pour ta réponse je n’avais pas vu J’ai fais quelques tests avec la lib nodejs et elle fonctionne plutot pas mal, je vais sans doute partir sur ça
Euh tu veux faire comment ça ? je suis preneur de ton astuce technique C’est un sujet très technique, à discuter avant implémentation.
Il faut savoir que dans Gladys on veut forcément que tout transite via Gladys sur le Pi, on ne se connecte jamais depuis le navigateur aux périphériques en direct, car on veut que tout le matériel domotique ne soit pas ouvert sur internet (pour rester sécurisé), et que Gladys soit le proxy entre le navigateur de l’utilisateur et la caméra.
J’ai quelques idées en tête de mon côté mais ça demande beaucoup de testing (c’est très très gourmand en ressource le temps réel).
Je privilégierais plutôt cette option, pas besoin de faire pop un container docker qui fait exactement ce que cette lib fait
je t’avoue que j’ai pas encore fini de tester donc niveau ressource j’en ai aucune idée
Je pensais donc récupérer le flux de la caméra avec le module pi-camera-connect et les envoyer côté client avec du web-RTC au lieu de MJPEG qui semble beaucoup plus couteux en ressource si j’ai bien compris. Le problème de web-RTC c’est qu’il faut un navigateur récent il me semble
Je suis pas fan de faire une solution propre juste à la caméra pi. Si on veut rajoute du live aux caméras dans Gladys, autant le rajouter à toute les caméras Dans Gladys 4 la gestion de chaque « type d’objet » est native, on évite de faire des tambouilles propre à chaque périphérique. ça permet d’avoir une intégration profonde (dans les discussions, le dashboard)
En fait le mécanisme qu’on utilise actuellement pour les caméras pourraient fonctionner en mode live ( on utilise des websockets, connexion permanente donc c’est performant )
Il faut juste tweaker un peu tout le process pour être sur que le process de capture d’une image soit inférieur à 100ms/50ms (pour avoir du 10/20 fps). Le transport en websockets fonctionne nickel avec ces latences là, le problème est plus côté capture.
Après, de ce que j’ai vu dans la lib pi-caméra-connect, ils sont dans ces temps avec ce code:
import { StreamCamera, Codec } from "pi-camera-connect";
import * as fs from "fs";
const runApp = async () => {
const streamCamera = new StreamCamera({
codec: Codec.H264
});
const videoStream = streamCamera.createStream();
const writeStream = fs.createWriteStream("video-stream.h264");
// Pipe the video stream to our video file
videoStream.pipe(writeStream);
await streamCamera.startCapture();
// We can also listen to data events as they arrive
videoStream.on("data", data => console.log("New data", data));
videoStream.on("end", data => console.log("Video stream has ended"));
// Wait for 5 seconds
await new Promise(resolve => setTimeout(() => resolve(), 5000));
await streamCamera.stopCapture();
};
runApp();
Dans cet exemple, tu as juste à envoyer la data du videoStream.on(‹ data ›) au front via les fonctions Gladys de capture de nouvelle image. ça sera propagé au front.
Et tout cela fonctionnera via le Gladys Gateway aussi !
Oui tu as complétement raison !
Je commence à bien prendre en main leur lib mais j’ai je n’arrive pas à faire une version de developpement de gladys sur raspberry…
J’ai eu aucun soucis pour l’installation et la lancement du serveur mais au moment de lancer le front, j’ai une grosse erreur :
Summary
You can view the application in browser.Local: http://localhost:1444
On Your Network: http://192.168.0.21:1444<— Last few GCs —>
fa[5372:0x20a9450] 260735 ms: Mark-sweep 222.0 (226.8) → 221.6 (226.8) MB, 433.3 / 0.2 ms (+ 43.5 ms in 7 steps since start of marking, biggest step 7.9 ms, walltime since start of marking 529 ms) (average mu = 0.175, current mu = 0.099) allocation fail[5372:0x20a9450] 261255 ms: Mark-sweep 221.9 (226.8) → 221.7 (226.8) MB, 459.6 / 0.1 ms (+ 25.9 ms in 6 steps since start of marking, biggest step 7.0 ms, walltime since start of marking 520 ms) (average mu = 0.123, current mu = 0.067) allocation fail<— JS stacktrace —>==== JS stack trace ========================================= 0: ExitFrame [pc: 0xee3360]
Security context: 0x3984ea21
1: fnModule(aka fnModule) [0x30b9091d] [/home/pi/gladys/front/node_modules/webpack/lib/Stats.js:~321] [pc=0x32d449d4](this=0x56f40279 ,0x568ecead )
2: map [0x3984716d](this=0x2b67f10d <JSArray[1144]>,0x30b9091d <JSFunction fnModule (sfi = 0x4d7457fd)>)
3: /* anonymous /(aka / anonymous */) [0x30b9163d] [/hom…FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Aborted
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! gladys-front@ start:development: npm run -s dev
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the gladys-front@ start:development script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2020-11-21T17_16_06_339Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! gladys-front@ start: per-env
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the gladys-front@ start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2020-11-21T17_16_06_432Z-debug.log
Une idée @pierre-gilles pour lancer le front sur mon raspberry de test ?
La stack strace dit « ouf of memory » error, il n’y a plus de RAM dispo sur ton Pi problablement.
Lancer le front de dev sur le Pi, c’est ambitieux. Limite tu pourrais lancer le backend sur le Pi (plus léger), et le front sur ton laptop, et faire pointer le front sur le backend du pi ?
Lancer le front en mode dev c’est lancer webpack (un tool JS très très lourd qui fait de la transpilation live et du hot reload), c’est malheureusement très gourmand ^^ Tu nous diras.
Sinon rien à voir, mais quelqu’un a converti ffmpeg en WASM afin de pouvoir utiliser ffmpeg dans Node.js nativement.
C’est possible pour l’instant uniquement avec des flags expérimentaux, mais c’est très prometteur et dès que ça sera possible sans flag ça permettra sûrement d’avoir la performance qu’on recherche pour du live.
Il y a codecov/patch qui n’est pas passé et qui me demande d’ajouter des tests mais je ne sais pas quoi rajouter, je ne vois pas comment tester seulement les quelques lignes que j’ai ajoutées au fichier server/services/rtsp-camera/lib/getImage.js
@pierre-gilles Tu me conseilles quoi pour que ce test passe ?
Comme tu peux le voir sur ton fichier à toi (le résumé de coverage): Code coverage done right.
Le coverage dit (en rouge) que les tests ne passent pas par le if que tu as rajouté if (cameraUrlParam.value === 'pi-camera') {
Donc l’idée c’est de rajouter à la main un device où le cameraUrlParam.value est égale à pi-camera.
Merci pour la réponse !
Je n’arrive pas à importer le package que j’utilise dans les tests, il a une manière différente de faire l’import ?
Ça ne serait pas lié à ce fichier qui semble remplacer la lib ffmpeg par exemple ? Gladys/FfmpegMock.test.js at master · GladysAssistant/Gladys · GitHub
Bonjour a tous ,
J’ai une camera chinoise qui est compatible flux rtsp, mais voila quand je l’installe sur mon smartphone avec app Yosee, je n’ai plus accès au flux de la camera sur Gladys . Est ce normal, où je ne prend pas le bon flux video. Voila mon flux : rtsp://admin:pwd@192.168.1.100:554/onvif1. (j’ai bien remplacé l’admin et le pwd). Avec ce flux j’ai bien une image, mais soit sur Yosee soit sur Gladys. C’est une camera Kerui Z05H-20
Merci de votre aide
@Psoy Il faudrait se renseigner sur le modèle sur internet, voir si d’autres utilisateurs ont des problèmes similaires, ça sent la caméra qui ne peut gérer qu’un seul flux
Sinon tu la connecte uniquement à Gladys, et tu regarde le flux sur ton téléphone ou via l’intégration Telegram (en mode: “Montre moi la caméra du salon” je sais pas si tu as déjà testé)
Bonjour,
je n’ai pas précisé, mais c’est une camera motorisée et j’ai besoin de l’appli. Mais je voulais savoir si des camera a flux unique existait, ou si c’est moi qui ne prends pas le bon flux,
Je ne pense pas nécessairement que ce soit une caméra “à flux unique”, je pense que c’est une caméra assez bas de gamme avec très peu de puissance, et donc elle n’arrive pas à répondre assez vite à 2 clients en même temps !
Une recherche sur internet confirme cette théorie:
merci Pierre Gilles,
j’ai fais des recherches sur les flux , mais je ne suis pas tombé sur les sujets que tu as trouvé. Je te remercie encore pour le temps que tu nous accordes. je vais approfondir ça
Bonne journée
)
C’est un sujet très technique, à discuter avant implémentation.
