Lazer

Sinon pour donner mon avis : je suis bien content sur Fibaro depuis que c'est redevenu stable. Jeedom c'est bien si on veut interconnecter plein de bidules low cost, surtout en bluetooth, mais perso tous ces produits ne me tentent pas. La force de la HC2 c'est le LUA, alors bien qu'il manque les plugins utilisateurs pour faire une intégration parfaite, on arrive quand même à tout piloter avec les scènes + VD. Le protocole qui unifie tout le monde, c'est l'IP, et grâce à ça, la HC2 n'est pas en reste. Là par exemple, ça fait 2 mois que je pilote mon vidéoprojecteur avec un VD, quand je vois la documentation Epson qui mentionne la compatibilité avec la domotique pro à what mille euros (Crestron et compagnie, très courant dans le monde du home cinéma haut de gamme), ça me fait bien sourire car on fais la même chose avec notre petite box, pas si limitée que ça. Idem pour Kodi, Sonos, et plusieurs marques d'amplis HC sur le forum. Bref, on a de quoi se faire de très belles installations sur HC2, perso je n'en vois pas le bout et ne suis toujours pas limité pour mes usages.

Oui c'est vrai que ce n'est pas abordable FHEM, et en plus Linux c'est la partie facile, car FHEM à lui seul est d'un complexe difficilement imaginable, et presque toute la documentation/forum est en allemand. Par contre c'est d'une robustesse à toute épreuve, pas un plantage en 2 ans et demi !!

Non n'importe quel Linux : une VM, un PC dédié, une HC2, etc

Ce n'est pas une stable transcendante ça ..... Qui se lance ?

J'ai déjà eu ça pour un FGK quand la pile est tombé en panne entre le moment où il a envoyé la trame de détection, et le moment (de ne pas) envoyer le trame de fin de détection. Donc vérifie ta pile. J'ai aussi le cas pour des FGBS qui sont en limite de portée Z-Wave, donc la 2nde trame, celle qui signale la fin de l'alerte, n'est pas toujours reçue par la box. Donc vérifie la portée du signal.

Augmenter le nombre maxi d'instance (jusqu'à 10) Ou écrire différemment ta scène. Par exemple, c'est une très mauvaise idée de faire des sleep() dans une scène : cela monopolise 1 instance de la scène, et la fin de la scène ne sera jamais exécutée si entre temps la scène plante ou la box reboot.

Je confirme, passer un maximum de câbles, ou au minimum des gaines sans coudes pour repasser un aiguille dedans plus tard. Perso j'ai même un FGMS "câblé" avec une fausse pile.

En fait, c'est la philosophie complète du panneau de l'alarme qui est totalement différent de ce que tu connais sur ton alarme dédiée. Sur ton alarme dédiée, tu armes la totalité des capteurs, puis tu désarmes la totalité, en une seule fois. Sur le panneau d'alarme de la HC2, ce n'est pas le panneau d'alarme qu'on arme, mais la totalité des capteurs. Une fois que tous les capteurs sont armés, alors le panneau d'alarme devient armé. Et non l'inverse. Pour le désarment, c'est bien sûr l'opposé : tu désarmes TOUS les capteurs, ce qui a pour effet de désarmer le panneau d'alarme. Sachant cela, si tu désarmes un seul capteur, il est normal que les autres capteurs restent armés. L'intérêt peut te sembler discutable, mais la logique derrière ce panneau d'alarme est de pouvoir se créer des scénarios bien plus sophistiqués qu'une alarme traditionnelle (celle-ci est généralement limitée à un armement total, ou armement partiel de certaines zones). Il faut donc que tu te fasses des scènes, qui permettent d'arme et désarmer tous les capteurs des zones que tu souhaites, afin de retrouver un comportement similaire à un système d'alarme traditionnel. Sur HC2, il existe déjà plusieurs VD en LUA pour cela (dont le module "alarme avancée" de @Moicphil ) mais pour HCL je ne suis pas certain qu'il existe grand chose sur le forum.

Il y avait un tuto sur domotique-info pour le dressing/lumineux/meteo http://www.domotique-info.fr/2013/08/armoire-meteo-fibaro-rgbw-controller/

@Sakkhho là comme ça, je ne vois pas ce qui coince. Et si tu exécutes la requête à la main dans phpMyAdmin, ça donne quoi ? Tu dois bien avoir un message. Dans ton tuto de la page précédente, j'ai l'impression qu'il manque le screenshot pour la table gaz_month. @ggpublic pas de limite de device connue. Tu as un message d'erreur quelque part ? (notamment dans le bouton Devices) ? Ca ne serait pas le bug Netatmo par hasard ?

Tricheur

ouais, enfin bon on n'a pas tous une CNC à disposition

@pepite dans ton coin, ils ne t'ont pas installé le télérelevé pour le compteur d'eau ? Ce qui permet d'accéder au relevé sur le site Web (Veolia pour ma part). J'ai partagé un script sur le forum pour envoyer ça dans Domocharts automatiquement. @Sakkhho l'utilise.

