Archives de l'auteur : Laurent

Ponctualité des trains versus Ressenti des usagers

imgRATP

La SNCF et la RATP communiquent leurs performances en annonçant une mesure de ponctualité de l’ordre de 95%. L’idée véhiculée par un tel chiffre est que les transports en commun sont pratiquement toujours à l’heure. Pourtant, le vécu des usagers est tout autre : ils doivent subir des retards dans leur trajet souvent importants et toutes les semaines, voir plusieurs fois par semaine. Cet affichage est donc souvent perçu de manière insultante par les principaux intéressés.

Tout d’abord, comment cette mesure de ponctualité est elle calculée ? La ponctualité prend en compte tous les voyageurs du lundi au dimanche, du premier au dernier train. Un voyageur qui arrive à sa destination avec un délai supplémentaire de 5 minutes ou plus est considéré en retard.

Prenons maintenant un cas concret (et réel) d’usager. Ce dernier vit en proche banlieue parisienne et se rend au travail à Paris en empruntant un transilien (ligne H), puis un RER (ligne E) et enfin un métro (ligne 13). Voici la ponctualité affichée pour ces différentes lignes (chiffres du trimestre janvier-décembre 2013) :

  • Ligne H : 94,4%
  • Ligne E : 94,7%
  • Ligne 13 : 94,3%*

* Le chiffre du métro n’est pas une mesure de ponctualité mais un pourcentage du nombre réel de métros en circulation aux heures de pointe par rapport au service commandé.

Quelle est la probabilité pour l’usager de ce trajet d’avoir un incident de plus de 5 minutes ?

  • La probabilité d’avoir un incident sur ce trajet est de (1-0.944×0.947×0.943)=0.157 soit 15,7%.
  • La probabilité d’avoir un incident pendant la journée (trajet aller + trajet retour) est de (1-(0.944×0.947×0.943)^2)=0.289 soit 28,9%.
  • La probabilité d’avoir un incident pendant la semaine (5 trajets aller/retour) est de (1-(0.944×0.947×0.943)^10)=0.819 soit 81,9%.

Ainsi, pendant que le SNCF et la RATP communiquent sur 95% de ponctualité, l’usager est quasiment certain (82% de chances) d’avoir au moins un problème dans la semaine. Sachant que, en général, un problème sur la ligne H c’est un train supprimé (donc 20 minutes de retard) ou un incident plus grave (qui se compte en heures) et la messe est dite :

95% de ponctualité = une galère hebdomadaire pour les usagers !

(suite…)
Publié dans Réflexions | Laisser un commentaire

Kile : plus de 1024 caractères

600px-kilesvg

Kile est un excellent éditeur de code LaTeX. Cependant, il nous embête parfois en nous disant :

Le fichier […] a été ouvert et contenait des lignes trop longues (plus de 1024 caractères). Les lignes trop longues ont été tronquées et le document est réglé en mode lecture seule, car l’enregistrement modifie son contenu.

Pour pouvoir modifier cette limite de 1024 caractères, il faut se rendre dans Configuration → Configurer Kile… → Ouvrir / Enregistrer → Limite de longueur de ligne. Il faut ensuite fermer puis réouvrir son fichier.

Pour pouvoir éditer et sauver le fichier sans modifier cette limite, il faut se rendre dans Outils et décocher Mode « lecture seule ».

Publié dans LaTeX, Applications | Tagué | Laisser un commentaire

Lua : vacances, jours chômés et jours fériés

reposFirefox

Indispensable dans une box domotique

Il est souvent utile de savoir si le jour courant est un jour passé à la maison, ou pas, pour planifier la programmation des luminaires ou du thermostat. Ce billet présente un ensemble de fonctions permettant de déterminer si le jour courant est un jours chômé (c’est à dire un jour où au moins un membre de la famille reste à la maison).

Jours chômés

La fonction principale pourrait se résumer à celle-ci :

function josdJourChome()
  local jour=josdGetJourSemaine()
  return jour=="samedi" or jour=="dimanche" or josdJourFerie() or josdJourVacances()
end

Un jour chômé est donc un samedi, un dimanche (à adapter selon votre situation) un jour férié ou un jour de vacances scolaires. Cette fonction fait appel à d’autres fonctions (josdGetJourSemaine(), josdJourFerie() ou josdJourVacances()) que nous détaillerons plus bas.

(suite…)
Publié dans Domotique, Tutoriels | Tagué | Laisser un commentaire

Luup et les Variables des Modules

