Vote for this board, with enclosure format
The size is as follow
Enclosure reference and datasheet
http://evatron.com/enclosures/sensor-cases/pp42m/
Vote for this board, with enclosure format
The size is as follow
Enclosure reference and datasheet
http://evatron.com/enclosures/sensor-cases/pp42m/
Vote for current board
The size is as follow
@AuFilElec
Géniale ton interface WEB pour les zones, c'est cool
Pour l'interface WEB je viens de tout passer en AsyncTCP (merci à @me-no-dev) et je t'assure qu'au niveau performance, c'est juste le jour et la nuit, avant au 1er refresh le temps de charger bootstrap ça prenait genre 3/4 secondes, maintenant en moins d'une seconde c'est bouclé!
En plus j'ai tout migré en WebSockets et j'ai ajouté une console série WEB pour passer des commandes, la config et voir les LOG, ça commence à donner un truc qui me plait.
Plus qu'a finaliser et intégrer ça dans le remora car pour le moment c'est pour un autre projet.
Tu peux déjà regarder l'exemple de la console Web Serial to Websocket si tu veux c'est ici car il y a aussi un dossier intéressant (webdev) qui contient :
J'utilise le même principe sur remora et WiFinfo avec qui scripts plus avancés car ils minifient les js et css non minifiés, et en plus ils les concatène tous en 1 seul fichier pour un chargement plus rapide depuis l'ESP vers le browser.
Bonjour,
Pour ceux qui rencontrent des soucis de commande de fils pilote avec les optos blanc (TLP168J), il faut essayer d'alimenter les optocoupleurs en 3.3V en lieu et place du 5V, pour cela il faut :
Une photo valant mieux que des explications, la voici :
Je vous souhaite à tous un très joyeux noël.
@scalz
ouais c'est compliqué (voir même complètement fou) de vouloir gérer le hard et le soft, nous sommes que des humains, notre gros soucis c'est que le temps est le même pour tout le monde et il nous faudrait des journées de 48H, une soft, une hard hahahaha
En plus tout le socle Arduino ESP8266 ça bouge tout le temps, l'équipe est super active et réactive, ça avance vite et une version OK peu ne plus compiler 6 mois après car tout à changé mais que en bien !
Ah oui je ne vous ai pas dit aussi, j'ai tout passé le JSON avec la super librairie ArduinoJSon de Benoit (encore un Frenchy), la encore trop de la balle à tel point que la AsyncWeb socket de @me-no-dev inclue tout ce qu'il faut pour s'intégrer avec cette lib.
Après je suis pas super calé en C++ (class, template, virtual) et parfois je galère pour contribuer aux codes de ces super dev. En revanche le C ça va très bien
@AuFilElec
Pour la partie du code dont tu parles, tu as du voir mais je fais un rappel, plus on aura d'yeux sur le soucis plus vite on le trouvera (bien que je suis pas certain que ça vienne du code, je l'utilise sous linux depuis des lustres sans le moindre soucis). Donc
La structure de la liste chaînée _ValueList
contient pour chaque élément (je fais grace du premier (root) qui est vide)
// Linked list structure containing all values received
typedef struct _ValueList ValueList;
struct _ValueList
{
ValueList *next; // next element
uint8_t checksum;// checksum
uint8_t flags; // specific flags
char * name; // LABEL of value name
char * value; // value
};
Donc pour chaque élément, tu as:
*next
un pointeur sur la même structure du prochain élément, sauf si nous sommes sur le dernier élément bien sûr auquel cas ce pointeur est NULL
checksum
la checksum du couple LABEL/VALUE de l'élémentflags
des drapeaux servant a savoir su l'élément vient d'être ajouté, ou juste modifié, .. (par exemple une valeur IINST modifiée)*name
un pointeur sur la chaine qui va contenir le nom du label (ex IINST)*value
un pointeur sur la chaine qui va contenir la valeur (ex 23)Ce qu'il faut bien comprendre c'est que quand tu alloues un élément de la liste chaînée (parce que viens de recevoir une nouvelle étiquette) tu n'as pas la taille pour stocker le nom de l'étiquette ainsi que sa valeur, ce ne sont que des pointeurs *name
et *value
il faut donc allouer l'espace mémoire nécessaire et c'est la qu'interviennent les lignes dont tu parles.
Donc dans un 1er temps on crée un node vide de la taille de la structure auquel on ajoute la taille de l'étiquette+1 et de sa valeur+1 (les 2 +1 pour les fins de chaine \0) newNode
// Our linked list structure sizeof(ValueList)
// + Name + '\0'
// + Value + '\0'
size_t size = sizeof(ValueList) + lgname + 1 + lgvalue + 1 ;
// Create new node with size to store strings
if ((newNode = (ValueList *) malloc(size) ) == NULL)
return ( (ValueList *) NULL );
else
// get our buffer Safe
memset(newNode, 0, size);
// Put the new node on the list
me->next = newNode;
Ensuite on positionne les valeurs de la structure, et la, c'est la ruse on stocke la chaîne du nom à la fin de la structure (car y on a réservé plus de place), donc son pointeur est l'adresse du noeud + la taille de la structure
newNode->name = (char *) newNode + sizeof(ValueList);
et enfin le pointeur de la valeur juste après la valeur du nom
newNode->value = (char *) newNode->name + lgname + 1;
D'ou le code suivant:
// First String located after last struct element
// Second String located after the First + \0
newNode->checksum = checksum;
newNode->name = (char *) newNode + sizeof(ValueList);
newNode->value = (char *) newNode->name + lgname + 1;
Et après on y copie label + valeur
// Copy the string data
memcpy(newNode->name , name , lgname );
memcpy(newNode->value, value , lgvalue );
Voilà j'espère avoir pu éclairer sur le sujet
Et Tadaaaaaaaaaaaa , la vache, en écrivant ça je viens de percuter sur un truc, je crois comprendre ce qu'il se passe et je pense avoir trouvé le bug !!!!!
L'ESP aligne par défaut les structures et leur contenu sur 4 octets et donc en fonction des tailles label/value tout peut changer et on se retrouve avec des alignement foireux (j'ai déjà rencontré ce souci en sauvant des config sous forme de structure en flash) que j'ai réglé avec des directives pragma pour aligner sur 1 octet.
Peux-tu essayer de changer le code de déclaration de la structure en y ajoutant les pragma avant et après déclaration de la structure? Si ça ne suffit pas il faudra aussi tenter d'aligner malloc pour label/value sur 4
#pragma pack(push) // push current alignment to stack
#pragma pack(1) // set alignment to 1 byte boundary
// Linked list structure containing all values received
typedef struct _ValueList ValueList;
struct _ValueList
{
ValueList *next; // next element
uint8_t checksum;// checksum
uint8_t flags; // specific flags
char * name; // LABEL of value name
char * value; // value
};
#pragma pack(pop)
Bon tests
Charles
Merci pour le lien, et oui @Barbu-Dor à fait un boitier génial justement pour le wemos teleinfo, peut être il peut partager les fichiers, je peux même les mettre sur le repo git dédié si il veut bien (ou faire une PR pour ça il maitrise le sujet)
@arthurlutz
Merci pour ton commentaire.
Alors, je te répondrais, oui, j'ai vu un tas de choses bizarre avec emoncms et je t'avouerais que parfois la mise en oeuvre et la compréhension des graphes relève de la magie vaudou !
En plus ils ont récemment mis à jour la version sur le site officiel et je ne suis pas persuadé que ça n'ai pas ajouté des soucis.
Peux-tu nous copier ta liste de feed et d'input ?
Essayes ça
http://hallard.me/blog/wp-content/uploads/tasmota-sensors.bin.gz
si tu veux le faire en OTA tu dois faire en 2 étapes
Bonjour,
Comme vu dans ce post, il se peu que dans certains cas après quelques mois d'utilisation, que la réception de la téléinfo ne fonctionne plus correctement.
Ayant eu entre les mains le cas, et pour rappel le schéma est le suivant
J'ai donc commencé par:
Etant donné que le 3eme composant sur lequel le signal arrive est le RXD du chip FTDI FT230SX, j'en ai déduit (peut être à tord) que la resistance de pull-up interne devait varier avec le temps et qu'en fonction des compteurs électriques, sortir de la plage de fonctionnement.
J'ai donc testé en ajoutant une pull-up de 10K comme le montage ci dessous et tout rentre dans l'ordre.
Le montage final devient alors le suivant avec R7 rajoutée.
La prochaine révision V1.2 contiendra le fix.
@Nicolas-Bernaerts il utilise le module USB sur un PI je pense, donc pas de Tasmota
Si son compteur est configuré en production (revente) normalement justement il doit avoir ces données (j'attends avec impatience cette config sur le mien pour vérifier)
@tommiedepommie Bonjour,
Alors c'est une très bonne question, mon linky sera dans la même configuration un jour.
tu dois avoir cet index dans la trame reçue mais peut être n'est il pas traité par l'application qui envoi dans home assistant, comment est faite ta configuration ?
@zoll38 c'est quoi comme ESP ? si c'est un ESP32 avec du berry c'est largement moins prise de tête que les rules je trouve (et surtout plus lisible)
@Delio la version de @Nicolas-Bernaerts les remonte aussi, direct dans HA mais comme toi je n'utilises pas les today et yesterday de Tasmota. En revanche le gros avantage c'est qu'il te calcule la puissance active et le cos phi que tu n'as pas en natif.
tu as quand même un paquet d'options que tu ne trouveras pas ailleurs
@alexlg au top merci pour le partage.
Pour information @Nicolas-Bernaerts à une super version de Tasmota gérant les fils pilotes.
https://github.com/NicolasBernaerts/tasmota/tree/master/offload-pilotwire
ça peut peut être l'intéresser de jouer avec cette board.
@jcoudrais yes il faut passer la commande dans la console
EnergyConfig standard
@devchristof avez vous essayé de jouer avec le petit potentiomètre de la carte Teleinfo ?
@kenavo ah yes l'intégration HA devait ouvrir le même port (logique ceci dit), mais c'est curieux qu'elle ne fonctionne pas quand elle est toute seule, tu as d'autres USB branchés et/ou configuré dans HA ?
@kenavo si ça refonctionne après que picocom se relance c'est qu'il reconfigure le serial et ça marche et je suis persuadé qu'un truc en arrière plan tente d'ouvrir ou d'utiliser le serial.
Tu peux aussi essayer d'arrêter tous les services inutiltes pour voir
je serais curieux de voir la sortie d'un ps -aux
@kenavo ok oui logique que à droite ça fonctionne mieux.
ce qui est très surprenant c'est que ça fonctionne parfaitement bien avant de partir en vrille, d'habitude soit le signal est bon soit pas bon mais dans ton cas c'est systématique après quelque temps. Une fois que c'est parti en vrille, si tu stoppes picocom et relance la même commande ça remarche un peu ou ça reste en vrille ?
Je me demande si il n'y aurait pas un process qui essaierait de jouer avec le port ttyACM0 ou prendrait beaucoup de CPU. Tu n'as bien que ce module connecté au Linky rien d'autre ?
Je veux bien te changer le module mais j'ai de sérieux doute que ce soit ça et tu pourrais te retrouver dans la même situation.
Est il possible de faire un essai avec une SD contenant une raspian neuve (sans GUI) et donc sans autres softs que l'OS et juste picocom pour voir ?