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 ! 
1 « J'aime »
Bon résumé !
Bonjour,
Merci pour la critique gratuite !
Cela m’a bien fait rire !
Surtout la notion des temps informatiques…
Bonne journée.
ps. pour la teleinfo il faut le plugin idoine.
Il n’existe pas sur le market celui la
Pourtant…
Oui ce lui la mais pas idoine 
ok je sort …
Avoir ou non le plug-in téléinfo ne change rien au fait que dans le moniteur série Arduino aucune trame ne s’affiche… ce qui fait qu’elle ne risque pas de remonter jusqu’a jeedom (test de la commande : « ») et encore moins jusqu’a plug-in téléinfo…
Mais c’est sympa d’être passé.
Bonjour @Forhorse,
Je vois que tu as pas mal de cartes Arduino, si tu as un esp8366 qui traine tu peux aussi te tourner vers cette solution, coté Jeedom avec le plugin MQTT ou jMQTT l’affaire est dans le sac assez rapidement. Je préfère les Wemos D1 mini, au moins pour prototyper, mais un ESP01 fait aussi le job, comme dans le tuto.
D’ailleurs ce tuto sur l’ancien forum montre le tout step by step, et c’est plutôt pas mal !
Hope it helps !
Même sans mqtt un simple push dans une commande info …
Farpaitement !
Depuis ce matin je développe ma solution perso basé exactement sur le même matériel que mon essais avec Jeedouino : Un Arduino Uno et un shield Ethernet a base de W5100
Le sketch se charge de récupérer (via un Serial software…) et décoder la trame téléinfo pour en extraire les valeurs intéressantes (index, puissance, intensité, tarif en cours)
ces données sont mise à dispo dans un fichier XML et un JSON (et en clair dans dans une page HTML) par le biai d’un petit serveur web simpliste.
Un scénario appel ce fichier JSON régulièrement et mets à jour les infos d’un virtuel…
Et vous savez quoi ? Ben ça fonctionne parfaitement !
Mon problème actuellement c’est de décoder des infos de la trame que l’auteur de la librairie que j’utilise pour ça n’a pas jugé utile de sortir… vu mon niveau en C c’est pas gagné, mais j’essaye.
Le « Push » est un concept encore vague pour moi… mais je ne suis pas contre apprendre si on peut me fournir un exemple simple qui montre le principe.
le push t’est proposer sur les équipements virtuel
https://IPJEEDOM/core/api/jeeApi.php?plugin=virtual&APIKEY=apikey&type=virtual&id=#cmd_id#&value=#value#
il te suffit de remplir L’ID et la valeur que tu veut affecter a ta commande info
en fait les nom sont push ou pull mais ça dépend de ou on l’utilise
se sera un push depuis ton arduino mais un pull dans jeedom …
Ah merci, c’est plus simple que ce que je pensais (en apparence en tout cas, je pourrais dire ça quand j’aurais réussit à faire fonctionner un push 
)
De mon côté je viens de réussir à extraire une nouvelle valeur de la trame téléinfo (soit je ne suis pas si mauvais que ça en C, soit c’est librairie est vraiment bien faite et du coup facilement customisable 
)
ça fait un candidat idéal pour un test en push… reste à voir comment je vais pouvoir implémenter un client web dans tout ce bazar…
J’ai éditer mon message et mis un lien vers le tuto !
tu peut même tester dans un navigateur …
Oui c’est ce que je viens de faire juste avant de voir ta réponse, et ça fonctionne, c’est bon j’ai compris le principe. Merci, et merci pour le tuto, ça peut servir