Peu de mouvements sur le blog mais beaucoup de mouvements sur Domogik . Le plugin 1wire est maintenant fonctionnel de bout en bout pour les sondes de type DS18B20 et DS2401.

La DS18B20 permet de récupérer les températures et la DS2401 quand à elle permet de récupérer son numéro de série… Mais un peu plus quand même. Plus sérieusement, en ajoutant entre deux de ses pattes un interrupteur, un contacteur (fin de course ou autre) vous obtenez un capteur d’ouverture basique.

L’IHM étant en perpétuels mouvements ces temps-ci, pas de tutorial sur la mise en place . Je vous invite juste à consulter la doc sur le wiki. Elle est complète et vous suffira pour tester le 1wire avec Domogik chez vous

Notez que beaucoup d’autres points avancent sur Domogik, mais tout ne se voit pas encore

PS : j’en profite pour signaler que suite à beaucoup de spams j’ai bloqué momentanément les commentaires sur le blog

Si comme moi vous vous méfiez des orages et avez tendance à débrancher tout matériel électrique lors d’un orage (sauf frigo et congélateur bien sûr), il faut se poser une question sur l’installation domotique : quel comportement je veux avoir lors d’un orage ? De quelles fonctionnalités j’accepte de me passer ?

Dans mon cas, je coupe pour le moment tout ce qui est ordinateur/télévisions/multimédia. Par couper, j’entands également débrancher les prises de courant, antenne TV et cable réseau. Dans mon cas, on peut donc dire que tout ce qui ets multimédia m’est inutile en cas d’orage.

Bon, mais les fonctionnalités pratiques ? Détecteurs de mouvements pour allumer la lumière, capteurs d’ouverture pour la sécurité, etc ? Il est bien connu que les voleurs aiment profiter du bruit ambiant de la tempête pour agir… En cas de tempête/d’orage, il faudrait donc garder ces fonctionnalités actives, mais je ne reste pas fan de laisser un ordinateur allumé pour gérer ceci.

La solution est donc à mon avis de gérer les scénarios domotiques de deux manières :

• tout ce que vous jugez comme vital (et donc indépendant de l’état votre serveur domotique) devrait être programmé via les fonctionnalités natives de scénarios/scènes des technologies que vous utilisez.
• tout le reste (confort, multimédia, etc), vous pouvez vous en passer pendant une courte période et peut donc être sans souci géré par le serveur domotique.

Bon, il reste toujours le problème des orages/tempêtes pendant vos absences, mais ceci est une autre histoire que je ne sais pas comment prendre

Pour finir,notez que cette analyse  ne concerne que moi et ma légère parano des orages

Un nouveau wiki qui a pour but de rassembler un maximum d’informations sur le monde de la domotique a été créé : http://domotiki.fr/. Je cite son créateur :

Il s’agit d’un Wiki spécialisé dans le domaine de la domotique en Français.
L’idée du Wiki est de référencer un maximum de ressources en français et cela de manière transparente et neutre.
Le DomoTiki ne contient pas de publicité et n’en contiendra jamais.
Le contenu est sous licence libre ( GNU FDL-1.2 )
Le contenu se veut pro GNU/Linux et Logiciels Libres, mais les logiciels propriétaires ne sont pas bannis

J’aimerai que ce Wiki devienne aussi populaire que son modèle Ã?kopédia, un Wiki dédié à l’écologie.

Je vous invite donc à collaborer au projet et à partager vos connaissances

Annonce de sa création sur le forum Toute la Domotique

Et un dernier mot pour vous rassurer : ce blog est un peu en pause (comme moi ) mais ne vous inquiétez pas, ça devrait recommencer à bouger d’ici une ou deux semaines…

Aujourd’hui j’ai décidé de vous faire partager une réflexion sur le choix d’une technologie en domotique.

Le besoin initial

Le besoin brut de fonderie est le suivant :

• pouvoir commander mes lumières
• pouvoir gérer l’intensité de certaines de ces lumières
• connaître l’état des lumières

Les challengers

Dans la liste des challengers que j’avais en tête il y a…

Le X10…

… qui se fait éliminer d’office, ne permettant pas un retour d’état (sans parler d’un manque de stabilité remonté par divers témoignages).

Les modules Chacon (hors gamme DIO que je ne connais pas)…

… qui se font éliminer ne permettant pas lui non plus un retour d’état. Toutefois, un argument de poids en leur faveur entraîne leur repêchage! En effet, le faible coût de ces modules mérite qu’on se pose la question.

Le Plcbus…

… qui se sélectionne avec brio .

Le Zwave…

