V5 - module météo - heures de lever / coucher - converties

Bonjour,
Comment convertir les heures de couché/levé du module météo dans un format lisible ?
Merci

Bonjour,
dans le widget afficheur de temps, il y a une unité spécifique : Timestamp

image

image

bonne journée

1 « J'aime »

Merci @fgtoul !
L’idée est de récupérer les informations de levé et de couché dans un scénario afin d’autoriser ou d’interdire une action.
Est-ce possible ?

Bonjour Gevaudan,

pas besoin de calculs pour ça, il existe une variable IO qui est à ON quand le jour est levé et OFF quand il est couché :

Capture d’écran 2022-09-22 à 07.51.46

Bonne journée

Questions, peut-on y faire des calculs :

  • déterminer le zenith ?
  • déterminer day + 1h ou night - 1h ?

il faut trouver une formule simplifiée, sinon c’est du script .
voir ici :

Il existe certainement quelques webservices pouvant répondre au besoin du genre de
Sunset and sunrise times API - Sunrise-Sunset.org
Un GET par PUSH serait alors possible.

oui, les timestamp Sun Rise et Sunset sont des variables analogiques 32 bits.
il est donc possible de les lier à l’entrée d’une fonction et de leur appliquer une formule en ajoutant ou soustrayant 3600 (les timestamp sont en secondes)
Ensuite il est possible de comparer l’heure courante de l’ipx (timestamp également donc Ana32) avec les résultats des fonctions Day+1 ou Night-1 pour enclencher une action.
Il suffira d’utiliser des comparateurs analogiques.

2 « J'aime »

Hello,

Merci pour cette réponse.

Je suis peu fan des ajouts de script externe, pour le fonctionnement de l’IPX, j’entends qu’il reste parfaitement autonome.

Pour le +1/-1 il s’agit de production photovoltaïque solaire, et comme via l’API d’Enphase (en zéro injection), je détecte le surplus par une règle qui compare production/consommation, je dois exclure les moment probables ou ce n’est pas possible (soit +1/-1h) et les moments ou c’est le cas (soit au Zenith).

Peut-on donc déduire qu’approximativement un calcul du type :

(86400s - Heure de levé - Heure de couché) / 2 = +/-Zenith ?

Ce calcul est il possible sur l’IPX ?

+/- zénith : oui, à +/-15 minutes près :slight_smile:

ce calcul est tout à fait possible avec ipx v5 :
ne rien lier à l’entrée X de la fonction et ne constituer la formule qu’avec l’ID des variables analogiques (sous la forme $id$)
exemple :

$idWeatherSunrise$ + ($idWeatherSunset$ - $idWeatherSunrise$) / 2

calcul de l’heure du Zénith solaire en fonction de la position par rapport à Greenwich :
il faut utiliser la longitude du lieu où s’applique le calcul :
exemple Bordeaux = 0.58 ° W
Sachant que 1° de longitude représente 4 minutes de décalage par rapport à Greenwich, nous obtenons par calcul simple une correction de longitude de 2 minutes 15s à Bordeaux.
En appliquant le Fuseau horaire et l’heure d’hiver, nous obtenons ceci :
Si le soleil est au zénith à Greenwich à midi, il sera au zénith de Bordeaux à 12 h +1h +2 min 15 s soit 13h 02min 15s (heure d’hiver)
En été, il faut ajouter 1h de plus, le zénith solaire est alors à 14h 02min 15s.

Nous avons pris Bordeaux en exemple, qui se trouve à l’ouest. Dans le cas d’une ville à l’Est du méridien, il faudra retrancher la correction de longitude (Toulouse, Paris, Strasbourg, Marseille, …).
En heure d’hiver, le Zénith solaire à Toulouse (L=1.5°E soit un décalage d’environ 6 minutes)) serait donc à 12h00 +1 - 6min soit 12h54 (13h54 en été).

Ce calcul simple à mettre en œuvre sur IPX donne un résultat ne tenant pas compte des décalages dus aux variations de vitesse de la terre sur son orbite, nous obtenons donc un résultat à +/-16 minutes.

L’heure zénitale, si nous ne tenons pas compte de l’équation du temps, est donc une variable ayant une valeur contstante à plus ou moins 1h (heure d’été, d’hiver).
Il est donc possible d’utiliser 2 objets « calendrier » à horaire fixe pour enclencher des actions.
exemple pour Toulouse :
1 objet calendrier Tous les jours du 27/03/2022 au 29/10/2022 à 13h54
1 objet calendrier Tous les jours du 30/10/2022 au 26/03/2023 à 12h54

L’inconvénient, c’est qu’il faut réajuster les calendriers tous les ans, vu que nous n’avons pas les récurrences du type dernier dimanche du mois, et que nous n’avons pas non plus une IO qui changerait d’état en fonction de l’application de l’heure d’hiver ou d’été (ON=été, OFF=Hiver) @GCE

