Lazer

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.

En effet, c'est clair, seul le 1er ID est contrôlé. Merci ça fera un autre correctif à apporter à la prochaine version. Mais en attendant, je pense que c'est sans impact, tant que tes ID sont bons. Et quand bien même le 2nd (ou 3ème...) ID serait mauvais, ça serait sans impact sur le fonctionnement de GEA, vu que le mauvais ID n'existe pas, il demandera à la HC3 d'exécuter une fonction d'un QA qui n'existe pas, donc il ne se passera rien.

HC3 & HC3L - 5.111.48 - BETA - 03/06/2022 Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Main features: 1. Completely new and redesigned process of first gateway configuration in WebUi. 2. Added possibility to test newly added Z-Wave devices during first configuration. What's new: Dashboard Added possibility to use Hold (start move) and Release (stop move) actions on buttons in sidebar for roller shutters. Devices Device roles now visible on the Settings/Devices page. Added missing support for devices which works on HC2/HCL platforms. Added channel designation in the target device selector in Z-Wave association configuration. Slider for level change for roller shutter with role "Device without positioning" removed from control dialog in mobile application. Parameter names are now displayed for Z-Wave devices.** Improved virtual power consumption algorithm for Color Controllers. Elero* Improvements in pairing process. JA Pulse device support added. Nice* Changed default devices names to be more understandable. Improved calibration mechanism for BiDi-Shutter and BiDi-Awning. Improved error handling during pairing processes. UI improvements. Improved removal of disconnected devices. Other Device location (room) added to e-mail and push notifications templates. Updated system packages for performance and stability. Profiles Improved saving for actions in profiles. Quick Apps Added support for Headers in Websocket connections. Scenes Added possibility to rename scenes from within the open editor. Safeguards have been added to prevent incorrect values being entered in Scenarios conditions. Performance improvements related to loading elements in Block Scenes. Added translations for modes and actions for thermostats. Z-Wave Added background polling for sleeping devices**. Improved devices adding process. Updated SDK to v7.17.2 for Yubii Home and Home Center 3 Lite. Performance improvements. Bug fixes: Dashboard Redirection to specific device settings not always works correctly. Elero* Issue with controlling Awnings in some cases (reversed states and/or actions). Energy Wrong rounding up the percentage of summary consumption for devices list in Savings tab. Issue with "Rest" graph in Detailed Consumption graph in General Tab if main energy meter is set. Gateway Connection Empty Z-Wave device templates after downloading them from Slave gateway. Network Listing available networks not always works correctly if the currently connected network has poor quality. Nice* Added device summary shows default names instead of configured ones. It is impossible to control old revision of Era Fit BD and Next Fit BD devices. Inconsistent device renaming during adding wizard in case of different protocols. Other Duplicated scrollbar in WiFi search window. Every logging into the system using mobile application generates redundant events to History. Profiles Wrong unit for Sprinklers watering time. Rooms Drag and drop the rooms not always works correctly. Quick Apps Slider ignores min/max values from the API. Scenes Impossible to edit or create scenes using thermostats in Czech language in some cases. Missing favorite positions condition and trigger for Elero devices. Z-Wave ZW300 devices update fails in some cases. Global polling not always works correctly. Known issues: Z-Wave Engine 3.0 Some Z-Wave devices are not fully compatible with the new version of Z-Wave engine. Gateway connection is not available in the new Z-Wave engine version. * - does not apply to HC3L (Home Center 3 Lite) ** - applies only to Z-Wave Engine 3.0

