Gestion EDF, solaire , chauffe-eau

International Français
1

Bonjour
sans être un débutant, puisque je code depuis quelques année, je butte sur un point de mon projet
arduino Mega 2560 , écran 4 pouces, shield ethernet
carte 8 relais .
modules de ma fabrication pour interfacer les capteur de tension et d'intensité , EDF et solaire.
description du projet qui commence a être bien avancé
lecture du compteur linky(contrat jour/nuit avec des heures creuses en journée)
extraction des infos pour détecter les heures creuses
extraction de l'intensité
extraction du PAPP(consommation ou injection si PAPP est égal à 0)

consultation d'un serveur NTP pour avoir l'heure exacte et gérer les heures creuse de jour et celles de nuit et calculer l'éphéméride du jour

mesure de la tension secteur, de l'intensité venant d'EDF et celle produite par mes panneaux solaire (librairie emonlib).

avec ces infos, toutes envoyées sur un écran 4 pouces, j'enclenche des relais qui commande
des télérupteurs ou contacteur pour mettre en service le chauffe-eau en heures creuse de jour uniquement (ce qui est le meilleur moment grace aux panneaux solaire) et les panneaux solaire en fonction de l'éphéméride

pour me rendre indépendant d'internet , je veux remplacer le module ethernet par un GPS
ce qui est déjà en grande partie réalisé

mon soucis, c'est le changement d'heure entre l'été et l'hiver

je sais récupérer la date et l'heure par le GPS, retrouver le jour de la semaine pour l'afficher en toute lettre, convertir cette date en temps unix, mais je n'arrive pas encore à mettre à l'heure correcte au passage été /hiver

je cherche encore LA formule magique pour cette fonction

je précise que je cherche uniquement des codes ultra simple
en général, je prend les codes déjà écris et les adaptent pour mon usage en les simplifiant le plus possible, jusqu'a ce qu'ils fonctionnent comme je le souhaite en ayant supprimer tout ce qui est inutile pour mon usage, y compris dans les bibliothèques que je suis obligé de renommer pour mon usage
lorsque mon projet sera totalement réalisé, je le mettrai en ligne sur ce forum

merci de votre aide
Patrick

2

Bonjour,

Es-tu au courant qu'un projet de la sorte existe déjà dans le domaine public ? Fait par F1ATB

Il est largement documenté et utilisé par beaucoup d'amateurs.
Je respecte ceci dit ta décision de faire le tiens !

Je comprends pas l'intérêt du module GPS ? À moins que je me trompe, le Linky (en mode standard) envoie déjà la date dans ses trames. Le module GPS serait donc en trop. À confirmer, peut-être as-tu une autre raison de le prendre ?

Concernant le changement d'heure automatique, j'ai fait il y a quelques temps mon propre programme pour détecter ça. C'est très rapide. Je pourrais te le donner ; mais je te propose de te guider pour faire ton propre code. (sinon je te le donne mais on apprend moins).

Voici les étapes :
1 - Connaître les règles de changement d'heure en France
2 - Détecter ces fameux jours dans l'année
3 - Savoir à quelle heure va intervenir ce changement d'heure (attention : pas la même heure si passage été => hiver. Mais il y a une astuce si on calcule en heure UTC+0 ;))
4 - Mettre à jour l'heure de l'ESP en fonction de l'offset (+1h en hiver et +2 en été)

N'hésite pas à me faire un retour sur ces 4 points avant de te lancer dans l'écriture de la fonction !

3

Après vérification, le compteur Linky envoie effectivement l'heure dans chacune de ses trames.
C'est au format AAMMJJHHMMSS
AA = Années
MM = Mois (pour le premier) et minutes (pour le second)
JJ = Jours
HH = Heures
SS = Secondes

Il y a même une lettre 'E' ou 'H' qui précède cette information pour indiquer l'heure d'été ou d'hiver

image
image1080×1195 133 KB

4

Merci Anthony_P
j'ai volontairement laissé le linky en mode "historique" pour que mon projet puisse etre utilisable sur les compteurs électronique
je suis en double tarif , sans contrat d'injection avec EDF
donc le linky n'envois que des trames simples et sans l'heure
de plus , dans la notice EDF , il est précisé que l'horloge du compteur peu etre en mode "dégradé", mais ils ne précisent pas dans quelle "degradation" elle peu se trouver
le montage pourrais donc être soumis a une heure faussée
ce qui n'est pas le cas avec un GPS

