Lazer

Moi je pense à un support d'unité centrale à fixer sous le bureau Copain de matos : Bosch, Domino, serres joints Wolfcraft EDIT : c'est un rack réseau 19" avec tablette pour NAS... on voit le rendu 3D sur la photo

T'as pas compris le principe alors, Apple ne vole pas au secours, au contraire même... il les aide à s'endetter pour s'acheter des objets qui ne sont pas dans leur budget. Technique commerciale bien connue depuis des lustres.... Par contre, 5000€ ne suffiront pas pour s'acheter le Mac Pro en config maxi.

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

Oui, voilà, faut un Proxy pour logguer les URL. Par contre, ce n'est pas Hadopi, mais la LCEN je crois bien qui impose de logguer (Loi pour la confiance dans l'économie numérique)

Le tuto c'est @mprinfo, en fait c'est basiquement l'utilisation de Win32DiskImager.

Maintenant que @Mulder est dans la place, on va pouvoir comprendre tous les phénomènes paranormaux qui entourent notre HC2. Désolé, c'était trop tentant, le pseudo est culte La vérité est ailleurs....

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.

Non elle a une coque orange, dans le même ton que celle proposée par @BenjyNet

Moi j'ai mis mon anémomètre en haut de la tour Eiffel, et le pluviomètre avec la sonde de température au milieu du champs de Mars, j'ai trouvé que ça pour respecter les normes

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é )

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.

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)

Est-ce que quelqu'un aurait une série d'icônes pour électrovanne avec 10 positions ? En effet, la mienne est pilotée par un module FGR de volet roulant, donc avec 10 icônes..... cependant je n'ai trouvé que des jeux de 2 icônes d'électrovannes en tout ou rien (ouvert/fermé). Merci.

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)

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

Oui, c'est maintenant officiel, on peut en parler 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)

Aucun souci, je biens de tester en accès 4G, que ça soit via le cloud Fibaro, ou en direct en forçant mon IP publique grâce à une redirection de port (beaucoup plus rapide que via le cloud Fibaro) Tu as peut être un souci de config de ton appli ? Va voir les paramètres.

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.

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

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

ça n'a rien de tordu, ça fait déjà plusieurs années que les initiés le pratiquent 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.

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.

Perso toujours rien eu.

Yes c'est à peu près la modifs que je voulais faire, mais j'ai pas eu le courage de publier. Bravo et merci

Faut que je t'envoie une photo de mon montage.... Le weekend prochain