Si, la variable child retournée par createChildDevice() pointe bien sur le module enfant, enfin sa représentation en mémoire (= une instance de l'objet, cf discussion sur le nouveau topic du QA pour les débutants) Tu peux l'exploiter comme bon te semble, mais c'est de courte durée, car au démarrage suivant du QA, la mémoire est perdue. Donc il faut recréer ton tableau de child, d'où mon message précédent, il te faut un moyen d'identifier simplement les child autrement que par leur ID. La variable stockée dans chaque child est le meilleur moyen à mon avis.

Cool Pour l'ID des enfants, ce qu'il faut faire c'est se construire un tableau dynamique des modules enfants, reconstitué à chaque démarrage, afin d'identifier facilement les enfants. De mémoire la doc Fibaro indique de procéder comme cela. Après la façon de le mettre en œuvre varie selon les gens. Perso lors de la création de chaque module enfant, je leur affecte une variable (variable de quickapp, donc visible dans l'onglet idoine du module) qui contient un identifiant unique (la forme de cet identifiant est très variable selon le but recherché... parfois c'est un ID numérique, parfois c'est juste du texte). Puis lors du démarrage du QA, je vais charger cette variable pour chaque enfant, et me construire une table utilisée dans le code LUA.

Génial, bravo et merci J'ai épinglé ton message du coup, il restera en haut de la page de cette section tutoriels. Juste 2 ou 3 précisions : Les "onglets" du QuickApp qui nous permettent d'organiser notre code LUA, sont en réalité appelés des fichiers. Pour les développeurs, c'est exactement comme quand on réalise un programme avec plusieurs fichiers, qui sont ensuite compilés et liés ensemble avant l'exécution. Le QuickApp lui-même est un programme, qui s'exécute dans un processus géré par le système d'exploitation (Linux) Si tu vas voir le JSON de tes modules QuickApp via l'API HTTP (ou après exportation du QuickApp sur ton PC avec l'extension FQA), tu verras que ces fichiers apparaissent dans le champ files, qui est bien la traduction anglaise de fichier. Le fait de créer un second fichier "tools" pour reprendre ton exemple n'a rien à voir avec le fait d'appeler ses fonctions avec tools:xxx(). Le nom du fichier n'a aucune importance dans l'exécution du programme LUA. En revanche, lors du développement de mes QA, j'ai choisi comme bonne pratique de nommer mes fichiers de la même façon que la librairie qu'elle comporte. Mes librairies, sont en réalité des tables au sens LUA du terme, c'est à dire un tableau qui comprend des fonctions. Basiquement : tools = {} function tools:maFonction(...) -- Fait des trucs end Et c'est bien le nom de la table tools qui importe, car c'est ainsi qu'elle sera connue dans tout le programme LUA (c'est à dire dans l'ensemble des fichiers, ou onglets, du QuickApp) LUA n'est pas un vrai langage de programmation orienté objet, néanmoins Fibaro a construit les QuickApps avec une approche objet. "QuickApp" est assimilable à une classe, donc la représentation théorique de l'objet. "quickApp" (sans la majuscule donc) est assimilable à l'instanciation d'un objet à partir de la classe QuickApp. Et le mot clé self permet d'accéder aux éléments de l'objet en cours. Donc si on est dans une fonction de QuickApp, alors self pointe également sur quickApp, ça revient au même. En pratique on n'a pas besoin d'utiliser quickApp (sans la majuscule), sauf quelques cas particuliers, notamment la communication d'un Child Device vers le QuickApp parent. Et donc justement, il est peu important de comprendre ces notions quand on développe un QuickApp "célibataire", mais il devient primordial d'assimiler ces concepts quand on commence à élever des enfants.

Ah yes, pas mal le format réduit d'ailleurs

Je ne sais pas comment fonctionne ton VD, mais je te confirme que la Téléinfo ne remonte que la puissance apparente (en VA), pas la puissance active (en W). C'est un problème qui existe depuis les tous premiers compteur électroniques, et quand Linky est sorti, ils ont gardé le même mode de fonctionnement. C'est complètement crétin, et ça participe à entretenir la confusion autour de Linky pour 99% des gens, et la défiance de certaines personnes... Cette puissance apparente ne sert à rien, puisqu'elle n'est pas facturée. En fait, elle a un seul intérêt, puisque le disjoncteur de branchement, ainsi que l'organe de coupure du Linky, sont calibrés sur cette puissance apparente (enfin pas tout à fait, pour être exact ils sont calibrés sur le courant... donc selon la tension, la puissance varie) Bref, pour obtenir la puissance active (en W), il faut que le VD fasse le calcul entre 2 relevés : (index_courant - index_précédent) / (timestamp_courant - timestamp_précédent) * 3600 Là on divise bien une énergie active en Wh (modulo la multiplication par 3600 pour passer en Ws) par un temps en s, ce qui donne bien une puissance active en W. C'est ce que fait mon QuickApp GCE justement.

Petit ajout rapide, voici la version 2.11 : La liste des type exclus peut être abrégée, c'est à dire retirer le "com.fibaro." afin de contourner la limite du nombre de caractère saisis dans le champ variable de l'interface Web. Exemple d'utilisation : excl_type = "temperatureSensor, humiditySensor, lightSensor, windSensor, multilevelSensor, meter, powerMeter, electricMeter, energyMeter" Pour la mise à jour, copier/coller simplement le contenu du fichier LUA par dessus le code situé dans le fichier main du QuickApp. Téléchargement : Evénements v2.11.lua

@mprinfo ah faudra qu'on essaye de se croiser alors T'es en voiture ou en train quand tu y va ? @Nico C'est la puissance active, celle qui nous intéresse car facturée par Enedis (enfin, dans le cas présent, non-facturée ) Quand tu seras passé sur HC3, tu pourras utiliser mon beau QuickApp qui remonte toutes les infos utiles sur la box. En attendant, voici quelques URL intéressantes : http://envoy.local/production.json : lecture des informations des micro-onduleurs par CPL toutes les 15 minutes, et des pinces en temps-réel : http://envoy.local/production.json?details=1 : idem avec des détails supplémentaires (puissance apparente, réactive, cos phi, etc) http://envoy.local/ivp/meters/readings : informations détaillées pour toutes les pinces (jusqu'à 6) sur les différentes phases : Toutes les informations sont disponibles en local, il y a plein d'API locales, dont certaines sont protégées par mot de passe (facile à décoder), voir cette page : Enphase Envoy-S “Data Scraping” Pour information il s'agit de l'API locale qui n'est pas documentée par Enphase. Enphase redirige officiellement vers l'API Cloud qui est parfaitement documentée, mais que évidemment personne ne veut utiliser (pas fou le geek ) : The Enlighten Systems API

