fel-x

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}

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"

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.

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}) ...

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.

...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")

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

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 ?

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.

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é.

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).

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

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)

Si tu as supprimé celui-ci, comment tu fais pour activer ta chaudière lorsqu'il y a une demande de chauffage de la part d'une vanne ? Tu as placé quoi comme module pour lancer et stopper ta chaudière?

tu as choisi de placer des thermomètres z-wave dans les pièces munies d'une vanne eurotronic car tu ne fais pas confiance à la prise de mesure de la vanne elle-même ? je me disais que c'est idiot de mesurer la température de la pièce au niveau de la tête thermostatique elle-même, mais elles sont munies de ce type de capteur et je ne pensais pas qu'on pouvait court-circuiter le fonctionnement de la vanne... je veux dire que dans ton système tout semble correct mais que se passe-t-il lorsque la vanne détecte une température supérieure à sa propre consigne (alors que la pièce n'a pas encore atteint cette consigne) ? Elle n'est pas programmée d'office pour stopper la demande et "se mettre sur zéro" ?

Dis @jojo comment tu gères le chauffage avec de multiples têtes Eurotonic? Tu passes par le panneau de chauffage inclus dans la HC3 ou tu as une meilleure solution? Jusqu'à présent je passais par le panneau de chauffage puisque mon thermostat Z-wave se trouve dans le salon et actionne la chaudière directement. Il est le seul module à pouvoir l'actionner d'ailleurs encore aujourd'hui. Mais ayant ajouté quelques Eurotronic Comet par-ci et par-là, je suis perplexe sur la façon de gérer le chauffage... Actuellement j'ai cette configuration-ci : C'est-à-dire que le thermostat active la chaudière s'il détecte une température insuffisante dans le salon (consignes horaires prévues dans le panneau de chauffage HC3) via un câble (ligne bleue) intégré dans la maison lors de l'achat. Ceci permet à tous les radiateurs de chauffer en même temps (circuit rouge). Je suis donc obligé de laisser les vannes manuelles sur différentes positions optimales et au cours des années j'ai trouvé un équilibre acceptable mais pas idéal. Désormais j'ai ajouté 4 vannes Z-wave dans des pièces stratégiques où je veux des températures précises à des moments précis. Je suis conscient que si l'une des vannes Eurotronic demande du chauffage, la chaudière va s'enclencher et alors toutes les vannes manuelles (circuit rouge) vont indubitablement chauffer. J'accepte ceci pour le moment puisque petite à petit je vais tout remplacer par des eurotec... mais ça en fait 22 quand même et le budget de noël est peu élastique. Ma question est surtout : faut-il gérer chacune des eurotronic par le panneau de chauffage en créant des "zones" ? Ou via GEA ? Ou les 2 ? Ou autre? merci

allez, pour tes modules parents @jojo, petit cadeau emballé en 128*128

moi aussi c'est pour faire joli. Alors tu peux uploader ton icône dans un autre module et en utiliser l'ID pour l'attribuer à n'importe quel parent ! Pour le coup j'ai créé une scène LUA avec mon code ci-dessus, et j'y ai uploadé plusieurs icônes que j'avais créées pour usage ultérieur. J'emploie la scène à chaque Parent que je veux "enjoliver" : je modifie l'ID du parent et l'ID de l'icône qui peut très bien provenir de n'importe quel module, script ou QA ! Donc rien ne t'empêche d'utiliser un iconID provenant de n'importe où, l'unique raison de l'uploader dans un enfant c'est la logique et la "propreté", mais après...

Tu voudrais que l'icône Parent soit dynamiquement changé selon l'état du child ? Avec GEA ce devrait être facile

@mprinfo tu as un lien pour ce tarif ? 50 Eur pièce c'est plutôt bien !

Merci @jojo je vais en commander quelques unes pour tester alors. 70 Eur la pièce semble le prix officiel, et je ne trouve pas de revendeur autre que Conrad (NL). Tu confirmes que c'est le prix attendu ? merci

Dites, je me prépare à l'hiver et je me dis une fois de plus... Non sorry ... je me dis que je mettrais bien des têtes thermostatiques connectées. Chaque année je peine à franchir le cap, vu le prix et les 22 radiateurs de la maison. J'ai bien une tête Danfoss LC-13 dans le hall d'entrée que j'avais placée pour tester, mais je n'ai jamais été convaincu. Suites à quelques recherches, j'ai vu que le choix aujourd'hui en Z-wave se limite aux Fibaro Heat controller et aux Eurotronic Comet. quelqu'un a-t-il testé les deux pour me dire ce qui est meilleur? Je vais sans doute commencer par n'en placer que quelques unes aux radiateurs stratégiques. merci

Si tu fais ça, tu réfères à l'ID de l'icône est cours d'utilisation pour ce device. Donc dans ta capture d'écran, le device dont tu affiches le JSON emploie l'icône 1129. Tu peux donc attribuer ce icondD à n'importe quel autre device bien entendu avec le petit code LUA ci-dessus. Moi ce que je fais, c'est uploader une icône de mon choix dans l'un des modules enfant. Ensuite j'en récupère l'ID en simulant un "enregistrer sous" par click droit sur l'icône. J'attribue cet iconID au module Parent avec mon code. De cette manière, si je supprime un jour le module, l'icône personnalisée disparaîtra aussi. Voici une petite illustration de ce que j'ai fait ce matin en réinstallant mon thermostat SRT-323, et créé une icône : 1. Inclusion du module 2. Ajoute de mon icône personnalisée dans le module enfant (877) 3. Click-droit sur l'icône uploadée pour en connaître l'ID --> je découvre que c'est le 1143 4. Attribution de l'iconID 1143 au deviceID 876 function QuickApp:onInit() local deviceID = 876 local iconID = 1143 self:debug("Attribution de l'icône " .. iconID .. " au module " .. deviceID) local payload = { properties = { deviceIcon = iconID } } api.put("/devices/" .. deviceID, payload) end 5. On admire le résultat CQFD. PS: je n'ai pas testé un reboot pour savoir si l'effet est permanent.

Bon sang mais c'est bien sûr ! J'ai suivi ta piste et j'ai réalisé que c'est plus simple qu'on ne le pensait. quelques lignes dans une QA et hop... ça fonctionne ! Icône Parent modifié > c'est largement plus esthétique que toutes ces boites avec un gros point d'interrogation. Voici le code pour ceux que ça intéresse : function QuickApp:onInit() local deviceID = 123 local iconID = 1234 self:debug("Attribution de l'icône " .. iconID .. " au module " .. deviceID) local payload = { properties = { deviceIcon = iconID } } api.put("/devices/" .. deviceID, payload) end

J'aurais espéré une astuce