Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 404
  • Inscription

  • Dernière visite

  • Jours gagnés

    1 185

Messages posté(e)s par Lazer

  1. 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 )

  2. 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
  3. 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)

  4. 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)

  5. 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

  6. 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

     

  7. 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.

  8. 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à.

  9. 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
  10. ç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
  11. 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
  12. Ouais, j'ai été clairement impressionné ( :D) par la qualité d'impression.

    Sur le net, tu vois les review, ce sont des photos prises en gros plan macro où on voit tous les minuscules défauts.

    Une fois en main en vrai, comme ça à l'arrache sur le salon, ça a l'air plus que top, super qualité !!!

     

    C'est dommage au moment où j'ai fait la vidéo, le MMU n'était plus en fonctionnement.

×
×
  • Créer...