Lazer

Ouh là, attention au CPU, il y a comme un gros souci : Avant / après la mise à jour : A surveiller de près EDIT 1 : saturation d'un coeur pendant quelques secondes : EDIT 2 : Un reboot n'y change rien. Cette saturation d'un coeur se répète chaque minute précisément. Je n'ai pas l'impression que ça soit lié à l'un de mes QuickApps, cependant ça se produit comme par hasard juste après que l'un de mes QA mette à jour la puissance/consommation d'un enfant, du coup je me demande si ce n'est pas lié au panneau d'énergie, qui traite cette information. Il faudra que j'approfondisse le sujet.... demain. ça fait pareil chez vous ?

Il a l'air chouette le nouveau panneau d'énergie, avec prise en compte de la production pour ceux qui sont équipés Il a falloir attendre qu'il se remplisse avec quelques données : En voilà une fonction utile, fini de se bruler les yeux avec les mots de passes visibles en clair dans les variables des QuickApps :

avec formula tu pourras toujours inverser la valeur, mais j'ai un doute sur le fait que la HC3 va accepter une puissance négative. Remarque, avec le nouveau firmware beta sorti aujourd'hui, ils parlent de supporter les appareils producteurs d'énergie, donc il doit y avoir moyen, mais je n'ai pas encore regardé comment ça fonctionne.

Bienvenue sur le forum

Merci, c'est ce que je voulais dire en plus

Attention, le Qubino Flush Shutter DC auquel tu fais référence est un contrôleur de volet par inversion de phase polarité en 12/24V, donc qui ne permet pas de l'utiliser dans le branchement tel que réalisé ici. Il viendrait en remplacement du module contrôleur fourni par Wibat, mais alors comme l'a clairement exprimé @Bebitoo il te faudra gérer à la main les temporisations des 2 battants, car bien sûr il te faudrait 2 modules Qubino, un pour chaque moteur. Bref difficilement gérable... (PS : ce module est souvent utilisé pour les moteurs de volets roulants Velux par exemple) La meilleure solution de mon point de vue reste celle de @Bebitoo : un module double contact sec qui vient entre les interrupteurs et le contrôleur. En 24V, il y avait le FGS-221 à l'époque, qui est remplacé par le FGS-224 aujourd'hui chez Fibaro. Il doit exister un équivalent chez Qubino, mais je ne connais pas les références.

Et bien, la RAM augmente : 58% utilisé, ça a bien grimpé, mais ça va encore. Il y a 3 semaines, je suis parti d'un recovery complet, et j'ai migré mon installation sur la HC3. J'ai fait un seul reboot il y a 2 semaines, depuis je n'ai fait que des backups (donc redémarrage des services), mais surtout énormément d'inclusion, ajouts de QA, etc. 85 modules Z-Wave inclus. 27 QuickApps + 35 enfants 6 caméras 1 plugin météo YR Weather 10 utilisateurs DomoCharts remonte 205 mesures chaque minute ! Évolution sur 15 jours (le gris c'est l'espace utilisé) :

Oui par exemple, j'allais le suggérer. Mais c'est pas évident à détecter. Tu peux commencer par installer la scène Z-Wave Monitor pour détecter les éventuels modules trop bavards : https://forum.fibaro.com/topic/32655-z-wave-monitor/

Oui voilà. Et puis je suis pas du tout fan de tes 2 "Inverse", que tu peux remplacer ainsi dans les conditions par exemple : {"Value", id["SENSOR_CH2"], false}

Nope, Z-Wave planté ça ne m'est jamais arrivé.

Mais donc, il a tenté de déclencher l'action ou non ? Est-ce que tu as reçu le message "Marche clim chambre 2 en froid le soir en semaine" par notification push ? Car sinon, c'est que tes conditions ne sont pas remplies.

Tu as essayé cette ligne ? Et sinon, tu as essayé d'attribuer ta production solaire à un sous poste de l'EDRT comme je te l'avais conseillé au message précédent ?