Ah je n'avais pas compris que tu voulais ajouter des Child devices à un QA existant, dont tu n'es pas l'auteur. Donc à la difficulté de gestion des QA enfants, s'ajoute la difficulté de compréhension du code LUA de quelqu'un d'autre... pas simple. Il faudrait vraiment écrire un tuto complet sur la création et la gestion des QA enfants, mais c'est un travail titanesque, surtout si on doit reprendre les bases d'un QA tout simple, ce que beaucoup d'utilisateurs ne maitrisent déjà pas très bien. En attendant le mieux qui existe, je conseille toujours cette lecture sur le forum officiel : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4

Euh... pourquoi s'embêter avec une variable de QA, c'est totalement inutile ? Je veux dire, pourquoi stocker la température dans une variable, alors que tu cherches à la stocker dans la propriété value du module. C'est directement là qu'il faut la stocker, pas besoin de rajouter une étape intermédiaire. Ensuite pour la façon de structurer son code, tout dépend de ce que tu fais. Là il n'y a aucune règle. Par exemple dans la majorité de mes QA, les enfants sont "passifs", c'est à dire qu'ils attendent des événements, mais n'ont aucune boucle infinie. La boucle infinie est gérée par le QA Parent, qui va lire les infos dans le monde extérieur (exemple fictif pour rester dans la discussion précédente : le statut de l'onduleur connecté au réseau). Une fois que cette boucle a obtenu toutes les valeurs désirées (température, état de l'alimentation, niveau de batterie, etc)... qui sont alors stockée dans des variables locales au sens LUA du terme, alors elle va "pousser" les valeurs dans les propriétés de chaque QA Enfant. Et dans cette façon de pousser les valeurs, il y a différentes façon de s'y prendre. La méthode basique c'est d'appeler directement la propriété updateProperty() des enfants. Exemple ultra simplifié, à intégrer dans ta boucle infinie du QA parent : -- Temperature : local value = 21 -- Mise à jour de la propriété value du module enfant identifié par son id : self.childDevices[id]:updateProperty("value", value) Bon après faut que tu gères correctement ton tableau d'enfants, car les identifier par leur ID ce n'est pas le plus simple dans le code. Perso ce que je fais maintenant, je crée une fonction push() pour les enfants, ce qui présente 2 avantages : - le parent peut mettre à jour les propriétés des enfants via cette fonction - le monde entier, via l'API, peut également mettre à jour les enfants. C'est particulièrement pratique avec les GCE IPX800 et EDRT2 qui permettent de déclencher des événements Push vers la box domotique pour un rafraichissement instantané. Mais c'est quelque chose que tu pourras voir dans un second temps.

