Panneaux solaires et automatismes de consommation

BESQUEUT

Senior Member
Je cherche des idées pour automatiser la consommation électrique en fonction de la production des panneaux solaires.
L'onduleur Fronius permet de piloter 4 contacts secs en fonction de divers critères liés à la production d'électricité.
L'idée serait de piloter le chauffe eau, le lave linge, le lave vaisselle, le frigo et le congélateur.
 

PieM

Senior Member
Bonjour,
Ce n'est pas seulement un problème de gestion des priorités et de délestages possibles en fonction de la production ?
Je ne vois pas quels sont les critères internes utilisés par l'onduleur pour l'activation des relais; Production instantanée , horaire, etc...
 

BESQUEUT

Senior Member
Bonjour,
Ce n'est pas seulement un problème de gestion des priorités et de délestages possibles en fonction de la production ?
Je ne vois pas quels sont les critères internes utilisés par l'onduleur pour l'activation des relais; Production instantanée , horaire, etc...
Bonjour Piem, fidèle au poste !
Ce thread est ouvert pour des amis qui souhaitent améliorer leur autoconsommation.
Le point essentiel est de récupérer les ampères qui passent dans un sens et dans l'autre au niveau du Linky. De là l'idée est d'activer des relais pour différents consommateurs plus ou moins prioritaires.

Mais j'attends de voir la motivation des intéressés avant de développer...
 

Jarrige

