Difficulté à récupérer les valeurs Push/Parser

Bonjour à tous,

Je coince actuellement sur un comportement que je n’arrive pas à expliquer. C’est certainement une incompréhension de ma part mais je ne vois pas où je bloque.

J’espère que vous pourrez m’aider.

Voici le contexte :

Dans le cadre de l’automatisation d’un éclairage en fonction de la tombée de la nuit, je souhaite utiliser la source “[WEATHER]Sunset day” en la comparant à la source “[IPX]CLOCK” sur un IPXV5 (5.7.0).

J’ai suivi la démarche proposée par @fgtoul dans V5 - Module Météo - TimeZone - Cartes Ethernet IPX800 - GCE Electronics - Forum domotique - IPX800 - EcoDevices etc…

Puisque “[WEATHER]Sunset day” ne tient pas compte du passage en heure d’été, je collecte les timestamp du passage été/hiver via un objet PUSH sur le site TimeZoneDB et une méthode get sur son API qui me retourne le Json suivant :

{
« status »: « OK »,
« message »: « »,
« countryCode »: « FR »,
« countryName »: « France »,
« regionName »: « »,
« cityName »: « »,
« zoneName »: « Europe/Paris »,
« abbreviation »: « CEST »,
« gmtOffset »: 7200,
« dst »: « 1 »,
« zoneStart »: 1743296400,
« zoneEnd »: 1761440399,

« nextAbbreviation »: « CET »,
« timestamp »: 1759853417,
« formatted »: « 2025-10-07 16:10:17 »
}

Je stocke les valeurs (en RAW) de zoneStart et zoneEnd dans les output respectifs 1 et 2 d’un parser dont j’affiche le contenu sur des tuiles pour contrôle :

Jusque là, tout va bien :slight_smile: !

Là ou ça se complique, c’est pour l’usage de ces valeurs dans un comparateur.

Mon idée est de créer 2 comparateurs que je testerai ensuite pour déterminer si on est en été ou en hiver.

