Lazer

Cool ça Pour le certificat, c'est plus compliqué que ça. Le checkcertificate = false est déjà dans les options de la requête http effectuée par le code LUA Le problème, c'est la HC2 qui ne supporte pas la suite de chiffrement utilisée par Unifi. En première page j'ai donné la modification à faire sur le fichier de configuration du contrôleur Unifi, je ne sais pas si c'est valable pour l'UDM.... encore faut-il avoir accès en root au système... est-ce le cas sur UDM ?

Je ne comprends pas la difficulté ? C'est le schéma normal sur lequel tu ne branches pas l'interrupteur ! Pourquoi tu te fais des nœuds au cerveau ? C'est ce que j'ai toujours fait pour inclure mes modules à coté de la box d'ailleurs, je ne branche que Phase + Neutre

C'est bien dommage.... Espérons que ça évolue...

@971jmd GEA.add( {"SceneActivation", 87, 3}, -1, "", {{"Open", 98, 95}})  GEA.add( {"SceneActivation", 87, 3}, -1, "", {{"Open", 95, 98}})  => comportement normal et attendu, tu peux relire la doc de @pepite Donc pas de bug à ce niveau là Extrait : ACTIONS : GEA.add( {CONDITIONS}, 30, "", {"Close", 35, 20} ) - Ferme le volet ID 35 à 20 % \\Close blind 35 to 20% GEA.add( {"SceneActivation", 87, 5}, -1, "", {{"Stop", 95, 98}}) => là c'est toi qui fait une erreur de syntaxe, là encore tu peux regarder la doc. Le STOP prend un seul argument, c'est l'ID du module... il n'est pas possible de définir une valeur, puisque par définition, c'est un stop, en français un arrêt. Si tu veux spécifier 2 ID, alors il faut les mettre entre accolades, comme expliqué dans le doc Extrait : ACTIONS : GEA.add( {CONDITIONS}, 30, "", {"Stop", 32} ) - Stop le volet dont l"id" est 32 \\Stop the blind id 32 GEA.add( {CONDITIONS}, 30, "", {"Stop", {32, 33}} ) - Stop LES volets dont les IDs sont 32 et 33 \\Stop the blind id 32 and 33 GEA.add({CONDITIONS}, 30, "", {"SectionLights", "RDC", "turnOn"} ) => Là pour moi il n'y a pas de bug, es-tu certain de ton test ? En plus tu dis " éteint " alors que tu as mis une instruction "turnOn", donc je pense que tu t'es emmêlé les pinceaux.

Non désolé je ne sais pas, mais tu n'as pas répondu à ma question, es-tu certain que c'est le même port ? Mais si l'API a changé, ça va être compliqué...

Tu es certain que c'est le même port ?

Merci pour tes remontées de bugs, je regarderai ça ce soir. Si entre temps tu en vois d'autres, n'hésite pas. Mais c'est quoi ton QuickApp 160 ? La ligne 18, c'est du commentaire dans GEA, donc ça ne peut pas être un crash de GEA.... c'est forcément un autre de tes QuickApps qui plante. Quand tu regardes la fenêtre de debug, il faut que tu filtres les messages pour n'afficher que le QuickApp en cours de debug En ce qui concerne QA_GEA_213, tout est normal dans ton screenshot, donc tout bon Pour les SceneActivation, c'est étrange tes lenteurs, je n'ai rien constaté de tel dans mes essais, et surtout il n'y a aucune raison pour laquelle les SceneActivations seraient plus lents que les autres triggers.

Ah... les bonnes manières... tout un programme Il a pris LUA en langue vivante, il est promis à un brillant avenir

Nickel, voici la version 7.01 avec ce bug corrigé. Par contre je ne m'explique pas.... je pense que ce bug devait également exister avec GEA v6 sur HC2. PS : ce n'est pas le QuickApp complet, juste le code du fichier main à copier/coller à la place du tiens. Ainsi, cela ne touche pas à ton fichier config qui contient tes règles utilisateurs. GEA v7.01.lua

Quelle présentation.... surprenante

OK, mais euh.... main.lua => ligne 18 => c'est du commentaire, donc impossible d'avoir un crash LUA sur cette ligne là Remet le code officiel que j'ai partagé STP, ensuite relance ton test, et dis moi sur quelle ligne apparait réellement l'erreur.

Bienvenue sur le forum

