All posts by admin

Comptage d’impulsion – vue d’ensemble

Que ce soit pour la visualisation de la consommation d’eau en temps réel ou celle de la puissance électrique instantanée, le principe de base est le même :

archi

  1. Il y a d’abord un capteur qui fournit l’information recherchée sous forme d’impulsions électroniques.
  2. Un processus activé par interruption logicielle relève ces impulsions aussi vite que possible.
  3. Un autre processus stock tranquillement ces relevés d’impulsion dans une base de données.
  4. Un serveur web anime un mini site internet qui récupère les données et les transforme en informations présentées dans un navigateur.

Les impulsions sont fugitives ; il est important de ne pas les rater et de pouvoir mémoriser l’instant de leur occurrence aussi précisément que possible.

Naturellement, comme dans l’exemple indiquée dans un commentaire sur l’exemple de code pour l’étape 2, une solution simpliste consiste à enregistrer dans un fichier le nombre total d’impulsions comptées et la date et l’ heure de la dernière impulsion.

Cependant, c’est long, relativement à la brièveté d’une impulsion. Il faut en effet : ouvrir le fichier, lire la dernière valeur du compteur, recréer une nouvelle version du fichier avec la nouvelle valeur du compteur et la date et l’heure de la dernière impulsion. Si les impulsions sont trop rapprochées, on pourrait en rater. Par ailleurs, un décalage, d’une valeur plus ou moins aléatoire, s’introduit entre l’impulsion qui déclenche le traitement et le moment où l’heure est relevée.

En plus c’est pauvre : on ne conserve que le nombre total d’impulsions et la date de la dernière occurrence.

C’est pour cela qu’il est préférable de faire le traitement des impulsions en deux étapes : une lecture aussi rapide que possible (étape 2) puis, indépendamment et  sans contrainte de temps d’exécution, le stockage de chaque impulsion dans une base de données (étape 3). Ce traitement est fait à l’initiative de l’étape 4 et, en parallèle, il est aussi fait à intervalles réguliers. Ce qui permet d’avoir l’information la plus récente possible à afficher et éviter qu’un trop grand nombre d’impulsions ne s’accumulent avant d’être stockées en base de données si l’affichage n’est pas sollicité suffisamment souvent.

De plus, le stockage de toutes les impulsions dans une base de données ouvre la voie à de nombreux traitements et analyses.

Mais pourquoi 10 kΩ ?

Pourquoi 10 kΩ ? C’est la question posée par Giome dans son commentaire sur le “module additionnel”. C’est sans doute une question que tout le monde se pose et que personne n’ose poser. Comme d’habitude, c’est une évidence pour ceux qui savent et un mystère pour les autres. Si la réponse apportée ici est satisfaisante, Giome aura rendu un grand service en posant cette question.

Schématiquement, la connexion électronique à un GPIO (General Purpose Input Output c’est à dire port d’entrée sortie d’usage général) est le suivant :

GPIO

A gauche de ce schéma on a le symbole d’un bouton poussoir qui correspond au fonctionnement des capteurs “à impulsion”.  Pour le capteur utilisé sur le compteur d’eau du système de visualisation en temps réel de la consommation d’eau, c’est juste ça. Pour les compteurs utilisés pour le suivi de la consommation d’électricité c’est l’équivalent en version électronique. Dans les deux cas, une impulsion correspond à ce qui ce passerait si on appuyait brièvement sur le bouton poussoir : un court-circuit entre l’entrée GPIO et la masse.

Au niveau de l’entrée GPIO, on veut la traduction de cette impulsion sous forme binaire : un bref passage de 1 à 0, c’est à dire la passage de la tension Ub de 3.3 V à 0 V, puis un retour à 1 (3.3 V).

Si on ne branchait que le bouton poussoir, la valeur lue par le GPIO serait indéterminée (on dit “flottante”). Pour la maintenir à 3.3 V, on la relie à une sortie 3.3 V. C’est ce qu’on appelle un “pull-up” car cela tire la valeur lue par le GPIO vers le haut.

