Lazer

Je suis en 1.0.2, et je pense avoir identifié un bug : [DEBUG] 23:41:11: Chargé avec succès dans la mémoire. [DEBUG] 23:41:11: La variable globale SysUpdateOptions a été créé avec succès ! [DEBUG] 23:41:11: Code d'état de la configuration du périphérique virtuel: 1 [DEBUG] 23:41:11: Veuillez attendre quelques secondes pendant l'initialisation ... [DEBUG] 23:41:16: Prêt [ERROR] 13:19:31: line 195: attempt to concatenate global 'errorCode' (a nil value) Je ne sais pas quand c'est apparu, je viens seulement de m'en rendre compte. Donc ça fait probablement plusieurs jours/semaines qu'il est dans cet état. Je pense que l'utilisation de la variable errorCode pose problème : fibaro:debug("status:" .. status .. ", errorCode:" .. errorCode); Et il vaudrait mieux utiliser la variable err

Bon et bien il ne te reste plus qu'àinstaller un compteur entre ton disjoncteur et ton tableau si je comprends bien. Et aucune risque de prendre une chataigne, puisque tu coupes le courant du disjoncteur (plombé ou pas, ça change rien)

Oui sans HC/HP ça va c'est facile. Par contre, pour EJP c'est pas gagné...

Thomas, sur le premier screenshot, les boutons Maison àdroite et àgauche permettent d'allumer ou éteindre toutes les lumières d'un coup dans la maison. En ce qui concerne le thermostat, j'ai un SRT321 que je peux bien contrôler depuis l'application iPad.

Fredric, c'est marrant j'ai eu l'approche inverse de la tienne : plutôt que de contacter pleins d'intervenants (enfin surtout EDF), j'ai préféré installer direct un compteur chez moi. Au final j'y ai passé moins de temps que toi. Le plus difficile a été de raccourcir mon câble 16mm² (àla scie a métaux finalement) puis de lui donner ma courbure voulue (c'est rigide ce machin là). Autrement la manipulation est quand même assez simple comme l'explique Fredo. Mon placard est bien rempli, mais j'ai quand même trouvé la place d'y glisser mon nouveau petit tableau.

Oui absolument

Énorme

La température, c'est pour tout le monde pareil. Espérons que ce soit corrigé dans la v4.

Je suis conscient que l'apparence est importante, mais je t'avoue franchement que ce n'est pas ma priorité... je préfère avancer sur les fonctions importantes. De toutes façon, ce paramétrage sera également stocké dans la base de données, donc il faudra toucher àla structure avec la création d'une nouvelle table. Ce n'est donc pas une simple mise àjour des fichiers PHP.

J'ai une centrale + ses propres capteurs (ouverture sur chaque porte/fenêtre, mouvements dans les zones de passage, détection de bris de vitre pour la baie vitrée, détecteurs de mouvement extérieurs, sirène + flash extérieur, transmetteur GSM, ...). C'est du Diagral, entièrement autonome, fiable, mais chère, mais surtout qui me permet de dormir sur mes 2 oreilles depuis 2 ans et demi. Et pas de problème de pile comme avec les modules Z-Wave (durée de vie annoncée : 5 ans) Depuis peu, mon système domotique Z-Wave et la HC2 m'apportent le confort (chauffage, volets, lumières, etc...) Pour l'interfaçage des 2 systèmes, j'ai commandé 2 modules récepteur 12/24V Diagral, qui seront connectés sur un Fibaro Universel afin d'obtenir 2 informations sur l'alarme : marche/arrêt, et intrusion. Ensuite, éventuellement, je ferai la bidouille qui consiste à souder un FGS-221 sur les boutons d'une télécommande afin de pouvoir la mettre en marche/arrêt à distance. Alors au niveau des limitations, la HC2 ne peut pas accéder aux infos des détecteurs d'ouverture et de mouvement de l'alarme.... mais je m'en passe bien.

Mon avis de parano : si tu as peur du cambrioleur "expert" (ce qui est mon cas), tu achètes une alarme NF A2P bi-fréquence et auto-protégée, et on n'en parle plus. Tu pourras faire confiance à ton système, et jamais tu n'auras de fausse alarme. La domotique c'est du confort, pas de la sécurité. Eventuellement tu mets en place des passerelles pour faire communiquer la domotique et l'alarme. Si maintenant tu souhaites faire une alarme avec le Z-Wave, tu vas galérer pour gérer la détection de brouillage.... il n'y a pas de "ping" d'un capteur, car les capteurs sur batterie sont en veille, ils n'écoutent pas le réseau pour économiser les piles. Ils se réveillent d'eux-mêmes à intervalle régulier (paramétrable dans les propriétés de chaque module), ou lorsqu'un événement survient (détection mouvement, etc...).

Pour utiliser le panneau de chauffage, il faut les conditions suivantes : - un thermostat (par exemple SRT321) - un module lié au thermostat (type FGS-211) La sonde de température n'est pas utilisée (le thermostat utilise sa propre sonde interne). Je ne sais pas si ça peut se configurer depuis un iPad, il vaut mieux utiliser l'interface Web pour l'administration de la box. Les applis tablettes et smartphones sont orientées "utilisation", alors que l'interface Web permet de faire toute l'administration en plus. Avec la HCL tu ne pourras pas utiliser les modules virtuels qui contiennent du LUA.

Dans le principe, il faudrait faire une boucle qui lit toutes les lignes de la page HTML, et rechercher dans chacune d'entre elle le mot "token", avec la fonction suivante : x , y = string.find (ligne, "token") Si ça matche, alors on doit pouvoir récupérer le token avec une commande du genre : token = string.sub (ligne, 25, 32)

Oui mais comme le dis Biboun, c'est pas non plus fiable à 100% : celui-ci peut être en 3G/4G (Wifi coupé), en mode avion, à court de batterie, oublié à la maison, etc... sans oublier les appareils pommés qui coupent le Wifi tout seuls (Android aussi, en fonction du réglage appliqué dans les paramètres) Donc il faut un algo qui se passe sur plusieurs critères pour prendre la décision de présence ou non (smartphone, détecteur de présence, détecteur d'ouverture, etc...)

