Archives de l'auteur : Laurent

Raspberry Pi Model B+, par où commencer ?

par Laurent publié le 2 octobre 2014

Présentation

RraspberryPiBPlus

Le Raspberry Pi est un nano-ordinateur monocarte à processeur ARM conçu par le créateur de jeux vidéo David Braben, dans le cadre de sa fondation Raspberry Pi2. Cet ordinateur, de la taille d’une carte de crédit, avait pour vocation de constituer un ordinateur pas cher et performant pour faciliter l’apprentissage de l’informatique au plus grand nombre et plus particulièrement aux plus jeunes. Aujourd’hui, force est de constater que ce petit appareil rencontre un grand succès dans différents domaines : jeux videos, serveur web, serveur multimédia, robotique et même domotique… Un Raspberry Pi permet l’exécution de plusieurs variantes du système d’exploitation libre GNU/Linux et des logiciels compatibles.

  • Processeur intégré ARM1176JZF-S core (ARM11) 700 MHz sur SoC Broadcom BCM2835 avec FPU et GPU double cœur VideoCore IV
    • raspberry-pi-b-plus
  • RAM : 512 Mo SDRAM
  • Lecteur de cartes Micro SD
  • Port Ethernet RJ45 10/100 Base-T
  • Prise audio/vidéo HDMI 1.3 et 1.4
  • Sortie audio/vidéo composite sur prise jack 3,5 mm à 4 pôles
  • 4 ports USB 2
  • Port GPIO 40pin
  • Connecteur MPI CSI-2 15 contacts pour caméra vidéo HD Raspberry Pi (775-7731)
  • Connecteur DSI d’interface série d’affichage à 15 contacts
  • Alimentation : +5V/2A via le port micro-USB
  • Dimensions : 85x56x17 mm

À titre de comparaison, la puissance de calcul est proche de celle d’un Pentium II 300MHz de 1997 et la puissance graphique proche de celle d’une Xbox 1 de 2001.

(suite…)
Publié dans Domotique, Raspberry, Système | 2 commentaires

Login gnome impossible pour un utilisateur

par Laurent publié le 1 octobre 2014
login-select-Gnome-Shell

Si un utilisateur particulier ne peut se connecter à son bureau gnome mais qu’il peut se connecter en ligne de commande (Ctrl+Alt+F1 par exemple), il est possible qu’il rencontre des problèmes de propriété avec des fichiers de son répertoire home. Pour résoudre le problème, il faut ouvrir un schell et saisir : 

sudo chown -R <user>:<groupe> /home/<user>

Publié dans Linux, Galères | Laisser un commentaire

Adaptateur USB Wi-Fi Bi-bande Edimax EW-7811UAC

par Laurent publié le 27 septembre 2014
EW-7811UAC-1

Présentation

Il s’agit d’un adaptateur USB Wi-Fi Bi-bande. Je l’utilise pour palier les problèmes (difficulté d’accroche, coupures incessantes) que je rencontre avec la carte Wifi de mon ordinateur portable.

  • Compatible Wi-Fi AC (jusqu’à 430 Mbps) et Wi-Fi a/b/g/n (jusqu’à 150 Mbps)
  • Connectivité sans fil Dual Band (2.4 GHz / 5 GHz)
  • Connexion simple et sécurisée avec un bouton WPS (Wi-Fi Protected Setup)
  • Signal de qualité sur une longue distance avec l’antenne 4 dBi (2.4GHz) et 6 dBi (5GHz)
  • Socle USB avec câble USB de 1.2 m, pour une installation plus flexible et une meilleure qualité de signal
  • Compatible Windows XP / Vista / 7 / 8 / 8.1, Linux et Mac OS X
(suite…)
Publié dans Matériel, Questions Réseau | Tagué | Laisser un commentaire

Universal Sensor Fibaro FGBS321

par Laurent publié le 22 août 2014
universal-sensor-fibaro

Description

Ce module permet principalement d’intégrer dans un réseau Z-Wave deux entrées de type contacts secs (alarme, détecteur de présence, détecteur d’ouverture…) ainsi qu’un bus filaire data 1-wire sur lequel quatre sondes de température Dallas DS18B20 peuvent être raccordées. Il dispose également de deux sorties tout ou rien libres de potentiel qui sont de simples copies des entrées (i.e. elles ne sont pas pilotables). Ce module est donc à classer du côté des capteurs et non de celui des actionneurs. Ce module doit être alimenté par une source de courant continu comprise entre 9V et 30V.

(suite…)
Publié dans Domotique, Modules | Tagué , , | Laisser un commentaire

Détecteur d’ouverture Z-Wave Fibaro FGK-101

par Laurent publié le 29 mai 2014

Description

Fibaro FGK-101

