Serveur de téléinformation Linky

[Loulou74]

Bonjour MicroQuettas

Merci pour le partage, beau travail.

Je planche actuellement sur un projet de carte relais pour la domotique (ioBoard) et une entrée Télé Info est prévue.

Les protos de carte sont bientôt prêts et je vais donc me pencher sur le firmware.

Pour la téléinfo je n'y connais pas encore grand chose et je pensais utiliser la librairie de Charles Hallard (Blog Charles et les sources: Git Hallard) jusqu'à ce que je découvre la tienne. La connais-tu et as-tu un avis par rapport à ta librairie? Peut-être même quelques conseils avant de me lancer?

Merci

Loic

[MicroQuettas]

Bonsoir Loïc,

Je ne connaissais pas ce site. C'est superbe et je l'ai inscrit dans mes marque pages !

Avec cette bibliothèque, l'auteur vise l'universalité. Pour cela, il doit traiter le problème de la multiplicité des tarifs, et donc des informations envoyées par les compteurs. C'est ce qu'il fait, et avec sa biblio, vous serez prévenus par un callback lorsqu'une nouvelle info est arrivée, mais ce sera à vous de la traiter dans le callback.

Tout dépend de ce que vous voulez faire. Si j'ai bien compris votre projet, votre carte sera un "frontal" d'une appli plus importante sur une autre machine. Dans ce cas, la biblio Ch. Hallard est adaptée. Vous envoyez tout ce qui en sort à la "grosse machine" qui fera le tri et commandera les actions appropriées.

Pour votre frontal, vous allez utiliser un ATMega 2560 avec 4 UART HW. Il faut en réserver une à la téléinformation, car softwareSerial consomme trop de ressources CPU (point aussi identifié par Ch. Hallard).

Enfin, j'ai regardé votre projet de carte. Vous êtes sûr qu'un ATMega 2560 sera suffisant ? Un 8 bits à 16Mhz, c'est un peu limite aujourd'hui, surtout si vous faites fabriquer des cartes. Il me semble qu'il y ait des solutions plus performantes et guère plus chères, toujours dans l'environnement Arduino, quitte à faire les IO discrètes avec des adaptateurs I2C genre PCF8574 (ou plus modernes).

Voilà, bon courage et bonne bidouille,

Fred de MicroQuettas

[Loulou74]

Merci Fred pour ta réponse.

Pour mon projet de carte, elle se veut un peu des deux à la fois, à savoir être pilotable par un système plus haut niveau (Node Red ou Jeedom par exemple) mais aussi être autonome (la base d'une domotique solide!) en gérant elle même des plages horaires (d'où le module RTC) et pourquoi pas un délestage via l'action d'un de ses relais si les infos transmises par la TéléInfo le requierent.

Donc la carte doit être capable de décoder "en interne" les infos reçues par la TéléInfo. De ce que je comprends de ta réponse, il y a des chances pour que le décodage via la librairie de Hallard soit plus lourd que par ta librarie car elle retourne plus d'infos, c'est bien cela? Je ne me suis pas encore penché en détail sur cette librairie mais il me semblait avoir vu qu'on pouvait filtrer en amont les tags que l'on souhaitait recevoir/décoder. Je vais vérifier.

Enfin, pour la carte j'ai choisi le processeur AT2560 car il avait une bonne taille mémoire et que j'ai un projet de taille raisonnable qui tourne bien dessus (PoolMaster), je ne me suis pas posé plus de question!

Loic

[MicroQuettas]

Bonjour Loïc,

Joli projet le poolmaster...

Pour revenir aux bibliothèques téléinformation, ce sont deux approches différentes :

• la bibliothèque Hallard enregistre tout ce qui sort du compteur en ASCII et c'est à l'utilisateur de récupérer ce qui l'intéresse,
• la mienne (A_LinkyDecEsp) ne capture que ce qui l'intéresse, directement en format numérique.

Dans tous les cas, il te faudra aller à la pêche des champs qui t'intéressent en fonction du type de contrat que tu as :