Si on reliait directement le 3.3 V au GPIO, sans résistance intermédiaire, on aurait, lors d’une impulsion, un cour-circuit du 3.3 V vers la masse !

La résistance de pull-up sert donc à protéger la sortie 3.3 V pour éviter de griller le circuit. L’intensité est alors limité à Ua/R. Avec une résistance de 10 kΩ l’intensité est donc de 0.33 mA, largement en dessous de la limite des 16 mA recommandée pour la limite du courant tiré d’un des GPIO. On aurait pu mettre moins que 10 kΩ mais c’est une valeur couramment admise pour une résistance de pull-up. C’est celle utilisée pour la version 1 du capteur de consommation électrique.

Par ailleurs, il est aussi possible d’activer, par une instruction logicielle, une résistance de pull-up interne, une par GPIO, d’une valeur annoncée de 50 kΩ.

Si on active cette résistance de pull-up interne, on peut donc se passer de rajouter une résistance de pull-up externe. C’est le choix fait pour la version 2 du capteur de consommation électrique.

Ce qui simplifie efficacement le montage.

Consommation électrique version 0.2

Chouette c’est le weekend ! Un peu de détente de geek, ça fait du bien…

Améliorations du capteur

Version 1 :el1La version 1 utilise un Raspberry Pi 1, une connexion avec des borniers, des résistances de pull-up de 10 kΩ, un compteur à 1000 imp./kWh. On note que tout ne tient pas dans le cadre de l’objectif tellement c’est encombrant. On cachera les détails, ils ne valent pas la peine d’être montrés.

Version 2 :el2

La version 2 a un bien meilleur WAF. Elle utilise un Raspberry Pi zero, une connexion sans bornier ni pull-up, un compteur à 2000 imp./kWh. L’intérieur est nettement plus élégant.

el2_details

Améliorations du traitement

Techniquement, le plus important est le passage à 2 impulsions par Wattheure : deux fois plus précis et deux fois plus réactif, surtout pour les consommations “faibles”.

Pour la peine, on passe pour le relevé des impulsions du Python au C (invisible à l’œil nu) et on améliore l’UX, nettement plus visible : el2_UX

Le fait que la consommation soit passée de 179 à 247 W est inopiné. C’est juste qu’il y a un ordinateur  portable en charge en plus au moment de la capture d’écran ; ah oui, 68 W pour charger le portable.

Consommation électrique version 0.1

Le commentaire de Mikael BERTHO à propos de l’article sur la consommation d’eau a fourni une piste pour un capteur permettant de suivre également la consommation électrique.

Affichage

Un poste de travail avec deux grands écrans

Le résultat attendu est un peu différent. Là il s’agit de connaître la consommation instantanée pour se rendre compte de la puissance électrique utilisée. Pour l’eau, c’était la quantité cumulée utilisée pour une action donnée mais le principe de base reste le même.

Pour explorer cette possibilité, on installe le capteur sur une vieille rallonge électrique recyclée pour l’occasion :

capteur

ATTENTION : c’est du 220 V ! Ne pas faire ce montage sans parfaitement comprendre et maîtriser les risques qu’il implique.

Et puis on monte un banc de tests :

banc2test

Tout l’intérêt du capteur réside dans sa sortie numérique :

testoutput

Cette sortie est reliée à l’entrée du banc de tests :

testInput

Ici elle est en parallèle avec une entrée manuelle ; un simple bouton permettant de simuler une impulsion et d’en valider la lecture par le Raspberry Pi.

Pour visualiser l’impulsion fournie par le capteur, on installe un oscilloscope digital, version geek :

bitscope

Ce qui permet de capturer une magnifique impulsion :

Impulsion

