Prévisions Tempo à J+9 - Mise en oeuvre

Plugins
1

(re) bonjour à tous,
Le post [Tutoriel] Prévision des couleurs Tempo à J+9 a attiré toute mon attention et j’ai voulu le mettre en œuvre (un grand merci à @Bison pour ce partage).
En résumé, çà ne veut pas fonctionner chez moi. En bref (enfin presque :wink:), quelques copies d’écran que ce que j’ai fait :

image
image784×402 23.7 KB

image
image1585×474 46.5 KB

Comme on le voit sur cette 2ème capture, çà a fonctionné pour « J + 1 probability », mais çà n’est pas constant.
Les logs d’exécution (j’ai déjà tenté « debug » mais je n’ai pas plus d’infos) :

0000|[2026-01-11 15:40:51][ERROR] Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2001 milliseconds
0001|[2026-01-11 15:41:07][ERROR] Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0002|[2026-01-11 15:43:11][ERROR] Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0003|[2026-01-11 15:43:27][ERROR] Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0004|[2026-01-11 15:43:44][ERROR] Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0005|[2026-01-11 15:44:19][ERROR] Erreur pour [Technique][Prévisions tempo][J+1 date] : Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0006|[2026-01-11 15:44:35][ERROR] Erreur pour [Technique][Prévisions tempo][J+1 color] : Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds
0007|[2026-01-11 15:44:51][ERROR] Erreur pour [Technique][Prévisions tempo][J+1 probability] : Echec de la requête HTTP : https://open-dpe.fr/assets/tempo_days_lite.json cURL error : Resolving timed out after 2000 milliseconds

De nombreuses recherches sur community (dont je remercie les nombreux « helpers ») m’ont orienté vers un problème de DNS, mais je n’ai vraiment obtenu aucun résultat, malgré de nombreux essais.
Par ailleurs, toutes les communications avec le monde extérieur fonctionnent bien, tant que je ne « joue » pas trop avec les DNS de la box :innocent:.
Par exemple, les plugins CloudSync Pro, Jeedom Connect, Météo France, RTE Ecowatt Tempo fonctionnent très bien. Bien sur, j’obtiens le json sans problème dans le navigateur.
Je me dis qu’il doit y avoir quelque chose d’évident, mais que je ne trouve pas :unamused:. C’est pourquoi je sollicite l’aide de la communauté que je remercie par avance.

Nota : soyez indulgent sur les tags, je n’ai pas vraiment trouvé lesquels étaient les plus pertinents.

Ci-dessous les éléments habituels (santé, configuration du plugin script, configuration du DNS). Si d’autres informations sont estimées utiles, je le fournirai avec plaisir.

image
image1569×424 56.7 KB

image
image1590×505 43.7 KB

image
image793×230 10.2 KB

image
image893×248 12 KB

image
merci d’avoir été jusque là.

2

Suite :
la version de @noodom dans sa dernière version [Tutoriel] Prévision des couleurs Tempo à J+9 variante Noodom fonctionne parfaitement ! Allez comprendre !

image
image1372×249 23.2 KB

Bonne soirée à tous.

3

Salut,

Bizarre cette histoire de DNS.

Dans l’administrateur système ça donne quoi cette commande : ping -c 3 open-dpe.fr

Il y a une erreur sur la probability : Requête : 0 > probability

4

suite de la suite !
Après intégration de la version @noodom , la version initiale de @Bison fonctionne.
Je donne ma langue au chat :stuck_out_tongue:.

image
image1584×411 42 KB

Toujours une bonne soirée à tous

1 « J'aime »
5

Merci pour ton aide
Pour la requête :
image
J’ai déjà remarqué un certain nombre de limites de la Luna, c’est peut-être çà ?
Pour l’erreur sur probability, je l’ai vue après, mais elle n’était pas la cause de l’erreur

6

J’ai un système diy, je connais pas les limites. C’est étrange de bloquer la commande ping…

Tu peux ajouter sudo devant ?

sudo ping -c 3 open-dpe.fr
7

