Lazer

Bienvenue sur le forum

Oui, exact, une version modifiée dispo sur un site russe.... perso j'ai pas osé Je préfère l'ancienne version officielle dispo sur apkmirror, c'est plus sûr.

Oui j'ai constaté que ça se produit de temps en temps avec tous les QA. Je ne suis pas certain, mais j'ai l'impression que quand on enregistre un QA au moment précis où il est en train d'exécuter une instruction, ça fait planter l'instance précédente. Rien de gênant en tout cas, ça n'empêche pas le bon fonctionnement du QA une fois redémarré

Aujourd'hui, je me suis connecté sur mon HC2. Pfiou... c'est laborieux. J'avais oublié à quel point l'interface web est lente Non pas lente. Ultra lente. Bref, j'ai installé ton VD et ta scène @ADN182 merci c'est nickel ça fonctionne (je n'en doutais pas ) avec mon Roborock S6 MaxV Pour récupérer le token il a fallu que je downgrade la version de Xiaomi Home sur mon smartphone Android (j'ai suivi ce tuto : https://xiaomirobot.wordpress.com/android-recuperer-son-token-jeton-methode-1/) En synthèse : - désinstaller Xiaomi Home - installer une vieille version de MI Home téléchargée ici : https://www.apkmirror.com/apk/xiaomi-inc/mihome/mihome-5-0-9-release/mihome-5-0-9-android-apk-download/ - lancer l'app et se connecter avec son compte Xiaomi, l'aspirateur est retrouvé automatiquement - utiliser MiToolKit dispo ici https://github.com/ultrara1n/MiToolkit/releases (il faut avoir déjà Java installé sur le PC, avoir activé le débogage USB sur son smartphone, et avoir autorisé le PC, heureusement tout ça j'avais déjà fait) - récupérer le token - désinstaller Mi Home puis réinstaller la dernière version de Xiaomi Home sur le Play Store Maintenant la suite... je vais attaquer le développement du QuickApp pour HC3. Je ne sais pas pour combien de temps j'en ai.... à suivre Précision vu qu'il y avait une discussion à ce sujet plus haut : il faut utiliser l'application Xiaomi Home, c'est le seul moyen (à l'heure actuelle) de pouvoir domotiser les aspirateurs Roborock. En effet, avec l'application Roborock, l'aspirateur est réinitialisé et le token disparait... je n'ai vu personne réussir à dialoguer avec l'aspirateur dans ce mode. Dommage car l'application Xiaomi Home est en retard sur la gestion des dernières fonctionnalités des aspirateurs Roborock (caméra par exemple), mais c'est un moindre mal, je préfère voir la domotique que la caméra au raz du sol sur mon smartphone.

Perso je suis à 100ms dans GEA pour refreshStates (et c'est paramétrable par l'utilisateur), mais je ne vois pas de raison de mettre plus ou moins. 50 ou 100 ms, du point de vue de l'utilisateur, c'est la même chose : instantané. En fait, le plus gros délai, sera comme toujours le capteur PIR lui-même. Plus la latence Z-Wave qui n'est pas nulle. A ce sujet, as-tu regardé le QuckApp GEA Alarm ? Il est indépendant de GEA, et permet de régler autant d'heures qu'on le souhaite, directement depuis une interface graphique (les boutons du QA), avec planning par heure/minutes et jours de la semaine. On peut aussi régler les heures "programmatiquement", donc mon intention à terme, c'est que GEA pourra régler l'heure, s'auto-déclencher une fois le moment venu, tout en laissant la possibilité à l'utilisateur de reprendre la main et de régler manuellement l'heure désirée. Les heures/jours sont stockées dans des variables du QA lui-même (pas de variables globales) Exemple de scénario : - GEA calcule tout seul l'heure de mise en route du chauffe-eau chaque nuit, en fonction de la température afin d'économiser et de ne pas chauffer trop d'eau inutilement. - Ponctuellement, je sais que le lendemain j'aurai besoin d'un maximum d'eau chaude (invités à la maison par exemple), alors avant de me coucher j'avance moi-même l'heure) Évidemment le même genre de scénario est applicable à l'heure du réveil-matin, ou à tout autre cas de figure.

Voici GEA version 7.21 : Correctifs :  Résolution du Profile identifié par son nom dans les conditions Ajout des paramètres user et password optionnels dans l'option "httpGet" Meilleure gestion des caractères spéciaux dans les notifications Push et Email. Copier/coller le contenu du fichier LUA téléchargé par dessus le fichier main dans le QuickApp. GEA v7.21.lua