Principes de fonctionnement

Propriétés d'un Module

Les variables d’un module (device) permettent de connaître, voir de modifier, l’état courant d’un module (allumé, éteint, température, niveau des batteries….). Dans l’interface de la Vera, pour accéder aux variables d’un module, il faut cliquer sur la petite clef à molette du module en question afin d’accéder à la boîte de dialogue des propriétés du module. Les variables du module se trouvent dans la partie inférieure de l’onglet Advanced de cette boite de dialogue comme illustré sur l’image ci-dessous.

(suite…)
Publié dans Domotique, Tutoriels | Tagué , | 2 commentaires

Thermostat Z-Wave Secure SCS317 et SSR303 (ou C-Stat 17-ZW et ASR-ZW)

Thermostat

Présentation

Il s’agit d’un thermostat Z-Wave, composé du thermostat proprement dit (SCS317 ou C-Stat 17-ZW) et de son récepteur (SSR303 ou ASR-ZW), permettant de contrôler une chaudière (gaz, fioul ou électrique). Le thermostat dispose d’un écran LCD rétroéclairé et fonctionne avec 2 piles AA (autonomie annoncée de 2 ans). La configuration est mémorisée même en cas de panne de batterie. Le récepteur doit être branché sur le 220V et peut être commandé localement à l’aide de deux boutons (ON et OFF). La transmission entre les deux modules se fait sans fil (868,42 Mhz) avec une portée de 30 mètres en champ libre.

Ce thermostat permet une programmation assez poussée différenciant les jours de la semaine et permettant de paramétrer jusqu’à 6 plages de température par jour. Il est possible d’intervenir à tout moment et simplement sur la température de consigne en appuyant sur les touches + ou -. En outre, le thermostat propose un mode Standby permettant de le mettre en pose (avec une température minimum hors gel paramétrable) ainsi qu’un mode vacances (Holiday) permettant de programmer un début et une fin pour retrouver la maison chaude au retour des vacances.

Ce thermostat met en œuvre un algorithme proportionnel-intégral en fonction du temps (TPI) pour offrir un contrôle précis de la température ainsi qu’une capacité (débrayable) de savoir quand commencer à chauffer pour atteindre la prochaine température de consigne à l’heure programmée (inutile dans ce cas de prévoir le temps de montée en température lors de la programmation).

Ce thermostat constitue donc un excellent thermostat parfaitement utilisable de manière autonome (i.e. en dehors d’un réseau Z-Wave). Mais bien entendu, tout cela peut s’interfacer avec une box domotique Z-Wave. Cependant la documentation ne décrit que l’utilisation autonome du thermostat. Elle reste muette sur son inclusion dans un réseau Z-Wave et renvoie, à ce sujet, l’utilisateur vers un installateur professionnel !

(suite…)
Publié dans Domotique, Tutoriels, Modules | Tagué , | 3 commentaires

Vera Lite : Polling

Cyber-The-Vote-Polling-Place

Problématique

Le polling désigne le processus par lequel la Vera interroge un module Z-Wave afin de connaître son état (on/off, niveau batterie, température …). Le polling n’est pas forcément nécessaire avec un module qui retourne spontanément son état à intervalles réguliers. Certains modules du type capteur fonctionnent souvent sur piles. Ces modules sont, la plupart du temps, dans un mode d’économie d’énergie qui n’écoute le réseau et pendant lequel tout polling est impossible.

Paramétrage général

Le polling n’est pas forcément actif bien qu’il le soit par défaut. Pour l’activer ou le désactiver, il faut cocher l’option Poll nodes (1) dans l’onglet SETUP → Z-Wave Settings → Options. Quand le polling est actif, un certain nombre d’options, dans le même onglet (SETUP → Z-Wave Settings → Options), permettent d’en affiner le fonctionnement général.

  • Number of seconds to wait to start polling 20 (2) : intervalle en seconde entre un redémarrage de la Vera ou du moteur de Luup et le premier polling.
  • Only poll a node if the Z-Wave network is idle at least 10 seconds (3) : nombre de secondes pendant lesquelles la Vera ne doit pas avoir généré de commande autre qu’un polling avant qu’une nouvelle demande de polling soit effectuée.
  • Unless specified otherwise, poll each node at most once every 60 seconds (4) : nombre de secondes minimum entre deux polling sur le même module.
  • Poll a node every 30 seconds (5) : périodicité en secondes du processus de polling.
