Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - DDEFF

Pages: [1] 2 3 ... 50
1
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 27, 2024, 08:32:06 am »
@Pierre,

Ma recherche d'itinéraires marche. ;D

Je n'ai plus besoin de "polluer" la partie "zones" du JSON avec des zones suivantes et côté suivant.
Je reviens donc à la partie "zones" originale.

En revanche, pour les itinéraires, je crée une partie "connecteurs" indépendante.

Donc, en indiquant (manuellement) dans les appareils de voie des vitesses à voie déviée, en ayant défini les zones de gare et de manœuvre, je peux CALCULER les cibles des signaux pour C, S, A, VL, R30, RR30, R60, RR60, Cv au sol.

Je remplirai donc la partie "signaux", "aiguilles" et "itinéraires" (uniquement pour les gares)

J'ai encore besoin d'un peu de temps pour faire tout ça, mais je vois le bout du tunnel.

Denis

2
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 26, 2024, 09:24:43 am »
Bonjour,

Moi, je veux bien qu'on ait ce genre de discussion, mais je pense qu'on a perdu tout le monde.

La signalisation SNCF est très complexe, elle permet de résoudre tous les cas, c'est vrai. Mais, là, je pense qu'on va trop loin dans le détail.

Je vais bientôt fêter l'anniversaire des 50 ans que je lis Loco-Revue. J'ai tous les numéros depuis le numéro 338, en 1974. Je lis aussi d'autres revues, y compris étrangères.
Eh bien, on ne voit quasiment jamais de signalisation sur les réseaux. Et le peu qu'on voit, c'est de la décoration, la signalisation n'est pas fonctionnelle.
Il y a de magnifiques contre-exemples (Soumagnac, Luzy, …), mais ils sont rares.
La plupart des gens utilisent le DCC, justement pour pouvoir arrêter un train sans avoir à gérer cette signalisation.
DRIM3D a fermé, faute de débouchés. Ils faisaient pourtant de magnifiques signaux.

Donc, il faut que les gens ne craignent plus d'avoir une signalisation fonctionnelle.
Mais il faut qu'on les aide et qu'UN PROGRAMME leur dise quel signal il faut mettre et où.
C’est-à-dire utiliser des règles simples, poser des questions dans un langage accessible pour qu'on puisse avoir une signalisation la plus complète possible sans connaissances pointues de la SNCF. Les situations rencontrées sur un réseau sont nettement plus simples.

Concernant la zone de manœuvre, je n'ai jamais vu sur un réseau de modéliste qui ait un signal blanc ou violet sur un mat dans la direction de la zone.
C'est déjà un grand pas si on a le signal au sol.

Pour moi, si les aiguilles sont tournées vers la zone de manœuvre, on tient compte du signal bas, sinon, on n'en tient pas compte.
Il y a des Cv en sortie de zone, la vitesse en zone de manœuvre est limitée à 15 km/h et on considère le panneau LM comme non franchissable.
L'itinéraire qui sort de la zone de manœuvre a un "carré virtuel" à l'emplacement du panneau LM et il s'arrête donc à ce point.

Denis

3
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 09:57:08 pm »
Merci Marcel,

Il est clair que tu aimes les trains américains : ton TCO est vraiment typique des USA.
On s'éloigne un peu du sujet, mais on pourra y revenir un peu plus tard.

Denis

4
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 05:21:49 pm »
@trimarco232

La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.

Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.

Denis

5
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 10:04:03 am »
Waouhh !
Voilà une gare comme je les aime : commandée de façon "géographique", avec quelques itinéraires compatibles.

J'en suis à refaire marcher mes itinéraires dans le nouveau contexte. Chaque chose en son temps. Mais je testerai ta gare, c'est sûr.
C'est une gare terminus, apparemment ?

Denis

6
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 21, 2024, 08:32:30 am »
@trimarco232,

Quand on me pose une telle question, c'est un réflexe : peux-tu donner le plan de ta gare ?