Effectivement CustomEvent est arrivé en 7.20 Mais attends, je vais partager la 7.21, elle est prête, du coup à priori il n'y a pas de bug à corriger avec cette option

Cette valeur est mise à jour suite au boot, au backup, etc, bref tout ce qui redémarre les services Fibaro. Il suffit de le comparer au os.time() courant, si par exemple le delta est inférieur à 120 secondes, on peut raisonnablement penser que la box vient de booter, sinon c'est juste le QA qui a été redémarré. C'est comme ça que GEA procède depuis la HC2, de même que l'une de mes scènes que je m'étais fait à l'époque. @henri-allauch d'ailleurs je ne vois pas bien comment tu voudrait intercepter le boot de la box dans le refreshState depuis un QA, puisque le QA a nécessairement démarré après le boot de la box.

CTRL+F5 plutôt, le F5 n'est pas suffisant. Règle de base après une mise à jour Mais du coup, je n'avais pas fait attention, mais le bug "il y a {{time}}" a enfin disparu, à la place il n'y a ... Plus rien En fait ça ressemble à une erreur de traduction : en anglais le "ago" se met bien après la durée, mais en français le "il y a" doit venir devant. Courage Fibaro, dans 2 ou 3 firmwares vous arriverez enfin à faire un string.format() correct

@Cardane j'ai déplacé ton message ici car ça ressemble à un bug de GEA v7 pour HC3. Tu pourrais m'en dire plus sur le problème ? Logs de GEA, etc ? @Dragoniacs j'ai identifié et corrigé le bug des Profiles dans les conditions. @manulemalin et @Dragoniacs J'ai testé les multi-ID dans les commandes Open et Close, et ça fonctionne, donc là aussi si vous avez un bug, il faudra m'en dire plus (logs détaillés, etc) Pour rappel dans GEA pour obtenir un premier niveau de log, il faut mettre GEA.debug = true dans votre config. Et pour obtenir le 2nd niveau (très bavard), il faut ajouter en plus GEA.lldebug = true

Si les 2 alims sont dans le même tableau, alors l'échauffement sera le même. Et ça sera peut être même pire, car le rendement des alimentations a tendance à baisser avec les petites puissances... il faudra que tu vérifies cela dans la datasheet du modèle que tu vas choisir

Il faut aussi penser à tester le timestamp contenu dans serverStatus via /api/settings/info pour vérifier que le QA n'a pas été redémarré longtemps après le reboot de la box

Bienvenue sur le forum

problème classique avec l'infra-rouge.... tu peux ajouter un wall plug sur les équipements, et en fonction de la conso tu saurais s'il est allumé.

A la louche je dirais environ 15 minutes (hors temps de téléchargement et backup préalable)

J'ai pas chronométré, mais vu l'heure, tu devrais être l'apéro, faut pas perdre les bonnes habitudes acquises avec la HC2

si si, ça a toujours été comme ça je crois bien ça le garde en mémoire tant que tu restes sur la page des dispositifs, si tu la quitte et que tu y retournes, il faut à nouveau cliquer sur le bouton "-" pour faire réapparaitre la corbeille. C''est une bonne petite sécurité je trouve (en plus du popup de confirmation)

Donc d'après les tableaux tu es dans les clous Je suis peut être trop prudent (quoi que, on ne l'est jamais assez ) Le souci avec le micromodule dans le tableau, c'est que même si le courant va se répartir en 3 parmi les 3 fils des 3 couleurs, tu auras quand même le retour sur 1 seul fil (l'anode commune), donc obligé de dimensionner ton installation à 1.5mm² (même si je mettrais de 2.5 perso)

Je propose un truc dans le genre pour calculer le délai d'ici le lendemain à 3h (pas testé, et il y a peut être moyen d'optimiser) : local currentTime = os.time() local futureTime = os.time({ year = os.date("%Y", currentTime), month = os.date("%m", currentTime), day = os.date("%d", currentTime) + (os.date("%H", currentTIme) >= 3 and 1 or 0), hour = 3, min = 0, sec = 0, }) local diffTime = os.difftime(futureTime, currentTime) self:debug("Time is " .. os.date('%H:%M:%S', currentTime) .. ", first loop at " .. os.date("%H:%M:%S", futureTime) .. " in " .. tostring(diffTime) .. " seconds...") fibaro.setTimeout(diffTime*1000, function() self:loop() end) C'est perfectible, car si le QA redémarre entre 0 et minuit il va attendre plus de 24h (le lendemain), donc il faut ajouter un test supplémentaire dans la définition du day + 1 => test ajouté A part cela, je me pose une question, je ne sais pas comment la HC3 gère les timeouts de 24h, je me souviens que sur HC2 ça ne fonctionnait pas et qu'il fallait découper en plusieurs intervalles de taille modeste, mais bon, c'était les VD avec tous leurs défauts. A tester donc.