… qui talonne le Plcbus eu sprint final de se premier tour de sélections.

Les cartes « web relay »…

… sont également de la partie (tout au moins pour les modules avec des boutons poussoirs dédiés au relais).

Le KNX…

… est également dans la sélection gagnante.

Seconde manche : creusons les besoins

Nous avons donc à l’issue de la première manche quelques challengers. Voyons quelques unes de leur caractéristiques :

Technologie	Type	Dongle (*)	Retour d’état	Variation	Sécurité (si radio)	Prix (**)
Chacon	Radio (compatible RFXCOM)	oui	non	oui	non (infos consultables par le voisin)	$
Plcbus	CPL	oui	oui	oui	n/a	$$
Zwave	Radio	oui	oui	oui	oui (***)	$$
Cartes web relay	Filaire (RJ45)	non	oui	non (****)	n/a	$
KNX	Filaire (*****)/radio	oui	oui	oui	oui	$$$

(*) Nécessite l’achat d’un adaptateur si on désire l’utiliser depuis un ordinateur

(**) $ : pas cher, $$ : prix moyen, $$$ : très cher

(***) : plus de détail dans un des commentaires de cet article de Cédric Locqueneux

(****) : pour le moment je n’ai pas trouvé de cartes « web relay » gérant les variations d’intensité. Toutefois, j’ai entendu une rumeur comme quoi un tel type de carte (en remplaçant les relais par autre chose du coup je suppose) serait en étude.

(*****) : KNX nécessite d’avoir un réseau électrique adapté dans la maison.

Concernant le Zwave, Cédric Locqueneux a fait plusieurs articles (orientés Homeseer mais très intéressants quand même) où il teste quelques dongles et modules. Je vous invite à les lire : http://blog.locqueneux.com/index.php/tag/zwave/

Le combat !

Dès le premier round, les modules Chacon sont mis KO par le manque de confidentialité des données même si il semble qu’effectuer une action sur un module nécessite d’être connu de lui (ouf!). Le KNX de son côté se prend crochet du gauche de la part de mon portefeuille qui le trouve trop cher… Un match serré s’ensuit et finit par une égalité entre les trois concurrents restants.

Troisième manche

Pour notre troisième manche, restent en lice :

• Plcbus
• Zwave
• Cartes « web relay »

Afin de compliquer le match nous allons ajouter des besoins :

• gestion du fil pilote d’un appareil de chauffage. Ici les trois challengers s’en sortent indemne.
• un coût global (dongle + N élements) modéré : ici c’est la carte « web relay » qui l’emporte de loin.

La carte « web relay » est la grande gagnante… Ah non, sa place est remise en question par son incapacité à gérer les variations d’intensité!

La troisième manche finit donc sur un match nul…

La grande alliance

Voici la conclusion à laquelle je suis arrivé :

• pour tout ce qui ne nécessite pas de variation, on utilisera des cartes « web relay ». Ceci permet de fortement diminuer le coût global.
• pour les éléments lumineux où je veux pouvoir faire varier l’intensité, j’utiliserais sois le Plcbus, soit le Zwave. A ce jour, je n’ai toujours pas réussi à choisir…

D’autres pistes…

Je n’ai ici pas exploré toutes les pistes :

• Zigbee : certains disent que c’est l’avenir. Ca reste tout de même très confidentiel pour le moment
• Les automates : les automates permettent énormément de choses (voir la solution Calaos qui se base sur un automate Wago). Toutefois, il faut prévoir l’installation électrique en conséquence dès la construction (séparation des réseaux de commandes des réseaux d’action).

Bilan

Cette réflexion que j’ai partagé ici est propre à mes besoins et peut ne pas vous correspondre du tout. J’espère juste qu’elle vous aura permis de vous poser aussi des questions sur vos besoins

Programme de la soirée, mettre en place OwFs sous Archlinux.

OwFS : 1 voyelle, 3 consonnes… Mais encore ?

OwFs est un système de fichier pour accéder à votre réseau Onewire. Il permet de manière très simple (accès à des fichiers/dossiers) de lire l’état de vos éléments 1wire ou encore de changer leur état.

Començons par quelques liens :

• Site officiel : http://owfs.org/
• Installation sous Debian : http://owfs.org/index.php?page=debian

Installation sous Archlinux

Bon, je vous passe les détails, Arch n’étant pas utilisée par une majorité de personnes . La commande suivante vous suffira :

# yaourt -S owfs

Monter le système de fichier

