Lazer
-
Compteur de contenus
25 857 -
Inscription
-
Dernière visite
-
Jours gagnés
1 255
Tout ce qui a été posté par Lazer
-
Topic unique Fibaro - Capteur D'ouverture Fgk
Lazer a répondu à un(e) sujet de Moicphil dans Modules Fibaro
ça ressemble à un problème classique de maillage Z-Wave. Essaye d'ajouter des modules sur secteur (car ce sont eux qui font routeur) dans les environs de la boite aux lettres, afin que le capteur puisse trouver un chemin stable vers la box. -
Pour rappel, il y a 2 showroom GEA sur le forum. Qui datent de la HC2 certes, mais la plupart des exemples sont encore valables, ça peut vous servir d'inspiration. En tout cas c'est là bas qu'il faut partager vos codes, ici c'est le topic du Support GEA, donc pour demander de l'aide.
-
Ah ben si tu as un QA externe qui fait tout le boulot de détermination de l'heure, alors c'est encore plus facile, je ne sais même pas pourquoi tu poses la question puisque tu connais (mais a oublié ) déjà les réponses fibaro.call(ID_GEA_Alarm, "setTime", numéro_alarme, PiscineHrFin) Au format "00:00" bien entendu. (ou hub.call si tu préfères)
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
J'ai regardé le code de GEA, et je confirme que ce n'est pas possible, "Time" ne peut prendre que des chaines de caractères contenant une heure. Pour définir l'heure avec GEA Alarm, comme tu l'as vu il faut appeler la fonction setTime() du QuickApp. Et là pour le coup, tu n'es pas limité à une chaine de caractère de type string, tu peux la définir programmatiquement. Je n'ai pas essayé depuis une Variable Globale ou une Variable Cache (ça devrait fonctionner), mais je l'ai testé avec "Function" (qui est bien plus puissant car on peut s'en servir pour calculer l'heure désirée en fonction de plein de critères). Exemple basique : GEA.add( {CONDITION}, 30, "", {"QuickApp", id["QA_ALARM"], "setTime", 2, {"Function", function() return "22:22" end}}) Dans cet exemple ultra simple, la fonction retourne bêtement la chaine "22:22" (j'espère que tu as relevé le choix de cette heure si particulière pas du tout due au hasard ), mais comme c'est du LUA dans la fonction, tu peux faire ce que tu veux, et retourner la valeur qui te plait, du moment que la valeur retournée est une heure au format chaine de caractères. Et puisque tu parles de valeur calculée tous les jours à 5h30, je pense qu'avec cette astuce tu vas pouvoir grouper 2 règles GEA en 1 seule, c'est à dire la règle qui calcule l'heure est la même que celle qui affecte l'heure au QA GEA Alarm. Cela simplifie le code, et cela économise l'emploi d'une variable qui devient inutile. "Function" est ultra puissant, la seule limite est notre imagination.
-
Tu es certain que c'est possible ? Je ne crois pas... Pour ce que tu veux faire, il faut utiliser le QuickApp GEA Alarm : https://www.domotique-fibaro.fr/topic/14651-quick-app-gestionnaire-dévénements-automatique-gea-pour-hc3/?do=findComment&comment=232268
-
Quick App - GCE Electronics IPX800 v4 et EcoDevice RT2
Lazer a répondu à un(e) sujet de Lazer dans Quick App Developpeur
En effet en triphasé c'est plus complexe. Tu as tout intérêt à conserver la gestion via Linky, surtout que le tien te remonte l'injection via la téléinfo, ce qui n'est pas le cas du miens, raison pour laquelle j'ai besoin d'utiliser une pince. -
Quick App - GCE Electronics IPX800 v4 et EcoDevice RT2
Lazer a répondu à un(e) sujet de Lazer dans Quick App Developpeur
Aujourd'hui j'ai installé la nouvelle version 3.0 de l'EcoDevice RT2 disponible sur le forum GCE : https://forum.gce-electronics.com/t/nouvelle-release-ecodevices-rt2-3-0/15493 Elle fonctionne très bien, il faut juste suivre la procédure de mise à jour avec attention (qui va complètement réinitialiser l'appareil EDRT2) Grosse nouveauté, la gestion de l'autoconsommation, je peux enfin mesurer en temps réel mon injection vers le réseau Par contre attention, l'API a un peu changé, plus exactement les valeurs retournées par l'API. J'ai relevé 2 différences dans l'API permettant de lire les valeurs instantanées des sous-postes /api/xdevices.json?key=apikey&Get=S : La numérotation de chaque sous-poste démarrait précédemment à 1 (donc de P1_SSP1 à P1_SSP8), elle démarre maintenant à 0 (donc de P1_SSP0 à P1_SSP7) Les puissances étaient précédemment en kW, elles sont maintenant en Watts.... donc d'un rapport 1000 (à ajuster avec la formula dans votre config) Il faudra donc ajuster la config de votre QuickApp en conséquence. -
C'est historique, l'API proposée par Fibaro a toujours fonctionné ainsi depuis la HC2. Donc GEA aussi. Cela dit, cette discussion me rappelle que depuis un certain firmware de la HC3, Fibaro a fait évoluer l'API proposée pour envoyer des notifications. Donc peut être que maintenant il est possible d'envoyer un Push à un utilisateur... ce qui implique que la box sache prendre en compte quel utilisateur est connecté au travers de tel ou tel téléphone. A creuser pour plus tard.
-
L'application mobile Fibaro a la mauvaise habitude de se ré-associer en créant un nouvel ID dans la DB, par exemple après une réinstallation / réinitialisation complète du téléphone. ça a toujours été comme ça... surement parce que l'identifiant unique du téléphone a changé entre temps. Si tu veux envoyer des notifs à un utilisateur, et non pas à un portable, alors il faut utiliser l'action Email... qui comme son nom l'indique, enverra un email. Voir la doc de syntaxe pour les différentes options existantes. OK c'est pour ça donc, "Value" ne peut être utilisé comme action que sur des actionneurs (car en interne, il appelle la fonction setValue via l'API). Si tu veux mettre à jour la valeur (en fait n'importe quelle propriété) d'un module, alors il faut utiliser l'action "Property" (qui appelle la fonction updateProperty via l'API)
-
Ce qu'il y a de bien, c'est que ton erreur est écrite en toute lettre dans ton message. Si tu mets l'ID d'un utilisateur dans une variable qui se nomme "portable", forcément, ça marche pas bien...
-
C'est quoi ton module PISCINE_TMPLAST ? Tu es certain qu'il peut prendre la valeur issue du module PISCINE_TMP ? Exemple si c'est un multilevelSwitch tu peux lui donner une valeur entre 0 et 99, mais pour un binarySwitch, ça sera true/false uniquement.
-
Tu es sûr que tu as un portable avec l'ID 2 ? Tu peux vérifier avec /api/iosDevices/ Perso j'utilise les noms des portables, exemple : GEA.portables = {"Pixel 5", "Pixel C"} EDIT : voir 2 messages plus bas...
-
Avec GEA c'est faisable, tu as plusieurs options pour gérer le Thermostat et ses différents modes, mais aussi le panneau de climat lui-même. Voir la doc de syntaxe pour les différentes options en question.
-
Basiquement : local id = { WP_SPA = 123, } GEA.add({{"Power+", id["WP_SPA"], 2000}}, 30, "Le Spa est démarré depuis 30 secondes") GEA.add({id["WP_SPA"], {"Power-", id["WP_SPA"], 10}}, 30, "Erreur consommation Spa inférieure à 10 W") Tu peux ajuster les durées si tu veux plus ou moins de réactivité pour les notifs. Et comme tu peux le voir, il n'y a aucune action, juste une notif pour chaque règle.
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
Dans ce cas il faut ajouter {"Value+", ID, 1} dans les conditions.
-
Oui dans les conditions il faut ajouter Value+ ou Value- afin de comparer la valeur. Par contre je ne me souviens jamais lequel de 0 et 99 correspond au volet complètement ouvert/fermé... donc faut faire des essais, ou regarder le JSON du module via l'API.
-
Oui c'est le même principe. La seule différence, c'est que VariableCache est stocké en RAM, donc pas d'écriture dans la DB, mais perdu en cas de redémarrage de GEA. Tandis que Variable est écrit dans la DB, donc conservé en cas de redémarrage de GEA. Pas vraiment utile pour ce scénario, mais cela dit une écriture par jour, c'est pas ça qui va user la mémoire flash.
-
Et bien justement en appelant la fonction updateProperty. N'oublie pas que toutes les fonctions des QuickApps sont automatiquement exportées, donc on peut les appeler de partout. C'est très pratique et très simple au final. En LUA : fibaro.call(id, "updateProperty", "value", 123) Et on peut modifier ainsi les autres propriétés que "value", par exemple "power", "energy", "batteryLevel", etc... Note que hub.call() c'est le nouveau nom officiel à utiliser depuis le dernier firmware stable, même si Fibaro a annoncé qu'ils allaient conserver la rétro-compatibilité avec toutes les fonctions fibaro.* Via l'API : /api/callAction?deviceID=123&name=updateProperty&arg1=value&arg2=123
- 12 330 réponses
-
- 1
-
-
- support
- script lua
- (et 1 en plus)
-
Apparemment ils peuvent aussi planter. ça ne m'est jamais arrivé (ou alors je ne m'en suis jamais rendu compte...), mais sur le forum officiel j'avais vu ça... surement sur le méga-sujet de @jang relatif aux QuickApps.
-
Je crois que c'est possible en imbriquant les "Value". Un truc dans le genre : GEA.add( {"Value+", id["1er_module"], {"Value", id["2nd_module"]}}, ... A tester... EDIT : autrement si ça ne fonctionne pas, et plutôt que de passer par un QA externe, tu devrais pouvoir y arriver en pur GEA avec 2 autres méthodes : "VariableCache" "Function" EDIT 2 : Non testé, mais ça devrait fonctionner ainsi avec "Function" : GEA.add({"Function", function(a, b) return a > b end, {"Value", id["1er_module"]}, {"Value", id["2nd_module"]}}, ... Pour VariableCache, il faudra faire en 2 lignes : 1 première règle qui met la valeur du 1er module dans la variable en cache, et la seconde règle pour la comparaison entre le 2nd module et la variable en cache. Mais si ça fonctionne avec les "Value" imbriqués, c'est le plus simple.
-
Non non pas la peine de se prendre la tête, lisez bien le lien que j'ai donné, tout y est expliqué, le problème vient du serveur de mise à jour de chez Fibaro. Bref, attendez patiemment, c'est Fibaro hein, pas l'équipe de développement la plus réactive qu'on connaissance...
-
En fait c'est plus simple. Puisque justement le code original ne change pas. Pour le do end, je suppose que ça sert à créer une closure pour limiter la portée des variables locales à cette closure (dès fois que ce code soit dans un fichier qui comprend plein d'autres choses)
-
C'est assez simple (et génial) en fait ce que @jang te propose. Il redéfinie toutes les fonctions "à risque" de Fibaro dans un nouveau fichier du QuickApp. Donc à l'utilisation, ça ne change rien, tu continues à utiliser les fonctions normalement (sans t'embêter avec les pcall(), mais elles seront protégées par des pcall() quand même)
-
topic unique Fibaro RGBW Controller 2
Lazer a répondu à un(e) sujet de couillerot dans Modules Fibaro
Sinon pour l'interrupteur spécifique, j'ai retrouvé, c'était une recherche puis un tuto de @turlututu74 Mais le module RGBW doit être configuré en mode Input/Output, donc on perd la possibilité de l'utiliser simplement avec l'interface web et l'application mobile Du coup à l'époque il avait fait un Virtual Device, ça ne me plaisait pas car même ainsi, ce n'était pas intégré nativement dans l'application mobile. Avec la HC3 on doit pouvoir faire un QuickApp de type colorController et retrouver le fonctionnement natif, mais il y aura un peu de LUA à coder. ça me donne presque envie de me lancer dans l'aventure pour le ruban de ma salle cinéma.... ça fait une idée de projet pour plus tard EDIT : produit vraiment difficile à trouver. Une rapide recherche sur Amazon et Aliexpress ne remonte que des contrôleur 0-12V ou 0-24V, mais pas de simples interrupteurs 0-10V Il faudrait creuser plus la question... -
topic unique Fibaro RGBW Controller 2
Lazer a répondu à un(e) sujet de couillerot dans Modules Fibaro
Et bien ça tu l'as en fait rien qu'avec le bouton 1. Bon tu ne choisis pas directement la couleur, faut attendre pour faire défiler les couleurs, mais ça semble répondre à ton besoin. Les boutons 2 et 3 optionnels permettent de changer la saturation et la luminosité, mais c'est pas indispensable si tu laisse la saturation et la luminosité tout le temps à 100% (ou que tu les contrôle par scénario en fonction de l'heure de la journée, de luminosité ambiante, etc) Page 15 dans la doc, mais je n'ai jamais utilisé :