le module GPS est donc utile dans le cas , par exemple, d'une résidence secondaire ou il n'y a pas de box internet
il peu être utile également pour gérer un tracker solaire trop loin de la maison si on veut remette le tracker à l'est une heure après le couché du soleil et le mettre hors tension la nuit
ce sont donc des exemple d'usage du GPS

pour le système réalisé par F1ATB, je l'ai vu et étudié, mais je préfère construire le maximum moi même , et écrire le maximum du code que j'utilise

si tu m'envois ton travail, je m'en servirai comme base , pour apprendre et enrichir mon savoir. je le modifierais donc

la ou je n'ai pas encore trouver la formule "magique" c'est de trouver les fameux jours du changement d'heure, tous ce que j'ai pu trouver jusqu'a maintenant, ne fonctionne pas, il y a des erreurs dans les formules, j'ai beau les remaniées, ça ne marche toujours pas

le reste, je sais déjà le faire
sur mon montage actuel, il y a un bouton qui change l'offset GMT dans ma formule de gestion de l'heure, j'aimerais juste le supprimer ou plutôt lui donner une autre fonction
ce qui m'évitera de me lever en pleine nuit ces fameux jours

j'ai déjà un système à 2 écrans qui fait une grande partie de ce projet, je veux les rassembler en un seul module et l'étendre encore plus , une fois le chauffe-eau sera chaud, avec le surplus solaire, ce sera le tour de la charge des voitures électrique
par pilotage de ma wall-box pour l'une des voiture et ensuite du CRO pour l'autre que je vais modifier pour cela.
si je pouvais en plus , avoir la météo du lendemain pour anticiper tout cela, ce serais encore mieux

Patrick

5

Bonjour

Si, en cas de panne, tu n'as plus d'accès à internet pendant un peu trop longtemps, tu peux utiliser un module récepteur radio DCF77 pour récupérer la date + heure d'été/hiver.

Dans la page wikipedia , on peut lire la description concernant le bit 16 du signal radio DCF77 :

1 = Annonce (pendant 1h) un basculement heure d'été/hiver au début de la prochaine heure

6

merci amic
un module DCF77, j'ai déjà essayé, chez moi, la reception est nulle.j'ai donc abandonné cette option
sur un premier prototype, j'avais un module RTC DS1302 , vu sa dérive ....
j'ai tester avec le RTC DS 3231, c'est mieux, mais ça ne change toujours pas l'heure été/hiver tout seul et surtout, il faut changer la pile régulièrement sous peine de se retrouver sans infos, donc stopper le système et le relancer avec la nouvelle heure injectée
j'ai besoin, d'un système fiable et pérenne sans intervention
le module GPS est bien plus fiable et j'en ai eu pour moins de 4€
l'intérêt de ce module GPS, c'est qu'en cas de changement de domicile, il me donne la longitude et la latitude pour le calcul de l'éphéméride du nouveau lieu
donc lorsque je publierais mon travail, il sera transposable partout dans le monde
pour les fonctions qui dépendent de la date, de l'heure, du lieu .

Patrick

7

Dommage que ce ne soit pas possible :frowning:

8

Bonsoir,

Pour les heures d'été/hiver, je procède comme suit:

  1. au démarrage du système, ou tous les ans au 1er janvier, le système calcule les 2 bornes de changement d'heure en temps Unix pour l'année en cours,
  2. ensuite, pour l'année, tout ce qui est entre les 2 bornes est en heure d'été, le reste en heure d'hiver.

Pour le calcul des 2 bornes, il faut calculer la date du dernier dimanche de mars et d'octobre.
Pour cela, j'utilise la méthode trouvée ici date de chgt d'heure

A partir de cette date, il reste à construire les deux bornes en temps Unix avec un coup de mktime.

Ce n'est pas d'une grande finesse, mais ça marche pile-poil.

Bonne bidouille

MicroQuettas

PS : j'ai simplifié le calcul en ne partant pas du 31 mars 0 mais du 31 mars 2000 (vendredi) resp 31 octobre 2000 (mardi).
J'ai aussi simplifié en ne tenant pas compte de la correction de siècle et de 4*siècles, car ni moi ni mes bidouilles ne seront là pour les voir... Je suis ainsi revenu au calendrier Julien!

9

