Merci pour ton partage
Merci pour le code
J’ai remonté une sauvegarde vite fait (proxmox) et j’ai exécuté le code.
Me voila avec mes valeurs précédentes. Plus qu’à remonter l’info tranquillement dans l’autre sens 
Merci, très sympa le rapport.
Pour ne pas faire tout à la main j’ai combiné les deux codes. Celui ci-dessous est à mettre dans un bloc code de scénario sur une sauvegarde où on souhaite récupérer les informations. Il va générer au niveau du log du scénario le code php qu’on va ensuite utiliser dans un bloc code sur la version où on souhaite restaurer les informations. A utiliser avec prudence après sauvegarde etc.
$msg = "\n// Code php pour rétablir les informations de niveau de batterie\n";
$list = array();
foreach (eqLogic::all() as $eqLogic) {
if ($eqLogic->getStatus('battery', -2) != -2 && $eqLogic->getConfiguration('battery_type', '') != 'Batterie') {
array_push($list, $eqLogic);
}
}
foreach ($list as $hbeq) {
$eqId = $hbeq->getId();
$lastChange=$hbeq->getConfiguration('batterytime');
$msg .= '$eqLogic = eqLogic::byId('.$eqId.'); ';
$msg .= '$newDate = \''.$lastChange.'\'; ';
$msg .= 'if (is_object($eqLogic)) { $eqLogic->setConfiguration(\'batterytime\', $newDate); $eqLogic->save();} else { $scenario->setLog($eqlLogic." non trouvé !"); }'."\n";
}
$msg .= "// Fin de code";
$scenario->setLog($msg);
2 « J'aime »
Bonjour,
J’ai restauré ma vm avec ma sauvegarde proxmox de la semaine passée avec Jeedom en 4.4.20
Malheureusement ton code ne fonctionne pas :
[2025-11-30 16:00:30][SCENARIO] **-- Début :** Scenario lance manuellement. [2025-11-30 16:00:30][SCENARIO] - Exécution du sous-élément de type [action] : code [2025-11-30 16:00:30][SCENARIO] Exécution d'un bloc code [2025-11-30 16:00:30][SCENARIO] syntax error, unexpected token "" [2025-11-30 16:00:30][SCENARIO] Fin correcte du scénario`
Mais je vais me passer de mes anciennes métriques de batterie. Merci
Bonjour,
Ton script pour réaliser un export me donne une erreur lorsque je souhaite sauvegarder le scénario après avoir fait copier-coller du code dans le bloc :
[MySQL] Error code : 22007 (1366). Incorrect string value: '\xF0\x9F\x9F\xA2';...' for column jeedom.scenarioExpression.expressionat row 1 : INSERT INTOscenarioExpressionSETid= :id,scenarioSubElement_id= :scenarioSubElement_id,type= :type,subtype= :subtype,expression= :expression,options= :options,order = :order
Apparemment c’est cette partie qu’il n’apprécie pas :
Ca fonctionne très bien ton script sinon :
Tu as fais comment pour faire reconnaitre les images ? c’est plus sympa
Bonjour,
Chez moi ça fonctionne très bien :
(Encore merci @537719 !)
Problème d’encodage UTF-8 dans le copier/coller ?
Comment tu as fais pour contourner ? Je suis même passé par Notepad++ pour préciser encodage UTF8 mais il me dit la même chose (mais oui le problème vient de la.)
J’avoue ne rien avoir fait de spécial ! Juste un copier/coller moi aussi, mais je n’ai eu aucun soucis…
Pour info, je suis sur Windows 11 25H2.
Bon ben j’ai demandé à ChatGpt de corriger et il vient de me le faire et ça marche
Il faut remplacer par ça :
$batt[0] = « \u{1F7E2} »; // Haut
$batt[1] = « \u{1F7E0} »; // Moyen
$batt[2] = « \u{1F534} »; // Bas$depuis[0] = « \u{1F7E9} »; // Ok
$depuis[1] = « \u{2B1B} »; // Ko
Et l’explication :
Le code PHP lui-même est correct, ce sont simplement les emojis qui ne passent pas dans ta base MySQL si elle est encore en utf8 (3 bytes).
Pourquoi ça marche ?
- Les emojis sont écrits en séquences Unicode (
\u{1F7E2}) - PHP les interprète correctement (PHP 7+)
- MySQL reçoit une chaîne ASCII, pas un caractère 4-bytes → plus d’erreur 1366
Ok, super !
Je me doutais bien que ça venait de l’encodage…
1 « J'aime »
Je pense que c’est peut-être lié aux 3 apostrophes à la fin, le formatage semble être mal passé quand j’ai collé le code.
J’ai eu le soucis aussi. En fait, certaines tables dans ma base de données mysql étaient en utf8 (qui n’acceptent pas semble-t-il les caractères unicode). Cela concerne possiblement des installations assez anciennes car sur une autre installation plus récente les tables sont bien en utf8mb4.
J’ai trouvé quelques infos ici : Erreur SQL "Error code : 22007 (1366). Incorrect string value..."
2 « J'aime »
Ce problème de 2023 ?
Bonsoir
Suite à mon constat et malgré les solutions proposées pour récupérer les dates de remplacement, j’ai laissé en l’état. Mais merci pour ceux qui se sont investis.
C’est le 28/11 suite au remplacement de 2 piles que j’avais fait le constat .
Aujourd’hui je m’aperçois que ces 2 capteurs, changés le même jour, ont deux dates différentes. 3 jours et 6 jours sans être intervenu manuellement.
Les 2 étaient pourtant bien à 0 jour le 28, cf. ma première copie d’écran.
Je ne sais pas si c’est en lien avec le passage en 4.5, mais c’est tout de même étrange que ces dates changent toutes seules.
De mémoire le core met a jour automatiquement la date de changement de piles si la batterie etait a 0 et qu’elle revient ensuite sur un taux élevé ensuite, signe qu’elle a été changée.
Mais j’ai déjà vu sur des capteurs un peu fantaisistes des niveaux de batterie qui varient beaucoup et pas toujours dans le bon sens pour que ce soit crédible.
Edit : Après une petite recherche rapide c’est effectivement visiblement fait par eqLogic.class.php du moins en 4.4 :
if ($_pourcent > 90 && $_pourcent > ($this->getStatus('battery', 0) * 1.5)) {
$this->setConfiguration('batterytime', date('Y-m-d H:i:s'));
$this->save(true);
}
Ça pourrait être une explication si mes piles avaient été faibles, mais là les deux sont neuves et installées le même jour dans le même modèle de capteur.
Une des deux a été réinitialisée 3 jours plus tard et sont toujours à 100%.
Ce que je veux dire c’est que parfois quand tu historise les niveau de batterie de certains capteurs tu as parfois des surprises 
En 2 jours la batterie repasse de 44% à 74%, trop beau pour être vrai
Bonjour
Encore une date qui a été réinitialisée hier sur un équipement, alors que la valeur de la batterie à 100% n’a pas bougée depuis le remplacement du 28/11
J’ai passé l’info en historisée pour voir si il y a des fluctuations, mais c’est quand même surprenant.
Cet équipement a un fonctionnement bizarre sur son retour batterie. Même quand je change les piles, il reste à 7%, bon… ça fonctionne sinon
Bonjour
Quelques semaines se sont écoulées et j’ai toujours des équipements (des capteurs de présence) dont les dates de changement de piles sont fantaisistes.
Elles semblent être réinitialisées aléatoirement sans aucune intervention de ma part, et coté historique c’est le calme plat avec un 100% qui ne varie pas
Par exemple sur ces 6 capteurs, 2 seulement sont restés avec la date de changement de version du core en 4.5 (42jours), les autres ne correspondent à rien. Ni update, ni redémarrage…