Member
Bonjour, j'ai 3kw/c de panneaux solaires, pour l'instant j'ai réalisé un système(en logique classique), avec mesure de courant sortant des panneaux et pilotage par une horloge, me permettant de commander mon chauffe-eau s'il y a suffisamment de courant (setting à environ 6A). Afin d'optimiser ce dispositif, j'ai pour "idée" de récupérer la trame de la TIC, afin de déterminer le courant disponible injecté (Si puissance apparente = 0, le courant est en injection). Avec la valeur du courant, j'envisage de piloter un relais statique proportionnel qui alimenterait le CE. Les trames de la TIC ne sont pas très rapides (la seconde je crois), mais je pense que ça mérite d'être essayé. Il y a bien des "routeurs solaires" qui doivent faire le job dans le commerce, ils travaillent avec des TI et coûtent une fortune ...
L'objet principal de mon message est de savoir si parmi vous, quelqu'un aurait déjà fait un programme implantable sur un PICAXE 14M2, permettent de recevoir et décoder la trame de la TIC en mode historique ?? (j'ai déjà fait une petite appli avec ce type de micro, mais pas très aguerri en programmation). D'avance merci pour vos idées et réponses.
Cordialement
Joël
 

PieM

Senior Member
Bonjour, en mode historique le débit est de 1200 bauds. Vu le contenu de la trame, il ne doit rien avoir de compliqué à lire les trame ASCII.
C'est une lecture classique via un simple serin.
Le plus gros problème est d'alimenter un Picaxe et de l'interfacer à partir de la sortie Linky, la puissance disponible étant très faible (un peu plus de 100 mW).
Une petite doc la dessus : https://lucidar.me/fr/home-automation/linky-customer-tele-information
Le contenu des trames est sur la doc Enedis: Enedis-NOI-CPT_54E.pdf
 

Jarrige

Member
Bonjour PieM, merci pour votre retour. Oui, j'ai déjà de la doc d'Enedis. J'envisage de mettre ce dispositif vers mon tableau électrique où la téléinfo arrive déjà par une paire torsadée pour un gestionnaire d'énergie. Mon montage serait autonome, ainsi que toutes les alims nécessaire, y compris le 5V pour le PICAXE.
Je suis novice en Picaxe et jamais employé ces instructions de com série, mais je vais potasser la doc et m'y atteler un de ces jours. Je ne vois d'ailleurs pas bien comment débugger ma future réalisation ... Mon message était surtout de savoir si quelqu'un avait déjà fait un programme pour une appli "identique" ou similaire.
 

PieM

Senior Member
Je ne connais pas d'appli TIC avec Picaxe. Mais nombreuses sont celles avec d'autres modules tel GPS ou autres capteurs. Le mieux est d'expérimenter avec une lecture de la trame, et de visualiser sur le terminal, au fur et à mesure.
Nous faire part de vos avancées et difficultés éventuelles (en joignant votre programme)...
 

PieM

Senior Member
Je pense que le problème est le même que celui de la réception de trames GPS, que j'ai utilisée dans certains programmes.
Il suffit de rester à l'écoute de l'étiquette de trame souhaitée via un serin avec qualifier.
Par exemple , serin pin,baudmode, ("IINST"), b2,b3 .... pour acquisition de l'intensité instantanée.
 

Jarrige

Member
Bonjour, étant donné le temps magnifique, je suis en train de commencer mon sujet ... Pour ceci, j'ai un peu réfléchi au besoin "matériel", et j'ai besoin d'une sortie analogique, donc un DAC, pour piloter un relais statique proportionnel. C'est avec un 14M2, donc à priori uniquement le broche B0 pour cette fonction. J'ai regardé les instruction Basic en Français (mais aussi Anglais), et .... je coince. Je n'arrive pas a affecter cette broche au DAC (dacsetup), malgré plusieurs formes "d'écriture", copie de l'exemple ... : erreur de syntaxe.
Veuillez excuser mon ignorance et mes débuts avec ce matériel et logiciel, mais comment diable fait-on pour faire une sortie DAC sur B.0 ????
Merci d'avance pour votre aide précieuse
 

PieM

Senior Member
Bonjour, avec un dacsetup %10000000 ?
Compte tenu du besoin, je ne crois pas que le DAC soit la solution; cette sortie n'est pas active durant le reste du programme. (à vérifier ...)
Dans ce cas il est préférable d'utiliser une sortie pwm qui elle, est active en tâche de fond, filtrée par un petit condo pour avoir une tension continue.
 

spheris

Senior Member
Un petit apparté qui n'a rien à voir mais qui prête à réflexion:
Un problème se pose pour alimenter un chauffe eau avec soit le réseau electrique traditionnel, soit par des panneaux.
Un simple chauffe eau en triphasé et le problème est réglé.
En effet le réseau traditionnel alimente un enroulement de la résistance et les panneaux sont sur les autres.
Ainsi deux circuits bien séparés.
Désolé pour le hors sujet.
 

PieM

Senior Member
j'envisage de piloter un relais statique proportionnel qui alimenterait le CE.
Comme il s'agit d'une commande d'un système résistif, une solution moins onéreuse serait d'utiliser directement à partir du Picaxe une commande de type burst, ou train d'ondes, telle que pratiquée sur des radiateurs. Le Linky surveille l'intensité efficace, calculée à partir de l'intégration de l'intensité instantanée, avec un temps d'intégration T de 1 seconde.
Ce qui laisse le temps pour un Picaxe d'envoyer des impulsions en TOR sur un SSR ordinaire bien moins cher. Les pulses étant proportionnels à l'intensité disponible pour le CE.
 
Last edited:

Jarrige

Member
Après ces quelques mois passés, je reviens sur ce sujet ... J'ai terminé un système de pilotage à partir de la TIC en mode historique, mon gestionnaire d'énergie actuel n'étant pas compatible avec le standard. Ce petit système m'apporte satisfaction et fonctionne plutôt bien. EDF m'indique des consos de l'ordre de - 70kW/h ces derniers mois, ce qui correspond à la production d'eau chaude (conso pour 1 personne en moyenne et charge d'entretien) qui est faite quasiment totalement en journée avec le PV. J'ai réalisé un circuit imprimé. Je tiens a disposition de toute personne intéressée toutes infos utiles, les typons (éventuellement je peux aussi faire les CI), le programme.
 

MGU

Senior Member
Bonjour,
Personnellement, je n'y connais rien, mais beaucoup peuvent être intéressés. J'ai déjà un frère qui veut chauffer de l'eau...
Peux tu donner des détails, schémas, etc.
Je pourrais aussi le mettre sur mon site, sous ton nom, bien sûr
MM
 

