Lazer

Good idea GEA can also react to customEvents.

Variable Globale ou Locale au QA e ne change rien pour GEA, il sait traiter les 2. De manière générale, j'ai tendance à dire qu'on doit restreindre la portée des variables au strict nécessaire (même concept que la programmation), donc plutôt variables dans le QA. Mais dans ce cas précis, tu auras une seule instance du QA Dawn and Dusk (en avoir plusieurs n'aurait aucun sens), et ce sont des données météo, donc plutôt globales à toute la domotique... par conséquent ça aurait du sens de stocker ces valeurs dans des VG. Par ailleurs, ça simplifie leur utilisation, que ça soit depuis GEA ou une autre scène, une VG est accessible directement, tandis que pour accéder à une variable de QA il faut déjà connaitre son ID, donc un peu moins pratique. De plus, GEA sait accéder nativement aux variables des QA, mais ce n'est pas le cas du LUA standard qui serait utilisé dans une autre scène/QA (Fibaro ne propose pas (encore ?) de fonction permettant de lire une variable dans un autre QA... mais seulement dans le QA actuel) Du coup, pour ton usage, des variables globales me semblent tout indiquées.

Créer des propriétés personnalisées dans un QA n'est pas supporté (il me semble cependant que c'est possible via un hack) A la limite, je pense que le moins pire dans ton cas, pourrait être de créer 4 QA children, de type multilevel sensor, et de stocker le timestamp de l'heure dans la propriété "value". ça ne sera pas très beau dans l'interface, mais à la limite tu caches ces QA children, mais leur valeur sera parfaitement récupérable et exploitable dans GEA. Mais je ne sais pas si cela sera pas utilisable dans les scènes blocs Ou bien tout simplement stocker ces valeurs dans des variables globales.... et garder des labels dans le QA si l'utilisateur veut visualiser ces informations facilement. EDIT : ou des variables locales du QA

Dans le code source de GEA (fichier main, tout en bas), tu trouveras un exemple simple et fonctionnel

Le 3ème fil normalement c'est pour le tachymètre, donc le retour de la vitesse de rotation du ventilateur sur la carte mère. Soit pour surveiller que que le ventilo tourne toujours.... soit pour vérifier qu'il tourne bien à l'exacte vitesse attendue ! C'est par exemple le cas sur le célèbre petit MicroServer d'HPe, ce qui rend le remplacement du ventilateur extrêmement compliqué (la machine refuse de booter). Cela ne semble pas être le cas pour l'onduleur Eaton, il n'y jamais râlé. PS : ne cite pas le message précédent le tient (surtout 2 fois de suite), ça ne sert à rien et alourdi la lecture.

Je pense que ce sont des sous-versions commercialisées à tel ou tel constructeur. La référence qu'on trouve dans la datasheet serait la version disponible librement sur le marché, et les autres références des dérivées sur commande spéciale. Mais bon, comme tu dis, on n'est sûr de rien... tu vois la difficulté de remplacer ce ventilateur dans les règles de l'art.

@henri-allauch ça donne quoi chez toi ? De mon coté ça tient depuis hier sans plantage. En parallèle, mon watchdog est déjà fonctionnel, il faut maintenant que je fasse de la cosmétique pour le rendre partageable.

Faut quand même que tu aies compris le mécanisme des appels asynchrones, car tu vas devoir les enchainer entre chaque écriture, puis lecture, de trames.