Fou, moi ? Non Ah si un peu quand même Oui il y a des photos sur la seconde page.... mais en Edge je suis sà»r que tu peux y arriver, avec un peu de patience Le compteur m'a couté 40€ (neuf sur eBay), et 1 mètre de câble 16mm² à 2 ou 3€. Le plus cher a été l'achat d'un nouveau tableau à 2 rangées pour faire un truc propre (car mon tableau initial est complètement plein), et j'en ai profité pour installer 2 nouveaux interrupteurs différentiels, et de nouveaux disjoncteurs qui me servent à faire des nouveaux départs (Eco-devices, prises de courant, pompe à chaleur). Bref, un investissement que j'estime nécessaire.

Je ne connais pas bien les systèmes chauffants électrique par le sol, mais je verrais bien un thermostat Secure SRT321 dans chaque pièce, qui pilote le câble chauffant via un Fibaro FGS-211 en tout ou rien. En gros, ça veut dire ne pas utiliser le thermostat fourni par le fabricant, si c'est le cas.

Ah tiens, tu pourrais aussi faire un ping via le Wifi des smartphones pour ajouter àl’algorithme de détection de présence. Ca ne boufferas pas de batteries (enfin sauf si tu fait un ping toutes les secondes àlongueur de journée)

Le problème des versions intermédiaires, c'est que ça touche à tout (module virtuel, pages PHP, et base MySQL, avec les données qui sont déjà dedans). Donc il faut que je valide la procédure de mise à jour, et que je décrive ça bien en première page, donc ça me fait beaucoup de boulot. Il faut voir qu'il y a beaucoup de non-informaticiens ici, et je ne peux pas me permettre de balancer les mises à jour à la va-vite comme ça, car sinon ils ne sauront pas se débrouiller tout seuls. Bref, j'essaye d'avoir une approche "production" qui diffère un peu de ce qu'on trouve habituellement sur les forums où tout le monde bidouille. C'est une déformation professionnelle... mais comme je ne suis pas développeur, la gestion du versioning n'est pas évidente pour moi. Ce qu'il faut voir, c'est que si les utilisateurs perdent les données déjà présentes dans la DB, alors tout cela perd de son intérêt, puisque j'ai plusieurs idées sur le long terme : étudier l'évolution à long terme des valeurs, particulièrement utile pour les données de consommation, afin d'établir des comparaisons de dépense énergétique en fonction de la météo, de la température de consigne des thermostats, de l'ensoleillement, du remplacement d'un chauffage par un modèle pus performant, etc... utiliser les variations de températures pour calculer la vitesse de remontée en température pour déterminer l'heure de redémarrage des radiateurs le soir ou au retour de vacances afin d'avoir un confort optimal à l'arrivée dans le logement. vitesse moyenne de déchargement des batteries, afin d'estimer la date de fin de vie des piles de chaque module (et éventuellement décider remplacer par des fausses piles) PS : édite ton message et enlève la citation de mon propre message qui est juste au-dessus du tient, sinon les admins vont te tomber dessus à leur retour de vacances.