merci a tous
j'ai enfin trouver, sur ce forum, la réponse
uniquement pour trouver les jours de bascule, j'ai tester de l'an 2000 jusqu'a 2040
tous les résultats sont bons.
pour la verification j'ai implémenter la formule dans une boucle for multiple.

je vais donc écrire le code pour la bascule de l'heure

depuis le temps que je vous lis en anonyme, merci
si j'ai mis autant de temps avant de demander, c'est que, dans mes habitudes, je cherche longtemps avant de demander de l'aide
Patrick

10

Un partage de la solution retenue est le bienvenu pour qu'on puisse commenter et également aider les prochains qui cherchent la même chose
C'est pour ça que le forum fonctionne si bien

11

Bonjour, en effet, voici le sketch de test avec mes commentaires

calcul_ete_hiver.ino (1,3 Ko)

comme précisé, le retour ne donne que le dernier dimanche de mars et le dernier dimanche d'octobre
pour le passage horaire, je n'ai pas encore fini d'écrire mon code

Patrick

12

en réfléchissant bien , je m'aperçois que le passage d'heure est plus compliqué que prévu
le GPS donne toujours la date et l'heure GMT,
ce qui va imposer, pour bien faire, le changement de jour devra se faire la veille à 23 heure si on est en heure d'hiver et à 22 heure si on est en heure d'été, et ce chaque jour et les jours de bascule , il faudra attendre attendre l'heure du basculement
le passage de l'année doit également être pris en compte dans le code

je pense que le plus simple , sera de passer par un timestamp et de le convertir ensuite en date et heure lisible par un humain

je bosse et vous fait part de l'avance de mon code

Patrick

13

Non. Ou alors tu vies ailleurs qu'en France.

C'est quand même surprenant de venir sur un forum demander de l'aide et ne pas répondre aux sollicitations des internautes qui tentent d'aider. Je t'avais donné 4 points à répondre pour que je puisse t'accompagner dans la résolution et l'écriture de ta fonction et tu ne t'es même pas donné la peine d'y répondre

14

bonjour
ma supposition de changer la veille ne serais valable que si je continu avec une date et heure au format humain.
en transformant la reception GPS en timestamp et et lui ajoutant 3600 secondes ou 7200 secondes avant de la retransformer en format humain, ce soucis disparais.

si je n'ai pas répondu a tes questions, c'est parce que j'ai trouver la solution dans un autre post sur ce forum
merci d'avoir voulu m'aider

voici le même sketch de test mais Francisé
et avec un peu plus de commentaires
calcul_ete_hiver.ino (1,5 Ko)

dans mon cas, je vais donc remplacer le retour de 1 ou 2 par 3600 et 7200 ce qui va resoudre le soucis du passage du jour au bon moment

15

Pour ceux qui n'aiment pas télécharger des fichiers, voici le code du post précédent :

// test de la formule qui donne les dernier dimanche de mars et d'octobre , date du passage des heures été/hiver en France métropolitaine

int year;    // L'année qui doit etre testée
int month;   // le mois qui doit etre testé
int day;     // le jour qui doit etre testé
int offset;  // l'offset GMT a apliquer
void setup()
{
  Serial.begin(9600);  // ouverure du port série a 9600 bauds
}

void loop()
{
  // la boucle qui teste de 2024 à 2030 pour les mois de mars à octobre du 20 au 31
  for (year = 2024; year <= 2030; year++)
  {
    for (month = 3; month <= 10; month++)
    {
      for (day = 20; day <= 31; day++)
      {
        ete_hiver();  // appel de la fonction de calcul
        Serial.print(day);
        Serial.print(" ");
        Serial.print(month);
        Serial.print(" ");
        Serial.print(year);
        Serial.print(" ");
        if (offset == 1) { Serial.println("heure d'été"); }
        else { Serial.println("heure d'hiver"); }
      }
    }
  }
  while (1)
    ;  // fin de boucle , il est inutile d ela répeter à l'infini
}
void ete_hiver()
{  // la formule qui indique si on est en heure d'hiver ou d'été

  int beginDSTDate  = (31 - (5 * year / 4 + 4) % 7);  // le dernier dimanche de mars
  int beginDSTMonth = 3;                              // le mois de mars

  int endDSTDate  = (31 - (5 * year / 4 + 1) % 7);  // le dernier dimanche d'octobre
  int endDSTMonth = 10;                             // le mois d'octobre
  // DST is valid as:
  if (((month > beginDSTMonth) && (month < endDSTMonth))
      || ((month == beginDSTMonth) && (day >= beginDSTDate))
      || ((month == endDSTMonth) && (day < endDSTDate)))
  // retourne l'offset GMT pour la France 1 = hiver, 2= été
  {
    offset = 1;
  }
  else { offset = 2; }
}
16

