GuiguiAbloc

Gestion d’une Cave à vins avec Tasker et Python

guiguiabloc — Mon, 31 Oct 2016 18:32:09 +0000

Je suis un grand amateur de vin et après m’être essayé au livre de cave papier (rébarbatif il va s’en dire) pour gérer le stocks de bouteilles de ma cave à vin, j’ai cherché et essayé nombre d’application (sous Linux il va s’en dire).
Malheureusement, je n’ai jamais trouvé mon bonheur, même si OpenCellar était quand même ce que j’avais trouvé de mieux.
J’ai donc profité de mon week-end pour mettre en place une gestion de cave à vins qui convient à mes besoins (et aux vôtres aussi peut être :))

J’attendais plusieurs choses d’une « application » de gestion de cave à vins et je suis surpris de ne rien trouver d’adéquat (ou alors j’ai mal cherché et je suis ouvert à vos suggestions :))

– une application légère (donc en mode web)
– fonctionnant sous Linux (donc le prérequis précédent convient)
– fonctionnant en local (pas de cloud machin truc)
– permettant l’ajout et le retrait de bouteille avec son smartphone (car se rendre dans la cave à vin, choisir la bouteille, puis aller sur son pc ou son portable, ouvrir le site web, retirer la bouteille, c’est un peu lourd, alors que le smartphone, on l’a souvent avec soi)

N’étant pas un grand développeur web dans l’âme (ni avec mes doigts d’ailleurs), j’ai d’abord cherché une base de site sur laquelle commencer car je n’avais pas vraiment envie de passer plusieurs heures a faire du css, du div et toute la joie inhérente à ce genre d’application.

