Lazer

Pour "Program" : Je te suggère de supprimer les 2 lignes suivantes de la syntaxe : {"Program+", <id_module>} {"Program-", <id_module>} Qui sont techniquement possibles, mais n'ont aucun intérêt en pratique... qui aurait le cas d'usage d'aller comparer si le programme n°X est supérieur/inférieur à la valeur Y.... ça n'a juste aucun sens.... ça n'est pas comme comparer une Value (de luminosité, de température, de puissance, etc)

OK, ton retour d'expérience ne m'étonne pas du tout. Sur forum-photovoltaique.fr, un gars avait fait un test pendant plusieurs jours avec et sans le profil zéro-injection, et la différence était énorme. Et quand on y réfléchi c'est logique, la passerelle n'a pas la possibilité de communiquer en temps réel avec les micro-onduleurs pour leur donner au 1/10ème de seconde près la consigne de production / écrêtage. Enphase, par le biais de l'un de ses employés qui officie sur le même forum photovoltaïque, avait confirmé que le profil zéro-injection d'Enphase est extrêmement conservateur, c'est à dire qu'il garantie qu'il y aura réellement zéro injection, quitte à faire l'inverse même, d'où les 10 Watts dont tu parles, qui sont en fait soutirés du réseau (car la meilleure façon de ne pas injecter reste encore... de soutirer.... quel gâchis) Du coup, entre ces 10 W consommés inutilement, et le défaut de réactivité de la communication Envoy / IQ7, font que les pertes de production sont assez importantes.... Il y a quelques pages, je m'insurgeais contre les pratiques de notre distributeur Enedis en France, ça prend tout son sens. Dans le reste de l'Europe et du monde, les règles des différents distributeurs sont assez variables, certains sont plus intelligents, et d'autres encore plus débiles... Là où Enphase est malin, c'est avec le profil 3 kW qui je pense a été développé spécifiquement pour la France, puisque la loi française (et contrairement à ce que prétend Enedis), autorise une injection de 3 kW. Je pense que cela permet de bénéficier du meilleur des 2 mondes : ne pas perdre de production solaire, et ne pas perturber le réseau Enedis. Bref, ma recommandation, c'est de ne pas faire de zéro-injection, c'est crétin pour plein de bonnes raisons techniques et écologiques. Utiliser le profil 3 kW me parait être la solution la plus pertinente. Ou bien le profil par défaut, on injecte tout le surplus, ça permet de bénéficier à tous les citoyens (enfin, les voisins en premier), particulièrement important en cette période de crise énergétique, pénurie, et transition énergétique. Car tout électron produit avec le solaire ne le sera pas avec du gaz, charbon, ou pétrole... c'est toujours ça de gagné.

Ah oui si tu changes le profil uniquement dans les options de l'application ça n'a pas d'effet. Tu as mis lequel du coup ?

ça c'est top le coup du laisser appuyé en complément de l'appui court "normal" Espérons qu'ils ne mettent pas 6 mois à sortir la prochaine version, car ils sont moins rapides pour développer l'app que la box, et c'est rien de le dire...

Lorsque tu cliques sur le bouton "-", au lieu de choisir Z-Wave ou Zigbee dans le popup qui s'ouvre, tu choisis "Autre appareil". Il va alors te mettre sur l'onglet des QuickApps. Mais tu cliques sur l'onglet Tout, Z-Wave, Nice, Elero ou Zigbee et tu pourras supprimer les modules que tu veux avec la corbeille (essayer de supprimer le module parent en 1er me parait préférable, pour cela il faut cocher la case "Voir ce qui est masqué") Exemple avec un FGMS qui n'a plus de pile (nœud mort).... je n'ai pas cliqué en vrai car je vais lui remettre des piles :

Je pense qu'il faut que l'application Toolkit soit connectée à la passerelle Envoy (et pas juste au Wi-Fi de la maison)

Je n'ai pas changé le profil, uniquement injecté la 1ère fois. Et je sais que le profil n'est injecté vers le micro-onduleur que si la communication CPL est correcte (et qu'il y a du soleil pour alimenter l'onduleur via le panneau) Du coup je suppose que pour changer le profil c'est pareil, dans l'application Toolkit, et il va le pousser vers les micro-onduleurs avec lesquels il communique... ça prend quelques minutes.

