Lazer

J'avoue que je me suis fait la même remarque ce matin en voyant ça..... Oui Qubino va faire sa propre box, c'est la QC3 (Qubino Center 3).... le choix du numéro est facile à comprendre Elle sera annoncée l'année prochaine. Krikroff a déjà commencé à développer le QC3 Toolkit. Vous aurez compris que tout ceci n'est que pur délire à ne pas prendre au sérieux

Oui j'ai remarqué ça aussi. A moins que la version 002 ne soit pour Orange, et que les futurs acheteurs du module Fibaro en boutique auront le droit au FGSD-001 avec les pins (on peut rêver). Ce qui rendrait le 002 obsolète et devra être remplacé par le nouveau 001 juste pour voir les pins.... spécialement pour Latoupie

Et j'ajoute qu'en matière de modules, tu devras toujours en acheter un nouveau, car le modèle précédent est forcément dépassé par le petit nouveau. Ce n'est pas propre à Fibaro. Sinon on aurait encore des Nokia 3310 et des 2CV. Bref, on appelle ça le progrès (ou l'obsolescence programmée.....)

Bah tu le savais dès le départ qu'il n'était pas aux normes.... Et puis perso j'ai 2 modules FGSS-001 (donc pas aux normes), et je trouve que c'est très bien car ils sonnent moins fort, donc ils ne me cassent pas les oreilles. J'en ai mis un dans la cuisine, et l'autre au dessus de la cheminée, exactement là où il ne faut théoriquement pas les mettre. Sauf que c'est parfaitement voulu, comme ça en cas de départ d'incendie je suis averti immédiatement (mais sans me faire exploser les tympans) et j'ai le temps d'aller chercher l'extincteur et/ou une couverture / seau d'eau pour éteindre le feu. Parce que les DAAF aux normes situés dans le couloir, c'est bien gentil, mais ça ne sert qu'à te réveiller la nuit quand tu dors, afin que tu sautes par la fenêtre depuis la chambre. C'est mieux d'avoir les 2 pattes cassées que de bruler vif. Oui sauf que la maison, elle aura bien cramé, elle.

J'ai passé pas mal de temps à jouer avec les paramètres du FGMS, et après avoir lu la doc en long en large et en travers, j'en suis arrivé à la conclusion que le capteur de luminosité n'est tout simplement pas fiable. Perso j'ai complètement abandonné l'idée de réaliser des scénarios basés sur cette valeur de luminosité, et je me base maintenant sur les heures théoriques de lever et coucher du soleil, et tant pis si il y a des nuages qui affectent la luminosité. De toutes façon ça reste plus fiable que le FGMS. En revanche, aucun souci avec la sonde de température (si ce n'est que située au plafond, elle ne sert à rien quand le chauffage est allumé). Concernant les graphiques, oui le module virtuel est en LUA, donc il faut une HC2. Pour la HC Lite, il faut soit attendre la v4, soit utiliser des scripts PHP externes qui viennent interroger la HCL via l'API. Il y a un tuto sur le forum, mais je n'ai pas le lien sous la main....

Les Qubino ont le soft-start ? C'est quand même agréable comme fonctionnalité. Ils chauffent moins aussi, dans les boites étanches ça peut être un détail d'importance. Et avec les futur Qubino Rail DIN, ça va être top !

10 ans la durée de vie des détecteurs de fumée FIbaro, c'est bon à savoir ça. Un peu mieux que les 7 ans que je pensais initialement, mais au final on peut être certain que dans 10 ans tout le monde sera équipé de DAAF, mais tout le monde aura oublié qu'il faut les remplacer. Bref, l'offre Homelive Au Cas Où c'était quand même le vrai bon plan 4 modules Fibaro pour 120€, et une box en plastique dont je ne sais pas quoi faire !

Quitter Fibaro pour aller vers la nouvelle eedomus+, je peux comprendre. Mais Zibase ? Alors làil faudra m'expliquer ce que tu lui trouve d'intéressant ???

ah oui en effet.... dans ce cas, il faut que ton Javascript appelle une page PHP qui se chargera d'établir la session avec la HC2. C'est pas simple l'Ajax.....

Je n'ai pas testé.... mais il demande de resaisir les identifiants à chaque fois qu'on clique sur le bouton ? Lors du premier appel à /api/devices, tu effectues la connexion avec le login/password. En PHP, tu poux récupérer l'entête de la réponse, qui contient un cookie contenant l'identifiant de session. Il faut que tu réutlises ce cookie aux sessions suivantes, afin de ne pas devoir se ré-authentifier à chaque appui sur un bouton. EDIT : sinon comme dis Nico (qui a pris la mauvaise habitude de me griller...hihi) tu peux simplement remettre le login/password en dur à chaque appui sur un bouton.

