Tags : Jeedom commande debian
Votre Jeedom tourne depuis plusieurs mois, vous installez des plugins, créez des scénarios, ajoutez des équipements… et un jour, vous remarquez que c’est plus lent, ou que l’espace disque sature. Pas de panique ! Voici un guide ultra-détaillé pour remettre votre système à neuf sans tout casser.
Avant toute chose, penser à faire une sauvegarde ou un snapshot !
1. Contrôler la santé du système
Vérifier l’espace disque disponible
df -h

Ce qui vous intéresse : la ligne /
, qui est votre racine.
- Si elle dépasse 80 %, il est temps d’agir.
- Plus c’est proche de 100 %, plus Jeedom risque de planter ou corrompre des données.
Voir quels dossiers prennent de la place
du -h /var/www/html | sort -hr | head -20
Cela vous montre les 20 répertoires les plus lourds dans Jeedom.

À faire : identifiez les répertoires suspects (ex : /log
, /plugins
, /backup
, /data
).
À ne pas faire : supprimer sans vérifier. Certains plugins (ex : camera
, homebridge
) ont des données importantes dans /data/
.
2. Nettoyer les logs de Jeedom
Les logs sont dans /var/www/html/log
. Ils peuvent devenir énormes si un plugin est trop bavard ou bug.
Lister les plus gros :
du -sh /var/www/html/log/* | sort -hr | head -20

Vider un fichier de log :
> /var/www/html/log/http.error
Cela vide le fichier sans le supprimer. Ne jamais faire
rm
ici sauf cas spécifique.
Pour scenarioLog
, c’est un dossier. Pour le vider :
rm -rf /var/www/html/log/scenarioLog/*
Ne jamais supprimer le dossier lui-même, seulement son contenu.
3. Gérer les sauvegardes
Par défaut, Jeedom garde les sauvegardes dans /var/www/html/backup
, même après sauvegarde distante (NAS, Google Drive, etc.).
Lister les sauvegardes :
ls -lh /var/www/html/backup/

Supprimer celles trop vieilles ou trop lourdes :
rm /var/www/html/backup/backup-2023*.gz
Astuce : ne garder que les 3 dernières automatiquement :
ls -tp /var/www/html/backup/*.gz | grep -v '/$' | tail -n +4 | xargs -r rm --
4. Alléger les historiques dans la base Jeedom
Se connecter à la base MariaDB :
sudo mysql -u root
USE jeedom;

Purger les événements vieux de plus de 10 jours :
DELETE FROM event WHERE datetime < NOW() - INTERVAL 10 DAY;

Purger l’historique agrégé (historyArch) :
DELETE FROM historyArch WHERE datetime < NOW() - INTERVAL 7 DAY;

À faire : toujours faire une sauvegarde avant ces requêtes si vous débutez.
À ne pas faire : supprimer ces tables sans raison (via DROP
), vous perdriez des structures.
5. Activer la purge automatique des historiques
Permet à Jeedom de supprimer lui-même les données au-delà d’un certain âge.
REPLACE INTO config (plugin, `key`, `value`) VALUES
('core', 'historyPurgeEnable', '1'),
('core', 'historyArchPurgeEnable', '1'),
('core', 'historyPurgeDelay', '7');
Cela dit à Jeedom : « je garde 7 jours d’historique, ensuite je supprime ».
Vérification :
SELECT * FROM config WHERE `key` LIKE '%Purge%';
À faire : vérifier que historyPurgeEnable
ET historyArchPurgeEnable
sont à 1
.

6. Désactiver les historiques inutiles
Certaines commandes historisent des valeurs toutes les secondes (température, pourcentage, etc.).
Lister les cmd_id
les plus remplies :
SELECT cmd_id, COUNT(*) as nb FROM history GROUP BY cmd_id ORDER BY nb DESC LIMIT 10;
Notez les IDs, puis allez dans Jeedom > Équipement > Onglet « Commandes » > décochez « Historiser » pour les lignes concernées.
À faire : désactiver l’historique sur les commandes non critiques (batterie, pourcentage, timestamp).

Requête complète pour avoir les noms associés
SELECT c.id, c.name AS cmd_name, e.name AS eq_name, COUNT(*) AS nb
FROM history h
JOIN cmd c ON h.cmd_id = c.id
JOIN eqLogic e ON c.eqLogic_id = e.id
GROUP BY h.cmd_id
ORDER BY nb DESC
LIMIT 10;

7. Surveiller les processus en cours
ps aux | grep php | grep jee
Regardez s’il y a des processus jeeScenario.php
actifs pendant plusieurs minutes. Un ou deux, c’est normal. Si vous voyez :
- un processus qui tourne depuis longtemps
- des dizaines de processus en simultané
→ Cela peut être causé par un scénario qui boucle, ou avec un sleep
mal placé.
À faire : corriger les scénarios concernés.

8. Augmenter le swap si Jeedom manque de mémoire
Vérifier l’état :
free -h
Si la RAM est utilisée à 90%+ et qu’il y a très peu de swap, ajoutez-en.

Créer un fichier swap de 4 Go :
sudo swapoff -a
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Le rendre permanent :
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab
À faire : sur Raspberry Pi, mini-PC, VM Jeedom avec < 4 Go de RAM.
Vider le swap :
Petit code Php a exécuter une fois par mois pour vider le swap et les ancienne sauvegarde
$scenario->setLog("=== 🧼 DÉBUT NETTOYAGE MENSUEL JEEDOM ===");
// 📊 AVANT : État disque et mémoire
$scenario->setLog("📊 Espace disque AVANT :");
$scenario->setLog(shell_exec("df -h | grep -E '^/dev/'"));
$scenario->setLog("📉 Mémoire & swap AVANT :");
$scenario->setLog(shell_exec("free -h"));
// 🔧 Commandes de nettoyage
$cmds = [
'sudo systemctl stop systemd-journald',
'sudo rm -rf /var/log/journal/*',
'sudo systemctl start systemd-journald',
'sudo swapoff /swapfile',
'sudo swapon /swapfile'
];
foreach ($cmds as $cmd) {
$scenario->setLog("▶️ Exécution : $cmd");
$output = shell_exec($cmd . ' 2>&1');
if (trim($output) !== '') {
$scenario->setLog("ℹ️ Sortie : $output");
} else {
$scenario->setLog("✅ OK (aucun message)");
}
sleep(1);
}
// 🧹 Suppression des backups Jeedom de +15 jours
$scenario->setLog("🧹 Suppression des backups Jeedom de plus de 15 jours :");
$backupOutput = shell_exec("find /var/www/html/backup -type f -name '*.gz' -mtime +15 -exec rm -v {} \\;");
if (trim($backupOutput) !== '') {
$scenario->setLog("📁 Backups supprimés :\n$backupOutput");
} else {
$scenario->setLog("✅ Aucun backup à supprimer.");
}
// 📊 APRÈS : État disque et mémoire
$scenario->setLog("📊 Espace disque APRÈS :");
$scenario->setLog(shell_exec("df -h | grep -E '^/dev/'"));
$scenario->setLog("📉 Mémoire & swap APRÈS :");
$scenario->setLog(shell_exec("free -h"));
$scenario->setLog("=== ✅ FIN DU NETTOYAGE MENSUEL JEEDOM ===");
Ce qui nous donne en log

8. Surveiller son jeedom
Ce bloc de code PHP est conçu pour surveiller automatiquement l’état système de Jeedom (RAM, Swap, température CPU, espace disque) et déclencher une alerte si un ou plusieurs seuils critiques sont dépassés.
Il est fait pour être intégré dans un bloc code d’un scénario Jeedom, exécuté régulièrement (ex : toutes les heures).
// ========== CONFIGURATION ==========
$alerte = '';
$log = '';
// ========== RAM ==========
exec("free | awk '/Mem:/ {printf(\"%.0f\", \$3/\$2 * 100)}'", $ram_out);
$ram_used = intval($ram_out[0]);
// ========== Swap ==========
exec("free -m | awk '/Swap:/ {print \$3}'", $swap_out);
$swap_used = intval($swap_out[0]);
// ========== Température CPU ==========
$temp_raw = @file_get_contents("/sys/class/thermal/thermal_zone0/temp");
$cpu_temp = ($temp_raw !== false) ? intval($temp_raw) / 1000 : -1;
// ========== Disque ==========
exec("df / | awk 'END{print \$(NF-1)}' | tr -d \"%\"", $disk_out);
$disk_used = intval($disk_out[0]);
// ========== LOG DEBUG ==========
$log .= "RAM: $ram_used% | Swap: $swap_used Mo | Temp: $cpu_temp °C | Disque: $disk_used%\n";
// ========== CONSTRUCTION DU MESSAGE ==========
if ($ram_used > 90) {
$alerte .= "RAM ${ram_used}% | ";
}
if ($swap_used > 2048) {
$alerte .= "Swap ${swap_used} Mo | ";
}
if ($cpu_temp > 75) {
$alerte .= "Temp ${cpu_temp}C | ";
}
if ($disk_used > 70) {
$alerte .= "Disque ${disk_used}%";
}
// Nettoyage du message
$alerte = rtrim($alerte, " | ");
if ($alerte != '') {
$message = "🚨 Alerte système Jeedom : $alerte";
$scenario->setData('alert_message', $message);
$log .= "➡️ Alerte détectée. Message stocké : $message";
} else {
$scenario->setData('alert_message', '');
$log .= "✅ Aucun seuil dépassé, aucune alerte.";
}
$scenario->setLog($log);
Puis j’ajoute un si :
variable(alert_message) != ""
alors j’envoie en message
variable(alert_message)

J’espère que cet article pourra vous etre utile
n’oubliez pas que la vie est une fête
Loïc