Bon, quand le programme calcule les itinéraires, il fournit évidemment la liste des zones concernées et la position des aiguilles.
La mettre sous forme d'un tableau est tout à fait envisageable, ça n'est pas le plus dur, et de loin.

Cela dit, il va bien falloir rentrer toutes les zones dans mon programme : c'est un peu fastidieux aussi  :)
Pour information, rentrer le Locoduinodrome 2 me prenait 4 minutes (je l'ai fait plein de fois, pour le développement)
Pour la gare de Dominique, ça m'a pris un peu moins d'une heure.
L'intérêt d'un programme, c'est d'automatiser certaines choses et, surtout, de vérifier les incohérences.

Denis

7
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 20, 2024, 05:41:12 pm »
Merci Etienne,

Je reconnais que l'idée du tiroir virtuel me plait, en particulier pour gérer le feu nain et la vitesse à 15 km/h maxi pendant toute la manœuvre.

Je n'en suis pas encore là. Je cherche à calculer les itinéraires car il est hors de question d'en donner la liste à la main.
Je sais le faire dans mon gestionnaire, mais, là, il faut que j'adapte.

Denis

8
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 19, 2024, 05:16:38 pm »
Bonjour,

Voici la version 5 de mon éditeur JSON.
De nombreux changements et l'occasion de faire le point, après 25 pages sur ce fil…

Pourquoi un éditeur JSON ?

Le but de ce programme est de simplifier au maximum la saisie d'informations, d'en vérifier la cohérence et d'automatiser tout ce qui peut l'être.

Le fichier important, c'est le fichier JSON puisqu'il fait le lien avec un futur gestionnaire de réseau.
On doit avoir la séquence suivante :
Editeur JSON --> fichier JSON --> gestionnaire de réseau.

Il est tout à fait possible que d'autres réalisent un éditeur JSON, à condition que le résultat soit un fichier identique, quel que soit l'éditeur. En particulier, mon éditeur graphique (en cours de développement) devra fournir un fichier JSON.
De la même manière, tous les gestionnaires de réseau devraient être compatibles JSON.
On évitera ainsi à celui qui veut faire un gestionnaire toute cette phase rébarbative concernant l'entrée des infos du réseau.

Remarque 1 :
Comme l'éditeur et le gestionnaire ne sont pas complets, la version que je vais présenter est encore susceptible d'évolutions.

Remarque 2 :
Ce programme qui décrit un réseau est sensé ne servir qu'une fois… ;D

Un deuxième fichier est généré par le programme, le fichier "Zones". C'est juste en phase de développement, je pense qu'il n'a pas d'avenir. C'est juste un "fourre-tout" qui permet de conserver des infos pendant le déroulement du programme.

Signalisation :

La signalisation SNCF, même réduite aux cas les plus fréquents, reste une partie complexe puisqu'une fois compris le cas de la pleine voie, on doit tenir compte de la position des aiguilles , des vitesses sur les appareils de voie et même de la longueur des zones pour prévenir que le canton suivant est plus court que d'habitude et qu'il faudra en tenir compte pour freiner.
Il s'ensuit que pour calculer tout ce que peut afficher un signal, il faut d'abord avoir défini les itinéraires possibles.

J'en suis donc actuellement à cette étape dans laquelle je vais pouvoir "récupérer" ce que j'avais fait pour mon gestionnaire.

Itinéraires :

En phase de développement, donc, et je propose de n'indiquer dans le JSON que les itinéraires des gares. C'est d'ailleurs pour ça que j'ai passé du temps à définir quelles zones sont des zones de gare. Idem pour les zones de manœuvre.

Les itinéraires vont aussi servir dans le gestionnaire, évidemment, mais avec une contrainte de temps, ce qui n'est pas le cas ici.

Il y a deux fonctions chronophages dans la gestion des itinéraires :
1°) quelle est la zone suivante ?
2°) par quel côté j'aborde la zone suivante ?

J'ai décidé de répondre à ces questions directement dans le JSON.
J'ai adapté mon programme pour qu'on ait un traitement unique de tous les éléments de voie.

