Domotique – proximité

L’objectif est de pouvoir utiliser l’information de proximité de personnes (via leurs smartphones qu’ils ne quittent jamais) dans des logiques domotiques (éteindre le chauffage ou la lumière lorsque l’on quitte l’appartement, faire des calculs de temps de trajet, etc).

Capture d’écran 2016-07-13 à 22.34.55

Le GPS (GeoFence)

Dans ce scénario, Une application (Pilot home par exemple) utilise le signal GPS reçu et si les coordonnées sont dans les environs (relativement large, 150m de rayon), une requête (http api rest) est envoyée sur la box domotique pour activer un switch virtuel.

Le problème est la fiabilité d’une part et la nécessite d’autre part de laisser le GPS allumé (batterie). Au niveau de la fiabilité, la requête peut être envoyée alors que la connectivité n’est pas bonne, dans le métro par exemple, étant donné que la précision n’est pas excellente (150m) . Aucune application ne propose de renvois récurrents à l’heure actuelle.

  • Précision: Faible
  • Fiabilité de l’information: Faible
  • Complexité mise en oeuvre: Simple
  • Consommation énergie: Elevée

Le WiFi

Dans ce scénario, un script (en python par exemple) sur la box ping l’IP attribuée au smartphone et s’il reçoit une réponse envoi une requête pour allumer le switch virtuel.

La précision est meilleure mais nécessite se laisser le wifi du smartphone allumé en permanence. Ce qui est problématique avec un iPhone convenons-en.

  • Précision: Bonne
  • Fiabilité de l’information: Faible
  • Complexité mise en oeuvre: Moyenne
  • Consommation énergie: Elevée

le ibeacon

Dans ce scénario, lorsque l’iPhone reçoit un ibeacon de la box domotique, une application envoi une requête à la box pour activer le switch virtuel.

Dans ce scénario le problème de la fiabilité de la transmission des données n’est plus car la précision est de quelques mètres. Aucun risque que la connectivité soit mauvaise 🙂

L’utilisation du iBeacon permettrait même de gérer des logiques à l’intérieur du logement (type allumer la lumière dans telle pièce en fonction de la force du signal reçu).

  • Précision: Bonne (qq mètres)
  • Fiabilité de l’information: Bonne
  • Complexité mise en oeuvre: Moyenne
  • Consommation énergie: Faible

La mise en place du ibeacon

Sur Raspberry

  • Une clé USB bluetooth 4.0 compatible (constructeur CSR par exemple)
  • Les librairies USB
  • La librairie Bluez

Les librairies USB sont déjà installées si domoticz est présent.

sudo mkdir bluez
cd bluez
sudo wget www.kernel.org/pub/linux/bluetooth/bluez-5.18.tar.gz
sudo gunzip bluez-5.18.tar.gz
sudo tar xvf bluez-5.18.tar
cd bluez-5.18
sudo ./configure --disable-systemd
sudo make
sudo make install
sudo shutdown -r now

Il convient ensuite de configurer les données transmisses par le iBeacon (son identifiant UUID notamment) en utilisation la commande suivante:

sudo tools/hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 00 4C 02 15 63 6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 00 00 00 00 C8

Les données sont au format suivant:

687474703a2f2f616a7265732e6769746875622e696f2f697369676e2d626c75657a2f697369676e7061796c6f61642e706e67

Sur l’iPhone

L’application Locative (iPhone) permet d’appeler directement une API web lors de l’entrée ou de la sortie d’un iBeacon. L’application iPhone “Pilot Home” devrait être capable de prendre en compte les iBeacon en version 1.7 ou 1.8 d’après son auteur.

L’utilisation de l’application IFTTT qui permet de déclencher des actions sur un trigger (le tout formant dans leur jargon “une recette”) aurait pu répondre à notre besoin mais aucun trigger n’existe pour la detection d’un broadcast iBeacon. L’action, grâce au module Maker Chanel eu été d’envoyer une requête sur l’API de domoticz.

Internet Of Things – Routage

Introduction

L’Internet of Thing défini tout ce qui tourne autour des réseaux de capteurs qui remontent des informations à des nœuds de décision qui peuvent à leur tour redescendre à d’autres capteurs des ordres (actions). L’Internet of Thing s’est démocratisé avec l’émergence des solutions de domotique basées sur les technologies sans fil simples à mettre en oeuvre.

D’une part la capillarité du réseau est très importante et l’utilisation du sans fil fait que la topologie est dynamique. D’autre part les capteurs et devices ont des capacités limitées en traitement de l’information (CPU, mémoire, alimentation Electrique). 

Les mécanismes d’échange d’information, de routage et de sécurité doivent être repensés en intégrant ces contraintes là. Nous allons nous intéresser ici au routage de l’information.

Lire la suite

Répartition de charge Geographique

Use case

Mise en place d’une répartition de charge géographique pour les demandes d’authentification SAMLv2 depuis des applications cloud (public) auprès de la fédération Active Directory (ADFS).

Nous verrons que la mise en oeuvre d’une répartition basée sur la proximité (via un probe ping par exemple) n’a pas de sens dans ce cas de figure. en effet un collaborateur utilisera sans aucun doute un autre DNS récursif lors d’une seconde demande d’authentification (collaborateur en déplacement et timeout d’authentification de plusieurs heures).

Geo1

C’est sur la prochaine étape, c’est à dire la requête émise par le DNS Recursif vers le DNS authoritatif de l’entreprise (via les DNS racine si nécessaire) que cela devient intéressant…

Lire la suite

Domoticz – Connectivité Internet

La BBox souffre d’un problème majeur: Lors d’une perte de synchro au niveau de l’ADSL, la BBox ne cherche à aucun moment à réinitialiser cette synchro. On reste donc déconnecté jusqu’au prochain reboot electrique.

Domoticz et une prise Chacon allaient répondre à mon besoin. Domoticz permet la création de switchs virtuels que l’on peut commander via une API, appelée par un script de test de connectivité. Ce switch est ensuite utilisé dans une séquence “evenement/action” dite blockly pour commander la prise électrique de la Bbox et ainsi la redémarrer…

Lire la suite