All posts by admin

Comment perdre 2 ans de confiance en 2 heures

Les faits

08:44

Un client de l’EURL Barme signale l’indisponibilité d’un service.

08:55 Création d’un ticket incident :

Bonjour,

Que ce soit depuis l’extérieur (ping barme.fr 195.154.60.32) ou par le RPN (ping 10.x.x.x), le serveur ne répond pas.

Est-ce un problème réseau ?

Merci.

08:58 réponse du support :

Bonjour,

Je fais quelque vérifications et reviens vers vous dans les plus brefs délais.

Cordialement,

09:01 (support) :

Bonjour,

Je vois des logs sur le kvm qui peuvent indiquer une Kernel Panic.

M’autorisez-vous à passer le serveur en mode secours afin de faire quelques tests? Je reviendrai vers vous dès les tests finis.

Cordialement,

09:08 (EURL Barme) :

Oui, passez en mode rescue.

A noter, j’ai basculé mon IP failover sur mon serveur de secours.

09:36 (support) :

Bonjour,

Après les tests que j’ai effectué, il apparaît que le serveur est fonctionnel et n’a pas de souci matériel.

Je vous invite à regarder du côté Software/OS et installation ou configuration.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:40 (EURL Barme) :

ping x.x.x.x: 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C

Vous appelez ça fonctionnel ?

09:43 (support) :

Bonjour,

J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:45 (EURL Barme) :

Merci, je sais ce que c’est le mode secours.

Ne touchez donc plus à rien ; je vais investiguer par moi-même.

09:47 (EURL Barme) :

A noter le “Monitoring” :

Monitoring

Service Statut

Ping du serveur Disponible il y a 1 année historique

!!

09:54 (support) :

Bonjour,

Très bien.

Cordialement,

10:00 (EURL Barme) :

Mon serveur sd-x est à nouveau opérationnel, directement sans _aucune_ modification de sa configuration…

Un simple reboot aura donc suffit à le remettre en service ; c’est habituel de mettre en cause la configuration du client mais comment pouvez-vous le justifier ?

10:16 (support) :

Bonjour,

Je vois que le souci sur ce serveur est résolu après un simple reboot.

Je vous invite à clore le ticket et à le noter en laissant un commentaire.

Bonne journée,

10:20 (EURL Barme) :

Dans syslog, j’ai :

Apr 11 21:17:01 ol1 /USR/SBIN/CRON[46128]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
Apr 12 09:40:42 ol1 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Donc mon serveur est down depuis hier 21:17:01 et à nouveau opérationnel depuis 09:40:42 ce matin.

Et pourtant votre monitoring ne m’a pas alerté et prétend qu’il est disponible depuis 30/09/2015 09:52:18 ! ?

N’y aurait-il pas un problème de votre coté ?

10:44 (support) :

Bonjour,

Je transmet votre demande au service concerné et nous reviendrons vers vous dans les plus brefs délais.

Cordialement,

10:53 (EURL Barme) :

Cela vous amuse de passez mon serveur en mode rescue sans prévenir ?

11:03 (EURL Barme) :

Vos techniciens mettent mon site HS alors que je leur ai demandé de ne plus y toucher à 12/04/2017 09:45:53.

C’est pourtant pas un jouet ce serveur !

11:09 (support) :

J’ai prévenu mes collègues en charge

— —

Cordialement,

11:30 (support) :

Bonjour,

je reprends la suite du ticket au vu du signalement de celui-ci.

Un quiproquo et un échange trop rapide lors de la remonté a en effet entraîné un autre passage en secours.

Je confirme que le serveur est bien opérationnel de mon côté

Il ping bien en mode normal.

J’ai remis à jour le monitoring sur le serveur en espérant que vous soyez allertez la prochaine fois.

Rien ne vous empêche de mettre en place votre propre monitoring.

Cordialement – Technicien Premium

Commentaires

C’est toujours dans un contexte défavorable qu’un incident survient, en l’occurrence lors d’un déplacement, avec un contexte technique d’intervention et une disponibilité réduits.

Evidemment, c’est un client qui découvre et indique le problème ; en temps normal il aurait été découvert bien plus tôt et l’investigation de l’EURL Barme aurait été faite directement par une connexion sur la console du serveur, avant de faire intervenir le support.