De la "même" façon que la Marine a pris la règle de "tribord, bâbord" pour qu'il n'y ait pas d'ambiguïté entre la gauche et la droite sur un bateau, la SNCF parle de "pair" et "impair", ce qui permet de gérer "gauche, droite, haut, bas, …" dans les dessins et le sens de circulation.

Pour indiquer les voisins, les "côtés" d'une zone, j'utilise des règles suivantes :

Cas des segments :

Je décrète que l'on parcoure l'octogone au départ (qui permet de définir l'orientation du segment à afficher) dans le sens des aiguilles d'une montre quand on est dans le sens "pair". Et, par conséquent, on est dans le sens impair dans l'autre sens.
Dans les dessins, comme il y a des lettres (A, B), on parcoure toujours un segment en allant de A vers B, de l'origine à l'extrémité.
Quand il n'y a un signal qu'à un bout, il est toujours du côté extrémité, c’est-à-dire B. Dans les boucles, on préfèrera les chiffres : on va de 0 à 1, mais ça, ça n'apparait pas sur le dessin.
Par ailleurs, l'origine est toujours du côté "voisin1" "côté0" du segment et l'extrémité est toujours du côté "voisin2" "cote1" du segment.

Cas des appareils de voie :

Il y a 2 types d'appareils de voie :

1°) ceux où il y a une extrémité commune à tous les trajets :
On part toujours de A, l'extrémité commune, et on va vers B, C, D.
A est côté "voisin1" "cote0" de l'appareil.
B, C et D sont, respectivement côté "voisin2", "cote1", "cote2" et "cote3"

2°) ceux qui sont des traversées (croisement, TJD, TJS)
A est côté "voisin1" "cote0",
B est côté "voisin2" "cote1",
C est côté "voisin1" "cote2",
D est côté "voisin2" "cote3".

L'intérêt de cette notation est que quand on rentre dans une zone du côté "voisin1", on en ressort du côté "voisin2". Et réciproquement. Et on peut facilement tester toutes les extrémités en allant de 0 à 4.
Pour être précis, de 0 à "zone.nb_voisins" :
3 pour les aiguilles et les enroulés,
4 pour les croisements, TJD, TJS et triples.

Exemple pour la zone 15 du plan de Dominique :

Je vous conseille d'imprimer le fichier "Z26 et ses voisins" pour mieux suivre.
 
Z26 est impair car Z25 est impair
vois1 est le voisin du côté A du triple. Donc, le vois1 est Z25.
Et, vu de Z25, Z26 est du côté B du segment. Donc vois2, côté 1.
C'est plus compliqué pour vois2 puisque ça dépend de la position des lames :
Côté B, le voisin est Z27, si a0 est à gauche et a1 est à droite
Et, vu de Z27, Z26 est du côté A du segment, soit vois1 côté 0.
Côté C, le voisin est Z15, si a0 est à droite.
Et, vu de Z15, Z26 est côté A de la TJD, soit vois1 côté 0.
Côté D, le voisin est Z44, si a0 est à gauche et a1 à gauche.
Et, vu de Z44, Z26 est du côté C de l'aiguille, soit vois2 cote 2.

Pour la suite, les itinéraires n'étant pas faits, les signaux ne sont pas remplis.

A suivre.
Denis

9
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 09, 2024, 10:40:27 am »
Bonjour à tous,

J'ai avancé sur mon programme d'éditeur de JSON.
Construire un JSON "à la main" est tout à fait faisable, mais il faut bien maîtriser les subtilités de la SNCF et il faut décrire énormément de choses, ce qui est pénible et source d'erreurs.
Grâce à un programme qui automatise un peu les choses, on peut regarder les anomalies, les corriger et minimiser les saisies.

Dans mes premiers jets, les saisies étaient, à mon avis, lourdes.
Quant aux modifications, elles étaient  impossibles : on efface et on réécrit les données de la zone. C'est toujours le cas en ce moment, mais j'ai des pistes prometteuses concernant les modifications. Je verrais bientôt.

