Lazer

Le -1 est vraiment à part, ce sont les déclenchements instantanés (= triggers de scènes comme on les avait sur la HC2) Le 0, c'est une durée comme une autre, comme 30, 60, 90, etc... aucune différence. Et toutes ces règles rentrent alors dans la boucle infinie de vérification des conditions de GEA. GEA fonctionne par cycle de 30 secondes (par défaut) À chaque cycle, GEA vérifie si la condition est valide depuis au moins (supérieur ou égal à) la durée indiquée. Oui parce que l'utilisateur, quand il allume une lumière, il le fait à un moment quelque part entre 2 cycle de GEA. Mais ça GEA ne le sait pas, lui il ne regarde l'état des modules qu'à chaque cycle. Donc quand tu mets 30s, au moment où GEA déclenche la règle, ton module est effectivement allumé à un moment situé quelque part entre 30s et 59s (juste après le cycle précédent) Exemple avec 30s : GEA.add(123, 30, "Le module 123 est allumé depuis au moins 30 secondes", {ACTIONS}) - Au premier cycle, la condition est valide, mais ça fait moins de 30s, donc GEA ne fait rien - Au second cycle, la condition est valide, et ça fait plus de 30s, donc GEA réalise les actions - Au troisième cycle, la condition est toujours valide, mais les actions ont déjà été exécutées au cycle précédent, donc GEA ne fait rien (sauf si on a spécifié {"Repeat"} ). => La règle ne sera "réarmée" qu'après que ses conditions soit devenue invalides. Dans le cas présent, il faut éteindre le module 123 puis le ré-allumer pour que GEA reprennent le calcul des 30 secondes. Autre exemple avec 0s : GEA.add(123, 0, "Le module 123 est allumé depuis au moins 0 secondes", {ACTIONS}) - Au premier cycle, la condition est valide, et ça fait plus de 0s, donc GEA réalise les actions - Au second cycle, la condition est toujours valide, mais les actions ont déjà été exécutées au cycle précédent, donc GEA ne fait rien (sauf si on a spécifié {"Repeat"} ). Du coup, tu as bien compris que si tu mets une durée de 60s, alors les actions ne seront réalisées qu'au 3ème cycle. Le mieux c'est d'expérimenter par toi même, c'est ce que j'ai fait pour comprendre le fonctionnement de GEA quand je l'ai porté sur HC3, car je me suis rendu compte que je l'utilisais depuis des années sur HC2 soit avoir bien compris son fonctionnement (remarque c'est toujours le cas, à part @Steven je ne sais pas si quelqu'un a compris à 100% tellement l'outil est complet et puissant) Donc tu prend un module quelconque (un des QuickApps données en exemples par Fibaro, qui ne font rien, de type Binary Switch), tu mets des durées de 0, ou 30s, la fenêtre de logs à coté, et tu verras immédiatement les conséquences des changement d'état du module. D'abord il faut réaliser des tests unitaires (avec 1 seule condition), puis petit à petit ajouter plusieurs conditions (il faut que toutes les conditions soient valides pour déclencher la règle.... sauf si on utilise "Or"...)

euh... ça ne me dit rien du tout cette histoire de durée = 0 qui fait planter le QA (ou la scène sur HC2)....

Hum... petit bug ? Normalement il repasse sur OFF lorsque le robot est à l'arrêt (donc soit arrêté en plein milieu de la maison, soit posé sur sa base de rechargement) L'idée, c'est : - ON = en mouvement - OFF = immobile Parce que je compte l'utiliser ainsi dans les scénarios GEA afin de ne pas prendre en compte les mouvements des détecteurs de mouvement pendant notre absence si l'aspirateur est en activité. Et c'est beaucoup plus simple de prendre la "value" true/false du module que d'aller lire les labels (ce que je faisais avec le Roomba) Et puis ça permet aussi d'avoir une icône qui se met à jour toute seule en vert/rouge pour identifier d'un coup d'oeil l'activité du robot. Donc si ce n'est pas ton cas, il va falloir reproduire le bug.... idéalement, tu mets le mode debug, puis tu captures le log entre le moment où il aspire et le moment où il s'arrête (un peu avant et un peu après pour être certain de voir large)

En fait ça dépend de la durée que tu as mis dans ta règle restartée. J'ai fait des tests avec une durée = 0, et la règle est bien redémarrée dès le 1er cycle suivant. Ce qui semble un comportement tout à fait normal, selon la logique de GEA. Une règle n'est validée que lorsque elle est vérifiée depuis au moins la durée indiquée. Donc pour 30s, c'est au 2nd cycle qu'elle se déclenche.

Tiens, c'est marrant, sur les forums je vois de plus en plus d'utilisateurs d'Unifi se tourner vers Mikrotik, au moins pour la partie routeur. Mikrotik j'avais justement étudié en détail leur gamme avant de choisir mon EdgeRouter, il y a pas mal d'années donc, et j'avais préféré Ubiquiti à ce moment là. J'imagine que ça a pas mal évolué depuis. Mais pas contre... c'est pas trop le moment de changer de routeur, les tarifs sont soit exorbitants, soit il n'y a plus de stock... c'est la crise des composants !

Ben moi j'ai mon routeur Ubiquiti EdgeRouter (gamme non Unifi du coup) qui est tombé en panne, la clé USB interne qui a lâché. Je le sentais venir depuis un moment, elle donnait des signes de faiblesse (crash... depuis 1 an !!! .... mais le routeur continuait à fonctionner ) Du coup je l'ai ouvert, réinstallé une clé lambda (j'ai hésité à utiliser l'ancienne clé Recovery de la HC2 ) et en moins de 2h le routeur est comme neuf. Donc pas mal du tout Après c'est leur gamme pro Edge, donc pas Unifi.... je trouve que de plus en plus, Ubiquiti s'est chié dessus avec sa gamme Unifi... l'idée était sympa, c'était bien parti, mais ces derniers temps, c'est pas ça... bugs, fonctionnalités manquantes, etc, et tout ça avec des tarifs qui ont sacrément augmentés !

Yes, I will do it... but later, I don't have time right now. Maybe in May, or even June. The next version will also make use of the WebSockets capabilities now available on HC3. For now, I have disabled automatic updates, so I can still use Kodi 18 a little bit longer. By the way, it gives time to the developer team to resolve the bugs of this first major release.

Hum... oui... pour restaurer... ben suffit d'utiliser la même méthode (à l'envers) que pour la sauvegarde non ? Pourquoi faire simple quand on peut faire compliqué... OneDrive, Dropbox, et compagnie, ça sert à monter un lecteur réseau local, donc usage ultra simplifié => copie de fichiers locaux, pas besoin d'outils de transferts de fichiers via le réseau (FTP, SMB, etc), puisque le transfert sur le réseau est masqué par le client OneDrive ou Dropbox installé en locaL Dans le cas du NAS, quand celui-ci intègre nativement la possibilité de transférer vers ces services, là aussi on n'a pas besoin de se préoccuper des transferts réseaux, c'est le client installé dans le NAS qui va exploiter l'API mis à disposition par le fournisseur cloud pour faire les transferts.