3 « J'aime »

:scream: @fgtoul you killing me !! Merci

2 « J'aime »

le résultat pourrait encore être affiné avec l’équation du temps en fonction du lieu (variations de vitesses sur orbite). Je pense que l’on pourrait trouver ça avec des utilitaires simples comme pour le calcul des cadrans solaires.

Il va me falloir un certain temps pour tout comprendre et pour mettre en place ça :S

bah, les 2 méthodes sont assez simples à mettre en oeuvre.

  • la méthode : ( heure_de_coucher - heure_du _lever) / 2
    avantages :

    • permet de calculer le méridien plus précisément
      Exemple pour Toulouse aujourd’hui
      image
      Inconvénients :
    • dépend d’une connexion internet (plugin météo).
    • pour lancer des actions, il faut reconstituer un timestamp pour l’utiliser dans le rule engine ou des comparateurs. Ce n’est en soi pas si difficile mais nécessite quelques précautions.
  • la méthode avec longitude
    Avantages :

    • laisse l’ipx 100% indépendante d’internet,
    • permet l’utilisation d’objets calendriers,

    Inconvénients :

    • reste précise à ±16 minutes car elle ne tient pas compte de l’équation du temps. Le calcul annonce un méridien à 13h54 au lieu de 13h46.
    • il faudra mettre les calendriers à jour tous les ans.

Les 2 méthodes ont donc leurs avantages et leurs inconvénients mais restent simples à mettre en oeuvre.

2 « J'aime »

Je vais pencher pour la méthode 1 (avec internet), car elle n’induit aucune maintenance, la précision dans mon cas n’étant pas un argument pour des panneaux solaires…
Comment opère t’on pour le calcul ? Comparateur ? J’ai relevé l’usage de « $id$ » mais comment ça fonctionne ?
Merci !

dans la formule d’un objet fonction, il est possible de faire appel à des variables analogiques en utilisant leur ID placé entre les symboles $. Cependant, pour que le résultat soit réévalué sans arrêt, il ne faut rien lier en entrée X. Il faudra donc faire appel aux variables par $id$ uniquement (pas par lien).
Ceci étant le fruit d’une évolution dans le firmware, il faut avoir la dernière version.

la méthode 1 nécessite :

  1. créer un objet fonction faisant le calcul ( heure_de_coucher - heure_du _lever) / 2
  2. initialiser un compteur avec un timestamp de départ (exemple 23/09/2022 à 00:00:00)
  3. incrémenter ce compteur de 86400 secondes tous les jours à 00:00 via un objet calendrier.
  4. créer un objet fonction qui ajoute le compteur au résultat de la fonction précédente
  5. créer un comparateur avec l’heure de l’IPX en entrée A et le résultat déterminé ci-dessus en entrée B.
  6. lier ou utiliser le comparateur dans le rule engine

Lorsque je parlais de précautions à prendre, je pensais au décalage qui pourrait se générer sur la régénération du timestamp (inc du compteur) en cas de coupure de courant aux alentours de 00:00. Il faut donc utiliser une alimentation X-PSU avec batterie.

Donc ceci correspondrait-il : « ($327704$ - $327705$) / 2 » ?

Quel est l’utilité du point n°3 (et du coup du n°4) ?

L’IPX est déjà secourue (via une alimentation MeanWell avec batterie 12v 7Ah, ça laisse la marge) et l’IPX se synchronise également via NTP, n’est ce pas suffisant ?

un timestamp représente le nombre de secondes écoulées depuis le 01/01/1970.
le résultat coucher - lever va donner en secondes la durée de la journée. Il faut donc ajouter les secondes écoulées entre le 01/01/70 et le lever du jour.
nous avons bien timestamp du lever + résultat du calcul = timestamp du méridien.
Pour un calcul basé sur lever, coucher ou méridien, (exemple méridien - 1h) ,Il est en effet plus simple de reprendre un timestamp connu comme celui du lever ou du coucher, mais tous les calculs ne dépendent pas forcément du lever ou du coucher du soleil. Il faudra alors utiliser le compteur.
J’ai donc donné plusieurs façons de faire des calculs sur dates et heures.

Je digère les explications…
Pour l’heure ma formule « ($327704$ - $327705$) / 2 » parait ne rien donner, il y a une erreur ?

je suppose que 327704 est l’id de la variable « coucher de soleil » et que 327705 est l’id de l’heure du lever ?
sur mon IPX, le lever est en 327688 et le coucher en 327689.
Je pense donc que tu as inversé les id concernant tes variables sur ton ipx.

pense à laisser les variables en mode raw.

Effectivement, les valeurs était dans le mauvais ordre et ce n’était pas en « raw ».
Mais pour le moment, le résultat reste à « 0 »…

quelle version de firmware ? il faut la 5.4.3 minimum.