La signalisation :

Je m'intéresse à la signalisation depuis des dizaines d'années.
Aussi, automatiser une signalisation pour un réseau est un vrai challenge.
Disons-le tout de suite : on ne peut pas tout automatiser. Il faut quand même donner un minimum d'informations simples qu'un programme ne peut pas deviner tout seul.
Tout le problème consiste à rentrer vraiment très peu d'informations.
A noter que très peu de réseaux ont une signalisation et encore moins une signalisation fonctionnelle. C'est malheureux.
Mais on a aussi des réseaux qui font circuler des locos électriques sans caténaire… ::)

Quelle signalisation ?

Suivant la période et la région concernée, il y a DES signalisations.
Chaque compagnie (avant la SNCF) avait sa signalisation, au départ mécanique puis lumineuse.
En 1936, on passe progressivement au code Verlant.
La création de la SNCF en 1938 entérine cette signalisation.
Je me limiterai donc à la signalisation lumineuse, postérieure à 1936 et antérieure au TGV qui a, lui aussi une signalisation tout à fait spécifique.

En fait, je procède par étapes :
 
Etape 1 : Le Locoduinodrome, même dans sa  version 2, est trop simple.
Je suis passé à un réseau que je connais bien et pour lequel j'ai un plan des zones, avec une signalisation complète, qui plus est, validée par Pierre il y a quelques années : le réseau de Dominique.
C'est d'ailleurs en rentrant toutes les zones dans mon programme que je me suis aperçu de la lourdeur de mon processus initial.
Par exemple, même si, à terme, on a besoin des limites de vitesse de chaque zone, ce n'est pas la peine de les rentrer dès le début. Ce sera donc dans un deuxième temps, en "complément" qu'on rentrera ces infos. Sans compter les incohérences possibles dans la saisie des vitesses.

Etape 2 : Décrire quasi automatiquement ce qu'est une gare et une zone de manœuvres.
C'est absolument nécessaire car il y a dans les gares et le zones de manœuvres une signalisation spécifique. J'en suis à cette étape

Etape 3 : En fait, on ne peut pas trouver quel signal est nécessaire si on n'a pas d'itinéraires.
Et, si on veut trouver les itinéraires dans une gare, il faut définir quels sont les zones qui la composent, avec les zones d'approche et de sortie, bien sûr. Dans un premier temps, on limitera les itinéraires aux gares.

Donc, voici ma démarche globale :

1°) Rentrer toutes les zones d'un réseau (nom des zones et des voisins)
     Dans les segments, donner la position des signaux, ce qui donnera la parité des segments.
     Dans les appareils de voie, pas de signaux et, je pense, pas de parité à rentrer.
          -> Pour les traversées (croisements, TJS et TJD), on met la parité à "pairimpair"
          -> Pour les autres aiguilles, la parité de l'appareil de voie est la parité de son unique point commun avec un segment dont on connait la parité.
Il faudra peut-être pousser un peu plus loin le raisonnement pour la parité des appareils de voie.

2°) Définir comme "gare" quelques zones pour calculer la gare entière.

3°) Définir comme "manœuvres" une zone pour calculer la zone de manœuvres entière.

4°) Trouver tous les itinéraires de chaque gare.

5°) Rentrer les infos complémentaires de vitesse des segments de la gare, ce qui donnera les vitesses des appareils de voie, branche par branche, en évitant les erreurs et les incohérences.
En déduire la signalisation correspondante.

Démarche pour définir une gare (voir le fichier gare) :

J'ouvre une ArrayList : "zones_gare" qui va collecter toutes les zones d'une seule gare, au fur et à mesure que le programme parcourt toutes les zones.

Une fois les zones rentrées, je déclare Z3 "gare", ce qui met "g0" dans le champ "gare" de la zone Z3.
Puis la recherche systématique commence. Elle est détaillée dans le fichier joint.

En ayant rentré une seule zone, on a décrit toute la gare.