• en interrogeant la biblio Hallard (méthode

  char * TInfo::valueGet(char * name, char * value)
• avec la mienne, si les infos qui t'intéressent n'y sont pas, il te faudra la modifier pour les capturer.

A toi de voir ce qui est le plus adapté à ton cas.

Si tu le peux encore sur ton proto, remplace la DS1307 par une DS3231. Le quartz est intégré et elle est plus précise. Elle a aussi un flag qui signale un arrêt de l'oscillateur, pratique pour valider sa sortie. L'interface SW est quasi identique, sauf qu'il n'y a pas de NVR (non volatile RAM).

Bon courage pour ce projet et bonne bidouille..

Fred de MicroQuettas

[Loulou74]

Bonjour Loïc,

Joli projet le poolmaster...

Bonjour Fred et merci. J'en suis très content, l'eau de ma piscine n'a jamais été aussi claire et propre, pas eu à la choquer de tout l'été alors que ça faisait des années que je galérais à l'entretenir (ce qui a stimulé ce projet) malgré l'achat coûteux de régulateurs du commerce et non connectés de surcroit.

Pour revenir aux bibliothèques téléinformation, ce sont deux approches différentes :

• la bibliothèque Hallard enregistre tout ce qui sort du compteur en ASCII et c'est à l'utilisateur de récupérer ce qui l'intéresse,
• la mienne (A_LinkyDecEsp) ne capture que ce qui l'intéresse, directement en format numérique.

Dans tous les cas, il te faudra aller à la pêche des champs qui t'intéressent en fonction du type de contrat que tu as :

• en interrogeant la biblio Hallard (méthode
• avec la mienne, si les infos qui t'intéressent n'y sont pas, il te faudra la modifier pour les capturer.

A toi de voir ce qui est le plus adapté à ton cas.

OK merci pour ces infos complémentaires. Dés que j'ai les protos je vais tester les deux approches.

Si tu le peux encore sur ton proto, remplace la DS1307 par une DS3231. Le quartz est intégré et elle est plus précise. Elle a aussi un flag qui signale un arrêt de l'oscillateur, pratique pour valider sa sortie. L'interface SW est quasi identique, sauf qu'il n'y a pas de NVR (non volatile RAM).

OK je le mets dans la wish list de la prochaine révision.
Mais que veux-tu dire par "Elle a aussi un flag qui signale un arrêt de l'oscillateur, pratique pour valider sa sortie"?

Loic

[MicroQuettas]

Bonjour Loïc,

Sur la DS3231, cf. datasheet DS3231, page 14, dans le Status register (0Fh), il y a le bit 7 : OSF (oscillator stop flag). Il est mis à 1 au démarrage et en cas de pb sur l'oscillateur.
En pratique :

• mettre le bit à 0 quand on met à jour l'horloge,
• le lire avant de lire l'heure sur l'horloge :
    si == 0, tutti bene,
    si == 1, méfiance, l'oscillateur s'est arrêté et l'horloge est invalide.

C'est un truc sympa qui n'existait pas sur la DS1307.

Bonne bidouille,

Fred de MicroQuettas

PS : pour les piscines, je garde un souvenir ému d'une maison où la piscine était surplombée par un beau tilleuil... La dite piscine se transformait inexorablement en un grand bac de tisane !!

[Loulou74]

Super merci.
Piscine: la domotique ne ramasse pas encore les feuilles ni ne nettoie le filtre du robot, hélas

[maccaire]

Bonjour MicroQuettas

Je viens de tester ton code, mais j'ai  des soucis sur la numerotation des lignes de code, je suis sur notepad++ et je n'arrive pas a identifier les lignes pour sur DHCP et l'adresse en dur. Donc ce n'est pas facile, la page web de config fonctionne donc je vais mettre mes info a jour par ce biais la. je suis en comptage HP/HC puissance kw ou je rentre les infos ?
Merci encore pour le bon boulot

[maccaire]

Voila tout mes problémes sont resolu avec la version 4 sinon dans le terminal je n'ai jamais pu avoir la config avec la commande %w ?
Il ne me reste plus qu'a integrer le montage a coté de l'épouventa

[MicroQuettas]

Bonjour,

Content que tout fonctionne avec la V04.
Pour les informations de "deboggage" :

• il faut compiler avec l'option

  #define LKYDEBUG true        /* Global debugging enable */
  

  décommentée (ligne 10 du fichier A_CompilSwitches.h),
• le moniteur série fonctionne à 9600 bds avec des fins de lignes Windows (CR et LF).

Ceci dit, une fois que le programme est configuré et que le bidule fonctionne, l'option de "déboggage" ne sert à rien. Cela fait du code "mort", ce que les bonnes pratiques commandent d'éviter.

Note : pour recharger le programme SANS effacer toute la configuration, bien régler l'IDE sur "erase sketch only".

Bonne bidouille,

MicroQuettas