hexan79

Oui je comprends... Après ça dépend de ce qu'on veut... Personnellement ça ne me choque pas de laisser 20 ou 30 secondes le temps de désactiver l'alarme.

@pepite, pour ton installation, l'utilisation du NFC aurait du sens si, lors d'une détection d'intrustion, tu ne declenche pas l'alarme tout de suite. C'est àdire qu'il faudrait laisser le temps àla personne de désactiver l'alarme par NFC. Meme principe lors de l'activation de l'alarme : laisser le temps àla personne de quitter le périmètre. ça répond àta question?

Non, je ne comprends pas non plus. @pepite, qu'est-ce qu'une alarme avec une barrière en façade ?

Hi jcosta, I don't think it is related to the automatic way to start the script. If it works manually, it should work with startup service.

Hi, Yes there is a log file : /var/log/thermos.log Only timeout errors are reported in this file (for example, when Home Center is not responding). This error should not lead script to crash. I think that your problem is a network interface failure in your PC. This kind of error is not handled by the script. Could you stop tempupdate service, then from source folder try this: python tempupdate.py let the script run, then report the error message if a crash occurs.

what is you Linux distro?

Have you configured restatmo service? does it work for you. If it works, "tempupdate" should also work, it's the same principle. So, if you do the following instructions, temperature update should work: chmod +x tempupdate.py sudo cp tempupdate /etc/init.d/ sudo chmod 755 /etc/init.d/tempupdate sudo update-rc.d tempupdate defaults sudo service tempupdate start

Bien vu @i-magin Alors, ça te tenterais de te lancer sur ce projet aussi?

