Oct 12

CloudTrax, gérer l’accès wifi de vos invités

Vous avez sûrement, tout comme moi, la nécessité parfois d’offrir un accès wifi à vos amis ou famille de passage à la maison.

Malheureusement, (surtout côté famille…), les « trucs » qui veulent se connecter à votre réseau Wi-Fi sont parfois très sales ou sentent un peu des pieds.

Si en plus vous avez méchamment blindé votre accès Wi-Fi a coup d’Ipsec et de firewall authentifiant, la soirée risque d’être longue à configurer leurs portables (même si on simplifie un peu le bouzin ), surtout après l’apéro avec le beau-frère…

Je cherchais donc une solution permettant de mettre en place un accès Wi-Fi temporaire un peu à la manière des Hôtels, avec un code d’accès aléatoire ayant une validité restreinte.

Alors bien évidemment, j’aurais pu partir sur une solution à base de Portail Captif, de redirection etc… mais franchement je n’avais pas envie de perdre trop de temps dans sa mise en oeuvre.

Voulant réutiliser le matériel Wi-Fi que j’avais à ma disposition et qui dort dans le placard la majorité du temps, j’avais le choix entre mes Fonera et mes boîtiers Accton Open-Mesh.

J’avais déjà parlé précédemment des petits boîtiers Accton d’Open-Mesh et comme j’avais bien aimé le principe, je décide de refaire un tour sur leur site et là, surprise ! :

« Open-Mesh’s cloud controller, CloudTrax, is a free cloud-based network controller that helps you build, manage and monitor your wireless networks from anywhere in the world. »

CloudTrax ??? Mais, mais, mais…. C’est tout a fait ce que je recherche !

La gestion est identique à ce qui existait avant mais ce qui m’a surtout intéressé, c’est la possibilité de créer des « Vouchers », comprendre des tickets temporaires d’accès au réseau Wi-Fi.

Ni une, ni deux, on s’attèle à mettre cela en place.

– Flasher le (ou les) boitiers Accton avec la version NG du firmware

Vous trouverez les images des firmwares  ici:
http://dev.cloudtrax.com/downloads/testing/firmware-ng/

La procédure de flash est parfaitement expliqué ici :
http://support.open-mesh.com/knowledgebase/12/How-to-Flash-Open-Mesh-Routers.html

La configuration ne change presque pas de mon billet précèdent, a savoir offrir la possibilité pour votre boîtier CloudTrax de se connecter au nain ternet comme un grand 🙂 (donc dhcp toussa), puis saisir l’adresse MAC du boîtier dans l’interface Web de Cloudtrax sur https://cloudtrax.com/dashboard.php