(suite…)
Publié dans Domotique, Contrôleurs, Modules | Tagué , | Laisser un commentaire

IPX800 Ping Watchdog : redémarrage automatique de la Freebox en cas de plantage

La problématique

Le boitier Freebox Serveur ne plante pas souvent, mais quand il plante pendant une absence prolongée, c’est très embêtant car :

  • Impossible de savoir si c’est la Freebox qui est plantée ou s’il n’y a plus de courant dans la maison
  • Le réseau de la maison n’est plus accessible, plus d’accès au NAS, pas de possibilité de redémarrage à distance
  • Plus de domotique non plus (remise en route du chauffage avant le retour par exemple)
  • Plus non plus de josDBlog
  • … bref, pas top du tout !

La solution décrite dans ce billet est une variante de celle-ci écrite pour SynoZwave. Elle consiste à intercaler une sortie relai de l’IPX800 entre l’onduleur et l’alimentation du boitier Freebox Serveur afin que la fonction Ping WatchDog de l’IPX800 puisse couper puis restaurer l’alimentation du boitier Freebox Serveur pour le contraindre à redémarrer.

Raccordements

PlanSynoOnduleurIPX800 (suite…)
Publié dans Domotique, FreeBox, Tutoriels | Tagué | Laisser un commentaire

Lua, tour d’horizon

Lua

Sommaire

Présentation
Éléments de syntaxe : Écriture, Commentaires, Chaînes de caractères.
Valeurs, Types, Variables et Fonctions : Typage dynamique, Lua possède 8 types de base, Portée des variables.
Structures de contrôle : Structure conditionnelle, Structures itératives, Structures itératives for générique, Conditions, Bloc d’instructions.
Fonctions particulières, particularités : self et « : », Fonctions sur les chaînes.
Plus d’information, sources

Présentation

Flexible, réflexif, impératif, compact et léger (compilateur, interpréteur et librairies standards n’occupent qu’environ 150 kilo-octets une fois compilés), open-source (distribué sous la licence MIT), Lua est un langage de script extrêmement puissant et rapide (dix à trente fois plus rapide que d’autres langages de scripts tel que TCL, Perl, Python, Ruby ou PHP). Lua est écrit en langage C ANSI strict et donc multiplateforme.

Créé en 1993, Lua (Lune en portugais, prononcer Loua, écrire Lua et pas LUA car ce n’est pas un acronyme) a été développé par Luiz Henrique de Figueiredo, Roberto Ierusalimschy et Waldemar Celes, membres du groupe de recherche TeCGraf, de l’université pontificale catholique de Rio de Janeiro au Brésil.

Voici un programme minimaliste en Lua. En sauvant le code ci-dessous dans le fichier hello.lua, le script s’exécute de la manière suivante : $ lua hello.lua

print("Hello World")

Voici un script Lua plus évolué :

-- Définition d'une fonction factorielle
function fact (n)
  if n == 0 then
    return 1
  else
    return n * fact(n-1)
  end
end
 
print("Saisir un nombre :")
a = io.read("*number") -- read a number
print(fact(a))
(suite…)
Publié dans Enseignement, Domotique, Tutoriels | Tagué | Laisser un commentaire

Luup debugging (Vera Lite)

debug

Introduction

L’un des gros avantage de la box domotique Vera Lite est de pouvoir développer ses propres fonctions en Lua. Les fonctions développées doivent être placées dans la fenêtre Edit Startup Lua (APPS → Develop Apps → Edit Startup Lua). Cependant debugguer du Luup sur la Vera n’est pas une chose facile car, avec l’interface UI5, l’éditeur de Luup est une toute petite fenêtre d’édition de texte simple. Cela implique plusieurs problèmes :

  • Comme la fenêtre est petite, une ligne de code se retrouve souvent sur plusieurs lignes se qui ne facilite pas la lecture
  • Pas de numérotation des lignes, aucune coloration syntaxique, encore moins d’auto-complétion…
  • Il faut sauver à chaque fois, en plusieurs cliques, puis attendre que la Vera redémarre le moteur Luup (plusieurs seconde)
  • Il faut déclencher l’exécution du code (parfois lié à un évènement par exemple)
  • Il faut scruter le fichier log ou les erreurs sont notifiées car la Vera ne signale pas d’erreur d’elle-même
  • Il faut bien déverminer les erreurs de syntaxe car elles ne sont pas toujours signalées dans le bon module
(suite…)
Publié dans Domotique, Tutoriels | Tagué , | 2 commentaires