Merci beaucoup pour ta contribution 
Il n’y a aucun problème, si tu veux me contacter en MP pour qu’on regarde ça en détail n’hésite pas 
Avec grand plaisir, toute documentation est bonne à prendre pour pouvoir satisfaire tout le monde ^^
Je vais d’ailleurs bientôt mettre un place un Google Forms pour savoir ce que chacun attend à peu près de ce service, de manière à ce que ça oriente la suite du travail vers des méthodes qui conviennent au plus grand nombre.
Je poste ce message ici car cela suit le développement du service Arduino, mais peut-être cela mériterait peut-être son propre thread… Je ne sais pas 
Pour tout ceux qui sont intéressés par l’implémentation Arduino, j’ai créé un petit questionnaire afin que vous puissiez me faire parvenir vos retours d’expérience sur Arduino, ce que vous attendez du service, et, si vous en avez, de la doc que vous pourriez juger utile.
Merci beaucoup de prendre sur votre temps pour ce petit sondage, c’est l’affaire de 2 questions 
Je voulais en parler justement, un sous-module parmis IR, RF433, capteur etc… serait un sous-service « arduino-to-arduino ». En wifi avec les l’ESP8266, gladys peut faire mais, s’il n’y a plus de wifi, parfois c’est pour ça que le 433 est utilisé, pour éviter de baigner dans le wifi H24 ou de se prémunir d’une coupure wifi.
Ce sous-service doit pouvoir renvoyer la commande JSON recue en USB à l’arduino collé à gladys, en 433, tel quel, à un autre Arduino, bien placé (au plafond!) pour mesurer un mouvement, envoyer une commande IR à l’aspirateur robot à l’opposé de la box TV (pour mon cas).
Bref pouvoir s’affranchir d’un arduino collé à gladys. Il doivent parler entreux: l’arduino USB devient alors une passerelle.
Bonjour, tout d’abord je suis content de voir que ce thread et le dévellopement reprend de l’activité.
J’avoue que je suis un peu partagé sur le fait d’avoir quelque chose de standard mais c’est probablement parce que mon arduino est un peu le 2ième cerveau de mon installation.
Pour détailler un peu à quoi il me sert :
Quand je dis que c’est un peu un deuxième cerveau c’est parce que je traite/filtre ici toutes mes différentes informations recues avant d’éventuellement les transmettre à Gladys. Par exemple si une valeur ne change pas je ne la transmet pas ou si elle est en dehors de ses limites min/max.
Sous gladys j’ai aussi créé un faux périphérique qui me permet d’activé ou non le renvoi de à Gladys de tous ce qui est lu sur le 433Mhz. Ca permet pas exemple de lire les codes des télécommandes de prise (via putty). Etant désactivé par défaut ca permet aussi de ne pas surcharger Gladys d’envois d’informations n’appartenant pas à mon système.
Je gère aussi tout ce qui concerne mon Roomba (robot aspirateur) en effet il fonctionne par un système de requete, je peux donc cadenser les demandes.
Mon code arduino est donc loin d’etre standard et basique ce qui le rend forcement plus difficilement portable.
Voilà un peu ce que donne mes différents périphériques pour imager un peu mes propos
Bref pas bien sur de faire avancer le schmiblik mais au moins ca ajoute quelques exemples d’utilisations de l’arduino.
Pouet !
@Spouet je comprends ta réticence vis à vis de cette manière de faire.
Pour m’expliquer un peu, ma philosophie vis-à-vis de ce code générique, c’est que l’utilisateur aie à mettre le moins possible les mais dans le cambouis pour préparer son installation Arduino. Il téléverse le code, il branche ses modules à l’Arduino, relie l’Arduino à Gladys, et paramètre le tout dans Gladys.
Pourrais-tu m’envoyer le code Arduino que tu utilises sur Gladys 3 ? Plus j’aurai de doc sur ce que tout le monde utilise, plus le code pourra correspondre aux attentes des utilisateurs.
Mais moi aussi je comprend bien ta philosophie qui est bien en accord avec la V4 de Gladys. Cependant mais ca n’est qu’un avis perso, mettre un arduino et diffrents conposant dessus c’est selon moi déjà mettre les mains dans le cambouis.
J’ai l’impression que pour ceux qui veulent vraiment faire au plus simple sur principalement de la RF il y a le RFlink qui est en train d’être implémenté.
Je t’envoie le code même si c’est un poil fait à l’arrache ^^ (comme tout bidouilleur qui se respecte )
Je rejoins @Spouet, qui dit arduino dit diy et donc avoir les mains dans le cambouis . Il y’a un juste milieu qui va être compliqué à trouver pour converger vers la philosophie de Gladys 4.
Le principal c’est que tout le monde s’y retrouve, les expert qui exploiteront l’api directement ou le mqtt, et les non expert qui utiliseront le service arduino.
Je suis plutôt d’accord avec @billona sur le fait qu’il faut proposer quelque chose de plus simple possible et avec le minimum de modification à faire dans le code arduino.
Pour moi, ce n’est même pas une histoire de DIY, c’est une histoire de simplicité, même pour le développeur, même pour celui qui sait faire, si c’est plus simple à mettre en place c’est mieux !
Ce qui n’empêche pas aux experts de modifier le code arduino et de faire du custom, qui peut le plus peut le moins: on garde une “API USB” ouverte à mon avis 
Pour information @billona, le module qu’on avait dans Gladys 3 et qui représente ce que beaucoup d’utilisateurs ont dans la v3, c’est celui là =>
Avec ce code arduino:
On se comprend pas 
C’est une histoire de DIY dan le sens où , l’utilisateur qui fait de l’arduino aime ça et il veut avoir les mains sales 
C’est pas 100% mais c’est quand même une sacré proportion je penses.
Et je me dit que le truc tout simple il va pas l’utiliser car ça l’intéresse pas.
J’essaye juste de constater pour pas passer du temps à faire une usine à gaz.
Je vous embête plus , ma vision est peut être biaisée car je ne serai probablement pas utilisateur du service
Je ne suis pas d’accord 
Beaucoup d’utilisateurs de la v3 on utilisé des arduino pour des raisons de coûts principalement, avaient suivi mes tutos à la lettre sans tout comprendre, et était bien content de n’avoir qu’un bout de code à téléverser sur l’Arduino !
Nice!
@billona Du coup pour l’instant le service Arduino gère quoi ? L’émission/réception en 433Mhz est fonctionnelle?
Actuellement rien du tout 
Pour l’instant je suis en train de construire le front.
Je suis en train de mettre en forme les devices, mais j’ai encore quelques soucis. Je n’arrive pas à faire ma requête POST API pour sauvegarder le device dans la DB.
Je sais que mon code contient des erreurs. Même si je m’améliore de plus en plus, je suis encore en phase d’apprentissage de Preact. Une fois que le front fonctionnera correctement, je m’occuperais du back. Dans un premier temps :
De plus, je me suis permis d’effectuer quelques petites modifications :
Si tu as des retours à faire concernant mon code n’hésite pas 
On pourrait discuter de ça? je pense qu’elle est là la vrai question !
Edit: En remontant j’ai trouvé ton post, désolé j’avais pas vu le message auparavant vu la vague de message ici, je le remets:
L’histoire du sous service je suis pas convaincu. Tu pourrais expliquer ici quelle est ton fonctionnement? Comment ça fonctionne pour l’utilisateur?
Et quelle est cette histoire de code?
La définition de l’API, c’est le plus important. Car une fois que l’API est définie, on ne pourra plus la modifier jusqu’à la prochaine version majeure de Gladys, car des utilisateurs dépendront de cette API. On veut être 100% sûr que cette API fait le boulot pour le long terme.
Mmm pourquoi tu ne peux pas stocker l’arduino sous la forme d’un device? un arduino = un device. Tu peux te servir du comPath comme identifier, et au démarrage aller chercher le/les arduino.
Pour l’instant, tu peux coder l’UI pour ne prendre en charge qu’un arduino pour l’instant si tu ne veux pas trop t’embêter et sortir une v0.1 assez vite, mais au niveau du stockage je verrais plus ça dans les device que dans les variables
Pour avoir trifouillé beaucoup les modules 433, j’utilisais ceux-là
salut. BOn en attendant que ça fonctionne…
Mon retour d’expérience:
Pour la partie SEND:
Il faut, en variable, le nombre de fois que le code doit être envoyé: parfois c’est trop prafois c’est pas assez. Exemple si j’envoi 4 fois le code 433, le code n’est pas reçu par mon device dans 100% des cas (cause brouillage momentané ou bruit de fond), si je mets 15 fois, mon alarme sonne 2 fois elle a le temps de lire 2 fois le code, c’est trop. Ca pourrait allumer et éteindre un device en un envoi.
RECIEVER:
Autre chose pour le reciever: parfois le code RF433 est mal récupéré. gladys inerprète le code envoyé par l’arduino et créé un device avec un code tout pourri. (genre “E53F”)
On peut limiter ça en coupant les suites trop courtes, ca évite le nombre de faux devices mais, pareil il faut garder la possibilité de prévoir un dialogue avec un code court. donc éventuellement à paramétrer dans le setup.
Autre proposition: tu peux passer l’arduino en mode apprentissage (un code = un device créé) puis tu le coupe (un code inconnu reçu ben ça fait rien).
Plus généralement, toutes les variables utilisées dans le code arduino pourraient être reportées dans le SETUP du module pour pouvoir tout customiser. Comme je te disais par téléphone, pour le gros newb comme moi qui veut pas passer 1000 ans à définir toutes les variables, une variable “pas conne” doit être mise par défaut. Voire même tu peux mettre un bouton “advanced” qui révèles les valeurs que d’habitude on ne trifouille pas pour l’utilisateur expérimenté.
Côté utilisateur je voyais quelque chose comme ça :
L’utilisateur choisit comment il veut que ce device fonctionne, lui fournit le data pin et le message. Ensuite, niveau code, on aurait ça :
Ca permet de stocker un paramètre dans la DB, qui correspondra en quelque sorte à la fonction qui sera appelée dans l’Arduino.
Exemple :
Pour moi je voyais quelques complications vis-à-vis de ça. Mais je crois qu’on s’embrouille légèrement sur nos définitions des devices alors voilà ce que j’avais en tête :
Un seul arduino relié en USB, son path et son modèle dans les variables. Ensuite, chaque device permettra d’effectuer une action sur cette carte.
Dans un premier temps je ne trouvais pas de manière simple de pouvoir gérer 2 arduinos dans la DB, mais au final si on fait un peu comme le module Serial de Gladys 3 alors ça peut marcher
Je regarde pour modifier ça alors. 
Pour moi le data pin ne se change pas à chaque fois. Dans le setup au branchement ça suffirait, comme le nombre de répétitions. Par contre, protocol, pulselength change selon le device.
Bon et bien après un peu de travail… Les Arduinos sont maintenant implémentés comme des devices
Voilà comment ça rend pour l’instant :
Bon pour l’instant l’UI est assez basique je l’admets 
Mais elle est fonctionnelle. J’ai l’intention d’améliorer le rendu une fois que tout fonctionnera comme je le souhaite.
Au niveau de la DB, ça donne ça :
@pierre-gilles pour m’expliquer un peu sur mon idée de départ, je me suis basé dans un premier temps sur le modèle de DB qui est disponible dans la documentation API. Or, ce modèle ne fait pas mention de la table t_device _param, cette même table dont se servent les caméras RTSP pour stocker les URL. J’ai donc modifié le tout pour que chaque propriété de l’Arduino (comPath, modèle), soit stockée à cette endroit.
Maintenant que les arduinos sont stockés sans difficultés (et surtout maintenant que j’ai réussi à me familiariser avec la création de devices par le front ), je vais regarder pour créer des d’autres « types » de devices. Pour moi, ces derniers seraient rattachés à un arduino, et contiendraient les fameuses propriétés évoquées plus tôt :
Je réfléchis donc à tout ça dans la journée, je mets ça au clair sur papier, et dès que tout ambiguïté est levé je m’attarde sur le dev
D’ailleurs @pierre-gilles je souhaitais te faire part d’une remarque que j’ai pu me faire : j’ai eu énormément de soucis lorsque j’ai créé l’action de suppression des devices. Or je me suis inspiré de l’action.js du service RTSP Caméra.
Le problème vient de la condition :
Dans RTSP Caméra, la condition est écrit comme ça :
if(device.created_at)
Or, en faisant des console.log, j’observe que la variable est
device.createdAt
Et juste à cause de ça, mes caméras ne disparaissent pas de ma DB lorsque je clique sur supprimer
Une orientation pour la structure de l’API: Ouvert ou fermé:
API fermée:
Le module Arduino n’exécute qu’un code .ino fait pour le module Gladys. Il est parfaitement abouti et n’a aucun bug.
Le problème si j’ai récupéré un code arduino sur une autre source, il ne peut pas être intégré.
API ouverte: un sous-service est une fonction, un copier coller de n’importe quel code arduino qui fonctionne. Il faut juste en argument récupérer ceux nécessaires au sous services.
{
“service”: “MyFunctionTrouveeSurInternet”,
“message”: {
“ARG1”: PinDeDonnee ,
“ARG2”: Le_code_à_envoyer
“ARG3”: “Je ne sais quel paramètre utile à la fonction”
… 5 Arguments seraient suffisants?
}
}
Dans le code .ino:
Void loop()
On serial event : Si “Service” = “MyFunctionTrouveeSurInternet” alors execute MyFunctionTrouveeSurInternet (ARG1, ARG2, ARG3…);
Copier/coller depuis internet
MyFunctionTrouveeSurInternet (int PinDeDonnee , Le_code_à_envoyer, etc…)
{ bla, bla, bla }
Mes autres sous services
SendRadioCode(PinDeDonnee, Le_code_à_envoyer, protocole, etc) {}
SendIRcode (){}
Fait comme ça, si le mec se plante et met “A” dans l’argument Pin, ça plante.
Enfin dans un tuto chacun peut faire “son” code arduino en remplaçant les arguments dans gladys.
@benPi à vrai dire tes 2 propositions ne sont pas incompatibles… D’une certaine manière.
Ce que j’avais en tête : un .ino fait pour le module Gladys, abouti et sans bug. Seulement, ce code serait composé justement de certaines fonctions, qui font elles-mêmes office de sous-service comme tu l’as décrit.
Par exemple dans un premier temps, le premier sous-service sera l’émission 433 MHz. Ensuite j’ajouterai le 433 MHz pour Chacon. Ensuite l’émission IR. Chacune de ses fonctionnalité aura sa fonction propre dans l’arduino, qui sera appelée dès lors d’une interaction avec le device.
Il faut y aller pas à pas tant qu’on est sur les bases.
D’autant plus que rien n’empêche ce fichier ino d’être évolutif. Une première version pourra sortir, puis, lorsque le besoin se fera sortir, on mettra à jour le service avec les nouvelles fonctionnalités, et on proposera une nouvelle version du code arduino.