Si, mais est-ce pertinent ? Alourdir la doc de trucs évidents ce n'est pas forcément pertinent... sinon tu vas devoir le faire pour l'ensemble des options qui proposent de comparer la valeur avec les paramètres + - et ! Une fois qu'on a compris et décrit le principe avec l'option la plus utilisée "Value", "Value+", "Value-", "Value!", c'est bon, les gens ont saisit la logique. Crée des QuickApp thermostats dans la HC3 et tu vas comprendre la différence entre les 2. Heating et Cooling sont les opposés, l'un pour chauffer, l'autre pour climatiser. Tout ça en coordination avec le panneau de climat (qui n'a plus grand chose à voir avec le panneau de chauffage que tu as connu sur HC2) Non parce que justement il faut spécifier si on parle de la consigne de chauffage ou de climatisation. Cela correspond à des types de modules bien spécifiques, avec des propriétés différentes. Et bien non justement, en vertu de ce que j'ai écris au dessus. Il faut que tu prennes le temps de créer plein de QA bidons, de chaque type, regarder leurs propriétés (JSON), tu verras les différences et tout ce que ça implique. Les différents types de thermostats sont particulièrement intéressants, ça n'a plus rien à voir avec ce qu'on a connu sur la HC2.... c'était tout pourri en comparaison. Disons plus "limité" (c'est moins politiquement incorrect)

ça dépend de la télécommande utilisée. Par exemple sur une Remotec ZRC90 j'utilise les keyAttribute suivants : Pressed Pressed2 HeldDown Les noms parlent d'eux même. Comme souvent pour connaitre les valeurs disponible, il faut aller voir le JSON du module via l'API : "centralSceneSupport": [ { "keyAttributes": [ "Pressed", "Released", "HeldDown", "Pressed2" ], "keyId": 1 }, { "keyAttributes": [ "Pressed", "Released", "HeldDown", "Pressed2" ], "keyId": 2 }, On voit bien les valeurs possibles pour chaque bouton keyId de la télécommande, autant qu'il y a de boutons.

Donc ne la change pas. Perso je ne la maitrise tout simplement pas du tout... encore une de plus !

Vu que ces 2 options sont codées différemment en LUA, elles doivent avoir des différences... probablement assez subtiles. Je m'abstiens donc de les fusionner. Si tu es curieux tu peux regarder le code de GEA, dans le fichier main du QuickApp. Et voilà encore 2 options que je n'ai jamais utilisé !

Les filtres possibles sont ceux de la box Fibaro, donc il faut être très rigoureux dans la syntaxe. En théorie je suppose qu'on peut ajouter turnOn, tu devrais le tester avant de l'ajouter dans la doc. Mais attention, pas TurnOn et TurnOff (à cause de la majuscule) Voilà typiquement une option que je n'ai jamais utilisé...

En fait les exemples sont complets, il n'y a rien de plus à ajouter. Le paramètre est juste un nombre, qui donne le numéro du programme à exécuter. On les retrouve dans l'API JSON du module : Ou bien plus simplement dans l'interface Web, dans l'ordre : Par exemple le programme n°5 c'est la police, ça fait son petit effet en cas d'intrusion

Ne pas oublier de cliquer sur le bouton "-" avant :

Ce qui serait plus logique je pense, c'est de pouvoir fixer l'unité sur le litre. Ainsi il serait pris en charge par GEA comme un compteur d'eau (ce que c'est en réalité) et affiché dans le graph idoine. Le seul souci, c'est que je ne pense pas que tu puisses changer le ratio de l'entrée analogique du module RGBW. Par exemple, afin que 100% corresponde à .... disons 1234 litres si ta cuve fait ce volume. Sinon il faudrait passer par un QuickApp intermédiaire avec le bon type et la bonne unité, qui fait la conversion propre.