V2-4 également pour mon module qui a planté. Avec le Toolkit de Krikroff, dans les données brutes de l'API : "zwaveInfo": "3,3,67" "zwaveVersion": "2,4"

J'envisage 2 solutions : - appeler EDF et leur demander de déplacer ton compteur dans ta maison (service payant). Le câble actuellement utilisé pour la téléinfo vers le Calybox pourra être utilisé pour le téléreport vers le petit truc rond dans le coffret de rue. - acheter un compteur sur eBay ou LBC, et l'installer dans ta maison, juste après le disjoncteur de branchement. C'est ce que j'ai fait chez moi, et expliqué en page 2 de ce topic. Ca fonctionne très bien ainsi, et c'est relativement facile àfaire.

Moi je n'ai jamais constaté que le gestionnaire d'event ne soit pas fiable. Je veux dire que je vois tous les événements que je m'attends à y trouver. D'ailleurs, c'est même très pratique pour détecter un module qui est hors de portée Z-Wave : tu le déclenches (mouvements, appui sur l'interrupteur, réveil, etc...) et tu vois dans les events si il apparait ou pas. Par contre, dans mes événements, la plupart des infos sont des remontées des capteurs de T°C, HR%, LUX, etc... et ça a tendance à être assez bavard par moment !!! Donc si tu ne prends que le dernier événement via l'API, tu risques de louper des événements qui se succèdent trop vite.

Si ça marche déjà comme ça, pas de problème alors Oui, effectivement, parser des pages HTML/JSON/XML c'est pas franchement optimal pour un script qui s'exécute sur la HC2. J'espère que Fibaro va améliorer ce langage de script, car y'a du potentiel, mais on pourrait vraiment faire des trucs beaucoup plus puissants assez facilement.

Si les triggers de ta scène se réveillent constamment à chaque événement, fait gaffe que ça ne surcharge pas ta HC2. Bon après ça dépend du nombre de modules que tu vas surveiller. Pour savoir comment a été allumé la lumière, j'avais imaginé la solution suivante : - si une scène allume la lumière, création d'une variable globale juste avant - si un détecteur de mouvement allume la lumière, création d'une variable globale juste avant - ensuite, lorsque l'événement associé à l'allumage de lumière se déclenche automatiquement (suite aux 2 conditions précédentes ou à appui sur l'interrupteur), il suffit de regarder l'état des variables globables pour en déduire la source de l'événement. En ce qui concerne l'API HTTP, c'est le principe même des interfaces Web 2.0 en AJAX. Toutes les requêtes sont effectuées par du Javascript en asynchrone en mode HTTP vers le serveur Web situé en local. Cela évite de recharger complètement la page comme ce serait le cas si c'était réalisé de manière traditionnelle en PHP. Le panneau des graphiques de consommation fonctionne de la même façon. A mon avis, c'est la meilleur façon de faire. Ce qu'on peut éventuellement reprocher à Fibaro, c'est de ne pas (encore) avoir mis à disposition une API pour consulter les événement en LUA.

Fredric, Finalement, même bug que toi depuis ce soir. Le détecteur de mouvement s'est transformé en capteur de température, avec les valeurs 0°C et 255°C, donc à chaque mouvement, il signale un risque d'incendie, avec notification Mail et Push sur tous les smartphones et tablettes de la maison... le concert quoi Le réveil du module ne rétablie pas la situation, qui reste toujours en capteur de température. Plutôt que de l'exclure et de le réinclure, sachant que ça va se reproduire, je vais l'éteindre et attendre sagement que Fibaro corrige le bug (dans la HC2 ou le firmware du module, je ne saurais dire). Du coup ça me refroidit bien, et je vais attendre avant d'en acheter d'autres...

Pour récupérer les events par l'API HTTP, c'est simple : http://<IP>/api/panels/event?from=1352509026&to=1392509026&type=time Le From et le To sont des Timestamps UNIX. J'ai constaté que les events sont supprimés au bout d'un certain temps, et que plus tu génères d'événements, plus ce temps diminue. Logique puisque la HC2 doit attribuer une mémoire de taille fixe pour stocker les événements.