Faut migrer en 4.5 avant le 1er Janvier 2026 pour ne pas perdre historique 2026

Bonjour,
{annonce au public :rofl:}
{edit 21/12 : ajout explication de l’origine de ce code}

Résumé :
Si votre version de Jeedom est inférieure à la 4.5 :
Sans intervention, Tout historique après le 01/01/2026 sera supprimé et NON-archivé.
(quelle que soit votre plateforme matérielle)
détails et quelles interventions possibles ci-dessous dans ce message.

Je suis en Jeedom v 4.4.19

En souvenirs de mes déboires de l’année dernière et anticipation pour le 01 Janvier 2026 :
Historique KO depuis le 01/01 sur vieilles versions de Jeedom

J’ai regardé le core/class/history.class.php
(ligne 214 et +)

public static function archive() {
		global $JEEDOM_INTERNAL_CONFIG;
		$sql = 'DELETE FROM history WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM history WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM history WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `value` IS NULL';
		DB::Prepare($sql, array());

spécifiquement ici

$sql = 'DELETE FROM history WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';

et aussi ici :

$sql = 'DELETE FROM historyArch WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';

(C’est le code de la fonction « archive » de Jeedom, qui est censée faire, chaque jour, l’archivage des données d’historique)

Vous l’avez compris :
Si votre version de Jeedom est inférieure à la 4.5 :
Sans intervention, Tout historique après le 01/01/2026 sera supprimé et NON-archivé.
(quelle que soit votre plateforme matérielle)

Pour éviter le soucis, il faut
-Soit modifier cette date de 2026 dans ce fichier (via l’éditeur de fichier Jeedom)
-ou alors migrer en version 4.5 minimum, qui est la version dans laquelle cette fonction a été modifiée pour ne plus créer ce problème.

Je ne suis pas prêt à passer en 4.5, j’ai donc édité le fichier et remplacé 2026 par 2040 !

Pour passer en 4.5, il me faut un peu de temps pour faire mes tests de non-régression : vieux plugins et vieux matériels.

voilà, joyeux noël et surtout une bonne année, dès le 01/01

(on verra bien début janvier 2026, s’il y a un nouveau sujet sur « l’historique disparu » :thinking:)
(si quelqu’un de l’équipe Jeedom a des stats de % de migration en 4.5…)

L’explication de cette date « dans le futur » se trouve dans la correction datant de Février 2025 par @Loic sur le github :
https://github.com/jeedom/core/issues/3034

Bonjour,
Cette limitation était la pour les 1er rpi qui quand ils démarrent avant la mise à jour, ntp se retrouve dans le futur (2027 en général). Il n’est donc pas possible d’utiliser du dynamique (next year) car la date systeme étant 2027 cela donne 2028 et ne nettoie donc pas les historique dans le futur.
Ce problème concernant surtout les rpi1 je viens de supprimer toute cette partie

17 « J'aime »

Bonjour,

Je n’ai pas la réponse, mais si c’est vrai : bravo et bien vue !

Ce qui est sûr, c’est qu’en version 4.5 cela n’est plus présent. Vous êtes en version 4.4.19, vous devez pouvoir passer en 4.5 facilement (lire le changelog, il faut reprendre les #Trigger# des scénarios si vous les utilisez par exemple), mais au final, il n’y a pas grand chose à reprendre.
Et la fonction [Rechercher] (interne à Jeedom) permet de trouver cela facilement dans vos scénarios.

Vous pouvez tester cela facilement dans une machine virtuelle sur votre PC par exemple.

3 « J'aime »

Idem en 4.4.20

	public static function archive() {
		global $JEEDOM_INTERNAL_CONFIG;
		$sql = 'DELETE FROM history WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM history WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `datetime` <= "2000-01-01 01:00:00" OR  `datetime` >= "2026-01-01 01:00:00"';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM history WHERE `value` IS NULL';
		DB::Prepare($sql, array());
		$sql = 'DELETE FROM historyArch WHERE `value` IS NULL';
3 « J'aime »

Merci Fabrice pour le commentaire.

Faut que je fasse effectivement le tour de mes scénarios car j’ai pas mal utilisé les triggers, en particulier dans des blocs code.
C’est à mon avis ce qui me prendra le plus de temps, le reste du changelog ne « semble pas » impacter mon usage. :fearful:

Vous pouvez tester cela facilement dans une machine virtuelle sur votre PC par exemple.

Vu ma plateforme « ancienne » (Raspberry pi3 B+), avant migration, je fait habituellement un test sur un autre pi3B+ dédié à ces tests (et aussi à prendre le relais si un jour l’original « claque »…)…

Dans l’absolue, si vous pouvez oubliez le Pi3B et le remplacer par un Pi4B (et pas un 5, qui lui nécessite un refroidissement actif), vous y gagnerez beaucoup.

Le Pi3B n’est pas stable chez tout le monde en 64 bit (donc l’accès à certains plugins n’est pas possible) et il n’a qu’1 seul Go de mémoire RAM, ce qui rend la compilation de certains plugins problématique (exemple ZwaveJS).

Bonjour @Fabrice,

Comme #trigger# est évoqué, je souhaitais simplement faire suivre ce sujet qui pointe des problèmes identifiés avec les commandes #trigger_id# et #trigger_name#:

Pour ceux qui ne souhaiterais pas lire l’ensemble des messages, @Henri a fait un résumé aux messages 82 et 83.

Ainsi, si vos besoins se résument à identifier le déclencheur qui lance un scénario et suivant la reconduction ou pas de l’actuelle commande #trigger# dans les prochaines versions de Jeedom, vous pourrez ‹ simplifier › votre prochaine vie d’utilisateur sur le long terme.

Mais avant de tout changer, notons que la fonction #trigger# fonctionne en 4.5.1 :wink:

A priori, rien ne bloquerait pour passer en 4.5.1 et ainsi garder vos historiques :blush:

1 « J'aime »

Hello,

Merci de l’info…c’est fou quand même, comment cela a t il pu être codé de la sorte ? Va t il y avoir un correctif 4.4 ou obligé de modifier à la main? c’est dans mes cordes évidemment mais je pense a tout ceux qui l’ignorent ou ne saurait pas faire.

Et idem pas prévu de passer dans les semaines a venir en 4.5 …

Merci pour l’info
je tourne avec la version 4.4.20
je viens de faire la modif pour passer 2026 en 2027, le temps de passer sereinement sur la 4.5

Hello,
Merci, ça évitera les galères annuelles :slight_smile: Je pensais être tranquille à ce niveau avec la V4.4 …
Patché de 2026 à 2050, ça devrait le faire pour un moment :smiley:

2 « J'aime »

un développeur n’est qu’un homme !
donc un code parfait sans bug est une utopie…

mais on est toujours en attente de nouveau génie et le source est dispo sur github

2 « J'aime »

Heu bah les mises à jour servent justement à ça en fait… quel que soit le logiciel…! Ce n’est pas plus fou que de refuser de faire les mises à jour finalement !

7 « J'aime »

Sans la remarque de @bertrandep pas sûr que cela soit taupé avant 2026…de la a dire que c’est un bug quand on code 2026 en end of date, pas sur quand même :face_with_spiral_eyes:. Si un update peu être poussé pour tous en 4.4 c’est l’essentiel.

La 4.5 vu les remontées, on va attendre encore un peu et bravo aux testeurs qui corrigent les bugs.

Merci.

1 « J'aime »

Merci d’être plus précis sur cette affirmation stp. Surtout que le reste, perso j’ai pas compris, un pseudo bug sur une date c’est loin d’être une nouveauté y’en a même des célèbres : Bug de l’an 2038 — Wikipédia

Allez un peu d’eau dans le vin va y’a rien qui justifie de s’offusquer à ce point.

Il me semble @Aurelien que l’intention n’est pas de critiquer le #4.5
Il y a beaucoup de messages et questions sur le forum en ce moment sur la 4.5, ce qui est tout à fait normal pour une version majeure.
il peut y avoir des questions sur des incompréhensions sur les nouveautés,
il y a certainement des problèmes avec des plugins anciens qui ne fonctionnent plus correctement, et peut-être nécessitent un changement

Bref compréhensible qu’une partie des utilisateurs préfèrent attendre quelques versions mineures et des relivraisons de plugins.

moi par exemple je suis passé en 4.5 sur un système de test, mais pas encore sur ma prod où j’ai pas mal de protocoles et plugins qui tournent

Jeedom, merci à l’équipe!!! fait tourner chez moi des fonctions essentielles comme le chauffage et l’alarme

2 « J'aime »

Exactement et évidemment que je ne suis pas la pour ‹ critiquer › mais @Aurelien a toujours la vision suprême et ça ne concerne pas que ce post et je clos ce debat. Mais faites une maj 4.4 ça peut se comprendre de ne pas se lancer dans une mise a jour majeure dans les semaines qui suivent, ça s’appelle la sécurité et stabilité.

Et oui merci pour tout le taf accompli sur la 4.5 !

OK moi je veux bien mais tu confimes bien que le core 4.5 est fonctionnel. Il ne resterait donc dans l’équation que quelques plugins qui n’auraient pas suivi le mouvement malgré le large délai qui été laissé…

Mauvais signe à priori malgré cela il reste l’immense travail de sélection fourni par la communauté :
Compatibilité des plugins avec Debian 12 - Bookworm, php 8, python 3.11 - Plugins - Communauté Jeedom

Et en dernier recours des correctifs au cas par cas sont encore proposés régulèrement pour les quelques plugins récalcitrants.

1 « J'aime »

Pourquoi ne pas simplement tester sur une machine virtuelle pour commencer ? Quel que soit le sujet faut bien commencer quelque part à un moment.

Oh oui! je confirme totalement que le core 4.5 est fonctionnel pour moi; je suis super content de cette version :smiling_face_with_three_hearts:
Je suis passé en Prod sur la 4.5 après tests sur un jeedom qui gère une petite installation avec seulement quelques plugin et en zigbee.

Par contre pas eu encore le temps de tout tester sur une grosse installation avec plein de plugins et zigbee+zwave+mysensors+mqtt

vu que je pars en congés à l’étranger, priorité que l’alarme fonctionne et le chauffage à mon retour :slight_smile:

Un cas classique que l’on oublie souvent quand on « tombe » sur un bug : c’est tout simplement que ça avait un sens quand ce bout de code avait été écrit, mais ensuite plein de code autour a changé et tout simplement cette partie là du code n’a pas été remise en question.

c’est le cas dans des bugs du genre « bug de l’an 2000 » : le développeur qui a écrit le code plusieurs dizaines d’années avant peut toujours rétorquer:

  • les specs ne précisaient pas qu’il fallait que ça marche pendant x années, ou après l’an 2000
  • aucun cas de test ne testait cela; donc mon code passe tous les cas de test et est donc valable :slight_smile:

Bonsoir,

Donc en gros, vous vous plaignez d’un bug mais vous ne voulez pas appliquer le correctif si j’ai bien compris ?

2 « J'aime »