Gladys 4 - Développement du service Arduino

[billona]

Bonjour à tous

Afin de rendre compatible Gladys 4 avec mon installation (principalement constituée de 433 MHz), je suis en plein développement du service Arduino.

Page des intégrations :

Pages du service Arduino :

Pour l’instant l’interface est simple et pas encore fini, mais je suis en train d’y travailler. Il faut aussi que je m’occupe de la détection de cartes grâce au service usb déjà en place.

Si vous souhaitez voir l’avancement du code, il est disponible sur mon repo.

Je me tourne donc vers vous afin d’avoir vos avis sur ce qui est déjà fait, des conseils que vous pourriez me donner, ou toute autre discussion sur le sujet

[peb]

Salut !

C’est une excellente nouvelle pour ce début d’année !
Dans une premier temps, je te recommande de créer une PR sur le GitHub de Gladys, histoire que tout le monde soit au courant qu’un développement du service Arduino est en cours !

La question est : de quoi doit être capable ce service Arduino ? Pour moi, c’est un connecteur entre du hardware (les arduinos) et des services plus haut niveau (433 MHz…)
Ce qui permettrait de dire sur tel arduino, c’est tel service qui tourne. (à voir s’il est possible d’avoir n services sur un arduino ou uniquement 1).

Qu’en penses-tu ?

Dans tous les cas, tu peux me compter parmis les testers des services arduino/433Mhz

[billona]

Merci beaucoup pour ta réponse

@peb

Dans une premier temps, je te recommande de créer une PR sur le GitHub de Gladys

La PR est fait, on va pouvoir avancer

@peb

Pour moi, c’est un connecteur entre du hardware (les arduinos) et des services plus haut niveau (433 MHz…)

Je suis d’accord avec toi, mon idée est d’avoir 1 device par arduino, et pour chaque device des « sous-devices » représentant les services présents sur la carte.

@peb

à voir s’il est possible d’avoir n services sur un arduino ou uniquement 1

Pour moi oui, ce que je faisais avec Gladys 3, c’est que j’avais différents émetteurs/récepteurs reliés à mon arduino, et Gladys renvoyait un JSON à la carte avec le nom de la fonction à appeler dans la carte, et d’autres paramètres en fonction de ce qui était demandé.

Voilà ma carte avec Gladys 3. Comme tu peux le voir j’ai 2 lignes IR (pour un ruban LED et pour une télé), un émetteur et un récepteur 433 MHz.

Donc pour moi il est tout à fait possible d’avoir plusieurs services sur une seule carte, reste à voir ce qu’il y a de plus optimal

Que penses-tu de cette solution ?

@peb

Dans tous les cas, tu peux me compter parmis les testers des services arduino/433Mhz

Merci beaucoup, ça fait plaisir

[Tlse-vins]

Pour moi aussi,
J’utilise un arduino avec un émetteur 433 Mhz pour mon lève TV.

[peb]

@billona

Pour moi oui, ce que je faisais avec Gladys 3, c’est que j’avais différents émetteurs/récepteurs reliés à mon arduino, et Gladys renvoyait un JSON à la carte avec le nom de la fonction à appeler dans la carte, et d’autres paramètres en fonction de ce qui était demandé.

Bonne idée les messages JSON ! Il faudrait alors standardiser l’échange des messages et définir le niveau d’abstraction de l’Arduino.

On pourrait avoir un message type :

{
 "service": "arduino-433-mhz",
 "message": {
   "value": "xxxx",
   "bbbb": "yyyy"
 }
}

Quelques questions en vrac que je me pose sur la création du service :

Pour la configuration et l’utilisation Gladys 4 doit être le plus plug and play possible. Via l’IHM Web, on peut identifier les Arduino connectés, et ensuite comment ça se passe coté code ?

Est-ce que l’Arduino contient déjà le code, et dans ce cas Gladys via un échange de messages, identifie quels services sont utilisés pour cet Arduino ?