Je vous propose ce tuto pour créer un Virtual Device HCL afin de contrôler un thermostat Netatmo. C'est très utile dans l'optique d'un tableau de bord unifié, regroupant tous les objets connectés au niveau de la box domotique. C'est pratique aussi lorsqu'il s'agit de créer des scènes intégrant des informations provenant du thermostat (température mesurée, température de consigne de la chaudière, mode de chauffage...). Il existe bien un plugin Netatmo sur HCL mais je n'ai jamais pu le faire marcher, du moins pour le thermostat (ça marche peut-être pour la station meteo Netatmo). Par ailleurs, du fait des limitations de la HCL en termes de programmation (pas de LUA comme la HC2), il a fallu développer un web service HTTP (et non HTTPS) jouant le rôle d'intermédiaire entre le virtual device et le thermostat. En marge de ce tuto, je propose donc aussi un web service pour piloter le thermostat Netatmo. Principe L'objectif est donc de "fabriquer" un virtual device HCL pour le thermostat Netatmo permettant de: Récupérer la température mesurée Définir une température de consigne Définir le temps de validité de la température de consigne Switcher entre les modes : manual, program, away Voilààquoi cela ressemble visuellement Prérequis - Savoir créer un virtual device HCL. Ce tuto est très bien pour ça. - Quelques connaissances Linux pourraient être utiles pour l'installation du software, la copie et la modification de fichiers... - Quelques connaissances http et web services pourraient aider àcomprendre le principe de fonctionnement (optionnel) Matériel - Une HCL - Un thermostat Netatmo - un PC ou un Raspberry Pi (ou équivalent) qui jouera le rôle de serveur hébergeant le web service Pour ceux qui voudraient installer le software sur un Linux autre que celui du Raspberry (Raspbian), il faudrait s'informer sur la manière de rajouter un service (deamon) qui pourrait être différente de celle présentée ici. Logiciel Le code (Python) du web service que je fais tourner sur Raspberry Pi et que j'ai appelé "restatmo" est disponible dans Github sur ce lien. Un descriptif d'installation et de configuration y est décrit ici. Il s'agit d'une première version avec surement quelques bugs. Voici quelques caractéristiques du logiciel: - Pour ceux qui connaissent un peu les web services, voici un aperçu de l'interface http de "restatmo": GET /tempSP : récuperer la température de consigne courante POST /tempSP/valeur_entiere : définir une nouvelle température de consigne (durée par défaut : 15mn). Cette requête permet aussi de définir les modes away et program POST /tempDur/duration : définir la durée de validité de la température de consigne courante GET /tempMeas : récupérer la température mesurée par le thermostat - Pour la mise àjour du "slider" de la température mesurée, j'ai prévu un second service (tempupdate.py) se trouvant dans le même répertoire "restatmo". Lorsqu'il est lancé sur la machine passerelle (raspi ou autre), ce service met àjour la température mesurée du virtual device àintervalles réguliers. Des paramètres d'identification de la HCL et l'intervalle de mise àjour sont des données requises par ce service et sont paramétrables dans ce fichier tempupdate.py. Cette manière de mettre àjour la température est la seule que j'ai trouvée. En effet, les requêtes HTTP d'un virtual device sur HCL ne permettent pas d'aller chercher des valeurs. Le virtual device il faut d'abord définir le "host" et le "port" du Virtual Device qui sont respectivement l'adresse IP de machine sur laquelle tourne le service "restatmo" et le port de ce même service (par défaut 5000) Ce virtual device est composé de 3 sliders et de 3 boutons: 1) Slider 1 : la température mesurée par netatmo Il n'y rien àconfigurer au niveau de la chaine de caractères àenvoyer par ce slider. En effet, il est mis àjour automatiquement par le service "tempupdate" décrit précédemment. 2) Slider 2 : la température de consigne Chaine àenvoyer: POST /tempSP/_sliderValue_ HTTP/1.10x0D0x0AHost:192.168.0.28:5000 0x0D0x0AAuthorization: Basic xxxxxxxxxxxxxxxxxxx 0x0D0x0A0x0D0x0A NB: _sliderValue_ est la valeur indiquée par le slider en question (très pratique comme variable) xxxxxxxxxx: "user:password" en base 64 (voir tuto de création de Virtual Device) 3) Slider 3 : la durée de validité de la température de consigne Chaine àenvoyer: POST /tempDur/_sliderValue_ HTTP/1.10x0D0x0AHost:192.168.0.28:5000 0x0D0x0AAuthorization: Basic xxxxxxxxxxxxxxxxxxx 0x0D0x0A0x0D0x0A 4) Bouton1 : mode program Chaine àenvoyer: POST /tempSP/0 HTTP/1.10x0D0x0AHost:192.168.0.28:5000 0x0D0x0AAuthorization: Basic xxxxxxxxxxxxxxxxxxx 0x0D0x0A0x0D0x0A 5) Bouton2 : mode manual (ce n'est rien d'autre qu'une température de consigne à20°) Chaine àenvoyer: POST /tempSP/20 HTTP/1.10x0D0x0AHost:192.168.0.28:5000 0x0D0x0AAuthorization: Basic xxxxxxxxxxxxxxxxxxx 0x0D0x0A0x0D0x0A 6) Bouton3 : mode away POST /tempSP/101 HTTP/1.10x0D0x0AHost:192.168.0.28:5000 0x0D0x0AAuthorization: Basic xxxxxxxxxxxxxxxxxxx 0x0D0x0A0x0D0x0A enfin, pensez àtélécharger l'icone (ci-joint) àassocier au virtual device. La suite je n'ai peut-être pas suffisamment détaillé ce tuto, notamment concernant la partie paramétrage et installation du service web. N'hésitez pas àme solliciter si vous êtes intéressés ou si vous avez des questions. Vous pouvez aussi jeter un coup d'oeil sur mon autre tuto dont le but est de piloter l'alarme HCL/HC2 avec une passerelle NFC. A++

Bien joué @i-magin ! Pour Raspbian Wheezy, je crois effectivement qu'il y a un problème avec le package "python-requests" que t'as essayé d'installer avec la commande "apt-get". En fait, il faudrait plutôt l'installer de cette façon. Sinon pour la LED, j'ai dénudé 2 fils de sorte à avoir des extrémités "souples". J'ai ensuite introduit ces extrémités dans le connecteur du Shield NFC pour ensuite introduire les pins du Raspi, qui du coup, permettent de coincer les fils. J'avoue que ce n'est pas une manière "propre" mais ça marche sans problème depuis plusieurs semaines

Bonne nouvelle ! A++

Est-ce qu'à l'occasion tu pourras poster une extrait du fichier log?

OK je vois. Je ne me souviens plus si j'ai eu àinstaller moi-même python-requests ou pas. C'est bien possible. Je vais rajouter cela dans le README... c'est fou les différences entre les distrib... Tiens-moi au courant pour la suite.

C'est très bizarre, J'ai l'impression que cette fois ton service a bien était pris en compte mais contrairement à ta précédente install il y a un souci avec le code. Le code de réponse HTTP 401 est bizarre aussi, ta HC2 fonctionne bien en dehors des communication avec le raspi? sinon, dans ta précédente installation as-tu bien essayé de créer toi-même le fichier pid? Je suis à court de solutions

Je suis sur wheezy. A ma connaissance le fichier pid est créé automatiquement par homegw. Peux-tu essayer de le creer toi-meme par la commande : touch /home/pi/homeGW/homegw.pid Puis réessaye

J'ai refais une install chez moi, ça marche sans pb. à tous les coups c'est ton fichiers homegw qui n'est pas bon. Je te propose de recommencer l'installation du service homegw (Pour tes sources python je pense que tout est OK) Repars de zero en commençant par supprimer ce que t'as fait: sudo update-rc.d -f homegw remove sudo rm /etc/init.d/homegw Tiens bon tu y es presque

Je sais pourquoi le service ne se lance pas, j'ai oublié d'indiquer qu'il faut rendre executable le fichier python : chmod +x hgwservice.py maintenant tout devrait fonctionner. Le service se lancera automatiquement au démarrage du raspberry. Amuse-toi bien et n'oublie pas de poster la photo de ton boitier homeGW.

effectivement ! on a trouvé le coupable. T'as dû faire un copier/coller de toute la page github pour avoir ces lignes dans ton code. La bonne manière d'installer le code comme indiqué dans le fichier README c'est en utilisant "git clone" ça devrait résoudre ton problème de démarrage de service.

Deux autres vérifications àfaire: - Python est-il bien installé sur ton raspi? en général il l'est par défaut (tape : which python) - depuis le repertoire des sources, essaie de lancer : sudo python hgwservice.py y'a-t-il un message d'erreur?

Tout a l'air d'être bien pourtant! Je n'ai pas sous la main d'environnement pour tester. Mais vérifie cela : 1) le fichier homegw, l'as-tu bien modifié avec un éditeur sous linux? Si tu le modifies sous windows pour ensuite le copier sur raspi, ça pourrait ne pas marcher. 2) peux-tu essayer d'enlever le slash "/" à la fin de HOMEGW_PATH, ça donne donc : HOMEGW_PATH=/home/pi/homeGW