Hum, encore une fois, je ne vois pas bien où tu positionnes ton code LUA... .Je ne vois rien qui ressemble à des règles GEA.add() Toi t'es encore en train de jouer à l'apprenti sorcier Il n'y a vraiment rien de compliqué, rien ne change par rapport à GEA pour HC2, sauf qu'il n'y a plus besoin de spécifier les triggers (déclencheurs de scènes)... Justement parce que ce n'est pas une scène ! D'ailleurs à ce sujet je me demande bien pourquoi tu mets des conditions = {...} Bref, rien de compliqué, mais là tu ajoutes de la complexité tout seul PS : merci pour le retour sur le fonctionnement de "Protection"

"Protection" y est bien, mais je ne l'ai pas testé, donc si tu le fais tu me diras si c'est OK ou non. D'ailleurs je pense que tu devrais commencer par tester les fonctionnalités standard de GEA pour te faire la main, et valider le bon/mauvais fonctionnement de cette version que je qualifie encore de Beta. sceneActivationEvent fonctionne, je l'ai testé. Tu peux partager ton code, et éventuellement le message d'erreur ? Ensuite, "Telegram" n'est pas une option standard de GEA. Il s'agit d'un usage particulier dont tu as le besoin. Et je n'ai pas de compte Télégram pour tester.... Donc le process est simple : tu développe ton option en utilisant un QuickApp et en mettant ta règle dans le fichier "config" (et non pas "main"), et si ça marche bien et que la demande des utilisateurs est là, on pourra l'intégrer dans le code standard de GEA.

J'ai toujours grillé les feux rouges, et je suis toujours en vie. Est-ce une raison pour continuer ? Désolé pour le parallèle douteux, mais si tu veux que je t'aide, fait au moins l'effort de respecter la règle... qui est simple en plus.. et pour ton propre bien. Désolé je n'ai pas le temps, et aucune envie, d'auditer ton code personnalisé. C'est in-maintenable avec les prochaines mises à jours.

Bienvenue sur le forum

Il est très facile de convertir une scène HC2 vers une fonction dans un QuickApp HC3, la logique du code asynchrone est la même, les fonctions http:request() sont les mêmes, etc. La récupération d'argument est encore plus simple puisqu'on les spécifie directement dans la définition de la fonction. La possibilité d'organiser son code en différents "fichiers" est aussi un énorme plus, pour se faire des librairies de fonction, ou comme dans le cas de GEA for HC3, de séparer le code utilisateur (n'est ce pas @971jmd ). Ca facilite la compréhension, et ultérieurement les mises à jours, puisqu'il suffira de copier/coller le nouveau code LUA du code principal (main) sans toucher au code utilisateur. Il n'y a que les triggers qui manquent dans les QuickApps, comme pour GEA, où j'ai dû utiliser l'API refreshStates à la place, dans une boucle. On verra à l'usage, mais ça semble bien fonctionner. A vrai dire, sur HC3 il n'y a pas vraiment de limitation... ou disons plus plutôt que les limitations qu'on a connu sur HC2 sont levées. Au fait, dans le futur Fibaro ajoutera l'import et la mise à jour automatique de QuickApps depuis le market (comme sur les solutions concurrentes....), donc l'avenir est vraiment aux QuickApps chez Fibaro. Bref, désolé du semi-HS sur ce topic dédié Support GEA, j'avais justement ouvert un topic à coté pour discuter des développements à faire pour "convertir" nos VD+Scènes HC2 en QuickApps HC3.

@971jmd non désolé ce n'est pas la bonne méthode, ni sur HC3, ni sur HC2 d'ailleurs Il ne faut pas toucher au code de GEA Ton option personnalisée doit être dans config() comme expliqué dans mon message précédent Par ailleurs ton numéro de ligne ne sert à rien, à partir du moment où tu as modifié le code de GEA, impossible de comprendre/reproduire chez moi. Commence donc par remettre ta config au propre, tu ne modifies que le fichier config du QuickApp comme expliqué dans le tuto, dans les fonctions config() et setEvents() De toute façon, il faut que tu commences par convertir ta scène dans un QuickApp distinct, qu'on pourra appeler par sa fonction, comme je le disais là aussi dans mon message précédent. @pepite : merci