Il faut bien comprendre que plusieurs options ont été créées par Steven à la demande des utilisateurs... donc parfois une option a été utilisée par une seule personne, et qui a peut-être quitté le forum entre temps. Lors du portage sur HC3 je me suis efforcé de garder le maximum d'options par souci de rétrocompatibilité, mais ça ne veut pas dire que c'est utile. Les rares options qui ont disparu, sont celles spécifiques à la HC2 et qui n'ont plus lieu d'être sur HC3. Ou bien elle ont été remplacé par un équivalent adapté à la HC3. La 1ère page du topic résume ces changements. Bref, si tu veux vraiment te pencher sur l'utilité et les cas d'usage de chaque option, il faudra que tu fouilles le forum, tu trouveras les réponses dans les profondeurs des quelques sujets dédiés à GEA. C'est le cas de la fonction StringToAlpha de MAM78, mais aussi de OnOff, etc... perso je ne les ai jamais utilisé. Oui évidemment, sinon il ne se passera jamais rien.

Et oui, c'est d'un pénible.... Comme beaucoup de choses sur cette application... J'ai peur que la seule solution soit de s'y habituer, vu que Fibaro considère que c'est une nouveauté et que c'est mieux ainsi. Tu peux toujours tenter de les harceler...

@jojo j'ai déplacé tous tes messages ici, et non pas sur le topic du Support GEA, car je considère que ce sont des questions d'intérêt général liées à la rédaction de la documentation de GEA. Je répondrai à celles qui sont pertinentes et/ou pour lesquelles j'ai une réponse à apporter. Les questions du type "à quoi sert cette option" seront ignorées, en principe du bon vieux "si tu ne sais pas ce que c'est, alors c'est que tu n'en as pas besoin"

"performance" c'est un terme générique qui ne veut pas dire grand chose si on ne précise pas le contexte. 2 exemples : si on cherche à réduire l'utilisation CPU de la box, alors il vaut mieux ne pas utiliser de déclenchement instantané (avec durée = -1), car c'est plus ou moins l'équivalent de démarrer une nouvelle instance de GEA (un peu comme une nouvelle instance de scène à l'époque de la HC2), car il va relire la config, analyser les règles, etc... Mais attention je tiens à modérer mon propos, ce que je dis dans la phrase précédente est très théorique. La HC3 est vraiment très puissante, il ne faut surtout pas se prendre la tête pour ça, ce n'est pas l'ajout de règles dans GEA qui va changer quoi que ce soit à l'utilisation CPU de la box... il faudrait vraiment des milliers de règles pour commencer à ressentir quelque chose. si on cherche à réduire la latence de déclenchement d'une action, évidemment la durée = -1 est à privilégier. Et c'est bien là que ce situe le choix. On veut réagir immédiatement à un événement (une fenêtre vient de s'ouvrir tandis que l'alarme est activée => alors déclenchement de la sirène), ou bien après un certains temps (une fenêtre est ouverte depuis 5 minutes tandis que le chauffage est allumé => alors extinction du chauffage). Donc ce n'est pas tant un problème de performance (terme qui n'a pas trop de sens ici), mais c'est la logique du scénario désiré qui prime sur la configuration, il ne faut pas se poser plus de question que ça. Je pensais que c'était des notions que tu maitrisais déjà, ancien utilisateur de GEA sur HC2. La logique générale n'a pas changée.

