Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 363
  • Inscription

  • Dernière visite

Messages posté(e)s par Lazer


  1. Il y a 1 heure, romanoel a dit :

    je reviens sur cette histoire de module fibaro pour les interrupteurs. Avec un module (disons celui que je place dans ma chambre), est-ce que je peux décider que de cet interrupteur, je piloterai en fonction de l'heure de la journée, la lumière de la cuisine et du garage par exemple (exemple complètement con, mais c'est juste pour l'idée :) ).

    C'est faisable (sans intérêt ;) , mais faisable  :) )

    Pour cet exemple précis, il faudra 3 modules :

    - 1 module derrière l'interrupteur qui ne commande aucune lumière

    - 1 module sur la lampe de la chambre (connecté uniquement à la lampe, sans interrupteur)

    - 1 module sur la lampe du garage (connecté uniquement à la lampe, sans interrupteur)

    Ensuite, tu n'as plus qu'à faire un scénario qui réagit en fonction de l'heure de la journée : quand on appuis sur l'interrupteur, cela active la lampe de la chambre, ou du garage.

     

    En optimisant, on peut réduire à 2 modules :

    - 1 module derrière l'interrupteur (connecté en S2), avec la sortie O1 connectée à la lampe de la chambre

    - 1 module sur la lampe du garage (connecté uniquement à la lampe, sans interrupteur)

    Le scénario réagit alors en fonction de l'événement sur l'entrée S2 du premier module.

     

    Tout est faisable en fait... mais attention aux usines à gaz impossible à maintenir, et au final pas WAF pour l'utilisateur (femme, amis, etc)

    Un interrupteur doit piloter la lumière de la pièce dans laquelle on se trouve, c'est sa fonction première.

    A ce titre les modules Fibaro sont parfait : installé derrière l'interrupteur, il permet de contrôler 1 lumière, de façon totalement autonome. Comme il communique en Z-Wave, la box domotique en est informée, peut agir en conséquence (ex : si j’allume une lumière, alors ça allume une autre, ou baisse les volets si il fait nuit, lance la musique, etc)

     

    Il y a 1 heure, romanoel a dit :

    Ce qui me fait un peu peur avec le zwave, c'est les éventuelles latences (pas que ca mette en péril ma santé mentale....mais plus pour le principe).

    En cherchant à droite à gauche, j'ai cru comprendre que dans les protocoles sans fil, le X3D était plus "rapide" que le Zwave. 

    j'aimerais bien où tu as lu cette connerie ?

    2 hypothèses :

    - 1 utilisateurs final qui n'a pas compris comment fonctionne le Z-Wave (réseau mal maillé), ou qui utilise une box de merde (eedomus 1, raspberry PI 1, etc)

    - 1 pro malhonnete

     

    Comme je l'ai expliqué récemment sur un autre topic, les latences du Z-Wave se comptent en millisecondes. Ce n'est pas perceptible par un être humain.

    Si il y a une latence, c'est qu'il y a une erreur d'architecture du système domotique. Exemple concret : allumer des lampes Philips Hue (qui n'est pas du Z-Wave....) en passant par un pont, du Wifi, des passerelles, et un protocole Zigbee, bah c'est lent....  à prendre en compte.

    Mais un réseau full-Z-Wave, correctement maillé, correctement paramétré, et avec une box domotique puissance (HC2, LifeDomus, Jeedom sur un NUC puissant), je te met au défi de constater des latences...

     

    • Like 1
    • Haha 1

  2. Non ce n'est pas prévu.... c'est censé être tellement rare les bascules sur batterie, et tellement court, que je n'ai pas jugé utile de s'embêter avec l'icône.

    J'ai préféré mettre l'accent sur les possibilités de notification, variable globale, et fakes devices.

    • Like 1

  3. il y a 29 minutes, J3R3M a dit :

    C'est bien ce que j'avais en tête, mais pour le coup, c'est nettement moins "smart", d'après-moi.

    Enfin, cela dépend des modules interconnectés, mais faire cela entre un interrupteur et une ampoule (ou un FGD), cela revient au même que s'il y avait un câblage électrique simple entre les deux, en plus cher. Mais cela est strictement personnel et je n'ai sans doute pas pensé à un cas où cela pourrait être utile.

    Je pense que tu mélanges plusieurs choses là.

     

    Déjà, je n'ai pas parlé d'intelligence ("smart"). Une association directe entre 2 modules, c'est justement tout sauf intelligent => C'est bête et méchant, un mouvement sur le détecteur allume immédiatement le dimmer, quelles qu'en soient les conditions (jour, nuit, humidité, age du capitaine, etc). L'action est donc quasiment instantanée, on parle d'une latence de quelques millisecondes entre les 2 modules.

     

    Ensuite, tu parles d'interrupteur sur un dimmer, il n'y a justement pas de communication inter-module, puisque l'interrupteur est physiquement connecté au module, et que l'ampoule également. Le module Dimmer agît alors exactement comme un télérupteur électrique. C'est totalement autonome et ne dépend d'aucun autre module, ni de la box domotique (laquelle est tout de même informée après que le dimmer ait effectivement allumé la lumière). L'action est donc instantané, impossible de faire plus rapide.

     

    Je me rend compte à la lecture de ton scénario rapidement décrit plus haut dans ce topic, et des autres messages que tu as laissé ailleurs sur le forum, que tu es parti dans des délires assez importants (ne le prend pas mal hein ;) ) avec une architecture complexe, appelée couramment usine à gaz.

    Les usines à gaz, c'est bien, ça sait tout faire. Mais c'est complexe, difficile à maintenir, souvent assez lent, et peu fiable.

     

    C'est pour cela que je t'invite à revenir aux fondamentaux, à savoir tester chaque interaction une par une.

    Tu verras que le Z-Wave est extrêmement rapide, les latences ne sont pas perceptibles pas nous autres pauvres humains, et que si latence il y a, elles proviennent d'ailleurs.

    Dans ton cas, on est plusieurs (toi y compris ;) ) à avoir de sérieux doutes sur le script LUA et ses nombreuses interactions avec la DB, ainsi que le pont Philips Hue. Sans oublier la latence du capteur PIR lui-même bien sûr, à l'origine de tout ton scénario.

     

    Tu l'as dit toi même plus haut, un grand nombre d’interactions n'entrainent pas nécessaire un temps de latence de plusieurs secondes, en citant en exemple ma chaine Harmony => ... => Lampe, qui bien que longue, ne prend que 1s maxi (bon, c'est déjà trop à mon gout, mais ça reste acceptable pour cet usage, à savoir piloter la lumière du bout des doigts sans bouger mon popotin du canapé :D )


  4. il y a 46 minutes, TonyC a dit :

    tu utilises quelle model de vanne stp? j'en ai une qui m'a lâchée il y a 1 mois et il faut que je la renouvelle.

    Malheureusement je ne peux plus te donner de référence, car Amazon a remplacé le produit par un autre sur la fiche produit, avec la même URL....

     

    C'est une vanne motorisée de marque générique alimentée par 2 phases en 230VAC, exactement comme un volet roulant. Donc 2 fils + 1 neutre.

    Phase ouverture pendant 10s environ, phase fermeture pendant la même durée.

    Consommation 5W pendant la manœuvre.

    • Thanks 1

  5. Ah mais je suis d'accord, je l'ouvre tout le temps ou tout ou rien.

    C'est juste que la commande de la vanne s'alimente avec un FGR. En fait, j'ai employé le mauvais terme, ce n'est pas une électrovanne, mais une vanne motorisée.

     

    Donc pour ce FGR, il me faudrait les 10 icones (je peux tricher et mettre 2 groupes de 5 icones identiques, mais bon, c'est pas propre)


  6. Le FGMS a une certaine latence inhérente au fonctionnement de tout détecteur de mouvement basé sur la technologie PIR (capteur d'alarme, etc)

    Le faisceau IR perçu par le capteur est découpé en zone par la lentille de Fresnel placée devant.

    Par défaut, je crois que le FGMS attend que 2 zones soient franchies pour confirmer le mouvement (cela se change dans ses paramètres).

    Donc si tu rentre "juste un peu" dans son champs de vision, tu n'as activé qu'une zone, mais pas 2, donc pas de notification de mouvement.

     

    Tu peux changer sa sensibilité à la hausse (comme à la baisse), mais attention aux faux positifs.

     

    Une fois la détection confirmée, l'info est envoyé par Z-Wave à la box HC2, ce qui est extrêmement réactif pour peu que ton réseau Z-Wave ne soit pas surchargé (ça peut arriver...) et qu'il ne doive pas passer par des relais (réseau maillé).

     

    Ensuite, c'est le trigger de la HC2 qui va déclencher ta scène, puis ton code LUA, et tu connais la suite.

     

    Si tu veux du quasi instantané (modulo le temps de détection inhérent à la techno PIR décrit ci-dessus), il faut faire une association directe entre le FGMS et le Dimmer (ou relai) pilotant la lumière puisque tu bypass la box (laquelle est tout de même informée).... ce qui implique d'être en full Zwave. Dans ce cas, on peut parler de quasi instantanée, la latence n'est pas perceptible par un être humain. On est au niveau d'un réseau KNX, où les participants (les modules) discutent entre eux en direct, sans dépendre d'un contrôleur (box)


  7. je sais pas trop, mais moi je repartirais à la base => 1 seul capteur de mouvement qui déclenche le trigguer sur un script LUA ultra simple (donc performant) qui allume 1 seule lumière

     

    Juste pour voir si la lenteur vient de ton script ou de la communication Hue.

    Ensuite tu sauras où optimiser


  8. Oui, c'est maintenant officiel, on peut en parler :D

    Elle est personnalisable, c'est cool, mais perso j'aime vraiment pas cette mode de merde du blanc de tout le monde qui copie Apple.

    Surtout que la grosse tendance actuelle c'est de revenir vers des thèmes sombres... ça n'a que des avantages, plus reposant pour les yeux, moins consommateur de batterie (avec les écrans OLED)

     

    fibaro-new-app.jpg

     


  9. ouais, t'as une grosse usine à gaz, tant du coté du script, que de l'archi hétéroclite.

    C'est comme quand j'utilise mon Harmony pour allumer la lumière, on est pas loin de 1s de latence, c'est la grosse usine à gaz aussi :

    Harmony => (RF) => Hub => (Wifi) => Borne Unifi => (Ethernet) => Switch POE => (Ethernet) => Switch => (Ethernet) => Serveur => (ESXi) => VM HABridge => (Ethernet) => Switch => HC2 => (Z-Wave) => FGD

     

    Une bonne installation haut de gamme, performante, réactive, est en full- Z-Wave (ou mieux, KNX).

    Mais pas en Wi-Fi, protocole à latence importante, sans compter les nombreuses passerelles à traverser.


  10. Regarde dans /opt/fibaro/FibaroSceneEnv.lua c'est là dedans que se trouvent les instructions pour brider le LUA des scènes... et donc le débrider

    Pour les modules virtuels, tu ne pourras rien faire, car le moteur LUA est plus ancien, et compilé avec l'exécutable. Donc bien pourri et non évolutif.

     

    Comme NIco, je pense que tu as plutôt un gros gros souci dans la logique de tes scénarios là.


  11. il y a 5 minutes, J3R3M a dit :

    Cela signifie qu'à chaque mise à jour, tu réédites seulement un fichier de la HC2 en précisant où trouver les fichiers que tu as délocalisé? 

    Fichiers délocalisés sur un NAS ? 

    Oui c'est sur le NAS, mais attention, tu as mal compris : je n'ai plus rien sur la HC2 !

    Donc pas de librairie partagée, rien du tout, mon HC2 est maintenant la même que tout le monde.

     

    N'espère pas gagner un quelconque gain de performance en utilisant des librairies partagées... au contraire même, avec le temps perdu à passer les infos entre process, etc.

    Le seul gain serait de simplifier la programmation, mais tu ne pourrait plus rien partager sur le forum (ça ne serait pas portable), et tu t'exposes à ce que plus rien ne fonctionne en cas de modification de l'archi de la HC2. D'ailleurs, je n'ai pas d'infos détaillées sur la HC3 (ou quel que soit son nom), mais c'est pas dit qu'on puisse y brancher un clavier/écran aussi facilement que sur la HC2 pour la rooter (hop, discrètement l'air de rien, j'ai donné 50% de la procédure)

     

    Bref, je ne te conseille pas de te lancer là dedans, tu vas te créer des problèmes plus qu'autre chose....

    • Haha 1

  12. ça n'a rien de tordu, ça fait déjà plusieurs années que les initiés le pratiquent :D

    C'est un PC sous Linux, faire sauter le mot de passe root est à la portée de n'importe quel admin système, c'est d'ailleurs la première question de la certification Redhat... donc les tutos sur le net pleuvent (mais pas sur ce forum). C'est infiniment plus simple que rooter un Android (ou jailbreaker pour les pommés)

     

    Donc oui, on peut faire ce que tu demandes, et bien plus.

     

    Par contre, ça n'a plus grand intérêt depuis les firmwares 4.500, car la Debian a été remplacée par une Bluidroot, distribution prévue pour l'embarquée, avec file-system racine en lecture seule (bon ça va encore, il est facile de remonter en read-write à chaud), mais maintenant la partition est écrasée à chaque mise à jour HC2. Donc toute modif que tu fait sera perdue N fois....

    Perso j'ai laissé tombé, j'ai passé 3 mois à migrer mes scripts ailleurs pour ne plus dépendre de l'accès root de la HC2. Comme ça je fais mes mises à jour sans me prendre la tête.

    • Like 2

  13. il y a 8 minutes, Yannick a dit :

    Donc je ne peux vraiment pas récuéprer ma conf de ma box vers ma box 2 sans devoir réinitialiser la box 1 et sans passer par le fibaro ID ???

    J'ai l'impression que non justement, avec le nouveau système qu'ils ont mis en place depuis la 4.500 :

    => externalisation des backups (dans le cloud ou en local) chiffrés, pour des raisons de sécurité, avec une clé unique contenue dans la HC2 (probablement générée à partir de son numéro de série et Hardware-ID, qui sont stockée dans l'eeprom de la carte fille sur la carte mère)

     

    Par conséquent, impossible pour une autre HC2 de relire un backup externalisé.

     

    En passant par le cloud Fibaro, ils sont capables de déchiffrer le backup, pour le rechiffrer avec la clé de la HC2 cible.

     

    Comme toujours en informatique, la sécurité apporte des contraintes.... vous devez connaitre cela sur les postes de travails de vos entreprises respectives.

    • Like 1
×