sans avoir à mettre tout ça en route, le linky à un contact sec qui se ferme lors des heures creuses.
Une simple comparaison de l'heure liée à la fermeture du compteur te donne l'info si les heures creuses sont de nuit (heures entre 20 et 07 par exemple) ou de jour (heures entre 08 et 19 autre exemple) Et basta les heures d'hiver et d'été ou autre calculs complexes...
Si ça se ferme à 22h alors il fait nuit. Si ça se ferme à 14h alors il fait jour... Mais on me dit dans l'oreillette qu'il faut prendre en compte l'astre solaire et la petite bille qui le cache de temps en temps ce qui fait que c'est tout noir même à 14h :grin:

17

J'ai suivi que de loin, mais pourquoi t'embête tu avec le changement d'erreur, il n'est pas possible de travailler en UTC+1(ou UTC+X, si tu veux gérer autre chose que la métropole) ?
Il n'est pas possible avoir aussi les éphéméride en UTC+2 ?

18

en effet, comme tous les compteurs avec double tarif, il y a ce contact
quasiment tout le monde se sert uniquement de cela
mais, ces dernières années, avec le linky ,le contact se ferme avec une heure de retard en hiver, ce qui ne permet pas toujours d'avoir suffisamment d'eau chaude pour les douches du soir, d'ou ma gestion personnelle des heures creuse.
mais cette gestion heures et date ne me sert pas exclusivement a cette gestion eau chaude,
avec l'éphéméride, je coupe l'a jonction EDF de mes micro onduleur, ce qui les préservent d'une usure prématurée et supprime la toute petite consommation inutile de nuit lorsqu'ils ne produisent rien. c'est pour cette toute petite économie que j'utilise des télérupteurs et non des contacteurs, ils ne consomment rien en dehors de l'impulsion
mais l'ensemble sert aussi a gerer d'autre éléments personnels de la maison

Patrick

19

Bonjour
avec les modules tout fait DSxxxx ces passages sont facile , mais je n'aime pas la facilité
avec les server de temps NTP, il faut etre à proximité de la box internet , ce qui n'est pas toujours le cas. le wifi ne passe pas correctement ou il est peu être impossible de passer un cable réseau.
le changement d'heure est important pour les heures creuse de nuit, sinon, je vais consommer sur les heures pleine et au vu de la consommation des voitures électrique, ça me couterais cher.
le GPS donne exclusivement la date et l'heure GMT, il faut donc, selon l'endroit du monde ou on se trouve, faire la correction, non seulement de l'heure, mais également de la date
d'après mes recherche, le plus simple est de passer par un timestamp , lui ajouter le nombre de secondes de décalage et re transformer le nouveau timestamp pour obtenir la bonne date et heure locale

Patrick

20

De mémoire, si tu utilises un RTC, les librairies les plus évolués gère pour toi tout ceci.
A moins que tu n'utilises pas de librairie ?
Si tu passe par le GPS, c'est forcément que tu n'utilise pas un serveur NTP, car à moins d'avoir de gros problème de connexion internet, cela n'apporte pas grand chose :slight_smile:

Après effectivement d'un point du vue programmation, je trouve aussi que c'est bien plus simple à gérer. le format humain n'étant pour moi à utiliser uniquement lorsque tu affiches l'heure.
Effectivement, si tu ne peut pas avoir l'information de la plage pleine/creuse autrement que par l'heure locale, il faut l'utiliser.
Je n'ai pas bien compris si tu utilisais un RTC en plus du GPS, ou finalement uniquement un GPS ?
J'avoue que je n'ai pas trop compris ton problème de pile sur le RTC, qui me fait dire que tu ne l'utilise plus.

Si tu utilises uniquement un GPS pour l'heure, pour moi à l'acquisition de l'heure UTC, tu applique le changement de fuseau +- la modification été/hivers, puis dans la suite de ton programme tu utilises l'heure locale.
J'avais cru comprendre que c'était ce que tu voulais faire, mais j'ai un doute :slight_smile: