Je suis en train d’essayer de récupérer les données téléinfo de mon compteur EDF. J’ai fait un convertisseur avec des optocoupleurs qui semble fonctionner correctement (essayé avec un sketch qui affiche bien les valeurs sur le moniteur série)
Je pensais qu’avec Jeedouino ce serait simple vu qu’une fonction est prévue pour ça, hors je n’ai aucune trame qui remonte.
Ma config : Arduino Uno officiel avec shield ethernet W5100 chinois.
L’Arduino semble communiquer correctement avec Jeedom (j’ai une entrée et une sortie digitales qui sont bien rafraichie)
J’ai essayé les PIN 4 puis 2 comme RX pour la téléinfo mais rien.
J’ai activé le mode debug dans le sketch Arduino et il ne semble recevoir aucune trame téléinfo.
Dans le doute j’ai fait un essais, j’ai supprimé le shield ethernet pour laisser l’arduino seul avec la réception de la téléinfo et là j’ai bien les trames qui s’affichent dans le moniteur série, donc aussi bien le matériel que le logiciel côté sketch semble OK
Pourtant dès que je remet le shield ethernet, aucune trame reçue…
Sans doute un conflit matériel, mais normalement les 2 PIN que j’ai essayé sont normalement libres alors ça devrait fonctionner.
Une idée ? est-ce que quelqu’un utilise cette fonctionnalité de Jeeduino ? si oui quel est votre config ?
The Ethernet shield uses digital pins 11, 12, 13, 10, and 4 for SPI communication with the W5200 Ethernet controller and SD card. Therefore, the shield is compatible with any other shield that does not use pins 10, and 4 in this regard.
C’est ton prog de shield qui déroule mal avec ton prog de téléinfo …
Tu a du raté quelque chose !
Je vois de par l’exemple que tu part sur un serveur web …
ne serait il pas mieux pour éviter jeedouino et compagnie
que sur un changement de valeur ou chaque x secondes tu fasse un push dans commande info d’un virtuel jeedom ?
(je n’ai jamais utiliser de shield mais sur ce genre de manip j’utilise des ESP qui integre du WiFi et je push mes valeurs dans jeedom) le principe reste le même que l’on soit en wifi ou eth !
J’ai rien modifié/écrit par moi même (sauf passer le flag DEBUGtoSERIAL à 1) c’est le sketch fournit tel-quel par le plug-in Jeedouino.
La fonction est théoriquement disponible « out of the box » sans rien faire de plus que de configurer l’objet dans le plug-in. Mais visiblement personne ne l’utilise car les quelques questions qui concernent cette fonction sur le forum restent sans réponse.
En même temps, visiblement, même si on arrive à faire remonter la chaine contenant la trame téléinfo jusqu’a Jeedom, on peut rien en faire, j’ai pas trouvé de plug-in qui exploite cette trame… donc faut decoder la trame soit même dans Jeedom.
Bref, l’intérêt semble proche de zéro…
Je vais insister un peu en utilisant un autre type de shield ethernet (je dois avoir un ethernet shield 2 officile qui traine dans un tiroir) et d’autres PIN…
Mais oui, je crois que je vais finir par passer par un petit serveur web sur l’arduino qui fournira un XML/JSON avec toutes les valeurs utiles déjà décodées et j’utiliserais la même méthode de remontée d’info que pour mon régulateur solaire, au moins je sais que cette méthode fonctionne.
Pour la téléinfo c’est un port serie software qui est utilisé donc pas de problème de ce côté là… et de toutes façon vu que ça fonctionne sans le shield ethernet de connecté, le soucis n’est pas ce côté puisqu’on a bien le serial hardware à 115200bauds pour le débug et le serial software à 1200 bauds pour la téléinfo qui fonctionnent en même temps.
J’ai essayé avec un shield ethernet 2 officiel, téléinfo toujours sur la PIN 8 et dans le moniteur série j’ai de temps en temps une trame qui s’affiche… soit en entier, soit partiellement… mais toujours rien qui remonte dans Jeedom.
J’ai un mega 2650 qui traine, je vais essayer avec… mais je me dirige de plus en plus vers la solution perso
J’ai essayé avec un Mega2560 et le résultat est identique… ce qui n’est pas étonnant car même quand on sélectionne une pin ayant un RX serial hardware, le plug-in génère un sketch avec un serial software
ça n’a jamais été optimisé, je pense que cette fonction est abandonné par l’auteur du plug-in et je vais en faire de même.
Je pourrais essayer de modifier le sketch généré pour qu’il utilise un serial hardware mais j’ai pas envie de perdre mon temps avec ça.
avez-vous bien transférer le sketch avec les bibliothèques fournis avec le plugin?
j’ai eu un soucis de lecture avec des DHT22 car j’utilisais mes bibliothèques habituelles. après utilisation des bibliothèques fournis, je n’avais plus de problème de lecture. vous avez peut-être le même soucis.
Je viens d’aller me geler dans le garage pour refaire un essais avec le sketch compilé avec les librairies fournies et… ça n’a rien changé !
Le problème est ailleurs.
Avant j’avais aussi fait un essais en supprimant toutes les fonctionnalités que je n’ai pas besoin (DHT, on-wire) idem, aucun résultat.
Non je crois vraiment que cette fonctionnalité n’a jamais été développée jusqu’au bout (sans doute la raison pour laquelle personne ne semble l’utiliser…)
Par curiosité j’ai un peu regardé le code du sketch généré et je suis tombé sur ce genre de truc
timeout = millis() + 30000; // 30s
while (client.connected() and timeout>millis())
Y’a un glitch là (que ce passe t’il quand « millis » est proche du débordement à votre avis ?)
Et on retrouve ce genre d’erreur à plusieurs endroits dans le code.
Ce qui m’amène à penser que la solution Jeedouino n’est pas très robuste.
je pense à deux possibilités. soit le timeout + 30000 effectue un débordement et sa plante. soit le timeout est juste en dessous du débordement et donc le programme aura dû mal à faire la comparaison donc jamais réinitialiser le timeout. c’est pour ça que dans mes programmes arduino et au début, je mets toujours un if millis() < 20 then timeout = millis() j’ai qu’un blanc de 20 millisecondes mais toujours un timeout opérationnel. chose que j’ai jamais fait mais pour éviter le débordement, rajouter une ligne genre si le débordement est à 1000 (pour l’exemple) if timeout > 970 then timeout = 0
je ne peux rien dire à ce sujet car mon jeedom n’est pas encore en service (démarré juste pour faire des essais pour le moment) mais j’ai constaté quelques latences entre l’arduino et jeedom. exemple: j’appuie sur un bp, jeedom le voit mais si je fais un autre bp dans la foulée, ça passe pas. il faut que j’attende entre les 2 appuis
Pourtant la bonne pratique avec Arduino est connue depuis longtemps, il ne faut pas faire une addition, mais une soustraction, ainsi même en cas de débordement de millis() il n’y a aucun problème.
Je ne vais pas détailler la méthode ici, il y a suffisamment de littérature à ce sujet sur le net.
(par exemple: Utilisez correctement la fonction millis() - IUT GEII Toulon)
Pour ce qui est de la latence entres les actions avec Jeedouino, ce n’est pas étonnant :
De base l’utilisation d’Ethernet est très lourde pour un petit microcontrôleur tel que l’Atmega 328, il passe don énormément de temps à mouliner tout ça (même si l’utilisation de chipset type W5xxx le soulage déjà pas mal) ce qui lui laisse peu de temps pour faire le reste.
Plusieurs bibliothèques et fonctions elles aussi très gourmandes en temps processeur (je pense par exemple au protocole On-wire) sont activée par défaut sans qu’on en ai forcement besoin. C’est plus souple pour l’utilisateur qui peut ajouter un capteur directement dans Jeedom sans devoir recharger un nouveau sketch dans l’Arduino, mais ça se paye a un moment ou à un autre.
L’auteur n’as pas vraiment la notion des « temps informatiques » dans le sketch il y a des tempos un peu partout avec des durée allant de 2 à 30s… même pour un microcontrôleur, même à seulement 16MHz, 2 secondes c’est déjà une éternité. habituellement on travail avec des délais en millisecondes… Alors forcement quand on introduit volontairement des latences aussi énormes dans des actions qui devraient être rafraichie le plus souvent possible, ça ne peut aboutir qu’a des fonctionnement erratiques.
Alors qu’on ne se trompe pas, loin de moi l’idée de critiquer l’auteur de ce plug-in, l’idée est louable, il fait ça gratuitement et certainement sur son temps libre, et le partage avec tout le monde. Le travail fournit est déjà énorme.
Le principe est intéressant et il y a matière pour faire quelque chose de bien. Mais en l’état le projet n’en est qu’a ses débuts et il ne faut pas se baser dessus pour faire fonctionner une solution domotique.
J’apporte là une « critique » de ce que je vois dans le code Arduino du haut de mes modestes compétences d’amateurs/bidouilleurs et que me font arriver à cette conclusion.
Je ne sais pas ce qu’il y a dans le code PHP du plug-in, c’est peut être bien meilleur, mais c’est peut être pas mieux ?
Pour bien faire il faudrait une communauté active autour de ce projet avec quelques « pros » pour au moins corriger toutes les plus grosses erreurs.
Avec tout mon respect pour l’auteur de ce plug-in !
