Intégration domotique Transports en commun (GTFS), gratuite et open source

Prochains passages et perturbations de tout réseau de transport français, en données ouvertes.

• Publiée par guim31
• Appareils
• Version 1.1.0
• Nécessite Gladys >=5.1.0
• ★ 0

Voir sur GitHubToutes les intégrations

Les prochains passages à vos arrêts et les perturbations de leurs lignes, pour n'importe quel réseau de transport français qui publie ses horaires en GTFS sur transport.data.gouv.fr : TER et TGV (SNCF), Naolib (Nantes), STAR (Rennes), TaM (Montpellier), M (Grenoble), Ilévia (Lille), Stan (Nancy), et des centaines d'autres. Le temps réel (GTFS-RT) est utilisé quand le réseau le publie, soit environ 220 jeux de données. Pour une vingtaine de réseaux sans GTFS-RT, le temps réel SIRI est utilisé à la place (voir « Temps réel SIRI »). Tout vient de l'open data : pas de compte, et une clé d'API seulement pour certains flux SIRI.

Pour Toulouse, Lyon, l'Île-de-France ou Bordeaux, préférez les intégrations dédiées (Tisséo, TCL, IDFM, TBM) : elles vont plus loin (vélos, métro en temps réel…). L'Île-de-France est de toute façon trop grosse pour cette intégration.

Cette intégration est un projet communautaire, sans lien avec transport.data.gouv.fr, la SNCF ni aucun réseau de transport.

Ce que vous obtenez

• Un appareil par arrêt surveillé : pour chaque ligne et direction, les minutes avant le prochain passage et avant le suivant ; les trois passages les plus proches en texte ; l'info trafic de ses lignes.
• Widget « Prochains passages » : le tableau d'un arrêt, les horaires suivis en temps réel en vert, les horaires théoriques marqués « ≈ ».
• Déclencheur de scène « Perturbation sur une ligne suivie » : une nouvelle alerte trafic sur une ligne de vos arrêts, ou sur tout le réseau.
• Action de scène « Lire les prochains passages », avec une phrase prête à envoyer (« Tram 1 vers François Mitterrand à Commerce : dans 3 et 7 min »).
• Jusqu'à 3 réseaux et 20 arrêts (par exemple le réseau urbain de votre ville et la SNCF pour la gare).

Temps réel ou théorique ? Quand le réseau publie un flux GTFS-RT « TripUpdates », les passages sont corrigés (retards, suppressions, arrêts non desservis) et affichés sans « ≈ ». Sinon, ou pour les véhicules non suivis, ce sont les horaires du plan de transport, marqués « ≈ » ou « théorique ». La recherche de réseau indique ce que chacun publie.

Prérequis

• Gladys 5.1 ou plus récent, avec un accès à Internet.
• Pour lister les arrêts autour de chez vous : la position de votre maison dans Gladys (Paramètres → Maisons). L'intégration la demande à l'installation (location) : elle lit les coordonnées de vos maisons, rien d'autre, et seulement pour trier les arrêts par distance. Sans elle, cherchez par nom.
• De 1 à 80 Mo de disque sous /data par réseau (l'archive des horaires, mise à jour une fois par jour) : 6 Mo pour la SNCF, 26 Mo pour Naolib.

Installation

1. Dans Gladys, allez dans Intégrations → Installer depuis GitHub et saisissez https://github.com/guim31/gladys-gtfs.
2. Ouvrez l'onglet Configuration de l'intégration et choisissez la langue des textes (français par défaut).
3. Ajoutez votre réseau, puis vos arrêts, avec les actions du même écran (ci-dessous), et créez leurs appareils dans l'onglet Découverte.

Configuration

Réglages

• Langue des textes : noms des fonctionnalités, noms des lignes, phrases des scènes. Les noms sont fixés à la création de l'appareil : changez la langue d'abord, créez les appareils ensuite.

• Fréquence de mise à jour : 30 secondes, 1 minute (par défaut), 2 ou 5 minutes.

• Temps réel : activé par défaut. Désactivé, l'intégration n'utilise que les horaires théoriques et ne télécharge plus les flux temps réel.

• Clés d'API SIRI (secret, facultatif) : seulement pour un réseau dont le temps réel est en SIRI et demande une clé (voir « Temps réel SIRI »).

Ajouter un réseau

1. Chercher un réseau : un nom de réseau, une ville ou une région (« Naolib », « Rennes », « TER »…). Chaque résultat donne son nom, son identifiant et le temps réel publié, par exemple • Naolib [tdg84101] — … — temps réel : passages. Certains réseaux publient deux fichiers (horaires en cours et à venir) : prenez celui « en cours ».
2. Ajouter un réseau : son identifiant (tdg…), ou son nom s'il est unique. L'intégration télécharge ses horaires et les lit : jusqu'à une minute pour un gros réseau.

Réseau hors catalogue : donnez l'adresse de son fichier GTFS (https://… .zip) dans Identifiant, nom ou URL GTFS, et, si vous les connaissez, les adresses de ses flux GTFS-RT dans URL GTFS-RT. Nom affiché remplace le nom placé devant celui des arrêts.

URL SIRI ou SIRI Lite (facultatif) : le temps réel SIRI d'un réseau hors catalogue, utilisé s'il n'a pas de GTFS-RT.

Ajouter un arrêt

1. Chercher un arrêt : saisissez un nom (« hotel dieu » trouve « Hôtel Dieu », accents et majuscules n'importent pas), ou laissez vide pour lister les 10 arrêts les plus proches de votre maison. Chaque résultat donne ses lignes, sa distance et son identifiant entre crochets, par exemple • Commerce [20] — 1, 2, 3, C2, C3 — 90 m. Avec plusieurs réseaux, le champ Réseau restreint la recherche.
2. Ajouter un arrêt : son nom, ou son identifiant si plusieurs arrêts portent le même nom. Lignes est facultatif : « 1, C2 » ne garde que ces deux lignes ; vide, toutes les lignes. Une grande gare a des dizaines de lignes : choisissez les vôtres (un appareil garde au plus 12 lignes et directions).
3. Ouvrez l'onglet Découverte et créez l'appareil.

Ajouter un arrêt déjà surveillé change ses lignes : Gladys propose alors de mettre à jour l'appareil dans l'onglet Découverte.

Identifiant SIRI (facultatif, réseaux en SIRI seulement) : quand « Afficher la surveillance » dit que le serveur SIRI ne connaît pas l'arrêt, son MonitoringRef (un par quai, séparés par des virgules).

Retirer, vérifier les flux

• Retirer un arrêt ou un réseau : son nom ou son identifiant. Retirer un réseau retire aussi ses arrêts et efface ses horaires. Les appareils restent dans Gladys jusqu'à ce que vous les supprimiez.
• Afficher la surveillance : pour chaque réseau, la date des horaires, l'âge des données temps réel, le nombre de trajets suivis, le volume téléchargé par heure, les arrêts surveillés, et la dernière erreur s'il y en a une.

Appareils

Arrêt

Pour chaque ligne et direction desservie (ou les lignes choisies) :

Fonctionnalité	Type	Valeur
Tram 1 → François Mitterrand	durée (min)	minutes avant le prochain passage
Tram 1 → François Mitterrand (suivant)	durée (min)	minutes avant le suivant

Et deux textes pour tout l'arrêt :

• Prochains passages : les trois plus proches, par ex. 1 → Jamet 2 min · C2 → Gare Sud ≈4 min (« ≈ » = théorique).
• Info trafic : les titres des perturbations en cours sur ses lignes, ou « Aucune perturbation ».

0 signifie que le véhicule est à l'arrêt ou à l'approche (moins d'une minute) ; 1440 signifie aucun passage dans les 24 heures (nuit, ligne qui ne circule pas ce jour-là). Ces valeurs ne gardent pas d'historique : un compte à rebours relu chaque minute remplirait la base pour rien.

Le nom de l'appareil commence par le nom du réseau (« Naolib · Commerce »). La direction d'un train est sa gare terminus : la SNCF met le numéro du train à la place, l'intégration le remplace.

Widget du tableau de bord

Prochains passages : choisissez un arrêt. Une ligne par ligne et direction (dix au plus, celles qui ont un passage d'abord) : « 3 · 7 min » en vert quand c'est du temps réel, « ≈ 3 · 7 min » en bleu pour le théorique. La légende liste les perturbations de ses lignes (⚠), ou rappelle la signification de « ≈ ».

Déclencheur de scène

Perturbation sur une ligne suivie : une nouvelle alerte trafic apparaît sur une ligne de vos arrêts surveillés (le filtre de lignes d'un arrêt la restreint), ou sur tout le réseau (grève, fermetures). Filtres : portée (une ligne suivie, tout le réseau, ou vide pour les deux) et ligne (telle qu'écrite par le réseau : A, C1, 15). Variables : portée, réseau, ligne, titre, détails (texte brut), lien. Une alerte est annoncée une fois ; celles déjà présentes quand vous ajoutez un arrêt ne le sont pas. Il faut un réseau qui publie ses alertes en GTFS-RT (« alertes » dans la recherche de réseau).

Pour « le prochain bus est dans moins de 5 minutes », utilisez le déclencheur « Changement d'état de l'appareil » de Gladys sur le compte à rebours de l'arrêt : il sait déjà comparer des valeurs.

Action de scène

Lire les prochains passages : un arrêt surveillé et, facultativement, une ligne. Sorties : phrase (jusqu'à quatre lignes et directions, les plus proches d'abord), arrêt, ligne et direction du prochain passage, minutes d'attente, minutes jusqu'au suivant, temps réel (1) ou théorique (0), nombre de lignes avec un passage. Les phrases suivent la langue de la configuration.

Exemples de scènes

• C'est l'heure : à 7 h 45 en semaine, « Lire les prochains passages » à votre arrêt pour la ligne C2, puis envoyez {{sentence}} par Telegram ou annoncez-la sur une enceinte.
• Mon TER est perturbé : déclencheur « Perturbation sur une ligne suivie », portée « une ligne suivie », sur la gare ajoutée avec votre ligne TER : envoyez le titre et les détails sur votre téléphone.
• Partir quand le bus arrive : déclencheur « Changement d'état de l'appareil », compte à rebours de votre bus inférieur à 4, condition « quelqu'un à la maison » et avant 8 h 30 : faites clignoter la lampe de l'entrée.

Données, rafraîchissement et bande passante

Données	Source	Quand
Catalogue des réseaux	transport.data.gouv.fr (API publique)	à la recherche ou à l'ajout d'un réseau, gardé un jour
Horaires (GTFS)	le réseau, via transport.data.gouv.fr	une fois par jour au plus, gardés dans /data
Temps réel (GTFS-RT)	le réseau, ou le proxy du catalogue	à chaque mise à jour, toutes les 15 min quand rien ne roule
Temps réel (SIRI)	le serveur SIRI du réseau	par arrêt, à chaque mise à jour quand un passage approche

Le temps réel est le plus lourd : de quelques Ko à 2 Mo par flux et par lecture. À une lecture par minute, Tisséo représente environ 100 Mo par heure et la SNCF environ 90 Mo par heure, pendant les heures de service ; l'action Afficher la surveillance affiche le volume de vos réseaux. La nuit, sans passage dans les 90 minutes à vos arrêts, les flux ne sont lus que toutes les 15 minutes, et un réseau sans arrêt surveillé n'est jamais lu. Choisissez 2 ou 5 minutes, ou désactivez le temps réel, sur une connexion limitée. Le catalogue et les flux ouverts n'imposent pas de quota ; le proxy de transport.data.gouv.fr n'accepte qu'une lecture par flux toutes les 30 secondes, et l'intégration s'y tient.

Licences : les horaires sont publiés sous Licence Ouverte (Etalab) ou ODbL selon le réseau ; l'ajout d'un réseau affiche la sienne, et transport.data.gouv.fr la précise sur la page de chaque jeu de données.

Temps réel SIRI

Une vingtaine de réseaux publient leur temps réel au format SIRI ou SIRI Lite plutôt qu'en GTFS-RT : Ginko (Besançon), CTS (Strasbourg), l'agrégat des Pays de la Loire, Idelis, TUB, évolitY, Tanlib, Calibus, Tréma, R'Bus, Evalys, ARVI, TuT, Dordogne, BlaBlaCar Bus… L'intégration s'en sert quand le réseau n'a pas de GTFS-RT ; la recherche l'annonce par « temps réel : passages arrêt par arrêt (SIRI) ». TCL et IDFM, qui en publient aussi, ont leurs intégrations dédiées.

• Sans clé : quand le catalogue publie la clé d'accès du serveur (le « RequestorRef » public de certains serveurs SIRI) ou que le serveur est ouvert, il n'y a rien à faire.
• Avec clé : beaucoup de serveurs en demandent une, gratuite, à obtenir auprès du réseau ; la page du jeu de données sur transport.data.gouv.fr dit à qui la demander (Ginko : son support, par courriel ; CTS : un compte sur son portail développeur). Saisissez-la dans Clés d'API SIRI de la configuration, sous la forme Ginko = votre-clé ; une par ligne (ou séparées par « ; ») si plusieurs réseaux en demandent ; seule, une clé vaut pour tous. Elle n'apparaît ni dans les journaux, ni dans « Afficher la surveillance », ni dans /data. L'intégration la place là où le serveur l'attend : RequestorRef en SIRI, authentification HTTP pour la CTS, paramètre AccountKey pour les serveurs Mecatran. Si votre réseau la veut ailleurs, écrivez nom=clé (paramètre d'URL) ou En-Tête: clé (en-tête HTTP).
• Arrêts : SIRI désigne les arrêts par ses propres identifiants. L'intégration demande au serveur la liste de ses arrêts (une fois par jour) et les relie à ceux des horaires (même code, sinon même nom à moins de 100 m) ; sans liste, elle essaie le code public de l'arrêt puis son identifiant GTFS. Si « Afficher la surveillance » signale un arrêt inconnu du serveur, donnez son identifiant SIRI dans Identifiant SIRI de « Ajouter un arrêt ».
• Ce qui change : rien sur l'appareil, le widget ni les scènes. Les passages donnés par le serveur remplacent les horaires théoriques de leur ligne et direction, sans « ≈ » quand le véhicule est suivi. Les perturbations (GeneralMessage, sinon SituationExchange) alimentent l'info trafic et le déclencheur de scène.
• Réseaux sur la passerelle Okina (Pays de la Loire, Tanlib, Calibus, Tréma, R'Bus, Evalys, TuT, Dordogne, CC Sud Gironde) : Okina n'accepte qu'environ une requête toutes les 30 secondes par adresse, pour tous ces réseaux ensemble. L'intégration s'y tient (35 s), et chaque quai suivi n'est donc relu que toutes les 35 s × le nombre de quais : avec un arrêt de deux quais, environ toutes les 70 s ; au-delà de 2 ou 3 arrêts, le temps réel arrive trop tard pour être utile. Suivez un ou deux arrêts, et donnez si besoin l'Identifiant SIRI du seul quai de votre direction.
• Serveurs particuliers : un serveur qui répond sans aucun arrêt ni passage demande presque toujours une clé (« Afficher la surveillance » le dit). Un serveur qui ne propose pas les prochains passages par arrêt (seulement les horaires estimés de toute la ligne, comme BlaBlaCar Bus) n'est pas lu : horaires théoriques.
• Sobriété : une requête par quai (quatre au plus par arrêt) à chaque mise à jour, seulement pour les arrêts qui ont un passage dans les 90 minutes (toutes les 15 minutes sinon), et les perturbations toutes les 5 minutes. Deux arrêts de deux quais, une mise à jour par minute : environ 250 requêtes par heure en journée, quelques Ko chacune. Un serveur qui répond « trop de requêtes » (429) n'est plus interrogé pendant le délai qu'il demande (5 minutes par défaut, puis davantage), pour tous les réseaux du même serveur (Okina en sert huit), puis les quais passent à tour de rôle ; le proxy de transport.data.gouv.fr une fois par 30 secondes au plus. Si votre réseau fixe un quota plus bas (voir la page de son jeu de données), choisissez une mise à jour toutes les 2 ou 5 minutes.

Dépannage

• « … sont trop gros pour les 256 Mo de l'intégration » : le réseau dépasse ce que le conteneur de Gladys peut lire (Île-de-France, plus de 400 000 trajets par semaine, archive de plus de 80 Mo). Utilisez l'intégration dédiée, ou un jeu de données plus petit du même réseau.
• « Plusieurs résultats » : ajoutez l'arrêt par son identifiant, donné par « Chercher un arrêt », ou précisez le Réseau.
• Tous les horaires d'un arrêt sont marqués ≈ : le réseau ne publie pas de temps réel, ou pas pour ces véhicules, ou le flux est en panne (l'action « Afficher la surveillance » donne la dernière erreur). Les horaires théoriques continuent de fonctionner.
• « Temps réel (SIRI) : accès refusé par le serveur » : la clé manque ou n'est pas la bonne (champ Clés d'API SIRI). Une clé fournie sous une autre forme (paramètre d'URL, en-tête) s'écrit nom=clé ou En-Tête: clé.
• Une ligne affiche 1440 : aucun passage dans les 24 heures (service de nuit, ligne qui ne circule pas ce jour-là, déviation).
• Aucun appareil dans l'onglet Découverte : ajoutez d'abord un réseau, puis un arrêt.
• Le réseau a changé d'adresse (erreur HTTP 404 dans « Afficher la surveillance ») : retirez le réseau et ajoutez-le de nouveau depuis la recherche.
• Logs : dans Gladys, les logs de l'intégration disent quel flux a échoué et pourquoi (jamais l'adresse complète, qui peut contenir une clé).

Limites

• Réseaux publiant un GTFS : la plupart des réseaux français, mais pas tous ; trois réseaux et vingt arrêts au plus.
• Trop gros : l'Île-de-France (IDFM) ; les agrégats régionaux les plus lourds peuvent aussi être refusés.
• Le temps réel dépend du réseau : certains ne publient que des alertes, ou ne suivent qu'une partie de leurs véhicules.
• Les noms de lignes et de directions sont ceux du fichier du réseau (codes de ligne SNCF comme « P2 » ou « C30 », par exemple).
• Un compte à rebours est précis à la fréquence de mise à jour près.
• Développée et testée avec les vraies données (SNCF, Naolib, Tisséo, Aix-Marseille) et le faux Gladys du SDK, sans instance Gladys réelle : vos retours sont bienvenus sur le forum.

Crédits

• Données : les réseaux de transport, via transport.data.gouv.fr (Licence Ouverte ou ODbL selon le jeu de données).
• Reprend le code de l'intégration Tisséo du même auteur ; inspirée de l'intégration TCL de prohand et des intégrations GTFS de Home Assistant.
• Code sous licence Apache 2.0.

Paramètres de configuration

Voici les paramètres demandés par Transports en commun (GTFS) dans son écran de configuration dans Gladys.

Paramètre	Type	Obligatoire	Description
Fonctionnement	section	Non	Ajoutez votre réseau avec les actions ci-dessous (recherche dans le catalogue national transport.data.gouv.fr, ou adresse d'un fichier GTFS), puis vos arrêts (par nom, ou autour de la maison), et créez leurs appareils dans l'onglet Découverte. Sans compte ; une clé pour certains flux SIRI.
Langue des textes	select	Non	Langue des noms de fonctionnalités, des noms de lignes et des phrases envoyées à vos scènes. Les noms de fonctionnalités sont fixés à la création de l’appareil.
Fréquence de mise à jour	select	Non	Fréquence de rafraîchissement des passages. Chaque rafraîchissement télécharge les flux temps réel de vos réseaux : de quelques Ko à 2 Mo chacun (Tisséo : environ 100 Mo par heure à 1 minute). L'action « État » affiche le volume des vôtres. La nuit, toutes les 15 minutes seulement.
Temps réel	boolean	Non	Corriger les horaires avec les véhicules suivis en direct et lire les perturbations, quand votre réseau les publie (GTFS-RT, sinon SIRI). Désactivé : horaires théoriques seuls, aucun téléchargement à chaque rafraîchissement.
Clés d'API SIRI	secret	Non	Seulement pour un réseau dont le temps réel est en SIRI avec clé (ex. Ginko, CTS) : une par ligne ou séparées par « ; », sous la forme réseau = clé (nom ou identifiant). Une clé seule vaut pour tous. Jamais dans les journaux.

Comment installer Transports en commun (GTFS) dans Gladys

1. Dans Gladys, ouvrez Intégrations : Transports en commun (GTFS) apparaît dans le catalogue, aux côtés des intégrations natives, avec un badge communautaire.
2. Cliquez sur Installer. Gladys télécharge l'image Docker (ghcr.io/guim31/gladys-gtfs:1.1.0), la démarre dans un bac à sable isolé du cœur, et génère l'interface de l'intégration (appareils, découverte et configuration).
3. Ouvrez l'écran Configuration de l'intégration, remplissez les paramètres, puis enregistrez.
4. Vous pouvez aussi l'installer directement depuis l'URL de son dépôt : https://github.com/guim31/gladys-gtfs.

Transports en commun (GTFS) nécessite Gladys >=5.1.0. Le catalogue dans Gladys se rafraîchit toutes les heures : une nouvelle version est donc disponible au plus tard une heure après sa sortie.

Vous n'utilisez pas encore Gladys ? C'est gratuit et open source : suivez le guide d'installation pour démarrer.

À propos des intégrations externes

Transports en commun (GTFS) est une intégration externe : une intégration communautaire empaquetée dans un conteneur Docker et publiée sur GitHub, que Gladys installe en un clic et exécute dans un bac à sable isolé de son cœur. Elle est publiée et maintenue par guim31, et non par l'équipe cœur de Gladys.

• Parcourir toutes les intégrations, natives et communautaires
• Créer et publier votre propre intégration externe
• Code source sur GitHub — source de cette documentation

Inscrivez-vous à la newsletter Gladys Assistant

Quelques emails par mois sur les nouveautés et l'actualité du projet. Envoyés par Pierre-Gilles Leymarie, le fondateur du projet. Désinscription possible à tout moment 🙂