image
image714×165 6.25 KB

Et maintenant, on connait l’hébergeur :wink:
Je ne pense pas souvent au sudo pour la Luna, la seule connection en ssh étant root, plutôt inhabituel.

8

Bizarre que ça n’avait pas fonctionné le premier coup.

C’est quoi derrière ton IP 192.168.100.1 ?

9

192.168.100.1 c’est le routeur et la passerelle.
Derrière c’est une box free (pop) en mode bridge.

< Hors sujet >
J’ai choisi de ne donner quasiment aucune fonction à la box du FAI, pour des dysfonctionnements peu prévisibles mais vérifiés encore récemment :
La liaison fibre de mon logement a été détériorée (fibre pliée) et j’ai d’autres expériences semblables. Conséquence évidente : plus de connexion extérieure au monde extérieur. Mais, moins prévisible : la box se bloque sur la connexion et n’active pas ses fonctions DHCP, routeur et autres. Conséquence, très désagréable, plus de réseau local. Comme je privilégie les liaisons IP (filaires) pour tout, je me retrouvait très mal. Tout ce qui était actionné par la box domotique, en direct, fonctionnait. Tout le reste était en rade.
Dans le détail, il ne faudrait pas redémarrer la box en cas de perte de liaison externe (contraire aux préconisations des FAQ et hotlines). Si on ne la redémarre pas, ses fonctionnalités restent actives.
< /hors sujet>

10

Du coup il ne devrait pas y avoir de raison pour avoir des échecs de résolution DNS sauf si cette passerelle est mal configurée et du coup, de temps à autre quand Jeedom utilise le serveur DNS 192.168.100.1, c’est en échec

11

C’est le DNS qu’utilisent tous les périphériques réseau de mon LAN (192.168.100.1).
Avec, entres autres, un périphérique qui envoie des données toutes les 17 secs sur le Web (thingspeak.com), je serai vite au courant d’un dysfonctionnement.
Quand au nombre de périphériques réseau, je tourne entre 18 presque à minima, et vraiment plus en périodes de fêtes. Dans ces conditions, les problèmes (télétravail par exemple) me remontent plutôt vite :blush:.

12
En fait, je mettrais plutôt en cause la Luna. Il y a quelque temps, l'espace disque libre m'a posé des difficultés. J'avais trouvé le problème presque tout seul (taille des logs), mais les solutions proposées sur Community ne résolvaient pas le problème. Avec l'aide d'un ami (https://chat.mistral.ai/), nous avons approfondi le problème, puis la solution. Et, manifestement, la Luna n'utilise pas les standards.

Le gestionnaire de log est rsyslog (détecté à partir de vos réponses)

Extrait de la solution :

sudo nano /etc/logrotate.conf
# Rotation globale pour tous les logs
/var/log/*.log {
    size 50M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        systemctl restart rsyslog >/dev/null 2>&1 || true
    endscript
}
  • size 50M : Rotation quand un fichier dépasse 50 Mo.
  • rotate 7 : Conserve 7 archives avant de supprimer les plus anciennes.
  • postrotate : Redémarre rsyslog après la rotation pour s’assurer que les nouveaux logs sont bien écrits.
sudo nano /etc/rsyslog.conf

b. Ajouter une règle globale de limitation

Ajoutez cette ligne dans la section GLOBAL DIRECTIVES :

$MaxFileSize 50M

Cette directive limite la taille maximale des fichiers de logs gérés par rsyslog à 50 Mo.

Paramètre Valeur
Taille max par log 50 Mo
Nombre d’archives 7
Compression Activée
Rotation Automatique

La situation en terme d’espace disque libre est devenue stable (ce qui n’était évidemment pas le cas auparavant).
Le tout n’avait rien de trivial.
Et j’ai souvent des difficultés avec le debian 11 de la Luna, bien que plutôt familier d’Unix, et de façon induite de Linux, plutôt version debian.
D’où ma propension à mettre en doute la Luna (je n’ai rien compris à sa gestion des DNS, par exemple).
</hors sujet>