L’entrée digitale du Raspberry Pi maintenue à l’état “haut” de 3.1 V par une résistance de pull-up passe brutalement à un état bas de 1 V pendant 76 ms lorsque le capteur annonce la consommation d’un wattheure.

Il reste à faire installer par un électricien professionnel le montage du capteur sur le tableau électrique pour avoir une visibilité sur la consommation électrique générale. En attendant, ce simple dispositif permet déjà de prendre conscience de la consommation d’un poste informatique.

En veille, les mêmes équipements consomment nettement moins :

veille

Et en veille encore plus prolongée, encore moins :

veille2

Tiens, cela permettrait donc aussi de donner des indications objectives sur les temps et horaires de travail effectif d’un informaticien…

Oh !

Une information incomplète est-elle mieux que rien ?

C’est la demande posée dans un commentaire sur l’article au sujet de la consommation d’eau qui interpelle :

Et que le programme qui permet de surveiller les impulsions, c’est possible :p ?

La réponse à cette demande, sous une forme visible par un profane c’est ça :

capteur

La version sous une forme qui intéresse un informaticien est sans doute moins sexy ( quoique…) :

#!/usr/bin/env python
import RPi.GPIO as GPIO
import time, datetime

GPIO.setmode(GPIO.BOARD)

def cb(pin):
        cd= datetime.datetime.now()
        f= open('/var/capteurs/eau/' + cd.strftime('%Y-%m-%d_%H%M%S.%f'), 'w')
        f.close

GPIO.setup(15,GPIO.IN)
GPIO.add_event_detect(15, GPIO.FALLING, callback=cb, bouncetime=180)

try:
        while True:
                time.sleep(1)
except KeyboardInterrupt:
        GPIO.cleanup()

Dans tous les cas cette réponse est incomplète.

Et pourtant c’est le contenu exact du fichier capteur.py qui fonctionne depuis le 17/02/2014 (bientôt 3 ans !) et qui est déjà à l’origine du comptage de plus de 1 900 000 impulsions…

Mais ce n’est qu’une (petite) pièce du puzzle qui permet de visualiser la consommation d’eau présentée dans l’article en question.

Au pire, cette information ne sert à rien. Au moins elle est inoffensive. Au mieux elle va susciter plein d’autres questions :-(. Mais qui sait, peut-être suffira-t-elle ? Dans le doute autant la partager.

La vrai question qui est posée est “Comment faire pour surveiller moi-même ma consommation ?” est importante et mérite une réponse. Cependant, il faudrait du temps pour y répondre vraiment, beaucoup plus que pour écrire cet article, presque autant que pour mettre au point le dispositif qui permet de le savoir, nettement moins que pour acquérir les compétences pour avoir pu concevoir et réaliser ce dispositif. La disponibilité nécessaire pour répondre de manière satisfaisante à cette vrai question rentre en concurrence avec des obligations plus alimentaires…

Ensuite, cela dépend aussi du nombre de personnes intéressées, ce qui pourrait motiver une révision des priorités en faveur d’une communication plus complète sur la solution mise en œuvre pour compter des impulsions.

Justement, il y a un autre projet parallèle tout aussi motivant : comment recueillir un avis objectivement quantifié sur une question. Ah la la, ce ne sont pas les projets passionnants qui manquent mais le temps pour bien les traiter.

En attendant, revenons-en aux priorités, celles qui contribuent immédiatement et directement au chiffre d’affaire de l’EURL Barme, toutes aussi passionnantes d’ailleurs…

Le forfait est un forfait pour les prestations informatiques

Forfait :

  • contrat dans lequel un prix global est fixé à l’avance,
  • crime atroce.

Ceux qui ont eu une enfance malheureuse (condamnés à aller au ski tous les ans) ont sans doute découvert la notion de “forfait” comme une libération : le passage immédiat et illimité au remonte-pente comme alternative aux multiples tickets à prélever laborieusement dans le stock fastidieux d’un ruban de papier perforé plié en accordéon. Avec les moufles, c’était encore pire et sans c’était glacial. En plus dans ce contexte, le prix des tickets était tellement onéreux que le calcul était vite fait : quelques tours de pistes avaient vite fait de “rentabiliser” le forfait.

A l’opposé, l’avènement du téléphone portable a donné un nouveau sens au “forfait” : on paye un prix fixe obligatoire pour une durée de communications limitée. Si on consomme moins  : tant pis, c’est perdu, si on consomme plus : tant pis, on paye un prix encore plus exorbitant pour chaque minute supplémentaire dès la première seconde…

En réalité dans les deux cas, l’usage est borné : le forfait de ski ayant une validité limitée qui implique un nombre nécessairement limité d’utilisation des remonte-pentes. De plus le très grand nombre de skieurs et leurs niveaux très différents entraîne une compensation des usages intensifs (et peu rentables pour la société des remonte-pentes) par les usages faibles (et très rentables) des skieurs débutants. Sur un gros volume, on s’y retrouve forcément.

Dans un tout autre contexte, poser du carrelage par exemple,  le coté répétitif et prévisible du travail à accomplir permet de vendre avec une bonne marge de bénéfice la prestation au forfait d’après des mesures simples à faire : la surface à couvrir en l’occurrence. Certes, les bords d’une pièce ne sont pas toujours d’équerre et la surface à couvrir n’est jamais un multiple précis de celle de chaque carreau, sans compter les inévitables petits imprévus tels que les quelques carreaux qui cassent lorsqu’on les coupe. Mais globalement, le carreleur s’y retrouve avec un prix de revient maîtrisé.

Et le client est content car il sait sur quel montant il s’engage et il peut comparer les devis des prestataires plus facilement.

Le contexte des prestations informatiques est bien moins favorable, d’autant plus lorsqu’il s’agit d’obtenir un résultat original et dans un contexte novateur, sans parler des objectifs  flous ou revus au fur et à mesure de l’avancement du projet.

En informatique, la seule façon fiable de savoir combien de temps il faudra pour atteindre un objectif est de le réaliser. C’est aussi souvent la seule façon de définir précisément l’objectif…

Pourtant, aucun client ne veux s’engager sur un chèque en blanc. On les comprend. D’où l’inévitable conjecture du devis où l’on essaye désespérément d’imaginer la charge précise pour un résultat vaguement défini.

La marge de manœuvre est faible : trop cher et le client préfère la concurrence, trop optimiste et le prestataire travaille à perte. C’est le plus souvent la deuxième solution qui prévaut. Ce qui entraîne se nombreux dépôts de bilans et autant de clients abandonnés par leur prestataire et contraints d’en trouver un autre, avec des frais supplémentaires et un effet amplificateur : un travail fait à la hâte est souvent plus simple à refaire totalement qu’à reprendre.

Pour l’EURL Barme cette problématique est résolue selon deux approches.

Pour les projets modestes, le travail est fait d’emblée et un devis a posteriori est proposé au client. S’il le refuse, la perte est limitée et ne compromet donc pas l’avenir de la société. Si le client accepte le devis a posteriori, il fait une bonne affaire puisqu’il ne finance aucune marge de sécurité et paye le juste prix.

Pour les projets plus importants, les aléas du devis se compensent : les parties sous-estimées sont financées par celles qui sont surestimées. On retrouve en fait le principe du gros volume évoqué plus haut.

Et les meilleurs clients, les plus fidèles, ceux qui savent que la satisfaction des clients est prioritaire par rapport à la rentabilité à court terme, acceptent les prestations facturées au temps passé, celles qui permettent à la fois de gagner beaucoup de temps et d’atteindre le meilleur rapport qualité / prix.

En 2016 l’EURL Barme a…

1000b ans !

Le b signale qu’il s’agit d’un nombre écrit en binaire (base 2) ; on mettrait un h pour de l’hexadécimal (base 16). Ces 2 bases,  binaire et hexadécimale sont les bases utilisées en informatique.

Le nombre 8 en décimal s’écrit 1000b en binaire et, fondée en 2008, L’EURL Barme a 8 ans en 2016…

En 8 ans, l’EURL Barme a accumulé plein d’énergie, au moins pour les 10h prochaines années.

A cette occasion l’EURL Barme est donc heureuse d’offrir à ses fidèles ou futurs clients qui le demandent une réserve d’énergie d’autant de mAh que d’euros HT de prestations facturées en 2016, par unité entière de batterie de secours, dans la limite  de 5 batteries par client et des stocks disponibles.

10000mAhCaractéristiques détaillées.

2000mAhCaractéristiques détaillées.

 

Shutters and light control

PreProto

All tests are passed on the breadboard, it’s time to solder a first prototype:

MultiControlHere a Raspberry Pi accesses:

  • a 433 MHz emitter that controls power outlets, shutters’ motors and light switches,
  • a temperature and humidity sensor,
  • a luminosity sensor that gives a human perception of luminosity based on infrared and full spectrum diodes.

This home automation system already controls the temperature and humidity since several weeks. Now it also control the light and shutters.

In the background, the Raspberry Pi computes the sunrise and sunset times of the day. Half an hour after sunrise, it opens the shutters and switches off the light. Half an hour before sunset, it closes the shutters and switches on the light.

The next steps are to control a light dimmer and another luminosity sensor monitoring outside luminosity.

A light dimmer would allow to progressively shut on or off the light while the shutters close or open.

Monitoring outside luminosity will take into account the laziness of the sun (or rather the clouds hiding its light) some days.

Home automation is definitely a never ending story.

Encore mieux que le SaaS

On ne présente plus le SaaS (Software as a Service). Le aaS est devenu aussi tendance que le oo (orienté objet) des années 90. D’ailleurs cela fait bientôt 8 ans que l’EURL Barme est entrée dans le SaaS, avant même que le concept soit nommé ainsi.

Mais pas question de se reposer ; on a trouvé encore mieux, le RESTful (representational state transfer)!

SaaS_RESTTout en conservant tous les avantages du SaaS, l’API REST permet de déléguer juste les droits nécessaires pour mandater une application un service proposé par un tiers pour réaliser des actions sur des informations par ailleurs privées (et confidentielles).

Dans l’exemple illustré par la figure ci-dessus, c’est l’EURL Barme qui fournit un service permettant à un utilisateur d’automatiser des actions sur son compte chez OVH sans donner à l’EURL Barme le contrôle sur ses produits chez OVH.

Le mieux pour le comprendre est de l’essayer sur un cas concret : https://numerunique.fr/id/services/ABL/

Ce service permet de se protéger contre les appels téléphoniques importuns en seulement 2 clics :

  1. un premier clic pour récupérer le numéro de la plateforme d’appel qui vient de vous appeler,
  2. un deuxième clic pour ne plus recevoir d’appel de cette plateforme.

En plus cela rend service à tout le monde :

  • l’utilisateur ne reçoit plus d’appel importun,
  • le “conseiller” ne se fait plus jeter comme un malpropre,
  • la plateforme d’appel évite de perdre son temps à appeler une personne réfractaire.

C’est beaucoup mieux comme cela.

Why it’s helpful to have two?

SchemaAs described in the schema above there is one keyboard and a mouse shared by 4 computers. For the Pi zero, an USB / Ethernet adapter is added.

SharedHub

The USB shared hub is supposed to be powered by its USB connections. It works for the Mac mini but fails for the Pi zero.

Indeed, the shared hub draws 260 mA and the Pi zero draws 240 mA: both are too much for the Pi zero alone.

PowerDrownDefinitely, it is better to have two, even for power supplies and USB multi-meters.