Cadre photo CTS

L'Open Data est l'accès et l'usage libre d'une donnée numérique. Cette donnée, notamment quand elle est produite ou reçue lors d'une mission de service public, peut être considéré comme un patrimoine public, un droit à l'information, une philosophie sur le bien commun et un intérêt général !

En France, le début de l'accès libéré à l'information est marqué par l'accès à Legifrance, en 2002.

Depuis 2011, la mission Etalab lance le portail data.gouv.fr qui permet d'accéder à des jeux de données tel que : impôts, budgets, subventions, dépenses, aménagement du territoire, chômage, rénovation de logements, mesures de qualité de l'air, adresses des services publics, délinquance et criminalité, statistiques du tourisme, résultats électoraux, dépenses de la Sécurité sociale, effectifs des fonctions publiques, aides de la politique agricole commune, rejets de polluants dans l'air par les installations industrielles…

Plus localement, près de chez moi, la Compagnie des Transports Strasbourgeois propose depuis 2012 un accès à une API Open Data. Elle permet l'accès aux informations suivantes :

• Prochains passages Bus/Tram en temps-réel
• Horaires de passages Bus/Tram théoriques
• Informations de déviations
• Nombre de Vélhops en temps-réel

Si des gens avaient tant travaillé pour me fournir à moi, citoyen, une information d'une telle qualité…il me fallait absolument leur faire honneur et trouver une idée afin d'utiliser ce service !

Mon temps de trajet domicile-travail est actuellement possible de 3 manières :

• 6 min de marche + 2 min d'attente + Tram pendant 11 min + 5 min de marche = Total de 24 min
• 1 min de marche + Tram pendant 8 min + 1-3 min d'attente + 4 min de Tram + 5 min de marche = Total variant entre 19 min et 21 min
• 0 min de marche + Bus pendant 10 min + 1-3 min d'attente + 1.5 min de Tram + 5 min de marche = Total variant entre 17.5 et 19.5 min

Vous allez dire… de quoi se plaint-il? Il lui faut 20 min pour aller travailler.. et le tout avec des solutions alternatives en cas de problèmes techniques ou de bouchons… Certains lui diraient même de prendre son vélo pour pédaler pendant 6 minutes… mais bon on se refait pas :)

L'idée géniale, c'est d'afficher à proximité de ma porte d'entrée, les horaires temps réel de l'arrêt de Tram de ma rue, ainsi que l'arrêt de Bus du boulevard à côté. Ceci afin d'effectuer au moment de quitter l'appartement, le choix le plus efficace entre les 3 solutions de déplacements, afin :

• d'avoir le moins d'attente possible (l'impression d'efficacité tient beaucoup à l'attente, même si le temps total est un peu plus long…), c'est à dire de partir quand on le souhaite et de ne pas se sentir tributaire des horaires du transport en commun :D
• d'avoir moins à marcher, surtout quand le gain en temps total est minime (efficacité du transport en commun)
• de prévoir des retards sur des liaisons bus, ce qui est facilement observable sur un horaire temps-réel (retard augmentant sur l'horaire théorique ou sur l'historique de l'horaire temps-réel)

Pas d'objectifs chiffrés, mais s'il fallait le faire, je tablerais sur 4 min par trajet x 2 trajets/jour x 250 jours ouvrés = 33 heures /an … ça vaut ce que ça vaut… mais ça motive quand même !

Car un vrai afficheur CTS est un peu grand et inesthétique…!

Les caractéristiques recherchées pour cet écran (qui serait hypothétiquement allumé une dizaine d'heures par jour) furent :

• une consommation électrique pas trop élevée
• une quelconque caractéristique pouvant faire penser que l'écran ne risquait pas de marquer trop rapidement (par impression de pixels toujours allumés au même endroit)
• une taille (10“) et définition correctes pour afficher les horaires CTS, mais également des informations additionnelles (Météo et le choix d'un parapluie si la probabilité de pluie est élevée dans les prochaines heures)
• une connectique compatible avec un Raspberry Pi (HDMI ou composite), afin de pouvoir afficher mon contenu dans un encombrement total minime
• une possibilité de fixation quelconque à un mur… J'imaginais déjà l'écran trônant sur un mur tel un tableau !

J'ai eu beaucoup de mal à trouver cet écran… à cause de contraintes de prix (> 50€), de contraintes de connectiques (pas d'HDMI au moment de la recherche, seulement via adaptateurs coûteux), de contraintes de taille (moniteurs trop épais pour fixer sur un mur, ou trop petits et mal définis)

Après quelques semaines de recherches plus ou moins intensives, j'étais presque prêt à abandonner l'idée… quand j'ai trouvé un produit inattendu dans ma démarche de réflexion : un cadre photo numérique et tout spécialement le modèle Kodak Easyshare W1020

Il possédait des caractéristiques intéressantes :

• une taille de 10.2” et une résolution moyenne mais acceptable de 800×480 pixels
• un écran destiné à être allumé 24/24 sans marquer…enfin on ose espérer ou parier avec un cadre photo numérique…!
• une consommation faible… en ordre de grandeur -9€/an
• un minuteur pour ne l'allumer que si nécessaire… on passe de -9€/an à -6€/an s'il est allumé 15h/j…
• un dispositif d'accroche murale ou sur pied
• une autonomie logicielle, couplé à une connexion Wifi intégrée, qui permet de séparer physiquement l'écran afficheur, et l'ordinateur générant les affichages
• la particularité de pouvoir gérer des “nouvelles images”. Au fil de mes recherches, j'ai constaté que beaucoup de cadres photos ne savent pas actualiser la liste des fichiers à lire…celle-ci était lue une première fois, et les images stockées en cache…impensable pour mon usage ! Pire.. en utilisant une carte SD Wifi pour y uploader des images, on doit resetter la carte pour rafraîchir la liste des fichiers… certains cadres photos plantent alors :) Ce modèle Kodak se distingue ainsi tout particulièrement par sa capacité à lire des flux RSS pour y télécharger les images et les afficher.

Et également des inconvénients:

• Pour tenir le budget (-50€), j'ai du le récupérer d'occasion (en très bon état !)
• Il n'était déjà plus fabriqué en 2013…j'espère tenir assez longtemps et changer complètement en technologie plus tard ! Si c'était à refaire, je recyclerais une dalle LCD (pour la finesse), et l'intégrerais dans un cadre en bois avec un Raspberry Pi. J'économiserais ainsi la gestion des contraintes liées à un cadre photo (images statiques en mode diaporama), pour fournir des images dynamiques actualisées à tout moment

Mon cadre photo est, comme décrit dans les caractéristiques, capable de lire un flux RSS pour y afficher des photos mises à jour d'Internet.

Ici, point de simples photos de paysages, ni d'Internet, mais il faut :

• Générer un flux RSS accessible en HTTP. La publicité Kodak fait tout spécifiquement référence aux flux RSS de Flickr.. mais on imagine aisément que tout fil RSS correctement écrit sera correctement décodé par le cadre photo
• Générer des fichiers JPEG qui seront listés dans le flux RSS et téléchargeable par le cadre en HTTP. Le choix final du cadre photo numérique, m'a tout bêtement fait penser qu'il fallait joindre l'utile à l'agréable… et se servir d'un cadre photo pour afficher mes photos de vacances ! Bien sûr, ces images contiendront en surimpression les informations souhaitées (horaires temps-réel CTS + météo)

Les premières maquettes “faites main/photoshop” donnent le visuel suivant… je décide d'ailleurs d'appeler l'afficheur “Chloé” :

La réalisation du programme prend la forme d'un serveur (ou démon) Python, qui est démarré 24/7.

Le serveur (en vert) est en attente d'évènements HTTP qui correspondent à des requêtes du cadre photo Wifi (en jaune)

Il exécute ensuite les actions pour fournir le fil RSS et les images au format JPEG, dans le protocole HTTP. Afin de fournir les images le plus rapidement possible, on pré-génère les images. En effet, les appels à des APIs externes prennent quelques secondes, qui s'additionnent au traitement total.

Le serveur a alors été découpé en “modules”, afin de faciliter la création ultérieure de nouveaux modules d'informations.

Les premiers tests de développements ne comportaient pas tous les modules :

Aujourd'hui, l'interface ressemble plutôt à :

Fichier : kodak.py

• Description : Serveur principal à exécuter. Gère le serveur HTTP, l'appel aux modules, et pilote la pré-génération des images. Grâce au fichier log.py il loggue ses actions dans un fichier.
• Paramètres : logfile (Emplacement du fichier de log), http_port (port d'écoute TCP), modules (liste des modules)

Fichier : background.py

• Description : Module qui cache les images du dossier Background en mémoire, et fournit aléatoirement un fond JPEG

Fichier : chloe.py

• Description : Module qui affiche le personnage Chloé (image dans le dossier Chloe)

Fichier : cts.py

• Description : Module qui requête l'API Open Data CTS et qui affiche les horaires de 4 arrêts
• Paramètres : cts_id et cts_mdp (authentification à l'API CTS), cts_stops (Nom, code de l'arrêt, terminus et code couleur)

Fichier : date_fete.py

• Description : Module qui restitue le nom du saint ou la fête pour la date d'aujourd'hui. Calcule automatiquement les dates des fêtes (Pâques, Mardi gras, Pentecôte, Fête des mères et des pères, Avent, etc…)

Fichier : heure.py

• Description : Module qui affiche l'horloge et la date du jour

Fichier : meteo.py

• Description : Module qui requête l'API wunderground.com pour afficher les prévisions de température et pluviométrie sur 12h, ainsi que les prévisions journalières sur 4 jours
• Paramètres : api (authentification de l'API), city (nom de la ville au format wunderground)

Télécharger le source

Pré-requis:

• apt-get install python3-cairo python3-pip libjpeg-dev libcurl4-openssl-dev
• pip-3.2 install Pillow python-dateutil pycurl

Utilisation:

• Vérifier et renseigner les paramètres (notamment ceux d'authentification aux API externes)
• Ajouter des images au dossier Background
• Lancer le script kodak.py ou créer un script de type service pour démarrer le démon automatiquement

J'ai peu de chiffres sur le niveau de service de l'API Open Data, mais c'est du très haut.. et je dis bravo aux équipes informatiques de la CTS, car j'ai pas remarqué de vrais pépins… La seule fois où j'ai cru à une indisponibilité du service Open Data… c'était en fait mon script qui bouclait sur l'API (si la CTS a vu ça sur sa métrologie..coucou.. et pardon !), je gérais pas le fait que ma station puisse ne plus avoir de prochains passages (arrêt désactivé pour certains évènements - braderie, marché de noël, travaux).

En 2012/2013, j'avais d'ailleurs demandé à la CTS si mon polling régulier (30sec) pouvait être sujet à problèmes sur l'usage attendu de l'API (en terme de trafic, de performances dans leur architecture Webservice)… ils m'ont plutôt dit qu'ils allaient observer les usages en général, voir comment les citoyens s'en servent avant de vraiment légiférer… au rythme de 30 secondes c'était très acceptable pour eux.

Aujourd'hui, les usagers recensés de l'API reçoivent occasionnellement des emails d'informations de la CTS, qui permet d'être informé de tout changement.

Bref, pour conclure, cette API Open Data, c'est du bonheur pour le citoyen informaticien !!

On est en 2017, je viens de finir cet article 4 ans après la mise en production… et l'on constate que le cadre est devenu quasi indispensable…! On l'en vient même à s'en plaindre quand il est HS :D (mise à jour API météo ou CTS, bugs)

C'est bien car cela signifie que l'afficheur a atteint son objectif en terme de service, que cela soit sur la prévision CTS qui permet réellement de diminuer l'attente, ou la prévision de pluviométrie qui permet de savoir s'il faut sortir avec son parapluie :)

L'objet arrive même à attirer la curiosité ou l'envie des personnes de passage dans l'appartement.. (non le cadre n'est pas à vendre ou voué à une production massive !!)

4 ans après, même avec la démocratisation des smartphones, le cadre se targue d'être plus rapide que l'application Strasmap de la ville de Strasbourg (lancement de l'appli, choix de la station, etc..) !

Cette dépendance à l'efficacité souligne également qu'on est moins prêts à revenir sur une qualité de service diminuée… même si on n'avait connu que ça avant !