Cool! tu y es presque J'ai peut-être un idée sur l'origine du pb. D'abord es-tu bien sur l'OS Raspbian au niveau du Raspberry ? En effet, la manière de définir un service peut varier d'un OS à l'autre. Si t'es bien sur raspbian c'est OK, vérifie que la variable "HOMEGW_PATH" dans le fichier "homegw" pointe bien vers le repertoire où se trouve les sources refais un coup de "sudo update-rc.d homegw defaults" Ensuite, essaie de lancer le service par "sudo service homegw start" et vérfie qu'il a bien été lancé par "sudo service homegw status"

Le câblage de la LED avec le Raspi ressemble à ce qu'on voit dans cette image . Il faudra aussi une résistance. Les câbles que j'ai utilisés ressemblent à ça La difficulté que j'ai eue, c'est que tous les pins du Raspi étaient cachés par le connecteur (noir) du shield NFC. J'ai donc dà» ruser un peu avec les câbles que j'avais sous la main pour choper les contacts depuis ce connecteur. D'où le câblage bizarre sur la photo du boitier ouvert... Ensuite le code Python qui contrôle la LED ressemble à ça (voir code Github): GP.setup(11,GP.OUT) GP.output(11,False) --> pour éteindre GP.output(11,True) --> pour allumer

Il suffit d'avoir l'image Raspbian pour Raspberry sur SD et d'installer dessus homeGW tel que c'est décrit dans Github. Ce n'est pas très compliqué et à mon sens c'est bien plus ludique que de récupérer une image toute faite