J’ai trouvé les projets de Christophe Coenraets sur Github qui à écrit plusieurs articles et applications pour gérer sa cave à vin (je vous invite d’ailleurs à lire ses billets à ce sujet (http://coenraets.org/blog/2011/12/restful-services-with-jquery-php-and-the-slim-framework/ , http://coenraets.org/blog/2011/12/restful-services-with-jquery-and-java-using-jax-rs-and-jersey/ , http://coenraets.org/blog/2012/01/using-backbone-js-with-a-restful-java-back-end/).
Mon choix s’est porté sur sa version PHP, plus léger pour moi à mettre en œuvre.
Le plus de son application, c’est la présence d’une API permettant d’ajouter, mettre à jour ou lister le contenu de sa cave (oh voui j’adore ça lister mes vins avec un curl -i -X GET http://localhost/cellar/api/wines )

Je ne vous ferais pas l’affront de la mise en place du dépôt sous votre serveur web fétiche (penser à activer les méthodes PUT,DELETE et POST), cela coule de source.

On peuple la base et voila le premier résultat (a peu près, la c’est ma version modifiée)

Car oui j’ai d’abord modifié quelques fonctions.
Pour gérer les bouteilles avec mon smartphone, j’ai d’abord pensé à des étiquettes RFID, mais avec le nombre de précieux flacons, j’allais exploser mon budget « loisir« .
Donc mon choix s’est plutôt tourné vers un élément que l’on retrouve « presque » sur toutes les bouteilles, le code barre (ou EAN 13 pour les puristes).
Dans l’ensemble, j’ai très peu de bouteilles sans, principalement des achats direct au producteur, donc ne saisir qu’une infime quantité de stock à la mimine m’allait parfaitement (au pire, je pourrais faire du RFID avec elles).

NB: Dans ma folie habituelle, je vous avouerais être d’abord parti sur de la reconnaissance de l’étiquette avec OpenCV et de l’OCR mais vu l’ampleur du projet, je me suis vite raisonné

Mes premières modifications apportées sur le code : ajout du champ EAN, traduction des champs, modification de la recherche sur la région en plus du nom et ajout d’un champ quantité.

Mes premiers tests de l’API était sympa mais il m’en fallait plus.
Etant plus à l’aise avec Python que PHP ou JavaScript, j’ai rapidement codé ma propre API.

Celle ci permet plusieurs choses :
– POSTer le code EAN d’une bouteille et la créer si besoin (en mettant la quantité à 1 par défaut et en lui affectant l’image ‘codeEAN’.png), si le code existe, ajouter +1 à la quantité. Possibilité également de faire -1 sur la quantité.

class addean:
def POST(self,uri):
try :
ID = web.data()
except:
return web.badrequest()
con = MySQLdb.connect(host=mysqlhost, user=mysqluser, passwd=mysqlpasswd, db=mysqldb);
cur = con.cursor()
print ID
cur.execute("""SELECT * from wine where EAN=%s""", (ID,))
result = cur.fetchone()
if result is None:
print "no bottle"
print ID
data = {'EAN': ID, 'picture': ID+'.png'}
data = json.dumps(data)
req = urllib2.Request(url, data, {'Content-Type': 'application/json'})
f = urllib2.urlopen(req)
response = f.read()
f.close()
else:
cur.execute("""UPDATE wine SET nombre=(nombre+1) where EAN=%s""", (ID,))
con.commit()
print "Number of rows updated: %d" % cur.rowcount
con.close()

class removeean:
def POST(self,uri):
try :
ID = web.data()
except:
return web.badrequest()
con = MySQLdb.connect(host=mysqlhost, user=mysqluser, passwd=mysqlpasswd, db=mysqldb);
cur = con.cursor()
print ID
cur.execute("""SELECT * from wine where EAN=%s""", (ID,))
result = cur.fetchone()
if result is None:
print "new bottle"
print ID
data = {'EAN': ID, 'picture': ID+'.png'}
data = json.dumps(data)
req = urllib2.Request(url, data, {'Content-Type': 'application/json'})
f = urllib2.urlopen(req)
response = f.read()
f.close()
else:
cur.execute("""UPDATE wine SET nombre=(nombre-1) where EAN=%s""", (ID,))
con.commit()
print "Number of rows updated: %d" % cur.rowcount
con.close()

– POSTer la photo de l’étiquette et l’inclure dans la fiche.

class index:
def POST(self,uri):
try:
web.cookies().filename
filenamereceived = web.cookies().filename
except:
filenamereceived == "generic"
try :
data = web.data()
except:
return web.badrequest()
if data == "":
return web.badrequest()
print filenamereceived
b64response = base64.b64encode(data)
fh = open(winepics+filenamereceived+".png", "wb")
fh.write(b64response.decode('base64'))
fh.close()
return "200 STORED"

Maintenant que mon API était prête, il fallait pouvoir utiliser le smartphone.

La meilleure application d’automatisation sous android est pour moi Tasker. De plus, de nombreux plugins existent et l’un des maîtres du plugin Tasker est sûrement João Dias alias joaomgcd.
J’utilise quasiment tout ses plugins (qui ne coûte pas grand chose pour une efficacité redoutable, dont le fameux AutoRemote) et en cherchant un plugin « barcode » (code barre) pour Tasker, et bien il existe AutoBarcode ! Magique, ce type est un génie

Un peu de « codage » Tasker pour réaliser ce que je veux :

Lancer un scan de code barre,

une fois effectué, lancer une « scène » Tasker me demandant si je veux ajouter ou retirer cette bouteille :

– je retire, je fais -1 sur la quantité
– j’ajoute, je fais +1 si le code EAN existe, sinon j’appelle l’API du site pour créer la bouteille avec son code EAN. Je continue en demandant si je veux ajouter une photo, si non, je sors, si oui, je lance l’appareil photo qui me permet de photographier l’étiquette et de la POSTer en la nommant ‘codeEAN’.png.

Bien sur la création de la bouteille lie automatiquement l’image à l’url ../pics/’codeEAN’.png.

Il ne me reste alors qu’a me rendre sur le site web pour compléter la fiche de la bouteille.

En quelques heures, j’ai enfin pu me créer un site de gestion de ma cave à vin efficace et qui répond à mes besoins.
L’ajout ou le retrait d’une bouteille se fait avec le smartphone en premier lieu (on peut le faire sur le site aussi).

Si vous voulez vous aussi déployer ce genre d’application chez vous, j’ai bien évidemment tout mis sur mon Github en forkant le projet de Christophe et en y ajoutant les éléments nécessaires

Amusez vous bien

Voyager dans les yeux de Morgan

guiguiabloc — Mon, 23 May 2016 19:54:36 +0000

J’avoue qu’il est assez rare que j’écrive des billets sur d’autres choses que mes passions primaires :p, mais cela arrive parfois.

J’ai connu Morgan par Twitter, au début sans trop y faire attention et puis je regarde son profil et découvre son site.

Et là, c’est un peu le choc pour moi. Morgan s’est donné un objectif, visiter 50 pays avant ses 50 ans.

En soi, c’est déjà un petit exploit et surtout un vieux rêve enfoui pour moi qui approche doucement de la cinquantaine.

Rien que ce « challenge » m’a remis en question.
J’ai bien vécu, j’ai fait des tas de boulots divers et variés, rencontré des tas de personnes formidables, fondé une famille, vécu des expériences inédites et indicibles pour certaines, visité quelques pays mais lire cet objectif m’a définitivement remis en place.
Oui, je suis passé à côté de quelque chose.
Ce constat que j’ai pris en pleine gueule m’a fait encore plus apprécier l’individu.

Et puis, j’ai lu, relu et vécu ses voyages. Car ce monsieur écrit bien, très bien même. Des récits de voyages, j’en ai dévoré pourtant plusieurs, mais Morgan à cette touche personnelle d’écriture qui fait que l’on vit avec lui son voyage, ses découvertes, ses déconvenues et ses sensations.

Alors oui il est doué, très doué même. Il s’est donné le courage et la volonté de vivre sa passion et d’atteindre son ambition mais surtout, et c’est pour moi
le plus important, il nous l’a fait vivre avec ses mots à lui, son regard et son cœur.

Je ne le connais pas encore réellement (ça devrait venir, parce que parmi toutes ses qualités, il est breton et donc on se retrouvera forcément autour d’un verre à Brest même !), mais vivre à travers ses écrits ses voyages me rapproche de lui, de mes vieux rêves regréttés et me fait découvrir le monde comme j’aurais aimais le découvrir moi même.

Alors ce billet n’est qu’anecdotique, n’est là que pour exprimer mes sincères remerciements à Morgan pour le temps qu’il passe à nous faire partager ses voyages, mais surtout, je vis à travers ses écrits des histoires dont j’aimerais être le héros. Et après tout, pourquoi pas 50 pays avant mes 70 ans…

Pour le découvrir, c’est ici : https://lesvoyagesdemorgan.fr/

PS: je suis les voyages d’un autre couple qui fait le tour du monde, Chloé et Romain sur http://www.playingtheworld.com/ , à lire également et avec eux trois, prenez un vrai bol d’air…

Jouons avec le WD Tv Live et UPNP

guiguiabloc — Sun, 06 Sep 2015 13:02:33 +0000

Depuis des années je dispose d’un boîtier WD TV Live qui me permet de lire sur la télévision les vidéos stockées sur mon NAS Synology.
Efficace, ce petit boîtier fonctionne parfaitement bien et a trouver naturellement sa place dans le meuble TV.

J’avais un peu oublié sa présence jusqu’à me rendre compte que mon système domotique ne le connaissait pas.
Qu’a cela ne tienne, c’était le moment de jouer avec

Sur mon téléphone Android, je dispose d’une application, WD TV Remote, qui permet de contrôler le boitier par wifi.
Cela suffit à se dire qu’il doit être possible d’interagir avec lui par le réseau local.

Qui dit boîtier multimédia, dit forcement UPNP. Une petite découverte via l’outil gssdp-discover du projet gupnp-tools nous donne les points d’entrées du boîtier (je vous passe l’ensemble des équipements trouvés pour se concentrer sur le WD) :

gssdp-discover -i eth0.8 --timeout=5
Using network interface eth0.8
Scanning for all resources
resource available
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77::upnp:rootdevice
Location: http://wdtvlive:10184/
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77
Location: http://wdtvlive:10184/
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77::urn:schemas-upnp-org:device:MediaRenderer:1
Location: http://wdtvlive:10184/
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77::urn:schemas-upnp-org:service:AVTransport:1
Location: http://wdtvlive:10184/
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77::urn:schemas-upnp-org:service:ConnectionManager:1
Location: http://wdtvlive:10184/
resource available
USN:      uuid:5e881b94-0090-a9c7-b3b0-56fc82ddce77::urn:schemas-upnp-org:service:RenderingControl:1
Location: http://wdtvlive:10184/

Une visite sur l’url http://wdtvlive:10184/ nous donne un joli arbre xml

...
urn:schemas-upnp-org:service:AVTransport:1urn:upnp-org:serviceId:AVTransportMediaRenderer_AVTransport/scpd.xmlMediaRenderer_AVTransport/controlMediaRenderer_AVTransport/event
...

Déformation professionnelle oblige, je lance un tcpdump sur mon téléphone et j’agis sur la télécommande WD TV Remote.

On retrouve bien le POST http sur le point d’entrée du boîtier et la réponse de se dernier.

POST /MediaRenderer_AVTransport/control HTTP/1.1
Accept: */*
User-Agent: Twonky-NMC/7.3-Android (Android/4.4.2 (Build KOT49H); samsung/GT-I9505) DLNADOC/1.50
Host: wdtvlive:10184
SOAPACTION: "urn:schemas-upnp-org:service:AVTransport:1#GetTransportInfo"
Content-Type: text/xml; charset="utf-8"
Content-Length: 312

0HTTP/1.1 200 OK

Transfer-Encoding: chunked
EXT:
CONTENT-TYPE: text/xml; charset="utf-8"
SERVER: POSIX, UPnP/1.0, Intel MicroStack/1.0.1497
1BF



PAUSED_PLAYBACKOK1

Génial

Ne reste plus qu’a tester tout cela avec une belle requête curl (accrochez-vous à votre clavier..) :

curl -H "Content-Type: text/xml" -H 'SOAPACTION: urn:schemas-upnp-org:service:AVTransport:1#GetTransportInfo"' -XPOST -d '0' http://wdtvlive:10184/MediaRenderer_AVTransport/control


PAUSED_PLAYBACKOK1

Elle est pas belle la vie ? :p

On voit dans la réponse le mode actuel du boîtier :
PAUSED_PLAYBACK

En remplacant la méthode « GetTransportInfo » par « GetPositionInfo », le WD Tv nous donne tout un tas d’information dont le film actuellement joué :

curl -H "Content-Type: text/xml" -H 'SOAPACTION: urn:schemas-upnp-org:service:AVTransport:1#GetPositionInfo"' -XPOST -d '0' http://wdtvlive:10184/MediaRenderer_AVTransport/control


100:22:46Naruto Shippuden 170.mkvobject.item.videoItemUnknownfile:///tmp/media/nfs/NAS/FILMS/Naruto/Naruto.Shippuden.Saison.7/Naruto%20Shippuden%20170.mkvfile:///tmp/media/nfs/NAS/FILMS/Naruto/Naruto.Shippuden.Saison.7/Naruto%20Shippuden%20170.mkv00:08:00NOT_IMPLEMENTED21474836472147483647

Ici je vois que Junior regarde le fichier « Naruto Shippuden 20170.mkv » (ok pas très instructif comme film…) et ce depuis 8 minutes.

Python disposant de l’excellent module lxml pour parser les fichiers XML, un coup de scripting tout simple permet d’isoler les informations importantes :

from lxml import etree

tree = etree.parse('le fichier xml')
for element in tree.iter('CurrentTransportState'):
result = element.text
print "WD TV Live status: "+result

tree = etree.parse('le fichier xml')
for element in tree.iter('TrackURI'):
film = element.text
print "WD TV Live joue : "+film

WD TV Live status: PLAYING
WD TV joue: file:///tmp/media/nfs/NAS/FILMS/Naruto/Naruto.Shippuden.Saison.7/Naruto%20Shippuden%20170.mkv

Toutes les commandes disponibles sont référencées sur l’upnp database.

Maintenant le serveur domotique connait l’état du boitier WD TV Live ainsi que le fichier joué sur le téléviseur.
Ce qui nous permet par exemple de programmer une surveillance de ce que Junior regarde…

tree = etree.parse('le fichier xml')
for element in tree.iter('TrackURI'):
film = element.text
if "Pr0n_A_Papa" in film:
# power off immédiat de la télévision

J’espère que ce petit billet vous donnera envie d’aller explorer un peu les points d’entrée UPNP des différents équipements de votre domicile

EDIT : Pour éteindre et allumer votre WD TV Live par une simpe requête http, il suffit d’envoyer le POST suivant :
curl -XPOST -d ‘{« remote »: »w »}’ http://wdtvlive/cgi-bin/toServerValue.cgi

Amusez-vous bien

l’API Domogeek, clap de fin

guiguiabloc — Sat, 01 Aug 2015 20:27:36 +0000

EDIT DU 06/08/2015 : Bonne nouvelle ! Le groupe Entropia SA basé au Luxembourg m’a offert gracieusement l’hébergement de l’API. Domogeek renait donc de ses cendres
Temporairement, l’url de l’API est http://domogeek.entropialux.com

C’est avec un grand regret que je vais cesser d’offrir publiquement l’accès à l’API Domogeek, après 1 an d’existence.

Le succès a était au rendez vous puisque ses dernière semaines, le nombre d’appels à l’API dépassait largement les 500 000 par jour.
J’ai tout fait pour supporter la charge (le taux de disponibilité (affiché publiquement par les sondes PingDom) a toujours était supérieur à 99,5%)a et pour cela j’ai du investir du temps mais surtout de l’argent pour payer la location des serveurs chez OVH.

D’une mentalité d’entraide et de partage innée chez moi, j’ai donc sollicité les utilisateurs pour faire un modeste don afin de m’aider à régler ses frais.
En deux appels, j’ai récolté la somme faramineuse de… 50 euros, avec en prime une suppression de mon post sur le forum Jeedom pour la raison que les appels aux dons sur le forum d’un produit à vocation commerciale n’avait pas lieu d’être. Soit. Je me suis longuement expliqué avec l’équipe et je concois que cela entrave le fonctionnement de leur businness-plan, mais bon, les plugins open, c’est un peu la force de Jeedom aussi…
Après, j’avais une position difficile, je ne suis pas l’auteur du plugin (c’est tmartinez, qui d’ailleurs a était parmi les premiers a faire un don pour l’api), et donc je ne suis qu’un fournisseur de service sans lien avec Jeedom mais j’ai eu un peu de mal à avaler la pastille, moi qui le premier revendique le partage, l’entraide et la transparence.

Je ne peux que remercier chaleureusement les 7 (:p) utilisateurs qui ont voulu m’aider : tmartinez, Kheops37, Stéphane (lademan ?), Mickael (Mika ?), edreams, mamatdv, lionel

Le code source est toujours disponible sur GitHub et vous pouvez donc l’héberger localement pour continuer à utiliser le plugin de tmartinez (pour les utilisateurs de Jeedom) ou en direct pour les autres.

Je suis de cette génération de barbu qui a toujours offert de l’entraide, qui a toujours partagé ses découvertes, ses modestes développements et je suis aujourd’hui déçu que cette mentalité tend a disparaître de plus en plus.
Sur IRC, sur les forums, je voyais déjà cette aide bénévole se transformait en assistanat (les gens ne cherche plus et attende la réponse tout de suite avec un merci donné du bout des doigts, quand il existe) et cette aventure m’a malheureusement démontré qu’on ne peut plus solliciter financièrement un coup de main, il faut obligatoirement faire payer le service.

Je salue les quelques irréductibles qui continue à offrir des services à la communauté en payant de leur personne et de leur porte-monnaie les infrastructures nécessaire (j’en oublierais sûrement donc spécial coup de chapeau à domotics du forum toute la domotique, à Jean-Philippe Encausse pour son projet SARAH, à l’équipe Domogik, à l’équipe Imperihome etc… J’en oublie plein mais ils se reconnaîtrons forcément :D)

A vous tous les utilisateurs de tout ses programmes, ses services, ses aides gratuites, n’oubliez jamais que derrière il y a souvent 1 ou quelques personnes qui vous offrent bénévolement de leur temps et souvent de leur argent pour vous rendre la vie agréable, alors un coup de main, même minime, cela donne toujours beaucoup de chaleur et de reconnaissance…

« La valeur d’un homme tient dans sa capacité à donner et non dans sa capacité à recevoir. » Albert Einstein

MQTT, faites communiquer vos objets simplement

guiguiabloc — Thu, 13 Nov 2014 13:58:13 +0000

La communication entre « objets connectés » ou tout simplement dans votre environnement domotique est probablement l’une des choses essentielles.

Dans les protocoles de communication que l’on retrouve le plus souvent, vous avez bien sûr http (et ses fameuses API Rest (ou pas)), xPL (dont je vous ai souvent parlé), XAP, XMPP, SNMP (si si je vous assure qu’il y en a qui ont essayé…) et d’autres trucs plus ou moins bien conçus.

Un protocole devrait pourtant tenir rapidement le « haut du pavé » et devenir le standard de l‘i.o.t (comprendre l’internet des objets (ou « internet of things » pour reprendre le terme officiel) : MQTT.

Et pour couronner le tout, MQTT est devenu depuis quelque jours un standard s’échange OASIS (OASIS (Organization for the Advancement of Structured Information Standards) est un consortium chargé d’aider au développement, à la convergence et l’adoption de standards ouverts pour « la société mondiale de l’information » (oui je mets des guillemets…). On y trouve des références qui ne laissent pas de marbre https://www.oasis-open.org/member-sections/ )

C’est bien joli tout cela, mais comment ça marche ?

MQTT est un service de messagerie TCP/IP simple et extrêmement léger dans le sens où des messages de toutes sortes (le contenu importe peu du moment que le message n’excède pas 256Mo (oui oui, vous pouvez envoyer des photos de la cousine Tatiana par MQTT…)) peuvent être transmis.

Les messages sont envoyés par des publieurs (les publishers) sur un canal (une chaîne d’information si vous voulez) appelé Topic. Ces messages peuvent être lus par les abonnés (les subscribers). Les Topics (ou les canaux d’informations) peuvent avoir une hiérarchie qui permet de sélectionner finement les informations que l’on désire.

Par exemple, le topic /sensor/temperature/salon ne me donnera que les températures du salon si je m’y abonne (et ma sonde de température dans le salon publiera sur le topic sa valeur régulièrement).
Je pourrais aussi m’abonner au topic /sensor/temperature/# pour avoir toutes les températures, ou au topic /sensor/# pour avoir toutes les remontées des sondes (plus de de détails sur les « wildcards » sur les topics sont disponibles ici http://mosquitto.org/man/mqtt-7.html )

Bien sur le topic pourrait aussi être /nagios/serveur/ping

Afin de préserver un peu de discrétion, vous pouvez bien évidemment définir qui a le droit de publier sur tel ou tel Topic et également qui a le droit de s’y abonner.

La sécurité peut se faire au niveau transport en SSL/TLS, et au niveau authentification, par certificats SSL/TLS ou couple user/mot de passe.

Une autre chose importante est la notion de QoS dans les messages qui transitent via MQTT (c’est le publieur qui définit la qualité du message).

Un message de QoS niveau 0 « At most once » sera délivré tout au plus une fois. C’et a dire qu’il n’est pas stocké et probablement envoyé sans garantie de réception (un peu comme un message UDP xPL par exemple), le broker (le serveur MQTT) n’informe pas l’expéditeur qu’il l’a reçu et le message peut être perdu si le client se déconnecte ou si le serveur s’arrête.
Un message de QoS niveau 1 « At least once » sera livré au moins une fois. C’est à dire que le client le transmettra plusieurs fois s’il le faut jusqu’à ce que le Broker lui confirme qu’il a était transmis sur le réseau (quitte a l’envoyer en rafale plusieurs fois).
Un message de QoS niveau 2 « exactly once » sera obligatoirement sauvegardé par l’émetteur et le transmettra toujours tant que le récepteur ne confirme pas son envoi sur le réseau. La principale différence étant que l’émetteur utilise une phase de reconnaissance plus sophistiquée avec le broker pour éviter une duplication des messages (plus lent mais plus sûr).

Je ne vais pas peaufiner les détails du protocole, je vous invite fortement à en lire les spécifications : http://www.ibm.com/developerworks/library/ws-mqtt/ et toute la documentation qui va bien http://mqtt.org/documentation

Vous trouverez des Brokers et des clients MQTT dans votre langage de prédilection ainsi que des projets bien avancés.
Si vous êtes un adepte de Node JS, je vous invite à regarder le travail de Matteo Collina qui est un gros contributeur MQTT (pour ne citer que les plus connus : MOSCA, QUEST …)

Maintenant un peu de pratique.

D’abord, installons un broker/serveur MQTT. Celui que j’affectionne est Mosquitto.
Vous trouverez les packages pour différentes distributions GNU/Linux ou *BSD (même pour votre raspberry pi ) ou vous pouvez le compiler depuis les sources.

La configuration se fait dans le fichier /etc/mosquitto/mosquitto.conf.
Pour nos tests, nous allons juste réaliser une configuration basique:

log_type debug
allow_anonymous false
password_file /etc/mosquitto/accesslist.txt

Nous interdisons l’accès en anonyme et nous allons autoriser les connexions uniquement avec un identifiant mot de passe (dont la liste se trouve dans un simple fichier de la forme user:motdepasse (PS: l’utilitaire mosquitto_passwd vous aidera à le créer)
Une fois lancé, le serveur écoute sur le port 1883 par défaut.

Un petit script python tout bête pour nous abonner à un topic et afficher les messages (vous trouverez plein d’exemples et d’articles intéressants sur le site de Jan-Piet Mens : http://jpmens.net/2013/02/25/lots-of-messages-mqtt-pub-sub-and-the-mosquitto-broker/ )

#!/usr/bin/env python

import mosquitto

def on_message(mosq, obj, msg):
print "%-20s %d %s" % (msg.topic, msg.qos, msg.payload)
mosq.publish('pong', "Thanks", 0)

def on_publish(mosq, obj, mid):
pass

cli = mosquitto.Mosquitto()
cli.on_message = on_message
cli.on_publish = on_publish
cli.username_pw_set("guigui", password="abloc)
cli.connect("broker.guiguiabloc.fr", 1883, 60)
cli.subscribe("/test/#", 0)

while cli.loop() == 0:
pass

Lancer le script et vous devriez voir dans les logs (/var/log/syslog par défaut) de votre broker, la connexion se faire :

Nov 13 10:57:17 eos mosquitto[19305]: Sending CONNACK to mosq/69ED9C77592ADC1E7D (0)
Nov 13 10:57:17 eos mosquitto[19305]: Received SUBSCRIBE from mosq/69ED9C77592ADC1E7D
Nov 13 10:57:17 eos mosquitto[19305]: #011/test/# (QoS 0)
Nov 13 10:57:17 eos mosquitto[19305]: Sending SUBACK to mosq/69ED9C77592ADC1E7D

Maintenant, publions un message.

mosquitto_pub -h broker.guiguiabloc.fr -u "user" -P "motdepasse -t /test -m "Hello la foule"

Le message s’affiche dans votre client :

/test                0 Hello la foule

et dans les logs :

Nov 13 11:00:42 eos mosquitto[19305]: Received PUBLISH from mosq_pub_21013_eos.sty (d0, q0, r0, m0, '/test', ... (14 bytes))
Nov 13 11:00:42 eos mosquitto[19305]: Sending PUBLISH to mosq/69ED9C77592ADC1E7D (d0, q0, r0, m0, '/test', ... (14 bytes))
Nov 13 11:00:42 eos mosquitto[19305]: Received PUBLISH from mosq/69ED9C77592ADC1E7D (d0, q0, r0, m0, 'pong', ... (6 bytes))

Plus drôle, il existe même une application android pour publier et s’abonner à un broker MQTT : https://play.google.com/store/apps/details?id=at.tripwire.mqtt.client&hl=fr_FR

Sachez aussi que vous pouvez, en websocket, pousser directement les messages dans un navigateur web http://jpmens.net/2014/07/03/the-mosquitto-mqtt-broker-gets-websockets-support/

Alors c’est pas génial ?

Bien évidemment vous imaginez toutes les possibilités offertes par ce protocole. Certains fous furieux ont déjà commencé à coder en LUA pour la Vera, un client MQTT .

Sachez également qu’un projet domotique très prometteur inclus déjà MQTT : openHAB
Je risque donc de vous en reparler

Autre chose à souligner, il existe un très bon projet : mqttwarn

Ce projet est une sorte de passerelle qui s’abonne à « tout » les topics et qui se charge ensuite de les transmettre à divers clients (pushover, mysql, redis, twitter etc…)

Même votre serveur de téléphonie Asterisk peut « causer MQTT » : https://github.com/zeha/agi-mqtt

Maintenant, peut-on considérer que c’est la panacée et que cela va supplanter tout ce qui existe.
Oui et non (une bonne réponse comme je les aime).

Oui parce que l’on standardise un protocole de transport d’information et que les systèmes de messages de type MQ, sont très performant. C’est temps réel, ça marche très bien en websocket, c’est déjà inclus dans plein de langage, bref, que du bonheur. De plus, l’implémentation est facile.

Non parce que l’on standardise le transport et pas le message reçu mais cela serai toujours la bête noire (même une API Rest vous retourne un json dans la syntaxe qu’il veut, à vous de vous adapter).

Toutefois, je pense sincèrement que MQTT est un protocole terriblement intéressant et qui peut nous rendre grandement service, reste désormais à l’intégrer partout.

Amusez-vous bien

Domotique et Intelligence : la communication

guiguiabloc — Wed, 13 Aug 2014 10:51:09 +0000

Quelques mois plus tôt, j’avais évoqué la nécessité de la connaissance pour un environnement domotique (cf. http://blog.guiguiabloc.fr/index.php/2014/01/04/domotique-et-intelligence-la-connaissance/)

J’aimerais maintenant aborder avec vous la deuxième partie, la communication.

A suivre l’actualité des constructeurs et les retours ou discussions des utilisateurs de domotique sur les blogs ou forums divers, j’ai l’impression assez désagréable de vivre à nouveau le même scénario qu’il y a plusieurs années quand l’informatique personnelle s’est généralisée auprès du grand public.

Tout le monde y va de son interface, de son protocole de communication, de sa box révolutionnaire, de ses structures http etc.. Bref, « c’est moi qui ait la bonne solution et les autres n’ont qu’a s’adapter ».

Alors heureusement, un peu d’intelligence à effleurer ce microcosme car la plupart des solutions « tout-en-un » intègre des api permettant d’interagir via des requêtes http.Ne vous réjouissez tout de même pas trop vite, chaque API est différente (REST (ou pas), SOAP (ou pas), LUA_API_QUEJESUISSEULEACOMPRENDRE(c), etc..)
Parce que s’il vous prend l’idée saugrenue (ou pas…) de faire discuter votre box Fibaro avec un RFXtrx branché sur votre VeraLite ou votre PC, vous allez y passer un peu de temps…

Ne soyez pas médisant, j’ai pris la solution la plus simple et ce n’est qu’un exemple très basique, j’aurais pu pousser le concept jusqu’à exiger que je puisse communiquer via mon smartphone avec Tasker qui appelle ma centrale MyFox, qui interroge le module fibaro relié à mon eedomus en fonction des sondes de températures dont les données remontent sur mon RFXCOM Lan en supposant que le module X10 relié à mon CM15 soit « on ».

C’est complètement idiot, j’avoue, mais c’était un exemple un peu capillotracté du travail à fournir pour pouvoir faire discuter tout ses équipements entre eux.

Ne croyez pas que cela se borne à vos box domotiques, tout ceux qui ont un jour ajouter un serveur Asterisk pour gérer leur téléphonie a la maison se sont demandé « et comment que je discute entre ce serveur et ma box ???? »
Car oui mon bon monsieur, c’est la génération des objets connectés !!! Connectés, oui, mais à moi tout seul parce que le dialogue avec les autres, très peu pour moi !

Nous sommes tout les jours submergés de ces nouveaux objets qui doivent nous rendrent la vie plus facile, mais ne croyez pas qu’il va vous être facile de l’intégrer à votre monde, chacun parle sa propre langue et dans le terme « connecté » largement usité par les médias et les constructeurs, on parle rarement de communication, la faute à qui ?…

Pour sauver ce petit monde de passionnés de domotique perdu dans les méandres d’un univers sourd et aveugle, il existe quand même des projets qui cherche à unifier ou interagir avec tout cela.

Nul besoin de vous présenter Imperihome qui risque fortement de devenir « LA » solution Android pour faire causer ensemble tout ça.

En protocole « natif », xPL (dont je suis un fervent défenseur :p (mais ça vous le savais déjà si vous êtes habitué de ce blog)), a du mal a se faire sa place malgré un concept simple et plutôt efficace.

Plus récemment, xAAL, prometteur, une grosse évolution de ce que l’on peut faire dans la communication des objets connectés et de la domotique en générale (quand on peut parler des copains :p @jkxathome )

Bref, vous l’avez compris, quand on veut discuter simplement avec toutes nos passerelles domotiques ou nos objets connectés, cela devient vite très problématique parce qu’il faut tout changer selon avec qui vous souhaitez communiquer.

Dans mon billet précédent de cette « série », j’avais évoquer le fait que mon serveur domotique était une sorte de centralisateur des informations remontées par tout ce qui gravitait autout de lui.
Pour la communication, je suis partie du même constat.
Je ne veux pas m’adresser dans des langues différentes à chacun des périphériques, mais uniquement à une « porte d’entrée » et dans un langage compréhensible.

Un des exemples les plus démonstratifs est le dernier projet dont je vous avais fait part, api.domogeek.fr.
Vous envoyez une requête simple pour connaître une information basique et publique sans vous soucier des méthodes différentes d’appels uniques à chacune de ses informations (les dates de vacances scolaires, la vigilance météo etc…).

Dans votre environnement domotique, cela doit être la même chose.
Un point d’entrée unique, structuré, défini, qui se chargera de discuter ensuite dans le langage de chaque périphérique.

La meilleure façon de mettre cela en place est une API de type REST.

La mise en oeuvre est simple et à la portée de tous (surtout si vous avez décider d’utiliser un vrai langage comme python (troll inside).

Une fois déployé, il devient facile pour tout vos scripts, applications smartphones, etc… de faire appel à cette API pour communiquer avec vos équipements sans vous souciez de vous rappeler comment doit s’écrire la requête http vers tel ou tel module.

Prenons l’exemple du lancement d’une scène sur une VeraLite.

Si je dois interroger directement la VeraLite par http, ma requête ressemblera à cela :

http://vera:3480/data_request?id=lu_action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=RunScene&SceneNum=1

(facile à retenir, hein ? :p)

Imaginons maintenant que l’on écrive une simple fonction en python pour cela :

def setscene(device):
  url = 'http://vera:3480/data_request?'
  values = {'output_format' : 'text', 'id' : 'lu_action','serviceId': 'urn:micasaverde-com:serviceId:HomeAutomationGateway1', 'action' : 'RunScene', 'SceneNum' : device }
  try:
    data = urllib.urlencode(values)
    req = urllib2.Request(url+data)
    sendrequest = urllib2.urlopen(req)
    responsefromvera = sendrequest.read()
    if responsefromvera != "OK":
      return web.notfound()
      return "200 SUCCESS"
  except Exception, detail:
    print "Error ", detail

Maintenant, codons une API Rest toute bête (attention c’est du brut de fonderie bien crado) :

#!/usr/bin/python
# Gruik coded by GuiguiAbloc
import urllib, urllib2, web, re
def scenevera(device):
  url = 'http://vera.styx.net:3480/data_request?'
  values = {'output_format' : 'text', 'id' : 'lu_action', 'serviceId' : 'urn:micasaverde-com:serviceId:HomeAutomationGateway1', 'action' : 'RunScene','SceneNum' : device }
  try:
    data = urllib.urlencode(values)
    req = urllib2.Request(url+data)
    sendrequest = urllib2.urlopen(req)
    responsefromvera = sendrequest.read()
    if responsefromvera != "OK":
      return web.notfound()
      return "200 SUCCESS"
  except Exception, detail:
    print "Error ", detail

web.config.debug = False

urls = (
'/scene/(.*)', 'scenes'
)

render = web.template.render('templates/', globals={'re':re})
app = web.application(urls, globals())

class scenes:
  def POST(self,uri):
    request = uri.split('/')
    if request == ['']:
      return web.badrequest()
    if request[0]:
      device = request[0]
      try:
        result = scenevera(device)
        return "200 SUCCESS\n"
      except:
        web.notfound()

if __name__ == '__main__':
app.run()

Démarrez votre script (python monscript.py), il écoutera par défaut sur le port 8080 et lancer une requête http de type « POST » (avec surement le meilleur outil sous linux pour contruire des appels http de toutes sortes, cURL) :

curl -XPOST http://localhost:8080/scene/13

Et hop, magique, la scène 13 est lancée

Maintenant, vous avez une base de données MySQL (par exemple) dans laquelle vous stockez amoureusement toutes les valeurs de températures de vos sondes Oregon.
Interrogeons simplement la dernière valeur dans votre BDD de la même façon.

D’abord la fonction, on va imaginer que votre table « sensor » contient les colonnes « sensorRoom » qui défini le nom de votre sonde et « sensorValue », la valeur enregistrée :

...
import MySQLdb
...
def tempdb(ID):
  try:
    if ID == "salon":
      ID = "TempSalon"
    if ID == "exterieur" or ID == "dehors" or ID == "ext":
      ID = "TempExt"
    conn = MySQLdb.connect('localhost', 'mabase', 'login', 'motdepasse')
    cur = conn.cursor()
    cur.execute("SELECT sensorValue from sensor where sensorRoom='%s' ORDER BY idx DESC limit 1" % ID )
    result = cur.fetchone()
    return result[0]

  except MySQLdb.Error, e:
    print "Error %d: %s" % (e.args[0], e.args[1])
    return None
  conn.close()

On l’inclut dans notre API Python et l’on rajoute les appels :

...urls = (
'/scene/(.*)', 'scenes',
'/temp/(.*)', 'temp'
)
...
class temp:
  def GET(self,uri):
    request = uri.split('/')
    if request == ['']:
      return web.badrequest()
    if request[0]:
      room = request[0]
      try:
        result = tempdb(room)
        return result
      except:
        web.notfound()

On lance le tout et on fait un appel :

curl http://localhost:8080/temp/exterieur
16.5

C’est quand même plus simple, non ?

Voici 2 exemples basiques qui nous permettent de communiquer simplement via un point d’entrée à divers équipements de notre domotique.

Gardez le contrôle, toujours, de votre environnement. Quelque soit les objets, périphériques, modules communicants qui seront et feront la vie de votre domotique, il vous appartient de maîtriser la communication avec eux. Établissez un point d’entrée unique dont vous détiendrez la syntaxe et le langage sans devoir dépendre du bon vouloir d’un constructeur.
Changer de fournisseur ou de technos ne doit pas être plus dur que modifier quelques lignes de votre interface de communication sans revoir l’intégralité de votre interface web ou de votre application smartphone.

Et puisque je suis dans ma période lolcats sur ce billet…

Amusez vous bien

DomoGeek, une API simple pour répondre aux questions simples

guiguiabloc — Thu, 03 Jul 2014 18:57:13 +0000

A force d’utilisation de scripts et de scénarios domotique, je me suis rendu compte que des questions toutes simples avaient parfois du mal à trouver une réponse.

Prenons l’exemple d’un jour férié. Aujourd’hui est-il un jour férié ?

Cela peut paraitre idiot comme question, mais pour avoir la réponse, ce n’est pas si évident (en fait, c’est quand on travaille pas :p)

Pour un scénario domotique, ce genre d’information est importante (rien que pour gérer la surveillance ou le chauffage par exemple), et pour avoir la réponse, la plupart code un bon gros script qiu vas poller un google agenda dans lequel ils ont intégré le calendrier des jours fériés.

Maintenant, de quelle couleur est le jour TEMPO EDF ?

Pareil, on va coder des dizaines de lignes pour aller parser le site EDF et en ressortir la valeur.

Etc…

Bref, vous l’avez compris, à chaque fois, on doit, individuellement, écrire des scripts pour avoir des réponses à des questions toutes simples qui relève de l’information publique.

Et la je me suis dit, pourquoi ne pas offrir une simple API qui répond à ce genre de questions ?

J’ai soumis la question sur le forum de Toute la Domotique et les retours étant plutôt positif, je tente un petit POC pour voir si cela intéresse les gens.

Lancement donc de api.domogeek.fr

Pour le moment c’est pas du tout sec, ça ne répond qu’à 2 questions, jour férié et couleur Tempo, mais au fil du temps, je rajouterais d’autres fonctions (surtout si la demande se fait sentir :))

Voilà l’idée que je pose là. Vous en faites ce que vous voulez (le code source est même disponible sur mon Github si vous voulez l’héberger sur votre RaspBerry par exemple), vous me dites si ça peut vous servir et surtout,

Amusez vous bien

Domotique : Valoriser et exploiter les données

guiguiabloc — Mon, 17 Feb 2014 10:30:59 +0000

Ce n’est pas faute de vous le répéter, les données sont un des éléments essentiels de la domotique (et par nécessité, de l’informatique également).

Après quelques jours/mois/années d’utilisation de votre environnement domotique, vous vous êtes sûrement rendu compte de la quantité de données dont vous disposez et que, probablement, vous n’avez que faire ou que vous exploitez faiblement.

Cette quantité de données peut aussi devenir problématique à stocker et traiter au fil du temps, et vous avez fait le choix sage et délibéré d’en omettre une bonne partie (par exemple, le nombre de fois où l’interrupteur des toilettes est passé de ON à OFF).

Vous êtes un producteur de données diverses et variées, qui vont des valeurs des sondes de températures et d’hygrométrie de votre domicile et de son extérieur, de la vitesse du vent, de la consommation d’eau, d’électricité, de fioul, de gaz, de la valeur de Co2 dans les pièces, du nombre de fois ou un module s’est activé etc… Bref, vous disposez d’un nombre conséquent de valeurs.

Vous, vous êtes industriel, vous concevez et vendez des modules à greffer derrière les interrupteurs et cela vous intéressez sûrement de savoir combien de fois votre module est activé dans une journée et combien de temps il dure. Ou vous êtes constructeur de maison BBC et après les examens concluants, vous seriez intéressé de connaitre le ratio température intérieure/extérieure/consommation énergétique de cette (ces) maison(s) au fil des années.

Bref, vous vous rendez bien compte qu’il existe un chemin de rencontre entre les producteurs de données et les consommateurs de ses données.

Ce point de rencontre, il prend désormais forme par l’entremise de CityzenData, la division « données » du groupe Cityzen Sciences. Il était destiné initialement à répondre aux besoins du consortium SmartSensing pour la gestion des données produites par des capteurs insérés dans des vêtements.

Je vous en avez déjà parlé il y a quelques mois (twitter, blog, forums) en vous interpellant sur le fait de garder un oeil dessus.

Le CTO de CityzenData ne doit pas vous être inconnu si vous suivez l’actualité informatique puisqu’il s’agit de Mathias Herberts, un des pionniers du BigData en France, mais aussi un copain et ancien collègue de travail.
Et quand Mathias m’a proposé de faire « joujou » avec leur plateforme, bien évidemment j’ai répondu présent (même si je suis plus scripteur que développeur, c’est toujours agréable :D)

Une fois enregistré sur la plateforme Cityzendata, vous disposez de 3 tokens.

– Un token « écriture » vous permet de pousser des données
– Un token « lecture » vous permet de lire uniquement les données liées à votre application
– Un token « lecture générale » peut lire toutes les données que vous avez produites indépendamment de l’application.

A cela est communiqué une url d’API endpoint pour pousser vos données, une autre pour les exploiter (ou pour que d’autres les exploitent).

Envoyer vos données

Basiquement, avant d’écrire votre propre code, cela fonctionne par un simple POST HTTP :

curl -i -H « Le_Header_Token: votre_token_ecriture » -H « Content-Type: text/plain » -d ‘// temperature{piece=tempsalon} 20’ http://url_endpoint

Et voila, vous venez d’intégrer une valeur comportant un timestamp (une valeur de temps) en microsecondes dans votre « application », sous la classe Temperature avec comme dénomination pièce est égale à tempsalon et la valeur est de 20.

C’est bien évidemment l’insertion la plus simple, vous pouvez y mettre votre propre timestamp, la latitude, la longitude et l’élévation en plus si vous le souhaitez. Car les données ont aussi la faculté d’être géo-temporelles.

Un peu de code plus tard, et je me suis écrit mon client xPL pour pousser automatiquement les données sur la plateforme de CityzenData.
En résumé, toutes les trames de mes sondes (température, hygrométrie, consommation électrique) qui transitent par mon bus xPL sont automatiquement transmises sur la plateforme.

Ce client, vous le trouverez sur mon github :

https://github.com/guiguiabloc/xPL-PyHAL/blob/master/tools/xPL-CityzenData.py

(ce client a besoin d’un fichier de paramètres, config.sonde (présent dans le dépôt github),qui fait le lien entre le code ID du module et le nom que vous souhaitez donné aux labels).

Traiter vos données

Pour récupérer, manipuler et traiter les données présentes sur la plateforme, CityzenData a développé un langage appelé Einstein. C’est un langage de programmation orienté pile, un peu comme le Forth.
Voici par exemple mon script einstein qui me permet de récuperer toutes les valeurs consommation électrique :

'Votre_token_lecture'
'=energy'
0 ->MAP
'2014-02-08T00:00:00.000000Z'
'2015-01-01T00:00:00.000000Z'
5 ->LIST
FETCH

Ou uniquement les valeurs de températures à l’extérieur depuis le 09 février.

'votre_token_lecture'
'=temperature'
'room'
'=exterieur'
2 ->MAP
'2014-02-09T10:00:00.000000Z'
'2015-01-01T00:00:00.000000Z'
5 ->LIST
FETCH

Comme pour l’insertion de données, une requête http exécute einstein sur la plateforme

curl –data-binary @guigui.einstein http://api_einstein

Le résultat est au format json :

[[{"c":"temperature","l":{".app":"domotique.guigui","room":"exterieur"},"a":{},"v":[[1391940411191000,7.1],[1391940368152000,7.1],[1391940325145000,7.1],[1391940282146000,7.1],[1391940239143000,7.2],[1391940196144000,7.2],[1391940153143000,7.2],[1391940024140000,7.2]]}]]

Pour gérer tout cela en Python :

import urllib
import urllib2
import sys
import json

einstein = open('energy2.einstein', 'r')
data = einstein.read()
url =  'http://api_einstein'
req = urllib2.Request(url, data, {'Content-Type': 'application/octet-stream'})
dataeinstein = json.load(urllib2.urlopen(req))

map = {}
for item in dataeinstein[0][0]['v']:
map[item[0]] = item[1]
print map

# si cherche une valeur pour un timestamp donné
data = {}
data = map
temp = data[1391931523551000]
print temp

Il y a bien entendu beaucoup de fonctions incluses dans einstein que ce simple exemple et ce billet ne suffirait pas à toutes les expliquer.

Maintenant que je vous ai présenté tout cela, en quoi cela vous concerne ?

Vous êtes producteur de données, outre le fait de disposer d’une plateforme de stockage et de traitement hors normes, vous pouvez mettre à disposition des consommateurs des données qui peuvent les intéresser, et être rémunéré en conséquence.

Vous êtes consommateur, vous disposez de sources de données multiples et variées sur lesquelles vous pouvez appliquer des modèles de calculs et de traitement.

Je vous laisse visiter leur site pour plus d’explications et la façon de les contacter si vous êtes intéressé.

J’imagine déjà certains d’entre vous agiter fièrement le drapeau de la protection de ses données personnelles et du grand méchant cloud, mais il va falloir rapidement que vous rationalisiez tout cela.
Tout d’abord, c’est vous qui décidez des données que vous mettez à disposition et si le température de votre salon vous semble être une notion totalement privée, alors oui, ce billet ne vous concerne pas.

Ensuite, c’est par le partage que l’on fait avancer les choses. Si je peux donner à Fibaro (pour en citer un au hasard), la durée de vie de son module (qui tombe en panne par exemple après 67789 utilisations), et qu’il revoit sa copie, alors oui ça m’intéresse.

En espérant vous avoir ouvert les yeux sur la façon dont on peut valoriser et exploiter des données de domotique,

Amusez vous bien

Domotique et Intelligence : la connaissance

guiguiabloc — Sat, 04 Jan 2014 18:55:48 +0000

Ce qui rend une installation domotique digne de ce nom, c’est la capacité qu’a ce système à interagir avec votre environnement mais surtout, je pense, a connaître ce qui l’entoure et de disposer d’informations lui permettant d’offrir une réaction ou une proposition en corrélation avec votre besoin de l’instant présent.

Quand j’ai abordé la domotique, j’en avais eu plus une vision d’intelligence artificielle à mon service que d’un simple concept d’électronique/informatique appliqué aux objets.
Sûrement parce que les gens de ma génération ont (re)découvert « 2001, L’odyssée de l’espace » et surtout HAL 9000 et s’en sont fait un Graal de ce qu’aller devenir l’informatique dans le futur.

Prendre cette voie a profondément modifié ma perception de ce que devait être mon système domotique mais surtout sa construction et son déploiement.
Je n’ai pas eu l’approche conceptuelle qui était de rendre mon environnement « contrôlable » mais d’intégrer une nouvelle entité virtuelle en son sein.
Cette démarche, que j’espère vous présentez au fil de quelques billets au gré de mon humeur et de ma motivation , donne à la domotique un nouveau sens qui, bien que cela demande plus de travail, apporte un oeil différent de cette « maison de demain » si chère à nos fournisseurs/intégrateurs/revendeurs.

Le terme « intelligence artificielle » me semble beaucoup trop présomptueux et souvent galvaudé pour l’utiliser, je parlerais donc surtout d’ « intelligence » au sens large du terme et d’entité pour tenter de vous présenter mon approche.

Le système mis en place chez moi s’appelle A.L.I.X.E (Automation Layer for Interact and eXchanging with Environment).

(pour l’anecdote (oui je sais que vous en êtes friand), quand j’attendais mon enfant, je souhaitais une fille, et j’avais déjà prévu de la prénommer Alixe. J’ai eu un garçon (rassurez-vous je n’ai pas de regret ), mais le prénom est resté dans mon subconscient et c’est l’entité de la maison qui en a hérité (oui c’est obsessionnel un geek )

C’est un serveur dédié a cela. Quand j’utilise le terme « serveur » c’est uniquement pour avoir une vue « physique » de la chose. C’est un système d’exploitation, basé sur Debian, peaufiné et modifié pour répondre aux besoins (kernel, sécurité, stack reseau, file descriptor , executables, etc…, bref tout ce qui fait que vous optimisez votre serveur pour un rôle précis), disposant de son propre shell (sa ligne de commande) que j’ai développé au fil du temps avec un mélange de python et d’erlang, de son centralisateur d’évènements (dont j’ai sorti un version plus légère pour tous, xPL-PyHAL), d’un système de procédure de raisonnement, mais aussi de sa possibilité d’agréger des sources d’informations diverses et variées et d’en tirer sa quintessence pour les exploiter.
Un coeur de l’entité reproductible car c’est une simple image disque, autonome et déployable en quelques minutes si elle devait se déplacer.
Elle dispose de rôles et de prérogatives clairement définis que, dès le début, j’ai tenté de consigner dans un cahier des charges et d’explications, qui fait aujourd’hui plus de 200 pages… et qui, je pense, ne sera (re)lu que par moi mais qui m’ont forcé dès le début à rester au plus près de la voie que je m’étais fixé.

La conception habituelle de la domotique est d’avoir, dans la majorité la plus répandue des cas, une box domotique sur laquelle on contrôle ses périphériques (interrupteurs, capteurs etc…) et auxquels on applique des scénarios (« s’il fait nuit et qu’il y a un mouvement dans la cage d’escalier, allume la lumière du couloir du haut et du bas », pour les plus simples).
C’est un fonctionnement abordable par tous, simple (si on maitrise un tant soit peu les nouvelles technologies), immédiatement opérationnel (après avoir connecté tout ses modules) et donnant des résultats plus que satisfaisant.

Toute cette très longue introduction pour aborder la notion de connaissance dans votre environnement domotique.

Une des choses les plus importantes, que ce soit en informatique ou en domotique, c’est la donnée.

A ce sujet, je vous invite grandement, avant tout, à regarder la keynote de Mathias Herberts à l’IFREMER (avec qui j’ai eu le plaisir de travailler et qui m’apporte, encore, des vues et des échanges plus qu’intéressants) dans laquelle il aborde, simplement, le rôle de ses données :

Votre système domotique ne peut être performant que si ces données sont importantes, pertinentes et variées mais surtout, s’il en a l’accès et la connaissance.

Lors de la rédaction de mon suivi de déploiement, il m’a semblé nécessaire d’y inclure une partie « connaissance », que l’on pourrait résumer simplement par « Ce que je sais ».

Que « sait » votre système domotique à l’instant T ? Quelles connaissances a t’il de son environnement au moment où vous le solliciter ? Bref, que connais l’entité pour apporter la réponse qui vous satisfait le mieux ?

La connaissance, aujourd’hui, est, du moins par chance dans notre pays, accessible à tous. Quelle que soit la question que vous vous posez, un moteur de recherche internet vous donnera une multitude de sources d’informations vous permettant d’acquérir cette connaissance (à vous bien sûr d’être assez objectif pour faire le tri de ce flot d’informations), et surtout de savoir rapidement se cantonner a sa demande (tout le monde a eu cette bizarre expérience de chercher une information sur quelque chose et de se retrouver à lire d’autres articles très éloignés du sujet principal (va savoir pourquoi aujourd’hui je lisais avec intérêt la définition du dizaote alors qu’à la base je cherchais une information sur un réalisateur de cinéma…)

Cette connaissance, c’est à vous de l’apporter a votre système et de savoir s’il y en a suffisamment pour que sa réaction soit la même que vous auriez eu.

Un des tests les plus simples à faire (et que je fais souvent avec ALIXE) est « Que sais-tu ? »

Voici par exemple un extrait d’une simple réponse donnée à l’écriture de ce billet :

DANS L'ENSEMBLE, JE SAIS QUE :
Il fait nuit , et nous  sommes en week-end
Aucun mouvement exterieur détecté depuis plus de 1 heure
Le dernier appel téléphonique reçu était le 0298  à 16h32
Tu es présent dans la maison ainsi que Madame et Junior
Tu n'es pas dans ta voiture et pas au travail
Tu n'es pas en RTT, ni Madame
Parmi les parents, personne n'est en congés ou en RTT 
Junior est en vacances scolaires
Nous consommons actuellement 1341 Watts 
Aujourd'hui, nous avons consommé 423 Litres d'eau
Et depuis le dernier relevé, nous avons consommé 34266 Litres d'eau
L'alarme est désactivée
DANS LE SALON
Dans le salon, il y a quelqu'un
Cette personne est Madame
L'halogène du salon est allumé ainsi que la télévision
Les fenêtres sont fermées
Il y fait 20 degrés 
DANS LE BUREAU
Dans le bureau, il n'y a personne
La fenêtre est fermée
Il y fait 19.8 degrés 
L'onduleur est sur secteur et consomme 507 Watts 
L'accès à internet est opérationnel

C’est une très petite extraction de ce qu’ALIXE peut ressortir de ses connaissances de l’instant T.

Elle est rendu possible parce qu’elle dispose de nombreuses sources d’informations qui ensuite sont ingérées par le système.
La box domotique Zwave (une VeraLite) est une de ses sources (et n’est pas considéré comme le contrôleur principal mais comme un fournisseur de flux), les sondes de températures, une autre, nos agendas gmail, les tags NFC, les smartphones, le récepteur RFXCOM 433 Mhz, les capteurs de mouvements, d’ouvertures, les caméras de surveillances, les bornes wifi, etc…

Tout est source d’informations et est envoyée ou reçue par ALIXE.

Ces données informatives sont ou durables dans le temps par nécessité d’exploitation future (les valeurs des sondes de températures et d’hygrométrie par exemple) et sont stockées dans une base de données, ou purement volatiles (l’état d’une lumière ou si je suis dans la voiture par exemple) et là elle sont stockées dans un Memcached en tant que clé/valeur (clé:guiguienvoiture valeur:non).

ALIXE ne fait qu’interroger ses données pour mettre à jour ses connaissances à l’instant T.

Vous utilisez Memcached, vous avez un simple serveur http apache avec php, une page toute bête du genre

connect('localhost', 11211) or die ("Connexion impossible");
$get_halogenesalon = $memcache->get('halogenesalon');
if ($get_halogenesalon=="on")
$halogenesalon="allumé";
else
$halogenesalon="éteint";
$memcache->close();
?>

DANS LE SALON :
L'halogène du salon est

Et vous avez une idée des connaissances de votre système domotique.

En ne considérant que tout les équipements domotiques de la maison n’étaient que des extensions de l’entité (les box/contrôleurs compris), cela a profondément modifié la façon d’interagir avec l’environnement mais surtout de simplifier l’interaction et les connaissances qu’elle pouvait avoir.

Aujourd’hui, je ne suis pas dépendant d’une technologie, d’une box, ou d’un protocole parce que tout cela n’est qu’un élément, une main d’ALIXE.
Tout son « réseau » de données lui donne les connaissances nécessaires pour savoir, quand c’est le moment, l’état presque complet de son environnement.

Si vous décidez de pousser plus loin le concept de votre domotique personnelle (ou même dans l’état actuel de votre installation), prenez à coeur d’essayer de recenser les connaissances qu’à votre système de votre environnement. Cet état de connaissance poussera beaucoup plus loin les possibilités de scénarios que vous pourriez demander à votre système et pourra même vous suprendre par les lacunes qu’il peut avoir.

Quand l’état de connaissance de l’environnement s’approchera très fortement (voir le dépassera dans la plupart des cas, sinon à quoi servirait la domotique ), de ce que VOUS savez, la phase d’interaction n’en sera que plus perspicace et efficace.

Mais ça, c’est pour un prochain billet

Mise en oeuvre d’un serveur d’authentification SSO avec CAS et Memcached

guiguiabloc — Mon, 11 Nov 2013 17:15:50 +0000

Après ce billet où j’ai détaillé la mise en place d’un load-balancing/failover a base de cascade de NS, nous allons passer aujourd’hui à la deuxième partie. Et surtout, au but dont je voulais vous parler dans ce petit challenge technique … Read More →