@pepite Je pensais mettre à jour le fichier Syntaxe, mais si tu es motivé, je te laisse faire Normalement GEA.options est toujours OK : à configurer dans le fonction config() comme avant. Cependant je ne l'ai pas testé... si tu as un exemple concret d'option personnalisée à me donner, je le testerai. Là où ça se complique réellement, c'est que fibaro:args() n'existe pas sur HC3, et globalement tout ce qui touche aux scènes. Clairement, les scènes sur HC3 n'ont aucun intérêt, à part pour faire 2 ou 3 clics en mode bloc. Même quand on écris une scène en LUA, il est impossible de lui passer des arguments (ou alors je n'ai pas trouvé.... et ce n'est pas documenté). Pour moi cette fonctionnalité n'existe plus. Donc pour tout ce qui est écriture de code LUA, il faut utiliser les QuickApps et abandonner les scènes. C'est mon avis. En QuickApp, au contraire, ça devient très simple. Il suffit d'écrire la fonction de son choix, avec tous les arguments nécessaires. Sachant qu'on peut appeler n'importe quelle fonction publique d'un QA depuis un autre QA, c'est juste parfait. fibaro.call(ID_du_QA, "nom_de_la_fonction", argument1, argument2, ...) @971jmd Ton bloc telegram = {name="Telegram", ... tu le positionnes où dans ton code ? Là je ne vois pas. Comme je viens de dire à @pepite, normalement il est censé être dans la fonction options() Et donc il devrait commencer par GEA.options.telegram = {...} sinon je ne vois pas comment il pourrait le prendre en compte. J'espère juste que tu ne modifies pas directement le code de GEA, il ne faut surtout pas, sinon tu ne pourras plus installer les mises à jours. J'ai justement séparé exprès le code GEA du code utilisateur dans 2 fichiers distincts. Concernant ta scène, en vertu de ce que j'ai répondu à @pepite tu comprends bien que ce n'est plus possible. Il te suffit donc de mettre ton code LUA dans une fonction d'un QuickApp, puis il suffit d'appeler cette fonction depuis GEA. Pour simplifier, dans ton option telegram, au lieu d'appeler fibaro:startScene(), tu utiliseras fibaro.call() PS : vu que tu me présentes directement un cas compliqué, quelque part ça me rassure, ça veut dire que toutes les règles usuelles ont fonctionné du premier coup chez toi ?

Voici une première version beta de GEA pour HC3 : On conserve ce topic-ci pour le support sur la syntaxe et l'écriture des règles GEA.add(...)

Et voilà, amusez-vous bien

QuickApp "GEA Alarm" lié à GEA Ce QuickApp Alarme pour HC3 remplace les modules virtuels Alarme de @Steven et MultiAlarme de @drboss sur la HC2. Il faut importer autant de fois le QuickApp que nécessaire, et il permet de programmer un réveil simple ou des réveils multiples : Exemple avec horaires différents pour la semaine et le week-end : On peut ainsi programmer une semaines complète avec 7 horaires différents si on le souhaite. Cela permet de modifier à tout instant l'heure des scénarios depuis le QuickApp sans avoir à modifier la configuration de GEA, simplement depuis l'interface Web ou l'application mobile. Le QuickApp fonctionne ainsi : H+ / H- = Ajoute / enlève une heure [ ] = désactive l'heure M+ / M- = ajoute/enlève une minute Lu, Ma, Me, Je, Ve, Sa, Di = Active ou désactive le jours en question Choix Alarme : permet de sélectionner le réveil à régler Le choix du nombre de réveils se fait en modifiant la variable "Nombre_Alarme" dans le QuickApp : (ne pas toucher aux autres variables _HeureX et _JoursX situées en dessous, elles seront automatiquement créées ainsi que les labels) Utilisation dans les scénarios GEA : -- Syntaxe : {"Alarm", <id_qa>} -- Vérifie si la période (jour et heure) configurée sur n'importe quelle alarme de GEA_Alarm est atteinte {"Alarm", <id_qa>, <id_alarme>} -- Vérifie si la période (jour et heure) configurée sur l'alarme spécifiée de GEA_Alarm est atteinte -- Exemples : GEA.add( {"Alarm", id["QA_ALARM"]} , 0, "Debout fainéant", {{"TurnOn", id["LUMIERE"]}, {"Open", id["VOLET"]}}) GEA.add( {"Alarm", id["QA_ALARM"], 2}, 0, "Debout fainéant", {{"TurnOn", id["LUMIERE"]}, {"QuickApp", id["PLAYER"], "play"}}) id["QA_ALARM"] est l'identifiant du QuickApp GEA Alarme Il est possible d'avoir plusieurs GEA Alarm puisque chacun est identifié par son... identifiant ! Astuce : on peut modifier les programmations horaires depuis GEA à l'aide de la fonction setTime() : -- Réglage de l'heure de l'alarme n°2 sur 22h22 : GEA.add( {CONDITION}, 30, "", {"QuickApp", id["QA_ALARM"], "setTime", 2, "22:22"}) -- Désactivation de l'alarme n°2 : GEA.add( {CONDITION}, 30, "", {"QuickApp", id["QA_ALARM"], "setTime", 2, "--:--"}) Icones : Le QuickApp est de type "binary sensor", ainsi on peut configurer 2 icônes pour identifier d'un coup d’œil si un réveil est actif (= horaire programmé) ou non : Téléchargement  GEA_Alarme_v2.10.fqa

GEA Gestionnaire d’Événements Automatique Version 7.38 Voici le célèbre GEA de @Steven porté sur Home Center 3. Cette version de GEA est basée sur la version 6.13, les fonctionnalités sont donc identiques, à quelques différences près documentées plus bas. Ce n'est plus une scène, mais un QuickApp. La notion d'instances multiples des scènes n'a plus lieu d'être, car le QuickApp est mono-instance par nature, mais son principe d'exécution asynchrone du code LUA permet d'obtenir le même résultat, à savoir : - une boucle automatique de détection des événements à intervalle régulier de 30 secondes - un déclenchement instantané sur événement (avec le paramètre -1 pour la durée) Au sujet des événements, il n'y a plus besoin (et de toute façon il n'est pas possible) de définir des triggers pour le déclenchement. C'était une opération fastidieuse, car il fallait saisir manuellement les ID des modules dans l'en-tête de la scène. Cette nouvelle version de GEA détecte donc automatiquement les triggers, et surveille les événements via l'API refreshStates. Actuellement j'ai positionné cet intervalle de surveillance à 100 ms, c'est à dire un dixième de seconde. Ce n'est donc pas de l'instantanéité absolue, mais ça ne l'était de toute façon pas sur les scènes de la HC2, et ça reste inférieur au seuil de perception humain. Pour l'instant cela n'a posé aucun problème de performance lors de mes tests.... on verra ultérieurement s'il y a lieu de faire évoluer cet intervalle. La syntaxe de GEA est strictement identique à celle de la HC2 : GEA.add( ... ) Pour cette raison, ce topic est ouvert uniquement pour les discussions concernant le développement de GEA, les nouvelles fonctionnalités, et les rapports de bugs constatés. Pour les questions sur l'utilisation et la syntaxe de GEA, se reporter au topic unique "Support GEA" où vous trouverez toute l'aide nécessaire : En clair : Une règle GEA fonctionne sur HC2, mais ne fonctionne pas sur HC3 => je viens poster ici pour qu'on puisse corriger le bug Autrement : je supprimerai les messages sans préavis, j'ai autre chose à faire que de déplacer les messages postés sur le mauvais topic... avis aux contrevenants Le topic de référence concernant la syntaxe de GEA se trouve ici, comme d'habitude : Remarque : j'ai mis à jour le fichier de référence GEA_Syntaxe à télécharger en bas de ce message. Changements de GEA pour HC3 par rapport à HC2 Supprimé : "VirtualDevice", "VD" => remplacé par "QuickApp" et "QA" "SetrunConfigScenario" => remplacé par "SetRunModeScenario" et "RunModeScene" "RebootHC2" => remplacé par "RebootHC3" "ShutdownHC2" => remplacé par "ShutdownHC3" "multiAlarm" => remplacé par "Alarm" "setMode" => remplacé par "ThermostatMode" "setThermostatSetpoint" => remplacé par "CoolingThermostatSetpoint" et "HeatingThermostatSetpoint" "ThermostatLevel" "ThermostatTime" "DebugMessage" "PluginScenario" "Popup" Ajouté : "QuickApp" | "QA" : {"QuickApp", <id_module>, <méthode>, [paramètres]} "DeviceIcon" | "CurrentIcon" : {"CurrentIcon", <id_module>, <no_icon>} "Color" | "RGB" : {"Color", <id_module>, <intensité_rouge>, <intensité_vert>, <intensité_bleu>, <intensité_blanc>} "RunModeScene" | "SetRunModeScenario" : {"RunModeScene", <id_scene>} | {"SetRunModeScenario", <id_scene>, <run_valeur>} - <run_valeur> : "manual" | "automatic" "isSceneRunning" | "RunningScene" : {"isSceneRunning", <id_scene>} "ThermostatMode" : {"ThermostatMode", <id_thermostat>, <mode>} "ThermostatFanMode" : {"ThermostatFanMode", <id_thermostat>, <fan>} "CoolingThermostatSetpoint" : {"CoolingThermostatSetpoint", <id_thermostat>, <valeur>} "HeatingThermostatSetpoint" : {"HeatingThermostatSetpoint", <id_thermostat>, <valeur>} "Profile" : {"Profile", <id_profil>} "RebootHC3" : {"RebootHC3"} "SuspendHC3" : {"SuspendHC3"} "ShutdownHC3" : {"ShutdownHC3"} "Parameter" "Climate" "Breached" "VariableQuickApp" | "VariableQA" "CustomEvent" "WOL" "httpGet" "Call" "isEvenDay" Modifié : "Armed", "Disarmed", "setArmed", "setDisarmed" => Prend l'ID de la zone Amélioré : GEA.portables = {123, "Nokia 3310"} : ID du mobile, ou nom du mobile "Email" : ID du mobile, ou nom de l'utilisateur : {"Email", <id_user>, <"Message du mail">, <"Sujet du mail">} | {"Email", <id_user>, <"Message du mail">} "Picture" : ID ou nom de l'utilisateur : {"Picture", <id_camera>, <id_user>} | {"Picture", <id_camera>, <"nom_user">} "VariableCache" : utilisable dans les règles à déclenchement instantané avec -1 (en tant que condition, actions, mais pas comme déclencheur) "Alarm" : remplace "Alarm" et "MultiAlarm" : peut contenir autant d'alarmes que voulu "Ask" : exécute une scène, une méthode d'un QuickApp, ou une action GEA Les zones d'alarme, les profils, et les zones de climat peuvent être identifiés par leur nom Note : les actions "Reboot", "Suspend", et "Shutdown" ne fonctionnent plus depuis le firmware 5.050.13... Installation Importer le fichier fqa ci-joint. Ne modifier que le contenu de config pour vos propres règles : Mise à jour Copier/coller simplement tout le contenu du fichier LUA téléchargé dans le fichier main du QuickApp. Téléchargement Nouvelle installation : GEA_v7.38.fqa Mise à jour : Fichier main : GEA v7.38.lua Fichier tools : Library - tools v2.30.lua Documentation de référence sur la syntaxe : GEA v7.38 Syntaxe.lua