Jarrige

Member
Bonjour "MGU", je vais tout d'abord faire un descriptif du principe de fonctionnement (pas encore fait), je peux bien sûr passer les schémas (ils sont fait main, pas de logiciel), joindre une photo de ma réalisation, passer le programme (écrit en Basic avec commentaires, et c'est avec un 14M2). Je ne sais pas comment passer tout ça, plus facile via une messagerie (j'utilise Thunderbird) ... Ce serait plus simple pour moi de vous passer ça pour votre site ?
 

MGU

Senior Member
On peut ajouter des photos et des fichiers en P.J. Sur PE6, il y a un copier-coller "spécial forum"
J'ai aussi un mail sur le site, mais le mieux serait de rester sur ce forum .
MM
 

MGU

Senior Member
Bonjour à tous les propriétaires d'installations PV en auto-conso. Comme suite aux suggestions de MGU, je transfère un certain nombre de fichiers de ma réalisation : schéma, notice de présentation, programme en Basic. Je reste à dispo des personnes éventuellement intéréssées.
Bonjour,
Merci beaucoup. Cela semble très intéressant. J'ai regardé rapidement et j'aimerais quelques précisions
Qui a t il dans le rectangle gradateur (je suppose un triac ?). Comment est il relié à la carte commande?
Peux tu me préciser la liaison des fonctions "Auto, ON Off" avec l’interrupteur?
Il y a sur le LM358 une R non renseignée (tu me diras qu'avec un gain de 2,18, on peut calculer...). Cette valeur est t elle sensible?
Pourquoi une R 10k sur C.5? J'ai vu que cette boche n'est pas utilisée
A+
MM
 

Jarrige

Member
Bonsoir, voici les réponses :
Le gradateur est un boîtier du commerce (voir le document pilotage CE), c'est un gradateur qui est piloté en 0-10V, il est connecté sur le commun de l'inter 3 positions (je vais peut-être faire un plan d'interco ...) et au zéro volt. La doc de ce composant est dispo chez INOREA ou le revendeur Technic achat.
Cet inter permet un fonctionnement du type relais HP / HC : Auto : c'est le système qui commande en fonction des paramètres choisis (consigne ...), en ON c'est marche permanente, et en OFF arrêt.
La résistance est une 39,2k, je passe un nouveau document indicé avec la correction.
La broche C.5 (utilisée pour la programmation) doit être obligatoirement reliée de cette manière pour assurer un fonctionnement stable (voir doc PICAXE). A+
 

Attachments

MGU

Senior Member
OK, j'aurais dû tout lire, je ne connaissais pas ces gradateurs pilotables par des tensions variables
OK aussi pour C.5, d'habitude, je la relie directement au 0V, mais si la doc dit 10 k...
Avec ton accord, je vais ouvrir une page sur mon site.
33.2k et 39,2k, c'est pas évident. 33k et 39k, c'est quasi pareil pour le gain et normalisé. Qu'en penses tu ?
MM
 
Last edited:

PieM

Senior Member
Bonjour,
Travail intéressant. Toutefois je n'ai pas compris quel élément d'interface existait entre le PV et ce système.
Le principe de travailler en gradateur par déphasage me semble compliqué et générateur d'harmoniques vu l'utilisation sur résistance pure. Un four céramique de plus de 12 kW fonctionne par train d'ondes sans perturbation du réseau, si celui ci est correctement dimensionné.
Le passage HP - HC (de nuit) pourrait se faire automatiquement avec une horloge interne .
En quoi consiste la Consigne Charge ? Car l'objectif est de chauffer l'eau jusqu'à la consigne qui est atteinte lors de l'ouverture du thermostat qui est resté mécanique ? Sauf à vouloir favoriser d'autres utilisations du PV plus prioritaires .
Le programme mériterait sans doute un peu plus de structure (goto) et de simplification afin de le rendre plus compréhensible et maintenable.. ;)
 

MGU

Senior Member
Bonjour,
Concernant la commande du CE, Jarrige dit:.
[
Le principe retenu est la gradation en angle de phase, qui, malgré les inconvénients de parasitage important à
prendre en compte, permet un ajustage très fin de la puissance injectée, et surtout ne provoque pas de
papillotements sur le réseau qui apparaissent avec les systèmes de type trains d’ondes.
Je ne sais pas en quoi consiste le "papillotement".
Pour mon cas, j'ai une tranche HC dans l'après midi, l'info du Linky et une facilité.
Pour le code, l'indentation et le nommage des broches faciliteraient déjà la lecture .
MM
 

Jarrige

Member
Bonjour, je note tous vos retours ...
Pour Piem, il n'y a rien entre les PV et ce système, le principe de fonctionnement repose sur la mesure de courant instantanée et de la puissance apparente P=0 et I>0, on est en injection donc on peut récupérer du courant.

Le principal problème (évoqué dans mon doc), ce "papillotement" (appelé aussi flicker) est lié à la demande sur le réseau (qui du coup en train d'ondes est au nominal de la charge, soit une dizaines d'ampères !!) J'ai déjà eu plusieurs fois ce problème parfois même avec des charges plus faibles, mais surtout lorsque l'on est loin du transfo Enedis ...
Ce mode de fonctionnement en trains d'onde est plutôt bien avec une période de régulation "longue" (genre plusieurs secondes). Il n'en demeure pas moins que si la puissance moyenne est diminué, mais pendant le temps de conduction, elle reste nominale.
Surtout bien avoir en tête que tout ce qui n'est pas fourni par les PV est soutiré du réseau ... Etant donné la mesure du Linky (il me semble à la seconde), avec une régulation longue il y aura forcément du soutirage et une facture.
Il me semble aussi que les routeurs du commerce bien conçus fonctionnent sur ce principe, mais avec des tores de mesures pour être plus réactifs.
Bref, c'est un choix de focntionnement ... et pour moi, le résultat est là.

Pour ce qui concerne le code, je suis un bricoleur (électricien puis électronique industrielle) et pas un informaticien ... Je sais que mon programme est probablement bien mal structuré et un peu brouillon, toutes mes excuses.. Mais il fonctionne. Et puis j'ai pas mal fait évoluer depuis le début ...
Pour les personnes intéressés, je passe en PJ un plan d'interconnexion entre les 2 CI qui permet d'y voir un peu plus clair
 

Attachments

Technoman

Senior Member
Bonjour,
Bravo pour votre travail et votre partage.
Sur le schéma, quelques remarques :
  • la valeur de la résistance de limitation pour la led rouge semble importante. Si vous utilisez une led faible consommation, un courant de 2 mA est usuel. Après, cela dépend de votre référence et de ses caractéristiques...
    A noter que pour la led jaune, la valeur sur l'implantation est de 3,2K au lieu de 1K...
  • utiliser des fortes valeurs de condensateurs en sortie de régulateur n'est pas recommandé. Le condensateur, à la coupure du système, soumet le régulateur à une tension par sa sortie, ce qui peut être dommageable. Généralement, il est de 1µF. Sinon, pour protéger les régulateurs, si vous voulez garder ces valeurs, vous pouvez placer, pour chacun, une diode entre les broches input/output cathode côté input.
  • J'aurais placé le condensateur pour B.5 après la résistance, connecté à la broche 8, pour garder le filtrage effectif pour toutes les tensions délivrées par le potentiomètre de consigne.
  • Un condensateur de découplage (100 nF) est recommandé aux bornes de de l'alimentation du LM358 (broches 4 & 8). Certes, le 100nF implanté n'est pas loin mais à quelques cm côté GND.
  • Le gradateur n'est pas détaillé, mais sortant de la carte, une résistance de protection de la sortie du LM358 me semble une option utile.
Question : quelles caractéristiques (tension/courant) sur le J/N, TIC et C/H?

Pour le programme :
Il est bien documenté.
Une indentation des IF faciliterait sa compréhension.
 

MGU

Senior Member
Je viens de jeter un œil sur le code. Il y a effectivement des simplifications possibles
Ex dans l'original
Code:
symbol creneau=b19; pour test entree creneau horaire
;puis
    Let creneau= PinsC AND %00000100; test entree creneau horaire sur C.2 : contact ouvert >>entree etat bas = chauffe
    IF creneau = 0 then goto demchauff; dans creneau chauffage
Ok, ça fonctionne, mais c'est équivalent à:
Code:
symbol creneau=pinC.2
;puis
IF creneau = 0 then goto demchauff; dans creneau chauffage
C'est plus simple, et on utilise aucune variable
MM
 

Jarrige

Member
Bonjour Technoman,
Pour les LED, il y a une petite évolution et un problème à l'impression sur le doc que j'ai "bricolé".
Ce sont des LED haute efficacité (chez Conrad). Pour la rouge, une 2,2k est bien suffisante, pour la Jaune c'est une 1k, le schéma est à jour, mais je n'ai pas refait l'implantation. Le but de ces valeurs "élevées" est de limiter au mieux les courants demandés au PiCAXE.

Vous avez plutôt raison pour les cond. de filtrage,mais je n'ai jamais aucun soucis avec ce genre de montage.

Pour le gradateur, je ne sais pas (rien de spécial dans les docs),mais l'impédance d'entrée ne semble pas très élevée et le CI doit bien supporter (déjà employé par ailleurs avec un montage classique à transistor).

J/N est à raccorder sur une sortie gestionnaire d'énergie (Calybox 230 chez moi), ou une horloge journalière en cas de tarif de base. Elle est prévue pour recevoir du 230V (env. 1mA de courant).

TIC doit être raccordée à la sortie du compteur par une paire téléphonique torsadée

C/H est une entrée TOR (bas niveau), elle doit être pilotée par un contact SEC si besoin.
 

Jarrige

Member
Je viens de voir le message de MGU pour le code ... oui, comme déjà évoqué, je bricole en BASIC. Il n'y aura bien sûr aucun problème sur ce programme (je n'ai pas de copyright !!) Tout le monde peut faire et modifier ce qu'il veut.

Pour les résistances de l'ampli, on peut bien sûr monter d'autres valeur, celles que j'ai mises sont issues de "tout venant" de mes tiroirs. Le tout est d'avoir le gain d'environ 2,2, mais ce n'est aucunement "critique". Il faut juste que l'on s'approche de 9,5v pour 900 points PWM. Si on regarde un peu la doc du gradateur, on peut voir que la fonction de transfert est loin d'être linéaire (il ne conduit quasiment pas en dessous de 2V et on arrive près du max pour env. 9V)
 

Jarrige

Member
Aucun problème, la liaison peut faire jusqu'à 500m (voir doc Enedis , par exemple la NOI-CPT-54E que l'on trouve sur le Net et qui explique tout ça).
La mienne fait une vingtaine de mètres et il y a 3 équipements dessus dont le gestionnaire Calybox, mon montage et une liaison qui arrive sur le PC via un petit module de "Carte Electronique" bien pratique (et que je recommande !!) pour observer ce qui se passe en temps réel : permet d'afficher les valeurs Linky via une USB.
 

Jarrige

Member
Là, je ne peux pas grand chose ... Pouvoir avoir une connexion avec le bornier client du compteur (Contact J/N et TIC) est effectivement un prérequis.
Un peu étonnant qu'il n'y ait pas de gaine depuis le compteur qui est semble t-il en limite de propriété.
En principe il y a une gaine de 80 pour le câble d'alimentation de la maison, et une gaine de 40 ou 60 prévue pour la liaison jour / nuit
Il existe aussi des modules radio qui s'installent sur le bornier Linky, mais je n'ai pas d'info.
 

PieM

Senior Member
En fait je n'ai pas bien compris la philosophie de ce système, mais je ne comprends pas grand chose en ce moment, à vrai dire...
Pour moi, il y a des panneaux PV dont l'objectif est de fournir le maximun d'énergie, ici stockée sous forme d'eau chaude. Et si cette énergie est insuffisante, il est fait appel au réseau, en Heures Creuses via le relais existant.
Il ne semble pas y avoir de gestion d'autres utilisations qui pourraient être parfois prioritaires, donc nécessitant un délestage.
Lorsque la température de l'eau du CE est atteinte, la consommation s'arrête par le thermostat mécanique et on est certain d'avoir utilisé le maximum d'énergie pour cette utilisation.
En ce sens, le message initial de Besqueut me semblait plus pertinent quant à l'utilisation de cette énergie qui était à répartir.
 

Jarrige

Member
Bonjour PieM,
Pour les PV, ils fournissent l'énergie qu'ils peuvent en fonction des divers paramètres physiques, c'est l'utilisation qu'on en fait qui doit être optimisée.

La "philosophie" du système réalisé me paraît pourtant assez SIMPLE :
En auto-conso avec revente chez EFD OA, l' énergie injectée est payée 0,1 € kWh
En tarif règlementé (pour 6kW et HP/HC) , l'heure pleine est actuellement à 0,27, la creuse 0,20
Résultat, lorsque l'énergie fournie par les PV dans la journée est suffisante (c'est à peu près tous les jours), le système chauffe l'eau avec de l'électricité à 0,1 € ald 0,2 en nuit. (0,1 car si l'on consomme l'énergie produite, forcément on ne la vend pas). Soit tout de même - 50% (et c'est "vert" et local) !!

Concernant tous les autres équipements de la maison, comme le système analyse en permanence les valeurs mesurées par le compteur et ajuste la commande du gradateur en fonction , ils demeurent tous plus prioritaires. Toute consommation en plus dans le circuit de la maison est réduite d'autant dans le ballon CE.
Comme déjà évoqué, ce n'est forcément pas parfait à cause de différends retards (Temps intégration compteur, temps communication, temps réaction du système ...) Aussi à cause de la résolution médiocre de la valeur d'intensité mesurée par le compteur qui est de 1A.
 

PieM

Senior Member
Bonjour,
OK, donc en fait tout est prioritaire devant le CE qui n'utilise que le surplus d'énergie des PV disponible. Désolé, cela ne m'avait pas paru évident au départ.
Un peu de fatigue de ma part ! :)