Faut-il préciser les services à la main ? Est-ce Gladys doit être capable de téléverser le code dans l’Arduino ? Comment coder les modules pour qu’ils soient le plus facilement cumulable dans un même Arduino ?

Idéalement, chaque sous module, aurait une phase de configuration, et une phase de fonctionnement standard.
Dans la phase de configuration, on pourrait préciser les pins nécessaires (le In et l’Out pour le 433 MHz) comme ça, pas de module qui se chevauchent sur les pins.

Voilà voilà quelques idées et questionnements en vrac

[pierre-gilles]

Génial @billona merci pour ton message et ton développement, ça va faire plaisir à un paquet de monde

Pour la partie serialport/connexion USB, tu peux te baser sur le travail qui est déjà fais avec le service “usb” de Gladys 4. Toutes les connexions passeront par là, et les routes pour lister les ports USB existent déjà.

L’objectif est effectivement d’avoir un service le plus simple à utiliser possible. L’utilisateur plug son arduino, il le voie dans Gladys, et hop en 1 click l’utilisateur l’ajoute à Gladys et ça marche.

Effectivement il va falloir standardiser le format de messages envoyé de Gladys à l’arduino et vice-versa. Pour moi ce format de message pourrait même être le même que celui de l’API MQTT.

Au fond, un Arduino c’est comme un service distant. Je parlais de l’architecture “Gladys core/Gladys Pod” dans le manifeste de Gladys 4, un arduino on peut le considérer comme un Pod qui remonte des informations et retourne des informations à Gladys.

Cf => A privacy-first, open-source home assistant | Gladys Assistant

[Spouet]

Hey Hey !
Très bonne nouvelle !
En fait je vais finir ma mission cette semaine et donc je m’étais dit que ça serait peut-etre l’occasion justement de m’y atteler à ce service. Mais je suis bien content que tu t’y colle vu que je ne maitrise que le c.
De mon coté ce service c’est le principal de mon installation Gladys. Arduino+433, sans ça je n’ai aucun actionneur.
Et donc sur mon arduino j’ai :
Émetteur/récepteur 433MHz
Un capteur de température/humidité DHT 22
Un capteur de qualité de l’air
un module HC-11 dont j’ai branché la contre partie sur mon Roomba

Je gère donc toutes mes prises 433 mais aussi et surtout j’envoie “grâce au” JSON toutes mes informations de mes diverses sondes de température/humidité, info du Roomba etc…
Bref comme je le dis sans ce service mon installation ne me sert à rien c’est d’ailleurs pour ça que je n’ai pas encore testé Gladys 4.

Bref (ouais ouais encore ) si jamais tu as besoin d’aide je pourrais peut-être aider.

[JPL]

Excellent : je trouve que ce début est prometteur, moi aussi je suis en attente du développement des 433 Mhz. Si je comprends bien, la reconnaissance de l’arduino (dans mon cas un nano) sera automatisée ? Je devrais donc pouvoir brancher ma boite avec émetteur récepteur et elle sera reconnue ? Puis indiquer ensuite les codes à générer sur les devices que je devrai créer ? (éclairage salon par exemple) Je dis peut être des bêtises, étant novices à ce niveau, mais ce serait sympa comme fonctionnement
Tu penses pouvoir sortir un test à valider prochainement (mais non je ne suis pas impatient…)
Merci et à suivre donc

[Spouet]

Bonjour,
@billona as tu eu le temps d’avancer sur le sujet ?
Pouet !

[pierre-gilles]

@CamilleB C’est l’objectif, développer une API Arduino unifiée de la même manière que le MQTT.

Il faut écrire des spécifications avant de se lancer dans le développement.

A voir si il n’y a pas même des standard qui existent déjà niveau communication série?

Ce sera un service comme un autre, à activer au besoin de chaque utilisateur

@CamilleB