Pour les gaines, oui plan obligatoire. Le mieux, ce que j'avais fait : photos AVANT de poser les plaques de BA13, avec un mètre ruban. Comme ça le jour où tu devras percer pour retrouver la gaine planquée derrière, tu n'auras qu'à regarder ta photo, mesurer pareil, et tu tomberas pile dessus au centimètre près. L'Atmos c'est un peu la base d'un home-cinéma moderne non ? (quoi que... faut regarder les films en VO, les pistes son en VF doivent se compter sur les doigts d'une main) J'ai 10m², j'ai mis 2 enceintes au plafond, c'est déjà sympa. Si j'avais eu 20m², j'aurais peut être tenté 4 enceintes (mais ça dépend surtout de la disposition de la pièce, faut qu'elle soit suffisamment en longueur pour pouvoir mettre le canapé aux 3/4 et garder de l'espace derrière, sinon ce n'est pas la peine)

Ouais faites gaffe. Les têtes Danfoss, je crois bien qu'elles sont de type thermostat dans la HC2 J'ai un SRT321 et un ZXT-120, pas envie de prendre de risque pour l'instant....

Mon QA est largement plus compliqué, tu risques de ne pas t'en sortir si tu ne commences pas par un exemple simple comme dans le tuto

Alléluia le correctif pour YR Weather Bon par contre... euh... le coup des thermostats... ça me refroidit

OK, je regarderai ça

ça c'est curieux, je n'arrive pas à reproduire le message d'erreur, même avec une table vide comme toi. Apparemment ce message d'erreur apparait en fonction du paramétrage du serveur SQL. Tu utilises MariaDB sur Synology ou autre chose ? Quelle version ? Et si tu remplaces 1 par date dans la clause GROUP BY, ça fonctionne ? Je ne me souviens plus pourquoi j'ai mis 1 à vrai dire... donc erreur ou bonne raison, mystère. EDIT : avec juste date il dit que c'est ambigu, donc il faut l'écrire ainsi : GROUP BY DATE(r.time), device_id EDIT 2 : bon bah du coup je sais pourquoi j'ai mis 1, ça désigne le 1er champ SELECT, donc c'est censé être identique à la syntaxe que je viens de donner juste au dessus. EDIT 3 : j'aurais dû commencer par lire le message d'erreur, ce qui ne lui plait pas c'est le t1.max_value issu de la sous-requête.... mais je ne comprends pas trop pourquoi... EDIT 4 : essaye comme ceci, sans garantie (puisque je ne peux pas reproduire sur mon serveur SQL) : GROUP BY 1, device_id, 6

Tu peux partager les lignes en question ? Je m'en servira pour reproduire le problème.

Non, c'est le principe même de la vérification, elle est effectuée avant la première exécution des règles. ça ne gêne pas de désactiver cette vérification pour le bon fonctionnement de GEA, le seul souci étant que tu peux passer à coté d'autres "vraies" erreurs potentielles dans d'autres de tes règles GEA.

Oui c'est normal, je t'avais expliqué pourquoi. Sinon en alternative, il faudrait peut être utiliser une variable globale à la place, car les VG sont persistantes, du coup la valeur du profil mémorisé sera correctement initialisé lors du démarrage de GEA, permettant de valider les vérifications du lancement.

Bienvenue sur le forum

On peut s'en servir pour protéger différentes parties du code, mais j'ai envie de dire que c'est obligatoire pour 2 fonctions natives : http:request(), et json.decode() tant ces 2 fonctions ont la fâcheuse habitude de crasher. Et c'est visiblement amplifié avec la dernière Beta.

Tiens voici Attention c'est une BETA, avec beaucoup de traces de logs codées en dur, à installer uniquement pour test Netatmo_2.6_BETA.lua

GEA peut planter, il peut y avoir des bugs, notamment dans la détection des conditions. Mais les actions qu'il réalise sont assez basiques, il se contente d'appeler les actions standards sur les modules via l'API fournie par Fibaro. Du coup quand une action fonctionne sur un module (Z-Wave physique) mais pas sur un QuickApp, c'est que le problème se situe probablement dans le QuickApp de l'utilisateur. Et c'est là toute la magie et la difficulté des QuickApps sur HC3, ils permettent une intégration native dans la box, mais encore faut-il les programmer correctement et penser à tous les cas de figure. Pas toujours simple.

Mais c'est quoi ce QuickApp ? Un QA que tu as créé toi même ? En tout cas, je comprends mieux pourquoi ça ne fonctionne pas. GEA appelle setValue(), et le code de cette fonction setValue ne fait rien du tout (à part mettre à jour le champ value) Je suis pas sûr, mais je pense qu'il faudrait appeler la fonction fcCommands, puisque c'est ce qui est fait dans les fonctions open() et close() Désolé, c'est définitivement HS ici, sur le topic de GEA. PS : Et je maintiens ce que j'ai fait tout à l'heure, si tu fais glisser le slider de ton module volet roulant, que ça soit depuis l'application mobile ou l'interface Web, je vois pas bien par quelle magie ça pourrait agir sur le volet à la lecture du code. Alors c'est sûr, si tu fais juste un open/close complet, ça marche, mais ça limite l'usage.

Bon j'avance, j'ai découvert que le QA plante lors de l'appel http:request() Donc je l'ai modifié pour faire comme dans tous mes QA : pcall() pour protéger l'exécution, et déclaration de la variable http en self.http comme conseillé par Fibaro, et confirmé par nos récents tests avec @henri-allauch On verra comment ça se passe dans les heures qui viennent. L'avantage des firmwares Betas, c'est que ça nous force à écrire notre code LUA plus proprement... ça me rappelle vaguement les heures sombres de la v4 betastable Et dire que j'ai installé cette beta juste pour le correctif de la météo YR Weather, en conséquence ça fait planter la météo Netatmo, c'est comique. PS : j'aime beaucoup mon statut de Newbie 1 étoile sur le forum officiel

Perso je n'ai pas le temps de relire et modifier ton code, mais une piste quand même : sur HC3 les accès réseaux sont asynchrones (comme pour les scènes sur HC2 d'ailleurs). Tu peux regarder ce tuto pour des requêtes HTTP, le principe est le même pour TCP : Et en complément, en pratique tu as mon QuickApp Onduleur Eaton sur le forum, qui utilise des requêtes TCP pour le protocole SNMP, ça pourrait te servir d'exemple :

Il faut cliquer sur le bouton - en haut de la page Et c'est normal, il faut recliquer dessus si tu quittes la page des dispositifs et que tu retournes dessus ensuite.