Aller au contenu

fel-x

Membres confirmés
  • Compteur de contenus

    416
  • Inscription

  • Dernière visite

  • Jours gagnés

    17

fel-x a gagné pour la dernière fois le 1 novembre 2025

fel-x a eu le contenu le plus aimé !

À propos de fel-x

  • Date de naissance 11/06/1976

Profile Information

  • Sexe :
    Homme
  • Ville :
    Bruxelles
  • Intéret :
    Fibaro, HomeKit, HomeBridge, Raspberry
  • Box
    Home Center 3
  • Version
    5.200.8

Visiteurs récents du profil

15 879 visualisations du profil

fel-x's Achievements

Enthusiast

Enthusiast (6/14)

  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare

Recent Badges

74

Réputation sur la communauté

  1. fel-x

    Recherche firmware Home Center Lite

    @Supermilk As-tu eu des nouvelles du support Fibaro ? J'ai une HCL en parfait état de marche qui repose dans une boite à chaussures... J'imagine que je pourrais en tirer le firmware pour te le partager ?? En plus elle était à jour il y a encore moins de 2 ans PS: si en plus quelqu'un veut la racheter
  2. fel-x

    Support Gea

    Tiens c'est peut-être une bête idée mais est-il possible/envisageable d'implémenter le * (wildcard) dans GEA? Pour permettre par exemple : GEA.add({{"Dates", "27/**"}, {"Time", "11:30"}}, 0, "message", {"Push", 840}) J'imagine que ça risquerait d'affoler le CPU si on l'emploie mal
  3. fel-x

    Support Gea

    Oui oui j'ai bien la bonne config de base avec GEA.portables = {840} Ceci dit je ne souhaite pas avoir une notification sur mon portable à chaque règle exécutée. Je préfère donc préciser en action vers quel(s) deviceID(s) doivent partir les push. Par exemple ceci fonctionne aussi : {"Push", {840, 716, 717, 718}, "Coucou la famille !"} mais je sais qu'un "Push" tout seul sans aucun argument/paramètre derrière va envoyer vers le {840}
  4. fel-x

    Support Gea

    oui en effet @Lazer je n'avais pas saisi le sens de ton message. Je suis justement occupé à remplacer tous mes "Monthly" par 12 lignes mensuelles, car de façon définitive aucune ligne "Monthly" ne fonctionne (même sans autre condition). Et là tu viens de me faire percuter. Je préfère une longue ligne pas jolie, mais une optimisation des ressources ! Je vais modifier de ce pas. J'en profite pour signaler que je constate que le message Push est celui qui est dans l'action et pas dans la notification, lorsque j'emploie "Dates" en condition. GEA.add({"Dates", "01/01"}, 30, "message 1", {"Push", 840) -- l'ID 840 (smartphone) ne reçoit rien GEA.add({"Dates", "01/01"}, 30, "message 1", {"Push", 840, "message 2"}) -- l'ID 840 (smartphone) reçoit "message 2" A quoi sert le "message 1" que je pensais retrouver dans le Push et dans le debug, mais que je ne retrouve nulle part ? Ou c'est moi qui fait un truc pas juste ? Parce qu'avec "Time" ou "Days" (ou les deux) en condition, je reçois bien le "message 1 en Push" et n'ai pas besoin d'ajouter un "message 2" GEA.add({{"Time", "13:10"}, {"Days", "All"}}, 30, "message 1", {"Push", 840}) -- l'ID 840 (smartphone) reçoit "message 1"
  5. fel-x

    Support Gea

    Et donc doit-on partir du principe qu'à défaut de pouvoir ajouter une condition "Time", pour l'instant "Monthly" se déclenche une et une seule fois par mois à minuit (entre 00:00:00 et 00:00:31) à la date correspondante ? Par exemple {"Monthly","Samedi"} se déclenchera dès qu'on passera du premier vendredi au premier samedi du mois à minuit.
  6. fel-x

    Support Gea

    Bien vu @jojo C'est pas le plus élégant mais ça contourne le problème. Je n'y avais pas pensé car on réfléchit toujours à prendre le chemin le plus court. Et "Monthly" était une évidence ergonomique... j'espère que @Lazer trouvera un jour le temps de tester. Bref je vais écrire les 12 lignes de ce genre pour toute l'année : GEA.add({{"Dates", "27/01"}, {"Time", "11:30"}}, 30, "message", {"Push", 840}) GEA.add({{"Dates", "27/02"}, {"Time", "11:30"}}, 30, "message", {"Push", 840}) GEA.add({{"Dates", "27/03"}, {"Time", "11:30"}}, 30, "message", {"Push", 840}) ...
  7. fel-x

    Support Gea

    Pour info, j'ai testé plusieurs combinaisons durant quelques jours et j'en conclus que "Monthly" n'accepte pas de condition complémentaire. Les seules possibilités d'emploi de "Monthly" sont décrites dans la syntaxe (v7.39) : -- SYNTAXE : {"Monthly"} {"Monthly", "First|Begin|1"} {"Monthly", "Last|End|31"} {"Monthly", <num_jour>} {"Monthly", <jour>} Si quelqu'un trouve le moyen d'y combiner une seconde condition horaire, je suis preneur En attendant je vais utiliser un scénario en LUA pur.
  8. fel-x

    Support Gea

    ...enfin si : je comprends que "Monthly" revient =true et que "Time" revient "false" systématiquement. Si je change la date (21 au lieu de 20 par exemple, puisqu'on est le 20 aujourd'hui) le "Monthly" revient =false aussi (même si je mets le "Temps" sous forme d'intervalle de 1 ou 2 minutes) Mais rien à faire pour que "Time" devienne =true (sauf à retirer la condition "Monthly")
  9. fel-x

    Support Gea

    J'avais déjà testé en mettant un intervalle d'une minute, mais sans impact. J'emploierai sans doute cette méthode si je constate des latences dans le futur mais pour le moment ma box n'est pas du tout surchargée et aucune règle GEA n'est loupée. Si je retire la condition "Monthly" ça fonctionne sans problème: GEA.add({"Time", "21:45"}, 30, "il est 21h45", {"Push", 840}) Mais si j'ajoute la condition "Monthly", il n'y a pas de déclenchement: GEA.add({{"Monthly", 20}, {"Time", "21:50"}}, 30, "On est le 20 du mois et il est 21:50", {"Push", 840}) et le debug complet (GEA.debug=true et GEA.lldebug=true) donne ceci : [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: GEA:encapsule() copy.check() copy.name="Monthly" id=20 property=20 value=20 value2=20 value3=20 value4=20 [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: GEA:encapsule() copy.getValue() 2 return copy.lastvalue, copy.lastDisplayValue : true, true [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: GEA:encapsule() copy.check() result = true [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: GEA:check() result = false, true [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: GEA:check() ready = false [20.01.2026] [21:50:10] [DEBUG] [QA_GEA_820]: @180s [Validation] #25 : ["Monthly",[20]] ["Time",["21:50"]] => ["Push",[840]] Idem à 21:50:40 (@210s) Je n'arrive pas à comprendre la cause sur base de ce log, et je veux bien un coup de main
  10. fel-x

    Support Gea

    Hello Je tente de mettre en place des rappels mensuels mais il apparait que "monthly" soit capricieux chez moi. Ou alors j'ai fait une erreur ? Ceci ne fonctionne pas : GEA.add({{"Monthly", 20}, {"Time", "18:15"}}, 30, "On est le 20 du mois et il est 18h15", {"Push", 840}) Vers 18h15 le 20 de chaque mois je devrais recevoir ce push n'est-ce pas ? Au lancement de GEA je vois que la condition est prise en compte, mais le moment venu, aucun push... Où est mon erreur ?
  11. Ce sont 3 QA du même auteur : https://marketplace.fibaro.com/items/openweather-weather-provider https://marketplace.fibaro.com/items/sma-pv-power-sensor https://marketplace.fibaro.com/items/sma-pv-energy-meter Je l'ai prévenu personnellement. Car je ne trouve rien dans son code qui tente de régler le niveau de debug... Une autre QA qu'il a écrite (https://marketplace.fibaro.com/items/velux-active-shutters-integration) a été rapportée avec le même bug, mais je ne l'emploie pas. On est bien d'accord, ce sont uniquement des QA proposées par lui qui plantaient à la mise à jour, et les miennes par exemple, ou GEA en l'occurence n'ont aucun problème.
  12. Salut, Je comprends ton coup de gueule @Lazer Pour le coup, mon info ne venait pas d'une IA mais d'un membre reconnu du forum officiel Fibaro (@jgab) J'aurais du le noter : https://forum.fibaro.com/topic/79616-unknown-error-occurred-no-static-loglevel-in-class-quickapp/ Ce n'est qu'après avoir lu la doc Fibaro mentionnée plus haut, et l'avoir testée sans succès (ou alors j'ai commis une erreur?), que je suis parti à la recherche de la réponse sur le forum officiel. Par contre ne trouvant pas l'explication de la valeur "1" j'ai demandé à une IA c'est vrai La réponse de l'IA.. je ne l'ai testée qu'avec des valeurs chiffrées et ça marchait aussi. Sinon avant de la coller ici j'aurais noté que les valeurs textuelles ne devaient pas être en minuscules mais en majuscules. Merci de ta correction. Je vais aller plus loin avec ce que tu as expliqué.
  13. D'après Gemini on peut donner la valeur 0 pour supprimer le log ou alors : Valeur Niveau Description 1 Error N'affiche que les erreurs critiques qui empêchent le bon fonctionnement. 2 Warning Affiche les erreurs + les avertissements (problèmes potentiels). 3 Info (Par défaut) Affiche les erreurs, warnings et les informations générales. 4 Debug Affiche tout, y compris les détails techniques de développement (très verbeux).
  14. Bon la solution est assez simple : ajoutez ceci AVANT onInit() dans le fichier main.lua des QA qui plantent. Ceci pour éviter toute erreur si Fibaro corrige modifie encore son moteur sans prévenir et sans documentation adéquate : QuickApp.logLevel = 1
  15. En effet, avec la 5.200.8 il y a plusieurs QA qui plantent en boucle avec ce type de warning ou d'erreur : [ERROR] [QUICKAPP739]: Unknown error occurred: no static 'logLevel' in class 'QuickApp' [ERROR] [QUICKAPP740]: Unknown error occurred: no static 'logLevel' in class 'QuickApp' [WARNING] [QUICKAPP740]: Variable Data Type not found Aucun fichier Lua de ces QA ne fait appel à QuickApp.logLevel ou self.logLevel !!! C'est vicieux ça comme mise à jour. Que faire à part un restore ? (je préfère corriger que rétropédaler si possible)
×
×
  • Créer...