Erreur du plugin Caméra avec cache MySQL

[Gautomax]

Bonjour,

J’ai passé la gestion du cache de mon instance Jeedom en MySQL et le plugin Caméra a cessé de faire des captures :

• bouton Enregistrer les fichiers jpg sont vides
• bouton Capture l’erreur suivante apparait :

SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\xFF\xD8\xFF\xE0\x00\x10...' for column `jeedom`.`cache`.`value` at row 1
#0 /var/www/html/core/class/DB.class.php(147): PDOStatement->execute()
#1 /var/www/html/core/class/cache.class.php(439): DB::Prepare()
#2 /var/www/html/core/class/cache.class.php(225): MariadbCache::save()
#3 /var/www/html/core/class/cache.class.php(85): cache->save()
#4 /var/www/html/plugins/camera/core/class/camera.class.php(854): cache::set()
#5 /var/www/html/plugins/camera/core/class/camera.class.php(878): camera->getSnapshot()
#6 /var/www/html/plugins/camera/core/class/camera.class.php(1033): camera->takeSnapshot()
#7 /var/www/html/core/class/cmd.class.php(1684): cameraCmd->execute()
#8 /var/www/html/core/ajax/cmd.ajax.php(102): cmd->execCmd()
#9 {main}

J’ai réussi à contourner le problème en modifiant le fichier plugins\camera\core\class\camera.class.php à la ligne 854 en remplaçant

cache::set('camera' . $this->getId() . 'cache', $data);

par

cache::set('camera' . $this->getId() . 'cache', '');

J’avoue ne pas avoir trop cherché comment corriger le formatage de $data quand j’ai vu que la chaine vide donnait satisfaction.

J’ai bien conscience que ma configuration est exotique, mais comme j’ai poussé l’analyse la charge de travail est diminuée.

Bonne journée,

Jean-Christophe

---

Informations Jeedom

Core : 4.6.1 (master)
DNS Jeedom : non

Plugin : Caméra
Version : 2026-07-28 01:23:51 (stable)
Statut Démon : Démarré - (2026-08-05 00:15:24)

Santé

🟢 Matériel : docker
🟢 Système à jour : OK
🟢 Cron actif : OK
🟢 Scénario actif : OK
🟢 Démarré : OK 2026-08-04 18:01:03
🟢 Date système (dernière heure enregistrée) : OK 2026-08-05 00:57:47 (2026-08-05 00:06:01)
🟢 Droits sudo : OK
🟢 Version Jeedom : 4.6.1
🟢 Version OS : debian 12.15
🟢 Version PHP : 8.2.32
🟢 Nombre de processus Apache : 13
🟢 Version OS : Linux 583df08c44cc 6.8.0-136-generic #136-Ubuntu SMP PREEMPT_DYNAMIC Wed Jul  1 21:53:05 UTC 2026 x86_64 GNU/Linux  [12.15]
🟢 Version database : 11.6.2-MariaDB-ubu2404
🟢 Espace disque libre : 73 %
🟢 Connexion active/max/autorisée : 17/71/151
🟢 Taille base de données : 996.92 MB
🟢 Espace disque libre tmp : 100 %
🟢 Mémoire disponible : 82 % (Total 31832 Mo)
🟢 Mémoire suffisante : 0 
🟢 Erreur I/O : 0
🟢 Swap disponible : 83 % (Total 2048 Mo)
🟢 Swappiness : 60 %
🟢 Charge : 1.38 - 1.6 - 1.98
🟢 Configuration réseau interne : OK
🟢 Configuration réseau externe : OK
🟢 Node : v20.20.2 
🟢 Python 3 : Python 3.11.2 
🟢 Persistance du cache : OK

[Mips]

Bonjour

C’est ridicule, vous avez juste cassé le fonctionnement du plugin en effaçant le cache systématiquement…

A ne surtout pas faire.

[Gautomax]

Bonjour,

Mon intention n’était pas de dégrader le fonctionnement du plugin mais de corriger le problème que j’ai rencontré.

En regardant le code, ma compréhension est que ce cache n’est utilisé que lorsque getSnapshot() est appelé dans les 2 tics suivant une précédente capture :

public function getSnapshot($_takesnapshot = false) {
	$inprogress = cache::bykey('camera' . $this->getId() . 'inprogress');
	$info = $inprogress->getValue(array('state' => 0, 'datetime' => strtotime('now')));
	if ($info['state'] == 1 && (strtotime('now') - 2) <= $info['datetime']) {
		$cahe = cache::bykey('camera' . $this->getId() . 'cache');
		if ($cahe->getValue() != '') {
			return $cahe->getValue();
		}
	}
[...]
}

J’en ai déduit que ce mécanisme sert principalement d’optimisation pour éviter des appels rapprochés à la caméra. Le correctif que j’ai proposé désactive effectivement cette optimisation, mais permet également d’éviter la mise en cache systématique de plusieurs Mo de données à chaque capture.

De mon côté, je n’ai pas observé de régression sur les autres fonctionnalités du plugin lors de mes tests. Bien entendu, si ce cache remplit un autre rôle que celui que j’ai identifié, je suis preneur d’explications afin de mieux comprendre son usage.

Les développeurs du plugin seront sans doute les mieux placés pour confirmer l’intention initiale de ce mécanisme et évaluer la pertinence de la modification proposée.