pour les envoyées via NTFY. Mais j’ai remarqué que toutes les nuits à minuit les apikey changent. Alors je n’ai plus la possibilité de récuperer les images alors.
le code camera.class.php montre ce qui se passe chaque nuit :
la fonction : public static function cronDaily()
fait exactement ceci pour chaque caméra :
tue le processus ffmpeg
2. tue rtsp-to-hls
3. supprime le fichier .m3u8
4. supprime les segments .ts
5.génère une nouvelle localApiKey
6.sauvegarde l’équipement
7.rafraîchit le widget
La ligne responsable est : $camera->setConfiguration(‹ localApiKey ›, config::genKey());
puis immédiatement :$camera->save();
Comment garder une APIKEY fixe ou bien la récuperer dés modification pour la remettre dans mon scenario ?
Version Jeedom
4.6.1
Version OS
debian 11.11
Caméra (camera) - stable Version 2026-07-28 01:23:51
Le changelog de la version beta du plugin mentionne :
Changelog Caméra
IMPORTANT
S’il n’y a pas d’information sur la mise à jour, c’est que celle-ci concerne uniquement de la mise à jour de documentation, de traduction ou de texte.
23/07/2026
Ajout d’une option pour convertir les fluxs H265 en H264
Correction d’un bug sur l’accès aux enregistrements vidéo
Amélioration de la gestion des retours a la ligne dans le widget
Ajout de la camera Reolink TrackMix
Ajout de la caméra Ubiquiti G5 Turret Ultra
Correction de la tâche de nettoyage quotidienne (arrêt des flux HLS obsolètes et rotation de la clé d’accès locale)
Version minimale du core Jeedom requise : 4.3.1
rotation de la clé locale, donc la solution c’est de passer en beta ou attendre le passage en stable ou alors c’est un bug autre voir l’équipe de dev ce qu’ils en pensent
Non justement la correction c’était que cette tâche ne fonctionnait pas alors qu’elle était prévue pour fonctionner.
Et la rotation des clés étaient déjà codée ainsi donc depuis cette correction, cela a débloqué la tâche et donc notamment la rotation des clés.
Je ne sais plus par coeur les commandes qui existent mais depuis un scénario jeedom ça ne me paraît pas le bon chemin de faire un appel api sur lui même pour récupérer une info.
Effectivement lorsque le plugin change l’api key, il met à jour la commande info qui donne l’url du flux.
Mais je ne comprends pas pourquoi tu fais du code ici pour quelque chose que tu peux faire nativement dans jeedom.
Surtout que tu manipules des variables et non des tags ce qui veut dire que tu va générer des écritures régulières pour pas grand chose.
Pour moi le seul intérêt de faire du code, ça serait de récupérer l’adresse de ton jeedom plutot que de la mettre en dur dans la variable $base.
[2026-09-12 12:14:08][SCENARIO] - Exécution du sous-élément de type [action] : code
[2026-09-12 12:14:08][SCENARIO] Exécution d'un bloc code
[2026-09-12 12:14:08][SCENARIO] http://192.168.1.201:80/
[2026-09-12 12:14:08][SCENARIO] Fin correcte du scénario
Si tu mets l’url en dur, pas besoin de faire du code et surtout d’écrire dans des variables (qui sont potentiellement consommatrices d’écriture sur disque).
Tu peux simplement faire :
C’est à la fois plus simple et moins consommateur de ressource vu que l’url est récupérée du cache et le tag écrit en mémoire et pas sur le disque.
2e remarque :
Lorsque tu fais du code privilégie plutôt le passage des infos via des tags et non via des variables.
Dans le cas d’espèce ça ne change pas grand chose (des déclenchements d’alerte de caméra tu dois pas en avoir 200 par jour) mais si jamais tu as quelque chose qui tourne très régulièrement tu va générer des écritures disque pour rien.
Ca permet de faire passer des données d’un bloc code au reste du scénario dans un tag plutot que dans une variable donc en mémoire plutot que sur le disque.
Si ton information reste interne au scénario c’est ce qu’il y a de plus optimisé.
) : récupere la ApiKey tournante via lacommande adhoc au lancemant du scénario et concaténer :