J'ai commencé à regarder le programme, mais j'avoue être un peu surpris, car son fonctionnement tient un peu du miracle. Vous utilisez en effet une multitude de goto qui renvoient a des procédures se terminant par des return. Or ça , ça ne marche pas car le programme ne sait pas où retourner, donc au mieux, il continue avec l'instruction suivante, au pire, ça plante le programme par saturation liées aux return.

"The return command is used with a matching gosub command, to return program flow back to the main program at the end of the sub procedure. If a return command is used without a matching gosub beforehand, the program flow will crash. "
 
Last edited:

PieM

Senior Member
Suite à mon oeil rapide sur le programme et bien que vous ne sollicitiez pas d'aide pour ce programme que vous jugez fonctionnel, je tiens à faire ces quelques remarque:
SERIN [3000,norecep],C.0,T1200,($C9,$C9,$4E,$53,$D4,$A0),b2,b3,Amp
Il est plus simple et plus parlant de mettre comme je l'avais écrit:
SERIN [3000,norecep],C.0,T1200,("IINST "),b2,b3,Amp
et SERIN [3000,norecep],C.0,T1200,("PAPP "),b5,b6,b7,b8,Papp

Je suis très étonné car vos codes ASCII $C9 et $D4 ne font pas partie des codes correspondant aux caractères transmis par Linky (maxi 7F).
De plus, le code $A0 n'a pas de sens car c'est un séparateur ($20) qui est dans le groupe de données transmises en mode historique.
Donc les deux serin ne peuvent pas à priori, recevoir de réponse. !?