Le support a été très réactif : réponse au ticket en 3 minutes. Son diagnostique initial (Kernel Panic) a été confirmé par le technicien Premium intervenu après escalade du problème.

Erreur du support : retour sans vérifier que le serveur est opérationnel après sortie du mode rescue. Il aurait été préférable d’attendre la fin du redémarrage.

Dérapage du support : mise en cause arbitraire du client (“J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.”)

C’est un grand classique de tous les supports de mettre systématiquement le client en cause. C’est évident que la plupart des remontées faites aux supports le sont par des personnes aux compétences informatiques modestes et de surcroît sans doute agressives car le problème pour lequel elles appellent est mal vécu. Mais ce n’est pas une raison pour mettre tout le monde dans le même panier et considérer, a priori, que l’origine du problème est du coté du client. La bonne approche devrait être de vérifier en premier s’il n’y a pas un souci du coté du prestataire et rien n’empêche, ensuite, de mettre le client face à ses responsabilités.

Erreur gravissime du support : passer un serveur de production (qui fonctionne !) en mode rescue sans autorisation du client. Là c’est le summum de l’inconséquence et totalement inadmissible de la part d’un service professionnel.

Ensuite c’est l’escalade et le problème atterri sur le dos d’un technicien “Premium” qui n’y est pour rien et ne peut plus rien y faire. Le terme “Premium” fait sourire avec sa connotation de “compétence supérieure”. Techniquement c’est sans doute vrai mais dans le contexte, ce sont davantage des compétences en communication qui sont requises.

Ce technicien “Premium” prendra la peine d’appeler pour signaler le retour au mode normal du serveur, ce qui est très bien et courageux de sa part mais son ton condescendant face à un interlocuteur avec 36 années d’expériences en informatique dans un tel contexte sera la cerise sur le gâteaux… Une formation de base à la communication lui serait bien utile.

Et pour la suite…

Les serveurs sous linux sont très fiables mais pas infaillibles. C’est justement la raison pour laquelle un serveur dédié utilisé pour un service critique  ou non doit être doublé par un clone synchronisé automatiquement et en permanence avec le serveur en fonction. Un kernel panic isolé est un aléa potentiel qui ne remet pas en cause le serveur ni sa configuration.

De même un incident isolé mal géré ne remet pas en cause un prestataire ni son professionnalisme.

L’EURL Barme ne changera donc pas ses serveurs impliqués dans cet incident et ne souhaite finalement qu’une chose : que cesse cette habitude des supports de mettre systématiquement en cause le client.

Epilogue

A l’occasion d’un autre souci technique (mineur celui-là) sur mes serveurs chez Online, j’ai eu affaire à un service de qualité, tant en compétences techniques qu’en communication.
Comme quoi cela dépend beaucoup des interlocuteurs ; il y en a des décevant mais aussi des très bons.
Ouf, mes serveurs sont décidément bien gérés et mes fournisseurs bien choisis 🙂

Why frameworks suck?

ol1

OPEN LOOK, once it was a must, now it’s but a mug – a nice and dear one though.

ol2

This is just an example of a wonderful framework: in 1990, it allowed building homogeneous UX for applications on top-of-the-moment desktop workstations.

As all really powerful frameworks, it required a long and tedious learning time – often with a steep initial learning curve – but with a beautiful result. The problem is that all the knowledge acquired to master it is now lost and this is the fate that doom all frameworks, thousands of framework since 1990.

The core of the problem is that frameworks provide high-level functionalities that don’t last more than the underlying fashion. As a programmer, one should look after learning how to build complex tools with low-level instructions: that will last forever.

Of course it is worst to reinvent the wheel; except for very special cases, nowadays nothing useful can be achieved with machine language. Using a higher-level language – whatever – is better. And while working within a team, frameworks provide a strong common context.

So yes, frameworks are useful somehow. But then use them scarcely, staying aware that you will soon need to forget all about them and learn the next one.

Beside, there is another drawback to the use of frameworks: they constrain what you can do with them. If your specifications is close to what a framework is meant for, you will probably benefit of its use. If not, then the challenge to adapt the framework to your need is so expensive that you end in adapting your specification to what the framework allows.

Framework are definitely incompatible with specific developments.

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.