je suis donc super motivé pour vous aider si mes idées vous conviennent pour réaliser des tutos sur les arduinos et tester les interfaces avec Gladys.

Top N’hésite pas à faire des tutos sur ce que tu as déjà intégré dans Gladys (MQTT, caméra), le service arduino-USB n’est pas encore commencé il me semble…

[camille]

Bonjour, je reprends mon compte officiel @camille, le compte @CamilleB
va être mis en sommeil maintenant.

@pierre-gilles Il faut écrire des spécifications avant de se lancer dans le développement.

Je ne sais pas de quoi il s’agit mais si tu as des exemples et le formalisme attendu, je peux essayer de faire avancer ce point.

@pierre-gilles A voir si il n’y a pas même des standards qui existent déjà niveau communication série?

Voici ce que je connais des com séries …, si d’autres personnes veulent corriger ou enrichir c’est avec plaisir que j’attends vos retours …

Parmi les communications “série” les plus utilisées par l’arduino mais aussi dans l’industrie, on peut citer le fameux protocole RS232 (années 60) qui a été et est toujours en électronique un protocole simple à utiliser et répandu, l’I²C (années 80) et son petit frère le 1-wire sont également pas mal utilisés en électronique pour adresser des périphériques (mémoire, convertisseurs A/N, N/A, expanseurs de bus …, SPI ( années 80) utilisé comme l’I²C en électronique pour l’échange de données avec des périphériques, le LIN et CAN pour l’automobile et l’industrie (pas trop adapté à notre besoin selon moi) et l’USB (années 90) que l’on ne présente plus et qui est maintenant un standard informatique.

Quelques exemples :

• les capteurs de température/humidité DHT11 et DHT22, les modules 433 Mhz utilisent le 1-wire
• le module RFID RC522, le shield W5100 ethernet et son lecteur de carte SD utilisent le SPI
• le gyroscope et accéléromètre GY-521, l’horloge temps réel DS3231, le baromètre MPL3115A2 utilisent l’I²C
• la communication/programmation avec les arduinos utilisent la liaison RS232 par le biais d’un UART USB

C’est cette dernière liaison qui est utilisée pour communiquer entre Gladys et l’arduino lorsqu’il est connecté en USB.
Les autres protocoles étant utilisés par les capteurs/périphériques gérés par l’arduino.

Comme standard série je ne connais que celui du monde industriel, le modbus et ses petits frères profibus, Jbus.
Le principe est simple, un maître (gladys) interroge ou commande des esclaves (arduinos).
les messages sont composés de la trame pour le maître : [adresse de l’esclave], [code de la fonction demandée], [données] ,[CRC] et pour l’esclave de la trame de réponse si nécessaire : [adresse de l’esclave], [code de la fonction demandée], [données] ,[CRC].

Le code fonction et le CRC répondent à une norme.

Il existe des bibliothèques qui gèrent le modbus pour les arduinos.

néanmoins, il faut programmer une maître modbus de Gladys, je ne sais pas si cela est facile à faire et surtout souhaitable ???

Mon avis :

1. Cela me parait beaucoup de travail pour quelque chose qui risque d’être à la fin compliqué à utiliser par un utilisateur lenda.
   néanmoins je suis dispo pour échanger sur le sujet et voir si quelqu’un d’autre à des idées de standards séries existants à proposer ou si vous pensez que le modbus serait une bonne idée.

2. Je reste bloqué sur la simplicité des topics utilisés par le MQTT. si nous réutilisons les même idées, il suffirait de diffuser/recevoir les topics avec les données.

Côté Gladys, il existe déjà quelque chose et idem côté arduino.

l’onglet “setup” pourrait ressembler à cela avec une détection auto des arduinos que tu connectes

Qu’en à l’onglet “device”, il n’y aurait pas grand chose à changer (garder la même structure que la mqtt)

pareil dites moi si je délire ou si c’est une bonne idée.

3. Dernier point, j’ai développé pour un de mes anciens boulots un projet dans lequel il y avait nécessité de faire communiquer plusieurs modules esclaves avec des flux de données relativement faible. J’avais utilisé le support RS232 et j’avais tout bêtement utlisé la philosophie du modbus mais en beaucoup plus simple. C’est à dire que je diffusais des trames avec un identifiant pour chaque esclave, les commandes et interrogations et ensuite chaque esclave me répondait.
   Il n’y avait pas de CRC parce que pas nécessaire et cela était très simple (la preuve j’ai pu le faire )
   Donc pour finir, une autre solution pourrait être de développer notre propre standard, qu’en pensez vous ?

@pierre-gilles Top N’hésite pas à faire des tutos sur ce que tu as déjà intégré dans Gladys (MQTT, caméra)

Je regarde ce qui existe déjà et je me lance …

[pierre-gilles]

@camille Oula tu es parti loin dans l’analyse

Quand je parlais de spécification d’API, la seule chose à définir est le format des messages, la communication série est déjà géré, c’est de l’USB ça fonctionne tout seul.

Exemple dans Gladys 3: dès qu’une nouvelle valeur de capteur est reçue

Si tu avais un capteur de température d’id = 1 (les id étaient entier dans Gladys 3), et que la température est de 20°C, alors l’arduino allait envoyer par USB la valeur suivante:

{ 
  "devicetype": 1,
  "value": 20
} 

Tout simplement

Le choix du JSON est questionnable. On pourrait adopter un autre format si il y a des standard plus simple et moins lourd pour un arduino.

@Terdious toi qui est expert arduino, la lib ArduinoJson c’est lourd à utiliser? il y a des alternatives, voir des standards? (Après, d’après le GitHub d’ArduinoJson, ça a l’air béton et léger!)

Si on reste sur du JSON, sur Gladys 4, on pourrait imaginer un format du style:

{
   "message_type": "device.new-state",
   "device_feature": "temperature-salon",
   "value": 20
} 

C’est ça qu’il faut définir pour chaque cas d’usage, le format de message !

[billona]

Bonjour,

Ayant eu beaucoup de travail ces dernières semaines je n’ai pas pu trouver le temps de me tourner vers le développement du service. Maintenant que je suis en télétravail, je vais pouvoir me pencher à nouveau sur le code.

Effectivement on avait parlé avec @peb des formats de messages. Il nous faudrait lister les différentes possibilités (433 MHz, IR, écran…). L’idée serait de pouvoir générer l’interface en fonction du matériel de l’utilisateur.

Par exemple : Si l’utilisateur veut un émetteur 433 MHz, un champ apparait pour qu’il saisisse le numéro du pin DATA. Ainsi, le système serait éventuellement capable de générer un code Arduino adapté à l’utilisateur et à sa configuration.

Et par la suite, plus qu’à configurer les devices de manière classique. Qu’en pensez-vous ?

D’ailleurs, une idée de feature pourrait aussi être d’utiliser de l’Arduino en wifi (ESP8266 ?) pour pouvoir piloter du matériel à distance.

[camille]

Bonjour,

Super si tu peux de nouveau faire avancer le sujet, si tu as besoin d’un testeur, fais moi signe.

Concernant ton exemple,

@billona Par exemple : Si l’utilisateur veut un émetteur 433 MHz, un champ apparait pour qu’il saisisse le numéro du pin DATA. Ainsi, le système serait éventuellement capable de générer un code Arduino adapté à l’utilisateur et à sa configuration.

je trouve cela intéressant que l’on puisse générer un code arduino générique (ça va dans le sens qu’un maximum de personne puisse utiliser GLADYS et ses périphériques sans avoir de connaissances pointues). Par contre là ou je vois une limite ou plutôt une complexité c’est d’appliquer cela à un grand nombre de périphériques différents et également aux différents arduinos.

Mais je trouve néanmoins cette idée très intéressante, si on prend par exemple l’arduino UNO, il faudrait dans ce cas essayer de créer un standard de mapping avec des pins qui seraient pré allouées à des fonctions et les autres dispos aux grès des besoins de chacun.

par exemple : les pins D10, D11, D12 et D13 seraient réservées uniquement pour SPI, les A4 et A5 pour I²C, D1 et D2 pour USB.

Qu’en penses tu ? Cela reflète ton idée ?

[VonOx]

@billona je penses que la gestion des esp c’est intéressant avec le service mqtt.

@camille je sais pas si tu connais platformio pour vscode. Il te permet de faire du code générique peut importe le type de carte. Il gère le mapping en fonction de la carte que tu branche.

[camille]

Bonjour @VonOx, merci pour tes infos, je ne connaissais pas Platformio, ça à l’air très sympa comme IDE, le debug me manquait en effet sur arduino IDE, l’aide sur les fonctions et la compilation en continu est appréciable. bref un vrai IDE.
Même si arduino IDE est en train de développer un debug arduino qui est pour l’instant en phase proto …

Par contre pour revenir au mapping et au code générique, je ne vois pas trop où cela se trouve dans l’IDE Platformio (j’ai juste installé et fait mumuse avec pendant quelques heures hier soir, je vais continuer par contre si tu as des infos dessus, cela me ferait gagner du temps).
Mais le problème reste entier selon moi pour Gladys, car si l’on donne la possibilité à l’utilisateur de choisir des pins pour affecter ses périphériques sans le restreindre, il risque d’avoir des effets de bords.
Qu’en penses tu ?

[billona]

Bonjour,

Suite à une nuit agitée en réflexion (et en café ) j’ai pu avancer sur le dev. Je fais donc ce petit message pour décrire tous les points qui me sont venus à l’esprit, j’aimerais avoir votre opinion sur l’avancement de ce service.

1. Comment le front se présente-t-il ?

J’ai imaginé 2 pages :

• Setup

Sur cette page, on aura le listing des ports USB, et on pourra indiquer sur quel port une carte est connectée pour pouvoir l’enregistrer, et la faire passer dans la page des devices.

• Device

Chaque device correspondra à une carte. Chaque carte sera munie de « sous-devices », qui représenteront l’équipement relié à la carte (433MHz, IR, …)

2. Le code Arduino

J’y ai réfléchis longtemps car c’est un point à ne pas négliger. Il faudra bien que chaque utilisateur aie LE bon code Arduino. C’est pourquoi j’ai pensé à un code « universel » propre au service. Ainsi, plus on considérera d’équipements, plus le code sera important. La spécificité est que chaque équipement aura son « sous-service », et que ce sous-service fera appel à un seul bout de code, ce qui allège la charge de la carte.

3. La standardisation des JSON à envoyer à la carte

Pour communiquer, il faut absolument un standard. Il sera donc le suivant :

{
    "service": "le service du sous-device",
    "message": {
        "DATA_PIN": "le pin de données",
        "code": "Le code à envoyer"
    }
} 

Pour le moment, je me concentrerai essentiellement sur les modules « d’émission », car ce sont les plus simples à mon sens pour un début de résultat.

4. L’état du dev actuellement

Je suis bien sûr toujours en train de développer, mais mon code est toujours dispo ici, si quelqu’un veut bien me donner sa critique

@camille

par exemple : les pins D10, D11, D12 et D13 seraient réservées uniquement pour SPI, les A4 et A5 pour I²C, D1 et D2 pour USB.

Qu’en penses tu ? Cela reflète ton idée ?

A vrai dire j’avais plus justement dans l’idée de demander directement à l’utilisateur le type de sa carte, et les pins en question, pour générer le code en fonction de ça. Mais je pense que la question ne se pose plus si tout est ok pour partir sur un code universel.

Merci d’avance pour vos retours

[camille]

@billona

je vais regarder le code et je te fais un retour.

Je suis 100% d’accord pour l’idée du code universel qui permet de gérer l’interface avec Gladys, c’est selon moi la meilleure des solutions.

Pour ton idée de demander le type de carte arduino, c’est une bonne idée, je pense que ce serait dans la fenêtre “device” ?
si j’ai bien compris, on choisirait dans cet onglet, le type d’équipement relié (433 MHz, …) et le type d’arduino ?

Dans ce cas, les pin relatives aux com seront automatiquement réservées par le système

Pour la vue arduino Settings, je pense également que c’est la bonne solution de pouvoir choisir via le port USB, par contre lorsque l’on connecte un arduino au raspi, est ce qu’il y a une indication particulière qui différencie le port usb des autres ? ou dit autrement si j’e connecte un arduino et un autre périphérique, y a t il quelque chose qui permette de ne pas se tromper et de bien choisir l’usb de l’arduino ?

Merci encore pour ton travail,

[billona]

@camille

Pour ton idée de demander le type de carte arduino, c’est une bonne idée, je pense que ce serait dans la fenêtre “device” ?
si j’ai bien compris, on choisirait dans cet onglet, le type d’équipement relié (433 MHz, …) et le type d’arduino ?

Oui j’avais quelque chose comme ça en tête, à voir comment l’organiser.

@camille

Dans ce cas, les pin relatives aux com seront automatiquement réservées par le système

Là je dirais de faire attention avec le terme « automatiquement ». Mon idée de départ est de laisser le choix à l’utilisateur. Il câble son équipement de la manière qu’il veut. Par exemple, il peut choisir de mettre le pin data du 433 sur le pin 12… Ou 13, c’est à lui de voir.

Dans tous les cas de cette façon, après qu’il aie fait son choix et connecté son Arduino, à chaque fois qu’il rajoute un équipement, on lui demande de rentrer le pin qu’il a choisi. Ainsi, quand la fonction du code Arduino sera appelé, on lui donnera en paramètre le signal à envoyer, mais aussi le pin sur lequel envoyer. Ce qui globalise un peu le code

@camille

Pour la vue arduino Settings, je pense également que c’est la bonne solution de pouvoir choisir via le port USB, par contre lorsque l’on connecte un arduino au raspi, est ce qu’il y a une indication particulière qui différencie le port usb des autres ? ou dit autrement si j’e connecte un arduino et un autre périphérique, y a t il quelque chose qui permette de ne pas se tromper et de bien choisir l’usb de l’arduino ?

Actuellement non. Pour faire le listing des ports USB, je passe directement par le service USB, et celui-ci pour l’instant ne fournit qu’une information : comPath. Pour l’instant, je fais ça manuellement : je rafraichis la liste et je regarde le port qui s’ajoute lorsque je connecte mon Arduino.

Après, j’ai fait le choix de me dire qu’il n’y aura qu’un Arduino connecté au raspi. De cette manière, je peux stocker sans ambiguïté le path USB de la carte dans la table t_variables de la DB. Après, on peut toujours réfléchir sur le fait d’en rajouter en wifi comme expliqué précédemment, mais pour un point de départ je trouvais ça plus simple de faire comme ça. Qu’en penses-tu ?

En tout cas merci de ton soutien ! J’ai très hâte d’avoir une première version fonctionnelle

[Reno]

Bonjour,

J’ai vu passer vos différents échanges sur ce fil et cela m’a interrogé sur le besoin d’utiliser un Arduino alors que la Raspberry Pi est capable de gérer elle-même tous ces périphériques.

Du coup, je me dis que j’ai dû rater un truc. Pourriez-vous m’en dire plus ?

Une de mes idées (pour plus tard, quand j’aurai le temps), serait de créer un service python un peu générique qui permettrait d’adresser les entrées-sorties de la Raspberry et de communiquer avec Gladys via MQTT.
J’ai l’impression que ça rejoint un peu ce que vous êtes déjà en train de faire, non ?