concernant
b4=b4 and %00001111 ; b4 unité des ampères est déjà défini comme variable Amp !
b3=b3 and %00001111 ; inutile puisque ne sont transmis que des chiffres 0 à 9
b3= b3*10; b3 contient les dizaines
Amp=Amp+b3
; Amp contient la valeur globale intensite

donc pour simplifier:
Amp = b3*10+Amp

Vous écrivez:
Let Infonuit= PinsC AND %00000010
répété plusieurs fois dans le programme, sans raison. Il a été défini une fois, c'est suffisant.
donc en fait Infonuit = C.1
mais vous avez défini avant: symbol Infonuit=b10

Pour savoir si on est en mode producteur / consommateur, l'info est donnée par le Linky, directement par le bit8 du registre de status, (étiquette STGE).
1 si producteur 0 si consommateur.
exemple:
SERIN [3000,norecep],C.0,T1200,("STGE "),b1,b1,b1 ; (b1 , 3e byte reçu, composé des bits 8 à 15)
If bit8 = 1 then .... ; on est producteur
Le bit 7 peut être utile pour du délestage: à 1 si dépassement de la puissance souscrite,en cours.

Eviter d'utiliser b0 et b1 donc w0 en tant que variables. Cela permet d'utiliser des simples bits en les adressant directement comme ici.