Comme je ne voulais pas que ce « réseau » tripote de ses sales doigts mon LAN perso, j’ai configuré un VLAN dédié pour l’isoler au niveau 2 et j’ai laissé le routeur Cisco faire office de dhcp, et bien sur router/filtrer comme un gros malade (mais pour les gens normaux vous pouvez simplement le brancher dans votre réseau local du moment qu’un serveur DHCP existe (comme la Freeteuse par exemple).

Une fois connecté et mis à jour, votre boîtier se retrouve dans votre administration Cloudtrax

 

Enfin la partie la plus intéressante, a savoir la génération d’un code temporaire pour l’accès wifi.

Quand votre « invité » se connecte à votre réseau Wifi CloudTrax, il n’a pas de clé a entrer, c’est un réseau « ouvert » (qu’il croit le petit padawan !)

Il lance son navigateur et tombe sur le portail captif (qui est totalement modifiable dans l’interface d’administration CloudTrax (la splash page).

C’est à vous de créer ses codes d’accès temporaire sur la page dédiée :

https://lobby.cloudtrax.com/lobby.php

Une page toute simple vous demande de remplir le code désirée (ou laisser le système le générer aléatoirement), la durée de validité, les limites de download/upload en Mbits etc…

Vous validez et hop, vous avez un numéro a communiquer à votre « invité » ou un ticket à imprimer pour lui remettre.

C’est pas génial ?

Une interface générale vous permet de jeter un oeil à vos tickets et les désactiver si besoin.

Toutes les possibilités sont superbement bien documentées sur la page d’accueil  https://cloudtrax.com/

J’ai trouvé le concept absolument génial, je n’ai pas passer du temps à mettre en place un portail type ChilliSpot en réutilisant un vieux boitier wifi « apacher » et cette façon de générer un ticket valable 1h, 6h, 1 week-end répond tout a fait a mes attentes de fournir l’accès Facebook tant convoitée de ma nièce sur son portable sans qu’elle pollue mes sains systèmes.

Bilan, une solution de Wi-fi pour des invités qui a répondu à mes exigences, qui n’est pas là pour être tout le temps en place, mais qui peut se rallumer en quelques minutes et frimer en donnant un ticket avec la « touche » GuiguiAbloc a ma nièce qui désormais ne peut que me vénérer 😀

En espérant vous avoir donner des idées 😉

Amusez-vous bien 🙂

Classé dans geekerie | Taggé , | 4 Commentaires
Août 16

Contrôler votre domotique par la voix avec Android

Le contrôle vocal est, vous le savez, un vieux rêve qui nous taraude depuis que l’on regarde des films de filles soumises  science-fiction.

Heureusement pour nous, le concept et les logiciels ont bien évolués depuis ses dernières années et nous sommes bien loin désormais de nos lointains souvenirs où nous passions des heures avec notre microphone a réciter des pages et des pages de phrases abjectes pour obtenir un résultat… désespérant (si toi aussi tu vois de quoi je parle et que tu souris en y repensant, tu ne me contrediras sûrement pas 😀 )

J’avais depuis longtemps mis de côté l’idée d’utiliser ma voix pour contrôler quoi que ce soit (et encore moins ma femme, cela marche un peu mieux avec les enfants), jusqu’a ses derniers jours après une lecture intéressante sur un site web dont je vous reparlerais plus tard dans ce billet.

Le but de cet article est de vous décrire comment, avec mon téléphone Android, je contrôle par la voix l’extinction ou l’allumage de mes lumières ou la fermeture de la porte du garage. Potentiellement, tout est contrôlable désormais, il faut juste prendre le temps de coder les règles.

Mais n’anticipons pas, tout d’abord de quoi avons nous besoin.

  • Un Webservice pour notre serveur Domotique

Si vous disposez d’une box domotique, vous avez sûrement le moyen de contrôler par une requête http vos prises ou interrupteurs (je vous laisse à la documentation de la dite box), mais si comme moi, vous contrôler tout par des scripts, xPL et j’en passe et des meilleurs, il va pouvoir devenir intéressant de disposer d’une API permettant par une URL de commander vos équipements.

Python (encore lui), est le candidat idéal pour créer ce WebService.

L’exemple de code que je vais vous donner n’est peut-être pas utilisable pour vous dans l’immédiat car il est fortement intégré à mon environnement domotique (xPL), mais il vous donnera sûrement des pistes pour réaliser vous même votre API.

Vous trouverez les classes que j’utilise dans mon projet xPL-PyHAL (xPLmessage par exemple ou Daemon). Donc si vous utilisez mon centralisateur xPL, il y a donc de fortes chances que cela marche tout de suite 😉 (pub pub pub)

#!/usr/bin/env python
 
import web
import re,socket,sys,os
from xPLmessage import xPLmessage
import threading
from Daemon import Daemon
 
motdepasse = "1234"
 
#exemple d appel http :
#lynx "http://localhost:8080/x10?cle=1234&module=a1&command=on"
 
web.config.debug = False                                                                                                      
 
urls = (
  '/', 'index',
  '/x10', 'x10',
  '/ipx800', 'ipx800'
)
 
render = web.template.render('templates/', globals={'re':re})
app = web.application(urls, globals())
 
class index:
    def GET(self):
         return web.HTTPError(403)
 
    def POST(self):
         return web.HTTPError(403)
 
class x10:
    def GET(self):
        sendmsg = xPLmessage()
        key = web.input(cle='')
        adress = web.input(module='')
        command = web.input(command='')
        if not key.cle:
            raise web.HTTPError(403)
        if not adress.module:
            raise web.HTTPError(404)
        if not command.command:
            raise web.HTTPError(404)
 
        if key.cle != motdepasse:
            return 'access denied'
        else :
            commandx10 = command.command
            devicex10 = adress.module
            sendmsg.xplmsgcmndx10(commandx10,devicex10)
            return 'accept'
 
class ipx800:
    def GET(self):
        sendmsg = xPLmessage()
        key = web.input(cle='')
        adress = web.input(module='')
        command = web.input(command='')
        if not key.cle:
            raise web.HTTPError(403)
        if not adress.module:
            raise web.HTTPError(404)
        if not command.command:
            raise web.HTTPError(404)
 
        if key.cle != motdepasse:
            return 'access denied'
        else :
            commandipx800 = command.command
            relayipx800 = adress.module
            sendmsg.xplmsgcmndipx800(commandipx800,relayipx800)
            return 'accept'
 
class MyDaemon(Daemon):
        def run(self):
          app.run()
 
if __name__ == "__main__":
 
        service = MyDaemon('/tmp/daemon.pid')
        if len(sys.argv) == 2:
                if 'start' == sys.argv[1]:
                        sys.argv[1] =  '8080'
                        service.start()
                elif 'stop' == sys.argv[1]:
                        service.stop()
                elif 'restart' == sys.argv[1]:
                        service.restart()
                elif 'console' == sys.argv[1]:
                        sys.argv[1] =  '8080'
                        service.console()
 
                else:
                        print "Unknown command"
                        sys.exit(2)
                sys.exit(0)
        else:
                print "usage: %s start|stop|restart|console" % sys.argv[0]
                sys.exit(2)

Comment ca marche ?

Je le dis tout de suite, ce n’est pas « restful compliant » (je réagis sur des GET http et pas des POST) mais pour l’usage personnel que j’en fais, c’est largement suffisant (et je n’ai pas vocation à en faire un produit commercial).

En appelant par votre navigateur (ou par curl ou par lynx (qui est pour moi le nec plus ultra du navigateur web (barbu inside))) l’URL : « http://monserveurdomotique:8080/x10?cle=1234&module=a1&command=on » vous allez demander au module A1 de s’allumer.

Je prend l’exemple X10 uniquement pour la simplicité de compréhension, cela pourrai être IPX800 dans mon code ou n’importe quelle techno domotique du moment qu’elle est « appelable » par le webservice (xPL est encore et toujours votre ami pour centraliser tout cela).

La « clé » est le mot de passe pour executer une requète sur votre serveur domotique, alors évidemment la sécurité est très minimaliste dans cet exemple, mais je vous laisse peaufiner a coup d’https, de certificats, d’iptables et j’en passe.

Le code est suffisamment simple pour que vous en compreniez le fonctionnement et que vous l’adaptiez à vos besoins (les tutos sur les webservice python sont nombreux sur le nain ternet).

Maintenant que nous commes capable de donner des ordres a notre système domotique par de simples requêtes http, il nous reste à pouvoir le faire de vive voix.

  • Tasker, le « must have » d’un téléphone Android

Tasker est sûrement l’un des meilleurs logiciels sous Android existant.

Il vous permet de créer toutes sortes de scénarios ou d’évènements sur votre téléphone (si je met des écouteurs alors joue une musique, si je me trouve à moins de 100m de chez moi, alors ouvre la porte du garage, etc..)

Si sa complexité rebute un peu au premier abord, on en prend vite la main et rapidement, on en arrive à coder des centaines de tâches ou de contextes qui nous facilite la vie au quotidien.

Le prix est dérisoire en comparaison de ses capacités et je ne peux que vous inviter chaudement à l’acheter.

Cerise sur le gâteau (Note inintéressante de l’auteur : Je vous fait grâce des expressions que j’ai voulu écrire ici et qui laisserait sûrement planer la honte sur ma famille durant des décennies), depuis quelques semaines, Tasker inclus désormais la possibilité d’exporter vos « scénarios » en tant qu’application autonome Android !!! C’est pas le top du summum de la geekerie ultime ça ??? (Note inintéréssante de l’auteur (encore) : Là vraiment, vous avez échappé à des expressions qui limite me vaudrait quelques années de prisons …)

Exemple, vous créez un petit scénario qui fait que quand votre téléphone est en charge, vous activez le wifi, si vous le retournez, il coupe tout, et se met en mode silence, s’il détecte votre oreillette bluetooth, il informe votre serveur domotique que vous êtes en mode privé et que les messages d’alerte de votre installation peuvent être envoyé via Notifry en Audio (qui depuis une petite discussion avec Daniel, le développeur de Notifry, a gentiment accepté d’intégrer le choix de la sortie audio des messages Notifry 🙂 Merci à lui pour répondre rapidement à mes demandes d’évolutions, un développeur aussi proche de ses utilisateurs est assez rare pour le souligner.
Et d’un clic, vous exportez votre propre application apk autonome.

Il n’y a quasiment pas de limite à Tasker, a part votre propre imagination.

Et dans toute ses imaginations possibles, je suis tombé sur un fou furieux de Tasker (dans le bon côté du terme :p, ce type fait quand même tourner 474 taches Tasker par jour oOO), Andreas Ødegård.
(alors vu que c’est un norvégien, vous comprendrez les caractères ésotériques dans son nom 😀 ), qui est ausi un des rédacteur associé pour l’excellent site Pocketables.

Ce geek comme je les aime, outre la qualité de ses billets, nous donne souvent des trucs et astuces pour Tasker et dans son lot de bidouilles, il a décider de créer son propre assistant vocal sous Android avec Tasker.

A la lecture de son billet, j’ai tout de suite accroché sur l’idée et bien sur, je me suis empressé de le mettre en oeuvre pour mon propre usage et en hommage a l’excellent travail d’Andréas, j’ai décidé de garder le même nom pour mon assistante vocale, Nelly (pour la petite histoire du pourquoi du comment ce prénom, je vous invite a lire son billet, a moins que vous ne soyez déjà un lecteur assidu de Mike Shepherd ).

Pour réaliser cet exploit, nous allons tout simplement utiliser la fonction « Obtenir depuis depuis la voix » de Tasker. Cette fonction se base sur le moteur de reconnaissance vocale de Google (une connexion au nain ternet est donc nécessaire)

La phrase analysée est contenue dans la variable %VOICE de Tasker, il ne reste plus qu’a réaliser une tâche s’executant si la variable %VOICE contient tels mots.

Pour appeler notre Webservice Python, nous allons utiliser la fonction « Get HTTP » en spécifiant les paramètres suivants :

Et pour l’analyse des mots sur lesquels réagir :

L’étoile étant bien sur un caractère joker, ce que l’on dit « autour » n’est pas pris en compte (ça vous permet de laisser libre cours a votre imagination devant votre entourage : « Nelly, mon petit, dans ta grande manséutude, si tu éteins le salon que je puisse dragouiller la demoiselle que j’ai invité chez moi pour un soi-disant repas en toute amitié, je t’en serais reconnaissant. »)
Attention quand même, par défaut vous n’avez que 30 secondes… (euh pour donner l’ordre vocal hein, pas pour la demoiselle…)

Pour vous montrer de visu de quoi Tasker est capable avec « Nelly », je vous propose une petite vidéo faite a l’arrache (je l’avoue) mais qui vous donnera les capacités du système.

 

Démonstration de contrôle vocal avec Tasker par Guiguiabloc

Avouez tout de même que cela en jette pas mal (en plus d’être diaboliquement génial 🙂 )

Merci donc à Andréas pour son idée, à Lee Wilmot pour son excellente application Tasker et à Olivier Sannier pour la traduction en français de Tasker 😉

Amusez vous bien 😀

 

 

 

 

 

 

Classé dans domotique | Taggé , , | 20 Commentaires
Juil 16

Ravalement de facade

Ce n’est pas le beau temps qui amène le changement mais bon :p

Donc vous l’avez sûrement remarqué (sinon c’est que c’est votre première visite ici, dans cas, bienvenue, bisous toussa), le thème du blog a changé.

Cela fait des années que j’utilise le même thème et la même conf (bouh !!!) et j’avoue n’avoir jamais pris le temps de passer un petit coup de renouveau ici.
Plusieurs d’entre vous m’avez fait remarqué (a juste titre il va s’en dire), que la lisibilité du blog n’était pas des plus fameuses (traduire : « ca pique aux yeux le blanc sur fond noir »), et je le conçois, à la fin, on s’en lasse.
J’ai donc complètement changé la charte graphique et vous propose quelque chose d’un peu plus lisible et épurée (tout comme moi :D).

J’espère que cela vous plaira (n’hésitez pas à me faire un retour de ce que vous en pensez ).

Tout n’est pas encore achevé (il reste quelques champs à traduire et je ferais cela tranquillement au fil de l’eau).

Voilà pour la partie « visible » du blog. Pour l’autre partie, celle qui justement permet de le faire « tourner », j’ai également fait quelques changements.

Depuis des années, ce blog était « propulsé » par Apache, aidé par memcached et eaccelerator, avec un soupçon de mod_security pour les méchants hackers chinois.

D’abord j’en ai profité pour mettre a jour le système (si si, j’avoue, le serveur ronronnait tranquillement depuis des années sous une vieille Debian, vous savez tant que ça marche :p …), repatcher mes bidouilles maisons et revoir la partie http.

Donc désormais, c’est un Nginx qui remplace Apache, php-fpm pour la partie php, memcached et eaccelerator sont toujours la pour aider, mod_security a été remplacé par Naxsi et un petit Varnish tourne en amont de tout ce système.

Il me reste bien sûr quelques coups de tournevis à donner ci et là, mais cela me semble déjà pas mal opérationnel pour le mettre en « production ».

C’est reparti donc pour de nouvelles joyeusetés diverses et variées, le temps que tout le monde s’habitue au nouveau « design » du blog, surtout moi…

 

 

Classé dans Non classé | 3 Commentaires
Mai 22

Projet xPL-pyHAL, un cerveau xPL, Episode 2 : Alpha Release

Des nouvelles de mon projet de moteur central xPL, xPL-PyHAL dont je vous avez parlé précédemment.

Après plusieurs mois, je suis plutôt pas peu fier de vous présenter la première version Alpha 😀

Cette version est dès à présent téléchargeable sur :

http://code.google.com/p/guiguiabloc/downloads/detail?name=xPL-PyHAL-alpha-0.1.tgz

Bien évidemment, comme toute version Alpha, elle doit subir son baptême du feu, et c’est pour cela que je vous la propose.

Je l’utilise au quotidien sans incidents mais forcément, elle est très lié à mon environnement et je ne sais donc pas comment elle se comportera ailleurs, c’est pour cela que vous êtes grandement invité à me remonter tout les bugs/remarques éventuels via la partie « Issues » de GoogleCode (cela me facilitera la tâche 😉 )

C’est un premier jet (sans jeu de mot, je vous connais hein !!!), des possibilités que je veux donner a xPL-PyHAL.
Le mieux est donc de le tester et de me faire savoir ce que vous attendez d’un centralisateur xPL de ce type.

Le plus dur dans un développement n’est pas de le réaliser mais plutôt de l’expliquer. Je vais donc, dans ce billet, détailler le fonctionnement d’xPL-PyHAL et de ses classes/modules.

xPL-PyHAL, le centralisateur xPL

xPL-PyHAL est un programme qui se greffe à votre bus xPL et écoute en permanence les messages qui y transitent.

Son rôle est d’éxécuter une action pour un module que vous allez définir dans un fichier texte tout simple quand il verra passer un message xPL lié a ce module.

Les ordres sont à déposer dans le répertoire « yamlrepo » sous la forme de fichier YAML.
Le fichier doit porter l’extension « .yaml ».

Exemple d’application :
Je souhaite allumer le relais 1 du boîtier ipx800 quand j’appuie sur l’interrupteur CHACON.
Il s’agit d’un ordre de type « HomeEasy » (schéma homeeasy.basic) à destination du client xPL-ipx800.

Le fichier YAML aura la forme suivante (interrupteur.yaml) :

ACTION: command
MODULE: "0x4b92ba"
UNIT: "9"
TARGETXPL: "ipx800"
TARGETMODULE: 2

ACTION : c’est une commande à exécuter
MODULE: le module qui initie l’ordre (ici l’adresse de l’interrupteur CHACON)
UNIT : l’unité de l’interrupteur
TARGETXPL : le client xPL qui doit exécuter l’ordre (ici le client xPL-ipx800)
TARGETMODULE: le relais cible a commander sur l’ipx800

Autre exemple, en appuyant sur l’interrupteur, je veux allumer une lampe x10 référencée comme module A2.
Le fichier interrupteur.yaml contiendra les valeurs suivantes:

ACTION: command
MODULE: "0x54cd16"
UNIT: "10"
TARGETXPL: "heyu"
TARGETMODULE: a2

Description  et configuration possible

Une fois le fichier xPL-PyHAL.tgz décompressé, vous trouverez différentes classes et modules python dont je vais détailler le rôle.

  • xPL-PyHAL.py

Il s’agit de l’executable qui lancera le centralisateur xPL-PyHAL.

– Configuration : Aucune

A lancer depuis le répertoire du centralisateur :

python xPL-PyHAL start (lance le démon)

python xPL-PyHAL stop (arrête le démon)

python xPL-PyHAL console (lance le programme dans la console sans le démoniser. CTRL-C pour l’arrêter)

  • BrainPyHAL.py

Le programme principal d’xPL-PyHAL.

– Configuration : Vous pouvez passer en mode debug (sortie dans le fichier logxplhal.log et dans la console si vous l’avez démarré dans ce mode)

# Debug : set True or False
debug = False

  • Daemon.py

Classe permettant de faire tourner xPL-PyHAL en tâche de fond (démon).

– Configuration : Aucune

  • Memcached.py

Classe permettant d’interagir avec un serveur Memcached

– Configuration :  l’adresse IP et le port du serveur Memcached (localhost:11211 par défaut)

def __init__(self, hostname="127.0.0.1", port="11211")
  • PushingBox.py

Classe permettant d’envoyer des notifications vers le service PushingBox

– Configuration : Aucune

  • xPLmessage.py

Classe pemettant de gérer les messages xPL

– Configuration : Aucune

Les fichiers de configuration YAML

Les actions qui doivent être exécutées par xPL-PyHAL doivent être déposées dans le répertoire « yamlrepo ».

Le fichier texte doit avoir l’extension .yaml

Il contient les entrées suivantes :

– L’action à réaliser (au choix)

ACTION : message | store |  command |  log

message : envoie une notification

store : stocke une valeur quelque part

command : execute un ordre xPL

log : écrit dans un fichier log

– l’adresse du module qui déclenchera l’action

MODULE: « xxxxxxx »

– l’unité du module qui déclenchera l’action (si applicable)

UNIT: « x »

– La cible qui doit être commandée

TARGETXPL: « xxxxx »

Vous trouverz des exemples dans le répertoire yamlrepo (extension .sample et dans le fichier YAML.FORMAT)

Quelques exemples :

– Stocker une valeur « alertemode » avec la clé « on » pendant 60 secondes dans un serveur Memcached quand le module « 0x4b99bb », unité 9 se déclenche

ACTION: store
TARGETXPL: memcached
MODULE: "0x4b99bb"
UNIT: "9"
KEY: "alertemode"
VALUE: "on"
TIME: "60" (défaut 900)

– Envoyer une notification PushingBox quand le module « 0x4b99bb' », unité 9, se déclenche

ACTION: message
TARGETXPL: pushingbox
MODULE: "0x4b99bb"
UNIT: "9"
KEY: "v9999AAAAEEEE4"

J’espère que les exemples fournis vous aideront à créer vos propres fichiers YAML. Bien sûr, il peut y avoir plusieurs fichiers YAML pour un même module.

La prise en compte se fait à chaud, inutile de relancer le démon xPL-PyHAL.

Voila pour une explication succincte d’xPL-PyHAL.

Je n’intercepte pas encore toutes les erreurs possibles, donc n’hésitez pas à me remonter les crashs éventuels avec le maximum d’information possible 🙂

Amusez-vous bien 😀

Classé dans domotique | Taggé , , | 8 Commentaires