Comme dit précédemment, OwFS permet d’accéder à votre réseau one wire comme à un système de fichier. Il va donc falloir monter ce réseau. Ici, je me suis inspiré du tutoriel que j’avais déjà rédigé pour Debian sur le wiki Smhteam.info : http://smhteam.info/wiki/index.linux.php5?wiki=Onewire

On va donc commencer par créer un point de montage :

# mkdir /mnt/owfs

Ensuite, on créée le fichier /etc/rc.d/owfs :

#! /bin/sh
# script de démarage de owfs

set -e
# on récupère le point de montage de OWFS
source /etc/default/owfs
# binaire OWFS
OWFS="/usr/local/bin/owfs"
# module à charger pour owfs
OWFSMODULES="fuse"

case "$1" in
  start)
        # on vérifie que le point de montage existe
        if [ -d $OWFSMNT ]
        then
                # on charge les modules
                modprobe $OWFSMODULES
                # On monte le owfs en donnant l'accès à tout le monde
                $OWFS -u $OWFSMNT --allow_other
        fi
        ;;
  stop)
        # On démonte OWFS
        umount $OWFSMNT
        ;;
  *)
        echo "Usage: $N {start|stop}" >&2
        exit 1
        ;;
esac

exit 0

On lui donne les droits en exécution :

# chmod u+x /etc/rc.d/owfs

On créée maintenant le fichier /etc/default/owfs (à adapter en fonction de votre point de montage) :

# Point de montage de owfs
OWFSMNT="/mnt/owfs"

Maintenant, ajoutons Owfs dans la liste des démons à lancer au boot en éditant /etc/rc.conf :

DAEMONS=(...owfs)

On lance le démon :

# /etc/rc.d/owfs start
DEFAULT: Opened USB DS9490 adapter at 007/002.
DEFAULT: Set DS9490 007/002 unique id to 81 93 70 2C 00 00 00 4D

Ici, mon adaptateur USB (disponible ici pour ceux que ça intéresse) est bien repéré et il s’agit bien d’un modèle DS9490

Analyse du système de fichier

Voyons ce qui est présent dans notre système de fichier :

# ls -l /mnt/owfs/
total 0
drwxrwxrwx 1 root root  8 27 avril 22:43 28.C57B2E020000
drwxrwxrwx 1 root root  8 27 avril 22:43 81.93702C000000
drwxr-xr-x 1 root root  8 27 avril 22:40 alarm
drwxr-xr-x 1 root root  8 27 avril 22:40 bus.0
drwxr-xr-x 1 root root  8 27 avril 22:40 settings
drwxrwxrwx 1 root root  8 27 avril 22:43 simultaneous
drwxr-xr-x 1 root root  8 27 avril 22:40 statistics
drwxr-xr-x 1 root root 30 27 avril 22:40 structure
drwxr-xr-x 1 root root  8 27 avril 22:40 system
drwxr-xr-x 1 root root  8 27 avril 22:40 uncached

Entre tous les dossiers avec des noms compréhensibles (mais qu’on ne va pas regarder aujourd’hui), on trouve :

• 81.93702C000000 : si vous regarder le démarrage du démon, vous remarquerez la même référence affichée. Il s’agit ici du contrôleur USB.
• 28.C57B2E020000 : ici nous avons un autre élément. Ca tombe bien, j’avais branché un DS18B20 sur le réseau 1 wire

Bon, que nous dit notre 28.C57… ?

$ ls -l 28.C57B2E020000/
total 0
-r--r--r-- 1 root root 16 27 avril 22:55 address
-r--r--r-- 1 root root  2 27 avril 22:55 crc8
-r--r--r-- 1 root root  2 27 avril 22:55 die
-r--r--r-- 1 root root  2 27 avril 22:55 family
-r--r--r-- 1 root root 12 27 avril 23:09 fasttemp
-r--r--r-- 1 root root 12 27 avril 22:55 id
-r--r--r-- 1 root root 16 27 avril 22:55 locator
-r--r--r-- 1 root root  1 27 avril 23:09 power
-r--r--r-- 1 root root  1 27 avril 23:09 present
-r--r--r-- 1 root root 16 27 avril 22:55 r_address
-r--r--r-- 1 root root 12 27 avril 22:55 r_id
-r--r--r-- 1 root root 16 27 avril 22:55 r_locator
-r--r--r-- 1 root root 12 27 avril 23:09 temperature
-r--r--r-- 1 root root 12 27 avril 23:09 temperature10
-r--r--r-- 1 root root 12 27 avril 23:09 temperature11
-r--r--r-- 1 root root 12 27 avril 23:09 temperature12
-r--r--r-- 1 root root 12 27 avril 23:09 temperature9
-rw-rw-rw- 1 root root 12 27 avril 23:09 temphigh
-rw-rw-rw- 1 root root 12 27 avril 23:09 templow
-rw-rw-rw- 1 root root 12 27 avril 23:09 trim
-rw-rw-rw- 1 root root  1 27 avril 23:09 trimblanket
-r--r--r-- 1 root root  1 27 avril 23:09 trimvalid
-r--r--r-- 1 root root 32 27 avril 22:55 type