Je ne suis pas allé plus avant car le cheminement logique de votre programme est semé d'embuches.
J'ai l'impression d'être devant une armoire électrique avec tous les fils qui se croisent, et rien de repéré. Mais je ne suis pas électricien !
C'est sympa de partager votre projet, qui vous conviendrait donc en l'état, même si je doute très fortement de sa fonctionnalité et qu'il ait pu "tomber en marche" pour reprendre l'expression de quelqu'un que nous connaissons bien sur ce forum ..
 
Last edited:

Jarrige

Member
Pour répondre sur les remarques de Piem et des SERIN, ce que j'ai fait est tout simplement nécessaire car le Linky envoie des caractères avec une PARITE et le PICAXE ne gère pas (à ma connaissance), j'avais initialement fait comme PieM l'écrit et ça ne fonctionne pas car le "qualifier" du serin teste les caractères sur 8 bits (0-255), et si on met des caractères ASCII, il sont sur 7 bits sans paraité. Cette histoire de parité est d'ailleurs mentionnée en commentaire.

Que je sache, même si mon programme n'est pas "joli", il n'y a pas de GOTO qui se termine par un RETURN, c'est sûr que ça se serait planté !!!
Je ne suis probablement pas très fort en BASIC et débutant (et je ne fais pas de miracle), mais tout de même ... Et puis, vu le nombre de lignes, il ne me semble tout de même pas si compliqué que ça ce programme.
Pour l'heure, ce programme tel qu'envoyé sur le forum (V2.3) fonctionne à merveille depuis plusieurs mois, n'en déplaise aux critiques, peut-être parfois jsutifiées.

