Aller au contenu

Rechercher dans la communauté

Affichage des résultats pour les étiquettes 'Réveil'.



Plus d’options de recherche

  • Rechercher par étiquettes

    Saisir les étiquettes en les séparant par une virgule.
  • Rechercher par auteur

Type du contenu


Forums

  • Bienvenue
    • Annonces et suggestions
    • Nouveau ? Présentez-vous
    • Le bistrot
    • Mon installation domotique
    • Autres Solutions Domotiques
  • La HC2 et ses périphériques
    • La Home Center pour les nuls
    • Home Center 2 & Lite
    • Modules Fibaro
    • Modules Z-wave
    • Périphériques et matériels autres
    • Plugins
    • Alarme & Vidéo-surveillance
    • Multimédia
    • Chauffage et Energie
    • Actionneurs & Ouvrants (Portail, volets...)
    • Eclairage
    • Applications Smartphones et Tablettes
    • English Section
  • Les objets connectés
    • Les Assistants Vocaux
  • Fibaro's Awards
    • Membre du mois
    • Jeux concours & Cadeaux
  • Les bonnes affaires
    • Sites internet
    • Petites annonces

Rechercher les résultats dans…

Rechercher les résultats qui…


Date de création

  • Début

    Fin


Dernière mise à jour

  • Début

    Fin


Filtrer par nombre de…

Inscription

  • Début

    Fin


Groupe


Jabber


Skype


Ville :


Intéret :


Version

2 résultats trouvés

  1. 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 atteint (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.
  2. Shad

    LUA scheduler for HC2

    Ce code a été écrit par robmac avec l'aide de jompa68 , A.Socha. J'ai également fais une traduction du poste original ici. Je ne vais pas tout expliquez mais juste faire comprendre le fonctionnement de base. Ce script a été écrit pour pouvoir gérer tout les heures de lancement d'une action depuis une seule scène. Personnellement ce script fonctionne beaucoup que le code standard lua. Les commandes sunset or sunrise fonctionne très bien. ATTENTION CE CODE NE FONCTIONNE PAS CHAQUE MINUTES DONC N'UTILISE PAS DE RESSOURCES SYSTEME. ILS DÉMARRENT SEULEMENT LORSQU'UNE TACHE EST PLANIFIÉE. Personnellement, depuis que j'utilise ce code ma HC2 ne fonctionne que mieux, dans chaque scène vous n'avez juste qu'à y mettre vos conditions et actions. Je ne posterais pas le code car il fait plus de 1000 lignes. Ce script ajoute également une fonctionne qui manque cruellement à la HC2, des alarmes. Par défaut il n'en possède que deux. Pour mon usage j'en ai programmé deux, une pour la semaine et l'autre pour le week-end. Installation du script: Créer une scène en Lua et collez le code du fichier Scene-1 - ID 1 Scheduler.txt, importez le fichier Alarm_Clock.vfib 4 fois (editez le numéro de chaqu'un dans le code) et 1 fois le Scheduler Control. Il vous faudra ensuite créer des globals variables avec comme nom: - scheduleGroup - scheduleActive - alarmTime1 - alarmTime2 - alarmTime3 - alarmTime4 Après pour redémarrez le scheduler il faut créer une scène avec: --[[ %% properties %% globals --]] local scheduleScene = 1 while (fibaro:countScenes(scheduleScene) > 0) do fibaro:killScenes(scheduleScene); fibaro:debug("Kill") end; active = active or { Active = 1, Disabled = 2 } activeIndex = activeIndex or { [1] = "Active", [2] = "Disabled"} local scheduleActive = fibaro:getGlobalValue("scheduleActive") or activeIndex[1] if scheduleActive == activeIndex[1] then -- restart a new instance if active fibaro:startScene(scheduleScene) end Maintenant pour paramétrez tout sa c'est très simple. Dans le scheduler il faut éditez les lignes: - 96: Id scène pour redémarrer - 97: Id virtual device pour controler le scheduler - 98, 103, 108 et 113: les id des virtuals devices pour les alarmes. Ensuite dans la scène pour redémarrer le scheduler éditez la ligne suivante avec l'id de la scène du scheduler: local scheduleScene = 1 Normallement c'est tout pour la configuration. MISE EN PLACE DU SCENARIO: Vous devez insérez vos lignes en-dessous la section <ADD YOUR LINES HERE> luaDaySchedule:add(<time>,<id>, <parameter> , <action>, <days> ,<catchup>,<p1>,<p2>,<p3>) Heure de lancement du scénario: <time> : Remplacez cette balise par une heure dans un format de 24h exemple: "23:21" ou "07:00". PS: Vous ne pouvez changer une variable globale pour changez l'heure de la scène sans relancez la scène. SUNRISE - SUNSET avec + ou - x minutes: <time>: Remplacez cette balise par "Sunrise" ou Sunset" <p1> Remplacez cette balise par 27 pour ajoutez 27 minutes ou - 11 pour lancez 11 minutes plus tôt. ID DU MODULE OU DE LA SCENE: <id> Remplacez cette balise par l'id de votre module ou scène. ACTION POSSIBLE (liste non entière et consulter le poste originale pour voir les commandes): Allumez ou éteindre un module régler une valeur pour un dimer envoyer un mail envoyer une notification push à un ou tous les périphériques envoyer un mail à un ou tous les utilisateurs appuyer sur un modules virtuels régler un slider pour un modules virtuels régler un variable global armer ou désarmer un module régler toute chacune des couleurs d'un module RGB démarrer un programme RGB démarrer une autre scène CHOIX DES JOURS DE LANCEMENT DES SCENARIOS: <days> Remplacer cette balise par jour de la semaine Il est également possible de mettre plusieurs jours de la semaine avec {"Sunday','Monday"}. Il y a 3 commandes spécial: {"All"] = Tous les jours de la semaines {"Weekend"} = Samedi et Dimanche {"Weekday"} = Lundi au Vendredi Ils peuvent également être fusionner avec les jours de la semaine {"Weekend","Monday"} = Samedie, Dimanche et Lundi LES ALARMES: Pour configurer les alarmes, un fichier vfib est disponible dans le zip joint. A la ligne 92 du scheduler vous devez paramétrer les id de vos modules virtuels ainsi que l'id de la scene du redémarrage du scheduler (également fournie dans le zip). Dans chaque bouton du module virtuel vous devez également reconfigurer l'id de ce module virtuel. Et pour finir vous devez créer des variables globales pour alarmDays1 - alarmDays2 - alarmTime1- alarmTime2. Voici les lignes que vous devez ajoutez à votre scheduler: --Réveil 1 luaDaySchedule:add(getAlarm("alarmTime1"),{"4"}, "" , "startScene", {"All"} ,false) --Réveil 2 luaDaySchedule:add(getAlarm("alarmTime2"),{"5"}, "" , "startScene", {"All"} ,false) Voici quelques une de mes lignes: luaDaySchedule:add("07:00","30", "" , "startScene", {"Weekday"}, false); luaDaySchedule:add("07:30","30", "" , "startScene", {"Saturday"}, false); luaDaySchedule:add("Sunset","Nightime", "1" , "setGlobal", {"All"}, false , 0); Comme écrit plus haut je n'ai pas tout expliquer car trop long. Il s'agit juste d'un résumé Des exemples sont fournis dans le scheduler + d'autre explication sur le poste originale du forum officiel. scheduler-1-3-0.zip Scheduler1-3-1.zip
×