Que d’informations . Le type pourrait nous intéresser :

$ cat 81.93702C000000/type
DS18B20

Bingo! Il s’agit bien de notre sonde de température DS18B20. Que peut-elle nous raconter de plus ?

$ cat 28.C57B2E020000/temperature
 24.4375

24 degrés ? Je suis en T-shirt, j’ai chaud et ma sonde Oregon à 2 mètres m’indique 23,9°. C’est cohérent (n’oublions pas qu’il y a souvent un delta entre différents type de matériel de relevé de températures…)

Bon, laissons de côté les autres informations, elles ne m’intéressent pas pour le moment…

Et le montage ?

Désolé, pas de photos du montage pour ce soir. Il va falloir faire avec les mots : je me suis contenté de brancher la sonde DS18B20 en mode parasite :

• broches 1 et 3 connectées ensemble sur la masse (GND)
• broche 2 branchée sur la ligne DATA

Promis, dans de futur articles je vous mets des schémas ou des photos . Mais le but ce soir était de tester Owfs et c’est une mission accomplié.

Et voici le premier article d’une longue lignée : la vidéo de la configuration d’un plugin sous Domogik (cette partie va encore évoluer, mais ça donne une petite idée de ce à quoi ça ressemblera une fois finalisé).

J’essaierais régulièrement de vous mettre une vidéo courte qui montre un élément de Domogik.

Je vous invite à la regarder en 720p afin de l’apprécier au mieux . A noter : les ralentissements dans la vidéos proviennent de mon PC qui a ramé sec lors de l’enregistrement

Nous venons de faire un appel aux suggestion sur le forum Toute la domotique : http://www.touteladomotique.com/forum/viewtopic.php?p=33193.

N’hésitez pas à y participer afin de nous permettre de faire au mieux sur le développement et l’utilisation des plugins

Derrière ce titre ronflant et trébuchant, je vais vous faire une petite démonstration aujourd’hui, à la fois économique, et écologique (un grain de sable vis à vis d’autres pollutions, mais bon, avec des grains de sables on fait des plages).

Lorsqu’un nouveau besoin en ordinateur se fait sentir pour un media center ou un serveur (web, domotique, mail, etc), il y a souvent l’éternelle question : est-ce que je tente de recycler mon vieux matériel ou est-ce que j’investis ?

Les premiers critères pris en compte sont les besoins en performance. Admettons, que votre ancien matériel puisse tenir la route. Admettons que ce dernier soit un PC de style « tour », un « classique » du genre . Cet ancêtre doit bien consommer au moins 350 watts avec ses disques durs, son lecteur optique et ses cartes qui chauffent un peu partout.

Un serveur est généralement allumé 24h/24 7j/7, 365 jours par an. Pendant tout ce temps, il consomme… Faisons un calcul rapide en partant sur nos 350 watts…

Quelques notions