Bienvenue sur le forum

Oui tu as raison. Les intégrateurs, les vrais pros de la domotique (pas les électriciens/poseurs d'alarme et de volets qui installent 1 box domotique tous les 2 mois), font du KNX. C'est cher, valable uniquement en construction/rénovation lourde (donc cher aussi !), du coup le marché ne se développe pas (particulièrement en France) Les trucs pour le grand public vendus sur les étagères de la Fnac ou de l'AppStore pour la famille Michu, j'appelle pas ça de la domotique perso... Mais des objets connectés. Donc oui la domotique est un marché de niche, et le restera très longtemps. Soit tu veux un système fermé qui ne fait rien à part allumer les lumières depuis ton smartphone comme dans les publicités débiles, soit du veux une vraie domotique "intelligente" (ce terme ne veux rien dire, il vaut mieux parler de maison autonome, c'est à dire une maison bourrée de capteurs qui sait réagir seule aux différents événements)., dans ce cas pas le choix que de nous tartiner la configuration à la main. Rien n'existe sur l'étagère, et la domotique avancée restera longtemps un marché de niche pour geeks. J'ai coutume de comparer la domotique avec l'informatique.... des années 80/90 ! Parce que c'est bien là qu'on en est, c'est à dire avant l'an 2000 de l'informatique, l'explosion d'Internet, l’interopérabilité de tous les ordinateurs autour d'un réseau commun. La domotique, c'est le DOS des années 80, se tartiner des commandes à la main avec des profils config.sys personnalisés en fonction de l'usage car 640k de mémoire c'est pas assez. C'est le Windows des années 90 où chaque nouvelle version impose un reformatage complet de son système. C'est le Linux des années 90/2000, se recompiler des noyaux la nuit si tu veux intégrer le driver du dernier périphérique à la mode. Le document Office qui ne peut être ouvert sur autre chose que Office lui-même. Etc.... Tu m'étonnes que ça ne décolle pas ! Dans 10 ou 20 ans, on en reparlera. Ce qui me désole, c'est que ça fait 7 ans que je fais de la domotique, ça n'a pas évolué d'un pouce. Le Zigbee cartonne, alors qu'il est moins évolué que Z-Wave. EnOcean est un échec cuisant. Les tentatives de standardisation type OpenThread ont fait plouf. La mode est aux objets et modules connectés sur Wi-Fi.... youhou, on est vachement avancé avec ça... Bref, ce débat on l'a déjà eu 100x sur le forum, et les autres forums, rien de nouveau.... fait ton choix de "centrale domotique" en fonction de tes besoins, de tes compétences, du temps que tu es prêt à y consacrer, etc Perso comme dit, je reste chez Fibaro car c'est un environnement que je maitrise, j'en connais les limitations, mais surtout il est stable, c'est plus important que de pouvoir intégrer le dernier objet à la mode à mes yeux.