C'est le nombre d'instance simultanées de la scène, donc en même temps. Ce paramètres a été introduit par Fibaro car pas mal d'utilisateurs avaient des scènes mal programmées, et se retrouvaient avec plusieurs 10zaines d'instances simultanées, ce qui faisait planter la box. Si tu la lance 12 fois dans la journée, mais à des moments différents, tu n'auras aucun souci puisque tu n'auras qu'une seule instance active à un instant t. Le 2nd, c'est l'autostart, donc que la scène démarre automatiquement au boot. Utile pour les scènes de type boucle infinie. Bon forcément sur HCL tout cela n'est pas clair, car tu n'as pas de LUA et tu es limité au Bloc, donc tu as aucune idée de comment les blocs fonctionnent derrière (c'est du LUA) Sur HC2, avec le LUA, tout cela devient limpide, car on voit le code, donc on sait ce qui est censé se passer (instances en //, et autostart)

Nope, la mienne fait quasiment 0 à l'arrêt, j'ai une impulsion 2 fois par jour environ. 80W c'est pas normal

Le plugin a planté, il faut rebooter ta box, seul moyen connu de redémarrer un plugin

La sécurité du protocole Z-Wave a été introduit avec le Z-Wave+, c'est à dire depuis environ 2 ans. Seuls les modules qui ont une puce Z-Wave+ peuvent être inclus en mode sécurisé. La HC2 n'a pas de puce Z-Wave+, donc elle utilise sa puissance de calcul CPU pour effectuer le chiffrement logiciel des trames. (un Intel Atom, même si peu puissant dans l'absolu, ça reste très puissant pour de la domotique). Mais attention : - si trop de modules inclus en mode sécurisé, cela peut ralentir (surcharger) la box HC2. - en mode sécurisé, un module réduit sa puissance d'émission au moment de l'inclusion, donc il faut l'inclure tout près de la HC2 (pour des raisons de sécurité et d'éviter que le pirate dans la rue ne capte les signaux au moment de l'inclusion.... car l'inclusion en elle même n'est pas sécurisé, seuls les échanges normaux par la suite seront chiffrés). - cela crée 2 sous-réseau Z-Wave au sein du même réseau Z-Wave (un chiffré, et un autre non chiffré) donc le maillage réseau n'est pas optimum. Par conséquent, comme tu le soulignes, il faut réserver l'inclusion en mode sécurisé aux modules qui le nécessitent réellement (serrures, etc), même si à terme, on devrait aller vers un chiffrement de l'intégralité du réseau Z-Wave. Perso, je n'ai inclus aucun module en mode sécurisé, car je ne gère aucune fonction sensible avec la domotique (portes serrures etc)

Encore faut il en avoir l'utilité par rapport à une première version qui marche au poil. Ce nouvel Eco-Devices RT intéressera prioritairement ceux qui n'ont rien et qui débutent. Ce serait mon cas si je faisais une nouvelle installation, ça m'éviterait de devoir utiliser un Raspberry PI en complément de l'Eco Device original, mais maintenant je n'ai pas de raison de changer, ça fonctionne très bien comme ça. De toute façon je n'ai pas la place, donc le remplacement serait compliqué, obligé de recabler la moitiée du tableau.... Pour rien. PS : mon téléphone va avoir 3 ans, j'ai rien vu de mieux sortir, donc pas de raison de le changer.

Oui, je hante le forum, je vise à terme le statut de fantôme ou esprit du forum

Je pense que ce n'est même pas un problème de compartimentage type docker. Un OS moderne, quel qu'il soit, est stable même si les applications (process) plantent. Il est loin le temps de Windows 3.x / 95 / 98 Les dockers ne servent pas à compartimenter (isoler) les applications, pour cela il existe une solution : la virtualisation. Les dockers, c'est pour que les développeurs puissent packager facilement leurs applications en vue de leur distribution. Pour le coup, c'est parfaitement adapté au besoin de Fibaro. Les dockers, c'est un peu le truc à la mode partout, mais faut bien être conscient d'un truc, ça ne permet pas d'isoler les applications, de les sécuriser, d'optimiser leurs performances, etc.... ce n'est pas de la virtualisation. Sinon, article d'Hervé du jour qui traire du sujet : La Smart Home de Fibaro s’allie aux NAS de QNAP

magnifique le nouvel écran de mise à jour Décidément, ils ont bien bossé.....

0 désactive le réveil, donc c'est le mieux pour les piles. Enfin une excellente idée, et c'est Fibaro qui l'a eu Désactiver le réveil est ce qu'il y a de mieux à faire pour des modules sur batterie, je n'avais jamais vu un module avant cela qui permette de le faire. Source : documentation

D'autant plus que les bugs Fibaro n'ont jamais fait planter l'OS en dessous, pourtant une vieille Debian 6. De ce coté là, je ne suis pas inquiet, les NAS QNAP continueront de fonctionner convenablement. En tout cas merci @labomatik de nous avoir partagé ta trouvaille, si tu as plus d'infos, n'hésite pas

@pepite ça ne te coute pas trop cher de chauffer les 90 pièces de ton château ? Chez moi, les ID du panneau de chauffage s'arrêtent à ... 1 !!!