Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 872
  • Inscription

  • Dernière visite

  • Jours gagnés

    1 256

Tout ce qui a été posté par Lazer

  1. Lazer

    Api Event/history

    Théoriquement tu pourrais avoir plusieurs QA qui exploitent l'api refreshStates. Je ne sais pas quel serait l'impact sur la charge système, je manque encore de recul.
  2. Euh, j'ai demandé le firmware, pas le prix
  3. Lazer

    Maitre esclave

    Encore une traduction mal.... traduite ! C'est une relation parent/enfant. Et c'est tout à fait normal.... enfin, aussi normal que peut l'être la logique Fibaro. Il n'y a rien à casser. La parent, c'est le module Z-Wave proprement dit. Les enfants, ce sont les "endpoints", disons les fonctions que ce module sait gérer. Si tu n'en n'as pas besoin, tu caches le modules correspondant dans l'interface, tout simplement.
  4. Tu pourrais partager le firmware ? Je ne vois rien sur leur site, pourtant Aeotec partage toujours ses firmwares, c'est même le seul bon élève dans la classe Z-Wave.
  5. Lazer

    Api Event/history

    Oui, je comprends, en fait tu cherchais une logique similaire à /api/redreshStates Les 2 ont un comportement inversé : /api/events/history permet de remonter dans le passé /api/redreshStates permet de suivre les nouveaux événements au fil de l'eau Du coup, n'est-ce pas refreshStates que tu aurais dû utiliser pour ton application ? Même si tu as trouvé une solution de contournement avec les timestamps from, cela me parait moins précis, car tu peux avoir plusieurs événements au même timestamp (pendant une seconde, c'est long).
  6. Bienvenue sur le forum
  7. Lazer

    Api Event/history

    Effectivement, la doc du swagger semble erronée, mais le comportement en revanche est logique. Avec numberOfRecords tu récupères les N derniers événements par rapport au moment spécifié (avec lastId). Si lastId n'est pas spécifié, alors c'est le tout dernier. L'idée, est de coller au fonctionnement du panneau d'événement de la HC3. D'abord, on affiche les N derniers événements (afin de remplir la page) Si l'utilisateur scrolle la page, alors on cherche les N événements précédent le dernier ID connu. Etc... cela permet de scroller indéfiniment, et de remonter dans l'historique.
  8. Lazer

    Conso RAM HC3

    En tout cas 43% pour le used, c'est tout à fait normal, j'ai la même valeur sur mon HC3. J'insiste, je le répète partout sur le forum, il ne faut prendre en compte que le used (= espace utilisé), et ignorer le cache et le buffer.
  9. Lazer

    Support Gea

    Ouais c'est ça la magie de GEA Extrait de la doc de syntaxe rédigée par @pepite : Je souhaite que la lumière s'allume au levé du soleil mais pas avant 7h30 : Utiliser le paramètre Sunrise>07:30 ou Sunrise<07:30. GEA.add({"Time", "Sunrise>07:30", "07:35"}, 60, "Allumage lumière", {"TurnOn", 18})
  10. C'est quand même assez aléatoire....
  11. Lazer

    Support Gea

    Euh, si, on peut utiliser Sunrize avec >, pourquoi tu dis ça ? Je l'utilise dans mon GEA v6 sur HC2 Pour moi cette condition devrait être valide : {"Time", "Sunrise>08:40", "09:00"}
  12. Non la valeur par défaut c'est seulement 3000 ms, soit 3 secondes. Et j'avais justement augmenté cette valeur à 10000 ms, soit 10 s, pour minimiser les erreurs, car le cloud Netatmo est parfois lent à répondre. Même si ce n'est pas suffisant, car j'ai encore des échecs de connexion. J'ai testé avec 20000 voire 30000, mais ça ne change rien.
  13. Lazer

    PROBLEME ZWAVE HC3

    J'ai plutôt l'impression que c'est un module qui a buggé, qui inonde le réseau, et fait tout planter. Je ne sais pas combien tu as de modules, mais il va falloir l'identifier... et si tu ne sais pas lequel c'est, il faudra les déconnecter un par un jusqu'à trouver le coupable.
  14. Non la mise à jour ne modifie pas la config du module. Je suppose qu'il n'est pas nécessaire de mettre à jour la HC Lite avant la mise à jour de ce module.
  15. Lazer

    QA Multilevel sensor

    Hum, oui en effet, alors le type multilevel, comme son nom l'indique, ce sont tous les modules qui peuvent prendre une infinité de valeur. Exemple classique : capteur de température, d'humidité, de luminosité, etc. Même si les valeurs peuvent être bornées (ex : humidité, forcément entre 0 et 100) Mais tu as aussi les actionneurs, exemple, le dimmer. D'ailleurs Fibaro fait bien la distinction : multilevelSensor et multulevelSwitch Les capteurs de mouvement et d'ouverture sont de type binaire, true ou false, 2 valeurs uniquement. Le generic n'a rien à voir, puisqu'il n'a tout simplement pas de valeur. Tiens regarde cette URL, tu verras la liste des types sous forme d'arbre : /api/devices/hierarchy Tu verras que temperatureSensor, humiditySensor, etc.. sont des cas particuliers de multilevelSensor L'avantage d'utiliser le type le plus juste, est d'avoir l'unité préconfigurée, l’icône, etc.... Quand tu utilises un multilevelSensor car tu ne trouves pas de type prédéfinis correspondant à ton besoin, tu peux lui affecter ta propre unité (par défaut l'unité n'est pas définie : chaine de caractère vide)
  16. Home Center 3, Home Center 3 Lite and Yubii Home comparison Cela confirme que la seule différence de la Yubii avec la HC3L est la présence de la puce NICE, comme sur la HC3. Cela dit, pour tout le reste, elle est strictement identique à la HC3L. Si je devais faire un classement, je dirais : HC3 >> Yubii > HC3L (oui j'ai bien mis double supérieur entre la HC3 et la Yubii, tant les différences sont nombreuses). Les râleurs vont dire qu'elle n'a pas de puce Z-Wave 700
  17. Ce n'est pas encore en place avec cette version.... ça viendra, mais plus tard. Maintenant je travaille activement sur la migration de ma propre installation d'ici fin mai, donc les améliorations des QA existants, et futurs nouveaux QA, reprendront après.
  18. Oui pour modifier le champ enabled, que ça soit par le GUI ou par l'API, dans les 2 cas ça fait la même requête PUT, qui redémarre obligatoirement le QuickApp. Donc passage obligé par la fonction onInit() Mais ce que je voulais dire, c'est que le QA sera toujours actif, donc il recevra les sollicitations de l'utilisateur, les appels de fonctions, etc. Donc si on veut faire les choses proprement, il faudrait tester son état enabled au début de chaque fonction. Un peu lourd... Oubli de la part de Fibaro, ou simple héritage de ce champ depuis les modules Z-Wave ? Je ne sais pas, mais en tout cas je suis content qu'on aie accès à cette valeur, ça permet de simplement bloquer l'exécution d'un QA.... Je me souviens sur HC2 d'avoir dû vider des main loop de leur contenu, ou d'avoir mis un fibaro:abort() en première ligne, et d'avoir oublié de l'enlever par la suite... "Mais pourquoi ce c.. de VD ne fonctionne plus ???"
  19. C'est exactement pour cela que j'en ai parlé, je me doutais que ça allait faire réagir les développeurs Et effectivement, c'est à nous de coder la logique de désactivation. L'équivalent de getSelfID() est tout simplement self.id (accessible uniquement depuis une fonction de QuickApp, puisqu'on utilise self), ou bien de façon plus générale plugin.mainDeviceId qui est accessible de n'importe où dans le code LUA du QA) fibaro.getValue(347, "enabled")) ne te retourne rien car enabled n'est pas une propriété du device (= elle ne fait pas partie de la sous-table properties dans son JSON) Perso j'utilise ce genre code, vers le début de la fonction QuickApp:onInit() : -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then self:updateProperty("log", "Disabled") for _, child in pairs(self.childDevices) do child:updateProperty("log", "Disabled") end self:updateView("LabelDebug", "text", "❌ " .. (self.trad.quickapp_disabled or "QuickApp disabled") .. " ❌") self:warning("Device", self.name, "is disabled => QuickApp stopped") return end C'est le return à la fin du bloc de test qui stoppe l'exécution du QuickApp (en réalité ça ne le stoppe pas, ça empêche juste l'exécution de la suite du code de onInit(), et notamment le setTimeout() un peu plus loi qui est censé lancer la boucle infinie)
  20. A ce sujet, dans tous mes QuickApps, j'ajoute maintenant la possibilité de désactiver facilement chaque QA, simplement en cochant la case qui va bien dans l'onglet de ses propriétés avancées :
  21. étrange ça, pourquoi il n'y a pas 2 robots qui se comportent de la même façon ? C'est pénible... Il faudra que je prenne le temps d'étudier les logs plus en détail....
  22. Oui voilà !
  23. Euh, tu es certain d'avoir fait la mise à jour des fichiers LUA ?
  24. Lazer

    Joyeux anniversaire @Domodial

    Distanciation sociale, le forum est COVID Compliant
  25. tient c'est marrant, ce message apparait de temps en temps aussi sur le miens, mais très rarement, environ 1 ou 2 fois par semaine. Dans tous les cas, si tu veux avancer, il faudra me partager les logs complets avec debug = true
×
×
  • Créer...