Regarde là :

FileZilla c'est le logiciel que j'utilise depuis 15 ans pour tous mes transferts FTP (et SFTP). Mais je ne vois vraiment pas le rapport avec la sauvegarde.... j'insiste, mais FTP n'a jamais été conçu pour la sauvegarde, la synchronisation, etc.... mais uniquement pour le transfert ponctuel de fichier entre serveurs : téléchargement ou téléversement (ouh là là que je n'aime pas cette traduction française.... allez je vais dire "upload") Donc non, avec FIleZilla tu ne te connecteras pas sur les services cloud tels que Dropbox ou OneDrive.

Bienvenue sur le forum

Bienvenue sur le forum

@fredokl pour info j'ai trouvé ce bug, il est corrigé dans la nouvelle version 7.22 disponible sur :

Mise en ligne de GEA version 7.22 : Correctifs :  Résolution du Profile identifié par son ID numérique dans les conditions Résolution de l'action RestartTask qui était sans effet Copier/coller le contenu du fichier LUA téléchargé par dessus le fichier main dans le QuickApp (ou bien télécharger le QuickApp complet disponible en 1ère page) GEA v7.22.lua

Bienvenue sur le forum

Je ne connais pas bien QNAP, mais sur Synology il y a un mécanisme natif de sauvegarde, avec un outil pas mal fait, qui permet de sauvegarder (et surtout restaurer) très facilement vers un autre Synology, n'importe quel serveur, et différents services Clouds (Amazon, etc) Du coup je ne me pose pas trop de question, ça marche tout seul. Bien sûr la première sauvegarde est très longue, surtout s'il y a beaucoup de petits fichiers. Mais les sauvegardes suivants sont incrémentales, donc très rapide. Perso ça se lance en pleine nuit, donc c'est totalement transparent. En cas de crash du NAS (ça m'est arrivé une fois), il suffit de le réinstaller, de faire la config de base, puis de reconnecter l'outil de sauvegarder, qui va alors aller chercher toutes les données pour les restaurer, y compris la config du NAS (comptes utilisateurs, etc) Sinon, pour sauvegarder des données entre mes différentes VM, mais aussi entre mes PC et mon NAS, j'utilise beaucoup rsync. Alors c'est sûr il faut mettre un peu la main à la patte car c'est en ligne de commande, mais ça permet une grande souplesse : je peux choisir exactement quoi sauvegarder, quoi exclure, etc. L'avantage pour le coup, c'est que rsync va synchroniser 2 arborescences, donc sur la cible on retrouve l'arbo, il est super facile de naviguer dedans pour aller chercher rapidement un fichier en particulier. La sauvegarde dans le cloud, c'est super car ça apporte une véritable sécurité (distance physique virtuellement infinie), le souci ce sont les prix des offres dès que tu as un peu de volumétrie à sauvegarder. FTP c'est un protocole d'un autre âge, c'est parfait pour transférer des grosses images entre 2 serveurs UNIX, mais pas du tout adapté au transfert d'arborescences aux multiples fichiers, et il ne sait pas du tout gérer la synchronisation, donc les sauvegardes incrémentales ne sont pas possibles (sauf à comparer chaque fichier un par un, ce qui est ultra long comme tu l'as vu). FTP est en train de tomber aux oubliettes, même les navigateurs récents ont annoncé l'arrêt de son support.

Bienvenue sur le forum

Ce sont les Custom Events, une fonctionnalité pas du tout mise en avant par Fibaro, et assez peu discutée sur le forum. Exemple d'utilisation ici : https://www.domotique-fibaro.fr/topic/15003-comment-simuler-les-properties-dun-qa/?do=findComment&comment=237702

Your 2 lines looks correct. - The first one will trigger on whatever alarm time is reached. - The second one will trigger only when the time of the second alarm is reached. You just need to past them in the setevents() function in the config file of the QuickApp, as explained on the first page of the tutorial : https://www.domotique-fibaro.fr/topic/14651-quick-app-gestionnaire-dévénements-automatique-gea-pour-hc3/

Ouais gros LOL J'aime bien leurs vidéos, c'est très divertissant Mais voilà, "divertissant", c'est le mot. On s'arrête là, pour la crédibilité on repassera. J'ai failli stopper la vidéo quand ils ont dit qu'avec esp32cam ils avaient la même qualité d'image qu'une caméra pro.... et tout est comme ça dans leurs vidéos, c'est bon pour se divertir dans la joie et la bonne humeur.

ah oui mais alors si c'est juste le problème de vitesse, alors là je ne sais pas. Sur HC2, d'après le code source, cette fonction se contente d'appeler l'API HTTP, ensuite on ne sait pas ce qui se passe : fibaro.callGroupAction = function(self, actionName, actionData) local response, status = api.post("/devices/groupAction/" .. actionName, actionData) if status ~= 202 then return nil end return response["devices"] end

ups.realpower.nominal * ups.load 540 * 12 / 100 = 64.80 Watts

Pour compléter, ça sera possible, un jour, quand Fibaro permettra officiellement d'utiliser les listes déroulantes dans l'interface des QuickApps. Ainsi l'utilisateur pourra facilement choisir une valeur dans la liste déroulante, limitée aux choix proposés. En attendant, tu peux faire plusieurs boutons, chaque bouton permettant de porter la valeur qui t'intéresse. Bon si par contre tu as une liste de choix parmi 10....20... 50 valeurs, créer autant de boutons ne va pas être une bonne solution.

Non... enfin il va falloir coder ta propre logique, mais rien n'empêcherait un utilisateur de modifier la variable à une valeur non autorisée directement via l'interface Web. Le principe des variables énumérées c'est de limiter les valeur à une liste de choix prédéfinie... du coup la réponse directe à ta question, c'est bien non.

Sur HC2 j'ai quelque chose qui ressemble à ce que tu as fait : un VD, avec une scène pour le pseudo retour d'état. Pour avoir un retour d'état fiable, j'ai supprimé la télécommande d'origine. Le contrôle du Velux se fait exclusivement au travers de la domotique, c'est à dire : - directement depuis la box HC2 (scénario, interface Web, application mobile) - directement sur le module FGS double-relais, que j'ai installé au mur avec un interrupteur double monté/descente (ce FGS agit directement sur le KLF-050, et également sur la HC2 car il déclenche la scène de mise à jour de l'état) Sur HC3, je n'ai pas encore trop réfléchi... Évidemment le QA sera typé comme un volet roulant, ça va de soi. Mais je voudrais éviter une scène à coté du QA, je veux que le QA soit 100% autonome. Cela implique donc l'utilisation de l'API refreshStates dans une boucle infinie, car les QA ne supportent les "triggers" comme les scènes. Je ne pense pas me lancer dans la gestion des modules enfants, donc ça sera 1 QA = 1 volet. J'avais prévu de faire ça d'ici fin mai... donc dans 1 mois.