Evidemment, cet exemple est très simple.
Il est basé sur le principe suivant : dans une gare, il n'y a jamais deux segments voisins.

Dans cette gare, il permet, à la fois, d'exclure Z0 et Z7 de la gare et de déclarer Z1 zone d'approche et Z6 zone de sortie.

Dans la gare de Dominique, ce seul principe ne suffit pas. Ça serait trop beau ! :P

Il y a 2 gares : g0 au sud et g1 au nord.
On doit rentrer un segment dans g0 : j'ai choisi Z27
On doit rentrer 2 segments dans g1 (un pour le haut de la gare, un pour le bas car il n'y a pas de communication entre le haut et le bas de la gare g1) : j'ai choisi Z4 et Z22.
On n'a pas à s'occuper de la partie droite du schéma car on y trouve 2 segments consécutifs.
Z11 est une zone d'approche de g0, mais pas Z30
Z34 est une zone d'approche de g1, mais pas Z7
Pour la partie gauche, on ne peut pas utiliser le principe puisqu'il n'y a qu'une zone entre les deux gares et on aboutirait à une seule et unique gare.
Il faut donc préciser "à la main" les informations :
Z25 est la zone d'approche de g0 et Z16 est la zone d'approche de g1.
Les infos rentrées à la main sont prioritaires sur les infos crées par le programme.

Les zones de manœuvre :

Dans le réseau de Dominique, il y a aussi des zones de manœuvre. Et, si on n'y prenait pas garde, elles seraient, elles aussi, ajoutées aux gares, ce qui serait une erreur.
Il faut donc bloquer le processus en rentrant "bloque" dans les zones Z36, Z45, Z46 pour g0 et dans Z2 pour g1.

Maintenant, il faut décrire les zones de manœuvre.

A noter une chose importante : sauf cas particulier, on rentre dans la zone de manœuvre en marche arrière et on en sort en marche avant.

C'est le même principe que pour les gares, à ceci près qu'il n'y a pas besoin de bloquer, la gare s'en charge et, aux autres extrémités, tous les butoirs arrêtent le processus de recherche de zones.
On définit donc Z36 et Z37 où on rentre m0 dans le champ "manœuvres" des zones.
La dernière chose à définir, ce sont les zones d'approche des zones de manœuvres.
Là, je ne vois pas d'automatisation possible : il faut les définir à la main dans Z30 et Z16, champ "manœuvre". A noter, peut-être une piste : Z30 et Z16 sont les zones de sortie de la gare et je pense que ça n'est pas un hasard.

Résumé :

En rentrant 13 informations simples, on remplit 37 cases sans erreurs !

Fichiers joints :

https://www.locoduino.org/IMG/zip/editeur_json4.zip

Dans le .zip, on a ma dernière version du programme Processing, avec la création des gares et des zones de manœuvre. Mais je n'ai pas fait la partie "entrée des infos gare/manœuvre" : je les rentre directement dans le fichier Excel. C'est la prochaine chose que je vais faire. C'était juste pour tester le fonctionnement.
On ne pose plus de questions pour les vitesses dans la première phase, mais il faudra poser les questions dans les "compléments". A réaliser, donc
Je vais aussi ajouter la possibilité de modifier les informations dans une zone.
Les fichiers Excel décrivant les zones (avant et après) sont dans le .zip

Il y a aussi le fichier détaillé du processus de définition d'une gare.
Et, évidement, le plan du réseau de Dominique (toutes mes excuses pour cet oubli)

Denis

10
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 26, 2024, 03:15:15 pm »
@ Laurent,

Je cherche à faire un programme qui permette de rentrer son réseau quand on n'a pas de connaissances SNCF. Ou vraiment très peu.
La liste existe, Pierre en a fait une avec un magnifique gif pour chaque signal, animé si clignotant.
C'est ce qui va être affiché sur le TCO.
Mais pour faire le JSON, je cherche à déterminer quel type de feu doit être là, quelle cible est nécessaire dans telle situation.

Denis

11
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 26, 2024, 02:42:03 pm »
@ PIerre,

Citer
Concernant les signaux leur génération automatique pose pas mal de problèmes :
- il faut trouver où les implanter
Je pose la question de l'emplacement dans le programme

Citer
- il faut trouver le bon type de signal (un S ou un SR, ...)
- il faut savoir s'il faut des ralentissements RR30 ou RR60 et sur quelles aiguilles ils sont basés (attention aux aiguilles courbes ou symétriques)
Je demande les vitesses, on doit donc pouvoir en déduire pas mal de choses

Citer
- il faut faire la distinction entre les carrés et les carrés violets
Je vais poser une nouvelle question : zone de gare (pour ne pas afficher S) et zone de manœuvre pour les feux spécifiques.

Mon but est de régler les cas les plus fréquents sans avoir de compétences SNCF pointues.
Je n'ai pas dit que j'y arriverai, mais je vais, au moins, essayer. 8)