Dans ce cas fait un copier/coller de mon explications Parce que dans le 1er exemple, "Value" n'est pas entre parenthèses, donc c'est un trigger, donc cette condition fera un déclenchement instantané de GEA à chaque changement de la valeur du module (c'est à dire à chaque fois que la température varie de 0.1°C). Rien de compliqué, c'est juste le fonctionnement de base de GEA en fait. Parce que tu peux très bien vouloir déclencher une notification, une action, lorsqu'une des condition est le trigger, alors que les autres conditions ne sont que des ... conditions ! Typiquement dans mon exemple, la porte s'ouvre (c'est le trigger), selon si la température est négative (une simple condition, mais pas un trigger) Je suis persuadé que quand tu avait tes 700 règles sur GEA pour HC2 tu avais des cas similaires, tellement c'est élémentaire. Pas sûr de comprendre, mais n'oublie pas les fondamentaux de GEA : - durée >= 0 : les actions sont déclenchées quand toutes les conditions de la règles sont validées depuis X secondes (avec X >= 0 donc)... tout en n'oubliant pas que GEA fait un cycle de vérification toutes les 30 secondes. - durée = -1 : les actions sont déclenchées instantanément lorsque le (ou les) trigger(s) change de valeur, et que toutes les autres conditions sont également valides Bah c'est pas bon, tu as oublié les parenthèses justement.... cf mes explications, il faut prendre ce réflexe, sinon j'en connais qui vont avoir des mauvaises surprises lors des prochaines versions de GEA. Donc puisque tu mets à jour la doc de syntaxe, autant aller jusqu'au bout de la logique, et écrire les choses correctement Sinon on reviendra sans cesse dessus... Je ne comprend pas la question de la performance, les 2 modes de fonctionnement n'ont juste rien à voir, tu choisis la durée en fonction de tes besoins. Si l'instantané n'est pas indispensable, dans ce cas tu as ta réponse dans tes question, utilise le mode par intervalle (appelé mode automatique par Steven)

Je viens de vérifier dans le code, et c'est strictement supérieur (>) et strictement inférieur (<) Pour ton 1er exemple, c'est effectivement impossible, à cause des 2 conditions Time différentes. La seconde écriture, avec les 2 règles distinctes, est donc correcte. En alternative, on peut utiliser "Or", ce qui permet de tout écrire en 1 seule ligne : GEA.add({17, {"(Days)","Monday,Tuesday,Thursday,Friday"}, {"(Or)", {"(Time)","11:30","13:30"}, {"(Time)","16:30","18:30"}}}, -1, "Porte ouvertes le #date# à #time#") On notera que j'ai ajouté des parenthèses autour des conditions "Days", "Or" et "Time" afin de ne pas qu'elles soient considérées comme des triggers, du fait du mode de déclenchement instantané choisi pour cette règle (durée = -1) Dans le cas présent c'est inutile car ces 3 conditions ne peuvent pas être utilisées comme Trigger, mais : - il n'est pas exclu qu'elles le soient dans une prochaine version, ce qui pourrait provoquer des effets indésirables sur les règles existantes. - c'est une bonne habitude à prendre pour écrire ses propres règles, trop de fois j'ai vu des gens se plaindre du comportement inattendu de GEA, car ils avaient un peu trop de triggers... Exemple : GEA.add({18, {"Value-", 19, 0}}, -1, "Ouverture fenêtre alors qu'il gêle dehors") En réalité, cette règle se déclenchera lorsque la fenêtre est ouverte, mais également à chaque fois que le température change d'un dixième de degrés tout en restant sous les 0°C.... et cela même si la fenêtre est fermée.... ça va faire beaucoup de notifications ! Avec les parenthèses c'est OK : GEA.add({18, {"(Value-)", 19, 0}}, -1, "Ouverture fenêtre alors qu'il gêle dehors") Je pense que tu peux ajouter cette remarque sur les parenthèses et les déclencheurs instantanés dans la doc, car je ne suis pas certain que ça y figure déjà, et l'erreur est courante. A noter que GEA sur HC2 fonctionnait déjà de la sorte, mais bien souvent le problème passait inaperçu car il fallait déclarer manuellement les triggers dans l'entête de la scène. Ce n'est plus le cas sur HC3 car GEA détecte maintenant automatiquement les triggers, donc les parenthèses sont plus que jamais importantes. Évidemment tout cela ne concerne par les règles classiques à déclenchement sur durée >= 0 (par exemple 30, 60, etc)

Tu as bien protégé toutes les fonctions à risque avec un pcall() ? httpClient, json, etc

OK.... ça reste un grand mystère alors. En tout cas c'est résolu

Il a toujours parfaitement fonctionné le SRT321 chez moi, c'est étrange ton comportement, l'inclusion s'était peut être mal passée ? @ericl78 ça par contre c'est très embêtant :( Du coup pas de mise à jour en prod, merci pour l'avertissement. Tu l'as bien remonté à Fibaro sur le forum ?

Aucun souci pour ma part sur ma HC3 de test. J'ai presque envie de l'installer en production, car il y a un bug résolu qui m'embêtait pour les QuickApps : "Slider ignores min/max values from the API" Cette amélioration : "Z-Wave : Improved devices adding process" pourrait être intéressante pour l'inclusion des modules Qubino Fil Pilote... sait-on jamais, c'est à tester.