Tout d’abord, Wikipedia nous rappelle que « Le kilowatt-heure est une unité de mesure d’énergie correspondant à l’énergie consommée par un appareil de 1 000 watts (1 kW) de puissance pendant une durée d’une heure » (http://fr.wikipedia.org/wiki/Kilowatt-heure)

Chez EDF (par exemple), dans un abonnement de base (sans distinction heures pleines, heures creuses), le kilowatt-heure coûte à ce jour 0,1081 euros avec un abonnement 30 ampères (on gardera cette valeur dans la suite du billet). Source : http://www.edf-bleuciel.fr/accueil/j-ai-besoin-d-energies/electricite/les-tarifs-electricite-141626.html

Consommation d’un PC classique de 350 watts pendant un an

• Un an = 365 jours * 24 heures, soit 8760 heures.
• Notre appareil va donc consommer 350 * 8760 = 3066 kilowatt-heure
• Il vous coûte donc 3066 * 0,1081 = 331 euros par an (et oui, on n’y pense jamais à ça…)

Consommation d’un mini PC de 25 watts pendant un an

Il existe actuellement de nombreux mini PC (Acer Aspire Revo, Asus Eeebox, etc) qui consomment très peu et peuvent être suffisant pour l’usage d’un particulier en terme de serveur personnel (certains peuvent même décoder des flux HD en 1080p). En terme de consommation, le Acer Revo consomme environ 20 watts. Nous allons ici prendre la valeur de 25 watts pour notre calcul :

• Un an = 365 jours * 24 heures, soit 8760 heures.
• Notre appareil va donc consommer 25 * 8760 = 219 kilowatt-heure
• Il vous coûte donc 219 * 0,1081 = 23 euros par an

Bilan

Entre nos 2 configurations, nous avons une différence de prix de plus de 300 euros, soit plus que le prix d’achat du mini PC neuf… Si le mini PC colle avec vos besoins, celà peut être un bon investissement (rentable en un an)…

Par contre, le point négatif, c’est qu’il faut quand même que votre vieux PC finisse à la benne pour se faire recycler (et ça, je ne pourrais pas vous dire l’impact écologique…)

Aller, hier j’ai fait mon radin en ne vous donnant aucune capture d’écran… Aujourd’hui, je vous mets quelques captures de la partie administration de l’interface principale.

Et voilà, c’est tout pour aujourd’hui

Un petit billet rapide aujourd’hui pour vous parler des interfaces sur Domogik.

A ce jour (v0.1 toujours en développement), il n’existe qu’une seule IHM exploitable.

L’IHM principale

Elle permet à la fois d’administrer l’installation domotique (ajout de zones, pièces, configuration des plugins, etc) mais aussi de commander vos équipements et suivre l’état des différents capteurs/senseurs. Cette IHM  est une page internet riche (pour vulgariser, il y a de l’ajax et ça permet de faire des trucs cools du style glisser-déposer, etc). Cette page est donc consultable depuis n’importe quel navigateur (si on excepte IE 6 de la liste des navigateurs dignes de ce nom). Cette IHM est conçue pour pouvoir être utilisé de manière tactile (sauf la partie administration où l’utilisation du clavier est un gros plus ) et peut donc être affichée en plein écran sur un écran tactile.

Et pour les petits écrans on a quoi ?

Pour les petits écrans (smartphones et autres iphones/android/etc), notre chef IHM a prévu un « truc » qui s’adaptera à vos petits écrans (quelque soit la taille, 320×240, 640×480, etc) et qui devrait reprendre les mêmes boutons que l’IHM principale. Bien entendu, petite taille obligé, il y aura moins de fioritures que sur l’IHM principale. Je ne vous en dit pas plus, mais honnêtement, si ce « truc » tient ses promesses, ça va être très intéressant et pourrait permettre même un usage détourné (je vous expliquerai en tant voulu). Ah si, un détail, ce sera une IHM web.

Moi je veux un jeu vidéo comme interface!

Là, je vais en dire encore moins que précédemment . Il y a juste un projet (sérieux) pour une IHM qui utilisera Edje. Cette IHM devrait donc permettre plus de délires graphiques, car elle sera faite en C. Un bémol toutefois, ne comptez pas sur cette IHM pour la 0.1. Son développement risque d’être plus long mais si elle tient ses promesses, elle devrait faire du bruit

Mais comment faites-vous pour prévoir tant d’IHMs ?

Nous sommes tout simplement des dieux
Non, blague à part, un des avantages de Domogik est sa modularité. Pour ceux qui l’ont oublié (ou qui n’ont pas lu mes précédents billets), Domogik est modulaire et a un module par tâche. Et il y a un module (et un seul) qui fournit une API sous forme de services REST (je sais, je vous ai promis un billet sur l’architecture REST, je n’oublie pas). Ce module, appelé REST est donc le seul point d’entrée pour une IHM, que ce soit pour envoyer des commandes, configurer Domogik ou récupérer des informations sur l’état du système.

L’API mise à disposition de ce module est pensée pour ne pas évoluer de manière destructive. Ceci veut dire que chaque nouvelle version de l’API pourra ajouter des fonctionnalités mais n’en supprimera pas. Les APIs que vous aurez donc utilisé pour développer votre propre IHM ne bougeront pas, ce qui garantira la pérennité de votre développement

L’API est plutôt simple, les appels se font sous forme d’url (exemple : http://domogik-rest-server/base/area/list pour lister les zones, http://…/plugin/list pour lister les plugins et récupérer leur état, http://…/plugin/start/plcbus pour démarrer le plugin plcbus, http://…/command/x10/A3/on pour allumer le module d’adresse A3 du réseau x10). Les retours d’informations (ok, échec, liste des areas, etc) se font au format json, qui est un format simple à parser.

Des screenshots ?

Et non, pas de screenshots aujourd’hui Circulez, il n’y a rien voir