0.3 ce sont bien des Volts La basse tension, c'est plus compliqué qu'il n'y parait, car à cause justement de la base tension, les courants sont beaucoup plus élevés (P = U * I) Si tu n'as pas le choix, dans ce cas, il faut utiliser des grosses sections, minimum 2.5 mm² pour limiter les risques. Mais reste le problème de l'alimentation, une si forte puissance dans un tableau électrique domestique, c'est moyen. Je dis bien domestique, car en industriel tu as des tableaux en métal plus volumineux, mais tu n'as surement pas la possibilité d'en installer un. Si @Did passe par ici il nous donnera peut être un avis plus éclairé

Pour les modules sur batterie, c'est normal, il faut réveiller manuellement le module, ou bien attendre qu'il se réveille. Petit rappel :

La formule est bonne, mais j'ai pas compris ton calcul 2 lampes de 36W => 72W au total P = U x I soit I = P / U donc 72/24 = 3 Ampères Perte = 0.017 * (2*4) * 3 / 1.5 = 0,272 Volts (du coup j'arrive au même résultat que toi mais avec un raisonnement différent, est-ce un hasard ?) Presque 0.3W de chute de tension, je trouve ça beaucoup. ça fait 0.272 * 24 = 6,528 Watts de perdus en échauffement dans les câbles, c'est énorme ! Si tu veux déporter ton alimentation aussi loin, à ta place je poserai du câble de 2.5mm² Perte = 0.017 * (2*4) * 3 / 2.5 = 0,1632 Volts Soit 3,9168 Watts de perdus dans les câbles, c'est déjà mois pire (même si je trouve ça pas super quand même) Outre l'échauffement des câbles (et le risque d'incendie qui va avec), le risque d'une trop grande chute de tension c'est de ne pas pouvoir allumer les LED du tout. Une LED, ce n'est pas comme une lampe à incandescence, ça s'allume ou ça ne s'allume pas, mais ça ne va pas s'allumer un peu moins. Pour info la gradation des LED n'est pas faite par baisse de la tension, mais par hachage du signal (PWM) Pour ton alimentation au tableau, tu vas tirer 72W, donc si tu pars sur une alim de 100W et qu'elle a, admettons 85% de rendement à 72% de charge, alors ça fait 72*(100-85)/100 = 10 Watts de perdus Et là encore c'est énorme, 10W dans un tableau électrique fermé en plastique, je ne m'y risquerais pas A ta place, si tu veux assurer le coup en toute sécurité, je prendrais une alimentation de qualité Meanwell tout en métal (ils en font des super bien qui sont étanches en plus, le boitier alu joue le rôle de dissipateur passif), idéalement d'une puissance nominale d'environ 90W (afin d'être dans sa plage de fonctionnement nominale), que j'approcherais le plus possible du sauna, dans un endroit où il y a suffisamment d'espace pour le dégagement de chaleur. De plus, tu pourras surement trouver une alim dont le rendement s'approche des 90%, ça sera toujours de l'énergie perdue en moins et du dégagement calorique en moins à gérer.

Si ça peut être utile, voici la mienne : tools = tools or {} -- -- Get QuickApp variable silently without showing warning message in case variable does not exist -- -- Usage : -- local mavariable = tools.getVariable(self, "debug") -- local mavariable = tools.getVariable(1234, "debug") -- function tools.getVariable(self, variable) local id = type(self) == "userdata" and self ~= tools and self.id or type(self) == "number" and self > 0 and self if id then if type(variable) == "string" and name ~= "" then local device if type(self) == "userdata" then device = self else device = api.get('/devices/' .. tostring(id)) end if device then if type(device.properties) == "table" and type(device.properties.quickAppVariables) == "table" then for _, v in ipairs(device.properties.quickAppVariables) do if v.name == variable then return v.value end end else tools:warning("tools:getVariable() : can't get QuickApp variables") end else tools:error("tools:getVariable() : can't find device", type(self), tostring(self)) end else tools:error("tools:getVariable() : invalid variable name :", type(variable), tostring(variable)) end else tools:error("tools:getVariable() : invalid self device :", type(self), tostring(self)) end end Comme tu peux le voir, on peut l'utiliser au sein d'un QA même (avec self), sur un child, ou bien encore sur n'importe quel QA identifié par son ID

Oui, effectivement j'étais arrivé aux mêmes conclusions

Tout à fait A ce sujet je rappelle cet ancien tuto oublié :