Quant à l'étiquette STGE, elle n'existe pas en mode HISTORIQUE (elle n'est transmise qu'en mode STANDARD)

J'ai juste voulu faire profiter à quelques intéressés dans des projets de PV en auto conso, que ce soit du hardware et éventuellement du programme
qui va avec.
 

MGU

Senior Member
Bonjour,
Merci Jarrige de partager cette expérience. Si je fais une page sur mon site, je posterai le code tel quel, je n'ai aucun moyen de tester un code modifié, peut être quelques simplifications évidentes...et encore. Je ne suis pas sûr que tu aies envie de tester un programme modifié.
Il faudrait aussi que je fasse un PCB DipTrace, pour envoyer les Gerber à JLCPCB, c'est le plus simple.
A suivre
MM
 

Jarrige

Member
Bonjour MGU,
Si vous voulez faire des modifs dans le programme, je peux envisager de le tester sur mon montage chez moi, pourquoi pas.
Pour le PCB, c'est vous qui voyez ...
Pour info, je risque d'apporter des modifs sur la partie puissance visant à atténuer les interférences plus efficacement. Je vais me "pencher" sur le sujet dans les prochains jours.
A suivre, oui
 

MGU

Senior Member
Merci pour la proposition, les modifs éventuelles ne seraient qu'esthétiques. Avez vous un organigramme du programme?
MM
 
Top