Denis



12
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 25, 2024, 08:03:11 pm »
Je ne me suis pas fait comprendre. C'est l'inverse :
Dois-je demander si une zone est une zone de manœuvre ?

J'aimerais que tu m'expliques à quoi peut bien servir une voie autorisée dans aucun sens  :D

Sinon, si tu as fait tourner le programme, tu as vu qu'il y a bien la possibilité de n'avoir aucun feu sur un segment.

Denis

13
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 25, 2024, 06:02:28 pm »
Voici la 3ème version de mon programme Processing : JSON_3

Dans le répertoire "data", il y a le réseau Locoduino2.

J'ai fini la partie ZONES, mais pas la partie JSON car j'ai encore quelques questions à vous poser.

Je suis parti sur la version de Pierre, avec "vois1" et "vois2" qui est effectivement plus simple que la version avec des trajets.
Mais elle suppose qu'on raisonne à partir d'un point virtuel au milieu de la zone, ce qui ne pose pas de problème.

Et que tout "vois1 "voit tout "vois2", ce qui est généralement le cas, sauf des zones où certains "vois1" ne voient pas certains "vois2".
C'est le cas des croisement simples et des TJS.

Il faut donc qu'on se mette d'accord sur la façon dont on doit décrire les croisements et les TJS.

Pour information, pour ceux qui vont aller dans le JSON généré, j'ai généré des TJD pour Z3 et Z11, alors que c'est bien une TJS qui est décrite dans ZONES … et dans le locoduinodrome2.

Par ailleurs, je n'ai pas généré la partie "signaux" car je suis persuadé qu'on peut décrire automatiquement les signaux possibles à partir des seules infos de zone.
Je continue mes recherches. Je pense que c'est assez simple. Au moins une question supplémentaire : la zone est-elle une zone de manœuvre ?
Par ailleurs, j'ai trouvé une méthode pour décrire la "zone complexe" des précédents posts.

Et je n'ai pas généré non plus la partie "itinéraires" car je ne pense pas qu'elle soit nécessaire.
En particulier, je ne me vois pas avoir 180 boutons pour ma gare…

Je suis ouvert à toute question sur ce programme.

Voici le programme et le mode d'emploi :
https://www.locoduino.org/IMG/zip/editeur_json_3.zip

Denis

14
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 20, 2024, 11:56:48 am »
Compredo  ;D

Ça marche, effectivement. Merci
Denis

15
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: février 20, 2024, 09:05:11 am »
Re-bonjour,

Je suis inquiet.

J'étais rentré sur ce fil (et je m'y suis investi) pour trouver une solution à mon problème : trouver une interface Processing-CAN pour faire marcher mon gestionnaire et l'améliorer avec des idées nouvelles qui seraient développées dans ce fil.

J'y ai appris l'existence de fichiers JSON qui, à mon avis, permettent d'unifier le passage de la description de réseau au gestionnaire.

Mais si le but est obligatoirement de porter le gestionnaire sur un ESP32, là, je ne trouverai jamais la solution à mon problème.

Denis

Pages: [1] 2 3 ... 50