Petite recherche au sujet des longueurs de câble pour l'extension des pinces de mesure de courant. La doc Enphase (cela sera peut être différent pour un autre fabricant comme Power Reducer) précise ceci : Donc ils disent que la résistance du câble doit faire maximum 3 ohm aller/retour, soit 1.5 ohm pour un aller simple. Le site suivant nous donne la formule de calcul de la résistance d'un câble en fonction de son matériaux : https://webetab.ac-bordeaux.fr/Pedagogie/Physique/Physico/Electro/e07fil.htm Si on applique la formule avec du cuivre, on arrive à 1.45 ohm sur chacun des 4 exemples donnés par Enphase, donc c'est cohérent. Je dispose d'une grosse bobine de câble réseau Cat 5e non blindé, exactement cette référence : https://www.touslescables.com/b.php?a=A5LLbo-ac5&amp;c=Voi&amp;h=65 Il est utilisé pour différents usages chez moi, les caméras tout autour de la maison, la téléinfo du compteur Enedis, ainsi que des compteurs à impulsion ou contacts secs pour la domotique. La page nous donne la section, AWG 24 (norme américaine), soit 0.205 mm² en métrique. J'estime la longueur nécessaire entre mon garage et ma maison à 20m. Cela nous donne une résistance de 1.66 ohm. C'est pas bon en théorie du moins.... je pense qu'Enphase prend de la marge de sécurité. Pour info la longueur théorique maximale pour ce câble réseau serait de 18m avec ce calcul. Autre piste, si j'utilise du câble Grade 3s, la section est en AWG 23, soit 0,258 mm² Et là pour 20m on tombe à une résistance de 1,32 ohm, donc c'est bon. Seul problème, je n'arriverai pas à passer le Grade 3s dans ma gaine existante (qui passe déjà le même câble justement... mais pour le réseau) Tandis que j'ai espoir d'arriver à passer le câble Cat 5e, car il est beaucoup plus fin (il n'a pas de double blindage) La solution serait de faire comme le suggère @Nico, à savoir grouper les paires, mais je crains de perdre le bénéfice de la torsade, d'autant plus important que ce câble n'est pas blindé. Bref, il faut que j'essaye. Déjà, arriver à passer le tire fil, première étape, le week-end prochain si la pluie ne s'invite pas (parce que la gaine ressort dehors... avant de rentrer dans la maison... oui c'est bizarre)

Ah, je pense que le navigateur fait automatiquement la correction de casse, ce que je ne fait pas la HC3. Avec le GEA.debug = true tu aurais vu le code de retour http, le message de retour ou d'erreur, etc, bref de quoi diagnostiquer. Comme on en discutait sur l'autre topic, il faut user et abuser de ce paramètre de debug, c'est fait pour, ça date de GEA sur HC2 et Steven pensait à tout

Hier j'ai oublié de publier une autre statistique : En mai, j'ai produit 777 kWh. La simulation donnait 762 kWh. Pas mal du tout, je suis au dessus des prévisions, sachant que : - j'ai toujours mon sapin qui fait ombre une partie de la journée (mais de moins en moins gênant à mesure que le soleil monte dans le ciel, on s'approche des jours les plus longs de l'année) - de plus en plus d'écrêtage des micro-onduleurs IQ7+ en milieu de journée Cette production meilleure que prévue s'explique facilement par le très beau mois de mai que nous avons eu cette année

Il n'existe pas de tuto sur le forum pour réaliser un QuickApp pas à pas. Il faut dire que le sujet est vaste, tant les possibilités avec les QA sont infinies. Si tu lis l'anglais, et que tu n'as pas peur de passer un peu de temps à bien comprendre les fondamentaux du LUA et des QuickApps, je te conseille le tuto de @jang sur le forum officiel, en particulier ces 4 messages : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4 J'ai commencé par ça