Attention, "ThermostatMode" c'est pour un module thermostat, pas pour le panneau de climat (qui se contrôle avec "Climate" dans GEA) Ne confond pas les 2. Et pour savoir si "Cool" est supporté par ton thermostat, il faut regarder la propriété "supportedThermostatModes" dans son JSON Et comme toujours, quand tu as un problème, il faut activer GEA.debug = true pour obtenir des logs, parce que "ne fonctionne pas" ne veut rien dire

Bravo Pas évident à trouver quand même, bien joué !

Yes mais la HC2 état un vrai PC avec une carte mère x86, pas super optimisé, elle consomme beaucoup (et pas que à cause de la carte réseau) Mais 100Mbps c'est plus que suffisant pour le flux de la caméra, qui tourne plutôt autour de 10M selon comment tu l'as configuré.

Oui, comme pour beaucoup d'autres options, tu peux faire des comparaisons avec + et - GEA.add({"VariableQuickApp+", 123, "variable", 5}, 10*60, "la variable est supérieure à 5 depuis 10 minutes") Même syntaxe que "Global" par exemple. Je vais modifier la doc de syntaxe pour faire apparaitre ce cas de figure. EDIT : c'est déjà le cas, tu n'as pas lu la doc, c'est pas bien

Notepad++ Installer le complément JSON Viewer Sélectionner tout le texte, faire Compément / JSON Viewer / Format JSON (ou bien le raccourci clavier que vous connaitrez par cœur à force...)

Pas sûr de bien comprendre ton besoin exact pour ta piscine. C'est difficile de te conseiller, il faudra peut être aussi expérimenter par toi même. Car mettre en œuvre des modules enfants, ce n'est pas si simple, surtout quand on débute. Il est surement plus sage de commencer par un QA simple, au moins tu arriveras rapidement à un résultat fonctionnel. Puis plus tard, éventuellement, remettre en cause ce que tu as fait en te rendant compte qu'il y a moyen de faire mieux (child device ou pas, ça restera à voir)

Bienvenue sur le forum

Pense à utiliser pcall() quand tu utilises http:request() comme je l'ai expliqué dans le tuto. D'une part, ça t'aidera à comprendre l'erreur, et d'autre part ça rendra ton code plus stable, particulièrement dans les scènes qui semblent assez instable par nature... cf discussion récente sur un autre topic.

Les caméras oui sont en 100 Mbps, tout comme la HC3 et beaucoup d'appareils "légers". Ça coûte moins cher, ça consomme moins, et ça reste plus performant en pratique que du Wi-Fi, donc faut pas s'inquiéter c'est normal.

Désolé, pas le temps d'écrire le code LUA des autres... Je passe déjà beaucoup de temps à aider, et à écrire mes propres QA que je partage. Il y a déjà de nombreux QuickApp sur le forum, tu trouveras facilement des exemples pour t'inspirer. Et n'oublie pas que lors de la création d'un nouveau QA, tu as déjà un squelette proposé par Fibaro. Et bien sûr la doc officielle, même si elle n'est pas du tout didactique : https://manuals.fibaro.com/home-center-3-quick-apps/

Oui, mais pas forcément. Je veux dire, faire un polling ininterrompu de la valeur en interrogeant l'appareil ce n'est pas forcément super optimisé non plus, ça consomme des ressources (CPU RAM Réseau) pour rien en fin de compte. Moins grave que de faire des écritures inutiles sur un disque/SSD, mais pas optimal non plus. Si tu veux garder la logique de fonctionnement de ton installation, tu pourrais, dans ton script Python, commencer par vérifier la valeur du module, la comparer, et seulement si elle est différence, envoyer la nouvelle valeur vers la HC3. Ainsi tu appliques la logique de ce que j'ai décrit il y a 2 messages précédemment, sauf qu'au lieu que ça soit un QA qui l'effectue, c'est ton script Python externe. Mais encore une fois, c'est strictement identique, les 2 méthodes exploitent la même API. D'ailleurs j'ai un cas similaire, j'ai FHEM qui tourne dans une VM pour exploiter mes quelques devices EnOcean. Au départ je voulais écrire un QA qui fait un polling régulier, puis je me suis rendu compte que c'était inutile, et que le push effectué par FHEM suffit bien. Ce n'est pas du Python mais du Perl, mais la logique est la même. Pour l'instant je fais un update systématique du device, c'est temporaire car je n'ai pas eu le temps de faire mieux pendant ma migration vers la HC3, mais je vais changer cela : essayer de modifier les lignes perl pour faire un test avant de modifier. Précision : j'ai associé chaque sonde EnOcean à un QA. J'ai donc plusieurs QA, et chacun contient exactement 0 ligne de code, fichier main totalement vide. Difficile de faire plus simple En somme, c'est comme les "Fake Devices" sur HC2, sauf que là c'est propre, chaque QA est un vrai module autonome.