Je bloque dès le premier. Je tente de vérifier si le timestamp de [IPX]CLOCK > au timestamp de zoneStart. (si c’est le cas, nous sommes après le jour de début de la période “été”, donc en GMT + 2.

Mais je n’arrive pas à récupérer dans mon comparateur la valeur de mon “zoneStart” (elle reste à zéro) :

Ais je oublié quelque chose pour que le comparateur collecte la variable B ?

Merci d’avance,

Frédéric

Bonjour @fmartinez

Je pense à une erreur dans les unités des variables A et B dans l’éditeur du comparateur

Essayer avec les types RAW

Bonne journée

Bonjour @tous30 ,

Merci pour ta participation,

les unités sont bien de type RAW.

C’est effectivement l’un des points que j’ai eu du mal à appréhender lors de mes recherches. Donc c’est une remarque tout à fait pertinente.

Merci à toi mais la réponse est manifestement ailleurs.

Juste pour complément, les outputs du parser sont de type ANA32 :

Bonjour @fmartinez

Vérifier les valeurs de sorties du parser en les visualisent dans des Widget et faite de même avec le Push.

Bonne journée

Bonjour @tous30 ,

Les tuiles (widgets) illustrées plus haut sont celles des output 1 et 2 du parser.

Voici l’édition d’un des widgets :

Ils sont tous deux fonctionnels.

C’est donc bien le lien entre le parser et le comparateur qui me pose problème.

Dans l’illustration suivante, on constate que j’ai bien pu créer le lien entre l’Analog B du comparateur et la sortie output 1 du parser. Mais la variable B (de type RAW) reste à zéro.

Aurais-je oublié d’effectuer un quelconque déclenchement (via une scène par exemple) ?

Re @fmartinez

Bon là je ne vois pas !

J’essaierais de voir si ce comparateur n’est pas utilisé ailleurs avec une entrée ana2 à 0

En raisonnement pas l’absurde:

J’essaierais supprimer de comparateur et de la re créé .

J’essaierais d’intercaler une fonction entre le Json et l’entrée ana du comparateur afin t’identifier d’où peut venir le problème.

Vous pouvez aussi utiliser le très bon utilitaire de @Michel94 afin de trouver d’éventuel erreur.

Bonne journée

1 « J'aime »

J’ai supprimé tous les comparateurs, redémarré l’IPX, lancé le Push, vérifié l’arrivée des données puis tenté de construire un nouveau comparateur en inversant les entrées (Parser sur la Variable 1) mais rien n’y fait. La valeur est toujours à zéro :

Alors que la valeur est bien affichée pour l’horloge de l’IPX :

J’ai créé une variable ANA32 “Test Parser Output1” (histoire de voir si le pb ne venait pas des entrées du comparateur). Même soucis :

C’est vraiment frustrant.

Si j’ai l’énergie (et le temps) je consulterai l’outil XL proposé.

Merci pour ton aide.

Bon, suite à un rapide coup d’oeil sur l’outil exceptionnel conçu par @Michel94 , je n’ai pas eu le courage d’abandonner si vite la partie.

Merci @tous30 pour l’info.

J’ai donc installé l’outil qui est d’une simplicité désarmante et j’ai pu aller plus loin :

La valeur du outpu1 du parser est bien identifiée (mais on s’en doutait) :

Quant on suit le lien (si si, non seulement c’est possible mais en plus c’est super simple :slight_smile: !), on constate qu’il y a bien un souci de liaison :

L’output1 du parser (en ANA 32) ne passe ni dans le comparator, ni dans la variable ana32.

Je viens de tenter de créer une fonction. même problème. Entrée à zéro.

Bonjour
Quelques idées en vrac :
Essayez de forcer une valeur 0 dans les ana32 qui représentent les outputs du parser, puis relancez la requête via le push.
Le but est de forcer un changement au niveau du parser.
Si toujours KO, supprimez puis recréez le parser.
Bonne journée

1 « J'aime »

Bonjour @fgtoul ,

Soit je n’ai pas compris la démarche (forcer une valeur 0 dans les ana32 qui représentent les outputs du parser), soit je ne vois pas comment faire … Peut-être les deux, d’ailleurs :slight_smile: !

Peux-tu me donner un supplément d’infos ?

Merci d’avance.

J’espère avoir bien compris la démarche :

J’ai placé 2 dans la variable A de mon comparateur et relancé le push. La variable A reste à 2.

Ha si, j’ai compris. Désolé je suis novice et du coup, je ne voyais pas bien comment modifier la valeur de l’output1 :

Effectivement, le 2 est bien relayé au compapator et à la variable :

J’ai relancé le PUSH et (oh miracle) :

La liaison est à présent établie.

Je vais refaire l’ensemble de la manip avec les noms définitifs pour vérifier si une initialisation de l’output du parser est impératif.

Merci pour la piste! C’était la bonne :slight_smile: !

Je teste tout ça dans l’après-midi et reviens sur la discussion pour la cloturer.

Bonjour @fmartinez,

Merci pour votre pub pour IpxBrowser.:smiling_face:

Concernant votre problème, comme @fgtoul, je pense que le problème est lié à la non variation de la variable issue du parser et au fonctionnement en mode événementiel de l’ IPX800V5 .

Fonctionnement en mode événementiel :

Les process de l’ IPX-800-v5 ne sont activés que lorsqu’une variation d’état, nommée « événement », survient sur les entités qu’ils surveillent. En absence de variation, ces process ne réagissent pas.

De ce fait, si aucun événement survient sur les variables d’entrée d’une ressource, celle-ci n’assure aucun traitement. Il en est de même pour les interfaces d’entrées : si le signal d’entrée extérieur ne varie pas, aucun traitement n’est réalisé.

De la même manière, si, suite à un traitement interne, le process d’une ressource détermine que le résultat à écrire sur une variable de sortie n’a pas varié, aucune nouvelle inscription ne sera réalisée sur celle-ci.

Le fonctionnement est identique pour les liens. Si aucune variation de valeur n’est détectée en entrée du lien, aucune donnée ne sera retransmise en sortie du lien.

Ce mode de fonctionnement événementiel peut parfois générer des résultats semblant incohérents :

A titre d’exemple, lorsque l’on créé une ressource objet comparateur, par défaut, les entrées InA et InB sont égales à 0. La formule de comparaison par défaut est inA == inB. Il serait logique que le résultat en sortie soit On puisque InA est égale à InB alors que le résultat affiché est Off. En fait le comparateur n’a pas été déclenché, n’ayant pas reçu d’événement puisque les valeurs entrées n’ont pas variées. Le résultat de la sortie reste donc à l’état Off.

Il est important d’avoir toujours à l’esprit ce mode de fonctionnement événementiel lors de l’analyse du comportement de l’ IPX-800-V5 .

Dans votre cas, le problème devrait pouvoir être résolu en remplaçant le comparateur par une règle avec en équation d’event : [sortie du parseur] [A<=B] [Clock] pour détecter l’heure d’été.

Comme Clock varie tout les secondes, la règle sera activée à cette fréquence !

Attention à l’utilisation de l’opérateur “==” lorsque l’on utilise clock. L’égalité entre la clock et une valeur est moment très fugitif (1s) ! Si le processeur est occupé durant cette période, il risque rater cet instant. C’est pourquoi on préfère les opérateurs <= ou >= , voire > ou < pour être sur de prendre en compte cet instant.

Bon courage !

1 « J'aime »

Je vous en prie @Michel94 , c’est totalement mérité :slight_smile: !

C’est bien la première fois que je vois un usage aussi particulier de ce tableur, et surtout aussi abouti. Et je sais de quoi je parle puisque de suis consultant informatique et dans la partie depuis près de 40 ans !

J’ai compris et c’est effectivement très logique (subtil mais logique). Le parser reçoit un Timestamp lors de la jonction avec le push. Etant donné que ce timestamp (la date du passage à l’heure d’été) ne change qu’une fois par an, cette donnée reste figée. Même si je redéclenche le push, cette valeur restera donc la même. Le parser n’a donc aucune raison de renvoyer cette donnée à l’entrée du comparator qui y est relié.

Lorsque @fgtoul m’a proposé d’initier la valeur de sortie du parser (que j’ai placé à “2”), le déclenchement du push a remplacé le 2 par le timestamp. La valeur ayant changé, le parser l’a signifié au comparator.

Merci pour la résolution et les explications. Je comprends bien plus de choses à présent.

Bonne journée,

Frédéric

Quant au == j’avais bien lu la recommandation dans un autre post.

Merci pour le rappel et l’explication.