J'aimerais partager avec vous ma petite réalisation DIY de passerelle domotique pour Home Center. Je l'ai testée pour HCL, mais ça devrait marcher aussi pour HC2. L'objectif est le pilotage des modules du système d'alarme Fibaro. Un sujet semblable a déjà été abordé auparavant ici, ou encore ici. En effet, je n'étais pas satisfait de la détection de présence (et d'absence) à travers la connexion wifi domestique et j'étais encore moins satisfait du système de géolocalisation de la Fibaro HCL et son côté hyper-aléatoire. Je me suis dit que le moyen le plus robuste pour piloter l'alarme en fonction de la présence/absence serait un système basé sur un contrôle d'accès NFC. Principe Une passerelle NFC est installée à l'intérieur du logement, juste à l'entrée. Cette passerelle est en attente permanente du passage d'un Tag NFC. Au passage d'un Tag NFC indiquant l'entrée ou la sortie de quelqu'un du logement, l'état de l'alarme de la HCL/HC2 change (de armé à désarmé ou inversement) Une LED permet de visualiser l'état de l'alarme (allumée si armée, éteinte si désarmée). Prérequis - Une HC2 ou une HCL et des modules d'alarme : détection de mouvement, détection d'infraction, sirène, etc Le tout configuré de cette façon au niveau du panneau d'alarme de la HCL/HC2. - Quelques connaissances Linux pourraient être utiles pour l'installation du software, la copie et la modification de fichiers... Matériel - Une HCL ou une HC2 - Un Raspberry Pi (modèle B+ ou 2), OS : Raspbian Wheezy (je n'ai pas testé si ça fonctionnait avec une autre distribution Linux) - Un contrôleur NFC NXP EXPLORE-NFC adapté au Raspebrry Pi. En vente ici (merci à @i-magin pour l'info). - Une LED, une résistance et quelques cables électroniques pour relier la LED au raspberry Pi de cette façon - Un câble ethernet pour relier le Raspberry Pi à la box ADSL ou à une prise murale réseau OU BIEN un dongle USB Wifi (plus simple) - Un boitier pour intégrer le Raspberry Pi et le shield NFC (j'ai utilisé le boitier Femto de ma freebox qui ne me servait plus, certains l'ont peut-être reconnu ) - Un câble micro USB pour alimenter le Raspberry Pi - Un jeu de Tags NFC type MiFare (un tag par utilisateur potentiel) Il faut compter environ 50€ de matériel (hors HCL/HC2 bien sà»r) Photos Logiciel Le code (Python) du logiciel qui tourne sur Raspberry Pi et que j'ai appelé "homeGW" (comme home GateWay) est disponible dans Github sur ce lien. Un descriptif d'installation et de configuration y est décrit. Il s'agit d'une première version avec surement quelques bugs. Voici quelques caractéristiques du logiciel: - Le logiciel est paramétrable : informations d'accès à la HCL/HC2, les ID des modules d'alarme, les ID des tags NFC pouvant contrôler l'alarme, etc (voir fichier README) - La HCL/HC2 n'a pas besoin d'être spécifiquement configurée pour "cohabiter" avec la passerelle. Autrement dit, aucune scène spécifique, aucun "virtual device" ne sont nécessaires. Par contre, je fais appel à une variable globale définie dans la HCL qui indique l'état de l'alarme (armée ou pas). Pour ma part j'ai fait une scène simple qui permet de positionner cette variable à "1" lors que l'un (ou tous) des modules d'alarme est armé et à "0" lorsqu'il est désarmé. Le nom choisi pour cette variable dans HCL/HC2 devra être indiqué au logiciel homeGW au niveau du paramètre "HCL_ARMED_VAR" (voir la description du paramétrage dans le fichier README). - Si l'état de l'alarme de la HCL/HC2 est modifié par un autre moyen (PC, smartphone...), la passerelle se synchronise automatiquement avec ce nouvel état au bout de quelques secondes (grâce à la variable décrite dans le point précédent). - Un fichier log est prévu pour répertorier tous les éventements qui se produisent au niveau de la passerelle NFC y compris les échanges avec la HCL/HC2, les erreurs, l'heure passage des tags NFC et leurs ID, etc. La suite... Je vais essayer d'améliorer ce projet à travers les échanges que j'espère avoir avec vous, vos questions, vos contributions... Si ce projet vous intéresse et si vous souhaitez vous lancez dedans, n'hésitez pas à faire part de vos retours d'expérience dans ce topic. Les possibilités offertes grâce à l'API de la Home center mais aussi à d'autres API sont très intéressantes. Dans la même logique que pour l'alarme, j'imagine très bien des actions de contrôle de l'éclairage, du chauffage, de la musique, d'une caméra IP... qui se déclenchent sur ordre de la passerelle NFC. A suivre donc...

Bonjour, Est-il possible de créer un module virtuel qui permet d'indiquer l'état d'une variable globale (0/1) sur HCL? Merci d'avance pour votre aide