Ce détecteur Z-Wave dispose d’un capteur reed, un interrupteur de proximité à fonctionnement magnétique, qui permet de détecter l’ouverture d’une porte ou d’une fenêtre. Il est constitué d’une partie mobile, un aimant fixé sur la porte ou la fenêtre, ainsi que d’une unité principale fixe positionnée sur le cadre de la porte ou de la fenêtre. Ces deux parties sont à fixer avec des vis ou un adhésif.

En outre, ce détecteur dispose d’une entrée analogique permettant d’y connecter une sonde de température 1-Wire DS18B20 ainsi que d’une entrée filaire. Cette dernière permet de l’utiliser comme un transmetteur universel pour transformer n’importe quel contact sec (sonnette, détecteur de fumée, de gaz ou de monoxyde de carbone, …) en dispositif Z-Wave.

Le détecteur FGK-101 est alimenté par une pile ER14250 (1/2AA) de 3,6V annoncée pour durer 2 ans.

(suite…)
Publié dans Domotique, Modules | Tagué , | Laisser un commentaire

Détecteur Z-Wave Fibaro Smoke Sensor FGSS-001

par Laurent publié le 26 mai 2014

Description

smoke_sensor

Le Fibaro Smoke Sensor FGSS-001 est un capteur de fumée permettant d’être alerté d’une menace d’incendie par une sirène, une lumière Led multi-couleur et un signal Z-Wave. Comme certains matériaux brûlent sans fumer les ingénieurs de Fibaro ont décidé d’inclure une protection supplémentaire sous la forme d’un capteur de température. La batterie du module est censée tenir 3 ans et une alimentation extérieure est possible. La sensibilité de détection du capteur est réglable (3 niveaux), il peut être connecté à un système d’alarme filaire et dispose d’une protection contre le sabotage.

Attention, à partir de 2015, un détecteur de fumée sera obligatoire dans chaque logement. Cependant, le Fibaro Smoke Detector FGSS-001 est uniquement compatible avec la norme EMC 2004/108/EC. Il ne respecte pas la norme Européenne EN 14 604 à laquelle tout détecteur de fumée (DAAF) commercialisé en France depuis 2008 doit se conformer. Notamment le son émis par sa sirène n’est pas très fort, il ne respecte pas les 85dB de la norme CE. C’est pour cela que Fibaro utilise le terme de capteur de fumée plutôt que celui de détecteur de fumée.

Note du 14/02/2015 : Une version respectant la norme Européenne existe et est présentée ici.

(suite…)
Publié dans Domotique, Modules | Tagué , , | 11 commentaires

Détecteur Z-Wave Fibaro Flood Sensor FGFS-101

par Laurent publié le 26 mai 2014
flood_sensor

Description

Le Fibaro Flood Sensor FGFS-101 est principalement un module de détection d’inondation. En plus de la détection d’inondation, ce module possède d’autre fonctionnalités car il dispose d’une sonde de température, d’un détecteur de bascule, d’une petite sirène, d’un bornier de sorties pour connecter une sonde ou le raccorder au système d’alarme. La durée de la pile est d’environ 2 ans, mais le module peut aussi être alimenté par une source externe.

(suite…)
Publié dans Domotique, Modules | Tagué , , | 5 commentaires

Vera Lite : Plantage sévère

par Laurent publié le 18 mai 2014
VeraDeadlock
Description du plantage

Ma Vera Lite a subitement planté alors qu’elle fonctionnait normalement (je n’étais pas en train d’intervenir dessus). Voici les derniers messages d’erreur du log : 

01	05/15/14 12:06:37.009	Failed to get lock(0xa3e20c) Variable: ../ZWave/ZWaveJobHandler.h:372 last used UserData.cpp:463  first used UserData.cpp:463  thread: 0x2c315680 (>579995)  handler 0x424934 bOkToFail 0 <0x2c915680>
01	05/15/14 12:06:37.019	Deadlock problem. going to reload and quit <0x2c915680>
01	05/15/14 12:06:44.231	Main WatchDogRoutine: blocked - terminating 1 <0x2d92f680>

J’ai immédiatement tenté de la redémarrer en la débranchant puis en la rebranchant, et là, plus rien : plus d’interface web, plus de ssh, aucune réponse au ping.
Les voyants de la Vera sont entrés dans la séquence cyclique suivante :

  1. Le voyant bleu clignote environ 40 secondes
  2. Le voyant vert s’allume quelques secondes
  3. Les quatre voyants s’éteignent puis s’allument puis s’éteignent
  4. Retour au 1
(suite…)
Publié dans Domotique, Contrôleurs | Tagué , | 1 commentaire

Alarme Home Control 2 de MyFOX

par Laurent publié le 17 mai 2014
myfox

Présentation

Cahier des charges

Mon cahier des charges minimal est assez simple :

  • Véritable alarme plutôt qu’un patchwork à base de modules Z-Wave sur la box domotique
  • Alarme connectée afin de pouvoir l’armer, la désarmer ou faire d’autres manipulations à distance
  • Alarme interfaçable avec la domotique de la maison