Ouvrir un ticket sur le bugtracker serait pas mal (sauf si ça a déjà été fait par d'autre) Sinon un mail à : support@fibaro.com http://www.fibaro.com/fr/contactez-nous

C'est pas con, j'aime bien le principe C'est effectivement utile pour les interfaces tactiles de nos téléphones, ou sur une tablette murale. PS : pour ton code, tu peux utiliser les balises en cliquant sur le bouton <> présent dans la zone d'édition du message, car là ce n'est pas hyper lisible...

Bonjour, Ouvre un ticket auprès du support Fibaro afin qu'ils se connectent sur la box et puissent diagnostiquer le problème, puis le corriger. On ne peut rien faire, et ce n'est pas la première fois que je vois passer ce problème sur le forum dans la semaine.

Dans ma signature http://www.domotique-fibaro.fr/index.php/topic/466-graph-de-temp%C3%A9rature-humidit%C3%A9-consommationsur-nas/

Oui je veux en faire un tuto dans un autre sujet, mais on va attendre un peu de voir si quelqu'un trouve quelque chose à ajouter ou à contredire. Pour la fréquence, je dirais que ça dépend de la fréquence que tu mets. Il faut trouver un juste équilibre entre le confort de mise à jour des infos, et l'usure des piles. Y'a pas de recette miracle de ce coté là . Perso, pour le FGMS, j'ai même désactivé la remonté des infos qui me sont inutiles : par exemple le tamper de mouvement/vibration, car je n'ai pas besoin de cette info dans mes scénarios, et le FGMS ne me sert pas à faire une alarme. Tu peux surveiller l'usure des piles avec mon outil de graph, c'est très visuel et il est assez facile de projeter la fin de vie des piles en établissant une ligne droite de tendance.

C'est le catalogue général 2014-2015 dont vous parlez ? De plus de 100 Mo ? Si c'est le cas je veux bien un lien (ou un MP), car j'ai celui de l'année dernière.

N'empêche, tu as posé les bonnes questions, j'ai juste eu à me laisser guider Pour approfondir la théorie, une saine lecture (dans un vrai livre avec du papier, en anglais) : Z-Wave Basics Explique très clairement tout la théorie du protocole Z-Wave. Attention, c'est au lecteur de transposer ces connaissances théoriques avec la pratique que l'on peut rencontrer sur telle ou telle box.

Si quelqu'un voit quelque chose à ajouter, qu'il parle maintenant (ou se taise à jamais....)° Ainsi on pourrait établie un guide clair et précis de la situation, et en faire un nouveau sujet qui servirait de référence.

Google, recherche : syslinux.cfg rmmod=ata_piix 1er lien : http://xpenology.com/forum/viewtopic.php?f=2&t=3132 Je veux bien aider, mais il faut chercher un peu aussi, là c'est du basique quand même (la recherche est basique..... je ne dis pas que la solution est basique, car c'est quand même pas évident si on ne connait pas)

Le réveil, c'est le DEVICE qui le décide. A ce moment là il communique avec la HC2 et échange un grand nombre d'informations (on voit la diode de la box clignoter frénétiquement pendant quelques secondes), puis attends un peu (au cas où la box décide de communiquer encore d'autres infos), puis ils se rendort quelques secondes plus tard (généralement 5 ou 10s je crois). Tout ce processus de réveil est extrêmement consommateur de batterie. L'intervalle de réveil ne concerne que les modules alimentés sur batterie (car les modules alimentés sur secteur écoutent toujours le réseau puisqu'ils participent activement au routage des paquets dans le réseau maillé). Le réveil est déclenché de 3 façons : - lors de la mise sous tension des piles du module - lorsque l’intervalle de réveil paramétré est atteins (soit la valeur par défaut, soit celle qui a été poussée par la box). - lorsqu'on triple-clique sur le bouton Le polling, c'est la HC2 qui le décide, en allant communiquer avec le module. Si il est configuré à 5 minutes (dans les paramètres généraux de la box), alors toutes les 5 minutes, la box contacte les modules afin de s'assurer qu'ils sont toujours en vie. Si elle n'arrive pas à les joindre, elle recalcule d'autres chemins (jusqu'à 15 tentatives en quelques secondes). Si cela échoue, elle les déclare comme mort. Cette pour cette raison qu'un module type Wall Plug ou Dimmer qui est débranché ne disparait pas immédiatement de la box. Il disparait quand la box n'arrive pas à le contacter (soit parce qu'elle essaye de lui envoyer un ordre type ON/OFF, soit parce que le délai de polling est atteint). Ce polling régulier peut surcharger le réseau, c'est pour cette raison que passé l'inclusion d'un certain nombre de modules, la HC2 conseille une nouvelle valeur de polling plus élevé. Bien sà»r, le polling n'a de sens que pour des modules qui écoutent le réseau, donc alimentés sur secteur (230V, 12V, 24V, etc). Je ne comprends pas à quoi sert ce paramètre de polling dans l'interface Web pour les modules sur batterie ? Le polling peut être configuré de 2 façons dans la HC2 : - via les paramètres généraux de la box, auquel cas la valeur s'applique à tous les devices. - via les paramètres avancés de tel ou tel module, en fonction de besoins très particuliers; Il n'est généralement pas nécessaire de modifier ce paramètres, qu'on laisse alors à 0 afin qu'il prenne en compte la valeur globale. En ce qui concerne la fréquence de remontée des infos, cela dépend des modules, et des paramètres spécifiques de chacun. Par exemples : - remontée immédiate pour un contact d'ouverture de porte, d'une détection de mouvement, ... - remontée après un certain délai pour une température, humidité, luminosité, ... - remontée après une certaine variation (delta) pour une température, humidité, luminosité, ... Le célèbre FGMS est le module qui dispose du plus grand nombre de paramètres afin de configurer finement la remontée d'infos. D'autres modules, tels que le ST814 disposent de paramètres beaucoup plus restreints. La mise à jour des paramètres d'un device dépend de 2 cas de figure : - module sur secteur : les paramètres sont envoyés immédiatement puisque le module écoute le réseau - module sur batterie : la box attend le réveil du module (voir explications au premier paragraphe). Pendant ce temps là , on voit le petit message en vert "En attente de réveil..." De par mon expérience personnelle, et comme je le disais plus haut, le réveil d'un module sur batterie est extrêmement consommateur de batterie. Par conséquent, j'ai tendance à allonger cette valeur le plus possible. De toute façon le réveil n'a d'intérêt que lorsqu'on modifie les paramètres d'un module, ce qui n'arrive jamais en production pour un module qui fonctionne correctement. Un intervalle de plusieurs jours ne pose pas de souci. Une exception toutefois : les modules de type thermostat, comme le Secure SRT321, car le panneau de chauffage doit pouvoir modifier sa valeur de consigne. On choisira alors une valeur raisonnable d'environ 5 minutes, ou 15 minutes si on peut se permettre 1/4h de retard entre la consigne et le début de la chauffe. Si on réalise des fausses piles, on peut descendre ce paramètres à 1 minute pour une réactivité presque instantanée (éviter ce descendre en dessous, cela saturerait le réseau inutilement). Enfin, pour la phase de réglage d'un module, surtout pour le FGMS qui a de très nombreux paramètres, on peut choisir un intervalle de réveil court de quelques minutes pendant les quelques jours nécessaires à son paramétrage optimal en fonction de ses besoins. Ainsi, il n'est pas nécessaire d'attendre plusieurs heures ou d'aller triple-cliquer sur le bouton pour qu'un nouveau paramètre soit pris en compte, le temps de faire les essais. Les paramètres d'un module, justement, permettent de régler finement la remonté des infos vers la HC2. Le FGMS dispose de tout ce qu'il faut pour obtenir le comportement désiré, encore faut-il prendre le temps de bien étudier la doc pour comprendre les interactions entre chacun. A l'opposé, le ST814 ne dispose que d'un intervalle entre 2 mesures, c'est hyper basique. Pour finir, grâce à tout ce qu'on vient d'étudier, et contrairement à ce que je vois parfois sur le forum, on ne devrait pas s'appuyer sur le réveil d'un module pour remonter les infos de température/hygro/luminosité/etc (car cela consomme beaucoup d'énergie et occupe la bande passante du réseau), et donc on doit s'appuyer sur les paramètres spécifiques de chaque module.

C'est donc ça qui a grillé sa box : il a trop forcé sur la puissance d'émission

Je ne te conseille pas de baisser l’intervalle de réveil, sauf durant quelques jours le temps que tu fasses tous tes tests. Autrement, cela va te vider les piles à vitesse grand V. Perso, pour tous mes modules sur pile, j'augmente l’intervalle de réveil à plusieurs jours, voire 1 semaine ! Très efficace sur la durée de vie des piles. Pour le délai entre 2 interrogations (polling) tu peux laisser à 0 qui est la valeur par défaut. Il va se baser sur le paramètres général de la box, qui doit être de 5 ou 10 minutes en fonction du nombre de modules de ton installation.

@Jojo oui voilà. Quelques éléments de réponse sur la clé USB par ici : http://www.domotique-fibaro.fr/index.php/topic/2364-hc2-usb-recovery-tweaks/

Ouvrez un ticket au support Fibaro afin qu'ils se connectent, puis ils peuvent extraire l'historique des données de la sauvegarde pré-migration v4.032 afin de les importer manuellement dans votre DB actuelle. Ainsi il ne manquera que 1 ou 2 semaines de statistiques. Je suis sûr qu'ils vont adorer si tout le monde fait cette demande

Jojo, les données de conso sont stockées dans la DB, qui est sauvegardé sur ta clé Recovery. En cas de restore, il récupère tout à l'identique. Le seul truc qui n'est pas récupéré, ce sont les icônes personnelles. Les devices ne changent pas d'ID en cas de restore, sauf si entre temps tu les as exclu et inclu sur une autre box par exemple.