"transparante", presque, car c'est quand même à ton QA de changer ses propres proriétés (le champ value principalement). Mais rien que modifier ce champ value, par exemple true/false si c'est du type binary, ou 0-99 si multilevel, alors c'est la box qui va adapter l’icône en conséquence et le visuel du module. Alors les enfants justement, pour moi c'est tout indiqué dans ton QA. Justement, tu parles de piscine, avec des FGS (donc "binary switch") des capteurs (donc "temperature semsor"), etc Et je me rend compte que tu n'as pas compris la philosophie des QA, tu raisonnes encore sous forme de VD. Ton QA Generic ou Device Controller ne doit contenir sur des choses qui ne peuvent pas figurer dans un QA typé. Du coup, tu devrais avoir un QA parent (Device controller) qui n'affiche rien, si ce n'est un bouton pour créer ses enfants. Une fois fait, tu peux le cacher dans l'interface. Du coup son icone par défaut n'a plus aucune importance. Et les enfants, seront typés chacun comme il faut, te permettant de piloter ta pompe, surveiller la température, etc. Si tu regardes mes QA GCE IPX800 & EDRT2, Surveillance Station, Netatmo, etc, ils fonctionnent sur ce principe. Une fois que le parent a créé ses enfants, il peut être caché, on n'en n'aura plus jamais besoin pour un usage quotidien de la box. Bon sauf si tu as des infos à afficher, ou boutons spécifiques à créer, auquel cas ils ne correspondent à aucun type de QA prédéfini. Dans ce cas, le QA générique garde son intérêt.

#1 Réponse 1 : choix du type lors de la création d'un QA C'est un super QA que tu nous fait là Sérieusement, j'ai aussi ce type de QA, notamment un qui s'appelle "Gestion Maison" et effectue des actions globales : éteindre toutes les lumières, baisser le chauffage, passer la maison en mode vacances, etc. Du coup, aucun des types "simples" ne lui convient (ou plus exactement, aucun des type correspondant à des modules Z-Wave) Dans ce cas, le type "Generic device" est tout indiqué. Ou bien "Device Conroller" s'il aura des enfants (d'ailleurs les enfants peuvent être typés avec un type utile : temperature, etc). En fait ça revient à faire un QA avec une certaine similitude à ce qu'étaient les Virtual Devices sur HC2. Les types Generic et Device Controller n'auront pas d'action associé au clic sur leur icône, ils n'afficheront rien sous leur icône. Il faut les ouvrir (pour afficher leur vue et accéder aux boutons sliders et labels) Par ailleurs, aussi étrange que cela puisse paraitre, on ne peut pas (encore ?) changer leur icône... sauf à utiliser le hack assez simple déjà partagé plusieurs fois sur le forum. Rappel : évidemment, autant que possible, il faut utiliser un des types qui correspond à un module Z-Wave (lumière, température, etc) afin de respecter la logique Fibaro, et surtout en bénéficier : à l'usage un QA correctement typé s'utilise exactement de la même façon qu'un module Z-Wave dans la box ou sur l'application mobile. Très pratique. Dernier point : une fois affecté, un module ne peut pas changer de type. Astuce de contournement : il faut exporter le QA, modifier son type à la main avec un éditeur de texte dans le JSON, puis le réimporter.