Je suis convaincu que ce n’est pas une bonne idée de concevoir son système d’alarme à base de modules Z-Wave. Tout d’abord, le protocole Z-Wave et les box qui le mettent en œuvre ne sont pas conçues pour faire de la sécurité (brouillage radio…). En outre, le Z-Wave n’est ni une technologie fiable, ni une technologie stable. Ensuite, ma box domotique est déjà bien chargée, il lui arrive (rarement) de planter sans qu’elle ne puisse redémarrer d’elle-même (même après avoir été débranchée et rebranchée). Enfin, mieux vaut ne pas mettre tous ses œufs dans le même panier : par exemple, une Vera Lite, une IPX800 et une HC2 de MyFOX se complètent bien et rendent le système bien plus fiable que si toutes ces fonctionnalités étaient supportées par un système unique.

Dans ce contexte, il est important que box domotique et système alarme puissent communiquer. En effet, il est intéressant de pouvoir baisser le chauffage ou éteindre certaine lumière quand l’alarme est armée, et faire l’inverse quand elle est désarmée. Il est également intéressant que la domotique puisse déclencher l’alarme en se basant sur l’activation de ses propres capteurs, ou être informée d’une intrusion pour prendre certaines mesures.

(suite…)
Publié dans Domotique, Contrôleurs, Alarme | Tagué | 20 commentaires

Vera UI5 : Créer son propre Plugin

par Laurent publié le 17 mai 2014
creer

Problématique

La création d’un plugin pour la box domotique Vera sous UI5 n’est pas une opération très simple et les tutoriels simples et en français pour en décrire les étapes ne sont pas légion sur Internet. Ce billet, rédigé sous la forme d’un tutoriel, à pour vocation de décrire les différentes étapes permettant la création d’un plugin équivalent au plugin Virtual ON/OFF Switches mais comportant 3 états plutôt que deux.

Ce billet n’est pas achevé. Il est cependant en standby pour une question de temps, mais aussi parce que la sortie de UI7 (personnellement, je ne l’attends pas avant 2015) va changer la donne.

Structure d’un Plugin

Un plugin Luup est composé de plusieurs fichiers dont certain sont optionnels.

4 fichiers permettent d’implémenter le fonctionnement du plugin.

  • D_GenericPlugin1.xml, Device description file (1) – Ce fichier est le principal, il permet de décrire le device implémenté par le plugin. C’est à partir de ce fichier que tous les autres sont atteints. Il s’agit en fait d’un fichier xml de spécification de device UPnP (UPnP device description file). Voici quelques liens utiles pour l’écriture de ce fichier : Luup Plugins ; Luup Plugins By Hand.
  • S_GenericPlugin1.xml, Service File (0 à n) – Ce fichier est optionnel car la Vera fournit déjà de nombreux Service File décrivant de besoins récurrents comme des switches on/off par exemple. Si les services du plugin n’existent pas déjà, il faut créer un ou plusieurs fichiers Service File et décrire l’implémentation dans le fichier Implementation file. Voici quelques liens utiles renseignant les Service File existants : Luup UPNP Files ; Luup Devices ; Luup UPnP Variables and Actions.
  • I_GenericPlugin1.xml, device Implementation file (1) – Ce fichier contient le code Lua nécessaire pour mettre en œuvre les services spécifiés dans le ou les fichiers Service File. Voici quelques liens utiles pour l’écriture de ce fichier : Luup Plugins By Hand ; Luup Declarations ; Luup Lua extensions.
  • L_GenericPlugin1.xml, Lua file (0 à n) – En principe, le code Lua est placé dans le fichier device Implementation file. Cependant, si le code est important, il peut être judicieux de le structurer en plusieurs fichier Lua file et de ne faire que des appels dans le fichier device Implementation file.

2 autres fichiers permettent d’implémenter la partie visuelle du plugin et son interaction dans l’interface UI5. Ces 2 fichiers sont optionnels, ils ne servent que si le plugin doit posséder une interface graphique.

  • D_GenericPlugin1.json, Device interface file(0 ou 1) – Ce fichier n’est utile que pour interagir avec le plugin directement depuis l’interface utilisateur. Dans le cas contraire, le plugin peut toujours être invoqué depuis des scènes, du code Luup, à partir d’appels URL… Ce fichier contient également les liens vers les icônes associés au plugin. Voici quelques liens utiles pour approfondir la questionr : Luup plugins: Static JSON file ; Luup plugin tabs.
  • J_GenericPlugin1.xml, JavaScript files (0 à n) – Appelés par le fichier JSON Device interface file ces fichiers ne sont utiles que pour implémenter des interactions bien particulières (autres que de simples affichages d’étiquettes, de boutons ou de curseurs) au niveau de l’interface.

Informations et sources

Publié dans Domotique, Tutoriels | Tagué , | Laisser un commentaire