Lazer

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.

Ca doit être la 4.032 alors qui a tout pêté, car je suis passé de la 3.600 àla 4.033 sur la box de Lionel et j'ai bien 1 an d'historique (et même plus, seulement le graph se limite à1 an par défaut)

C'est comme ça que je vois les choses oui. En même temps c'est le but du thermostat, sinon autant prendre une sonde Dallas 1-Wire, ça sera moins cher et plus fiable.

Hansolo, oui comme je le disais plus tôt, le thermostat régule certainement très bien. Ce qui n'est pas exploitable en domotique, c'est la remontée de température dans la HC2 en vue de réaliser la régulation dans la box.

La Toupie, ça pourrait être pire, pour certain le besoin c'est de savoir si ils doivent se lever plus tôt pour déneiger la sortie du garage..... si Steven nous écoute

J'ajoute que si le plugin a un polling de 600s, et que la remonté de température des la station est de 600s, alors il y a entre 10 et 20 minutes de décalage pour la remonté d'info dans la HC2 !!! Impossible de faire de la régulation de température dans ses conditions, àmoins d'avoir un système de chauffage àtrès longue inertie et des murs en pierre de 1m d'épaisseur.

Je pique le lien à Fredo, mais il a trouvé malgré lui l'utilité de la HCL dans la voiture : Nos voitures pourraient envoyer un SMS lors d’un accrochage en notre absence Bon sinon, je déplace le sujet dans la bistrot, car on est encore loin, très loin d'un tuto. Mais si tu mets ton projet à exécution Philippe, montre nous en image ce que tu as fait, je suis curieux. Comme beaucoup, je ne saisis pas comment tu veux résoudre le problème des noeuds morts;

Bon le miens est arrivé àmon domicile, àdécouvrir en fin de semaine

Monter le VMDK sur une autre VM sous Linux, et faire les modifs depuis cette VM. Je suis certain qu'il y a des tutos pour ça sur Internet.

T'inquiète pas Megabubu Je me demande si on ne peut pas mettre une limitation sur la taille des messages postés afin que ça ne se reproduise pas..... Yohan, une idée ?

C'est certainement ça. A chaque fois que quelqu'un poste trop de lignes d'un coup, ça fait planter la page du sujet. Ce n'est pas la première fois que ça arrive. C'est pas grave, ça fait juste un peu bosser Yohan car il doit aller fouiller la base de données. Il prononcera ta sentence, et on votera pour

MrGoose, si tu as également l'occasion de nous rapporter un max d'infos du stand Qubino, apparemment il y a de belles nouveautés (modules DIN, mesure de consommation, interrupteur gestuel, etc)

Je n'y accède pas non plus; Vers 16h, c'était Internal Error 500 sur tout le site, je ne sais pas si c'est lié ???

Ah je sais pas trop, je suis encore en 4.3, et dans les images de boot disponibles àl'époque, il n'y avait pas de MAC/SN préconfiguré. Donc Video Station ne fonctionnait pas du tout.

Perso les MAC/SN j'y vois surtout un intérêt pour Vidéo Station. Pas besoin de DynDNS, j'ai une IP fixe (Freebox Power) et un nom de domaine

Certes Mais les 70€ sont à comparer aux 60€ d'un module Z-Wave standard + le prix d'un support en plastique pour l'intégration propre au tableau. Et justement, ceux présentés en première page sont très chers pour un simple support passif (en plus de ne pas être compatibles avec les Dimmers). Les modules que tu cites nécessitent d'avoir le réseau Ethernet dans le tableau, ou d'utiliser le Wifi avec les problèmes de communication qu'on lui connait. Et il faut encore avoir besoin des 8 sorties mises à disposition, qui ne sont que des relais et pas des dimmers. Perso, j'ai besoin de seulement 1 ou 2 modules Dimmer dans chaque tableau électrique, donc les modules Qubino DIN sont la solution idéale dans mon cas. Bref, bientôt il y en aura pour tous les goà»ts, c'est ça qui est bon avec la concurrence, c'est d'avoir le choix

Avec les nouveaux modules Z-Wave Rail DIN de Qubino, ils ne vont pas en vendre beaucoup de leurs boitiers en plastiques. Blog Domadoo : Qubino présente ses nouveautés à l’#ISE2015 Qubino, le fabricant qui bouscule la domotique.... elle me plait de plus en plus cette société