Lazer

C'est très simple : attendre mardi

Je pense que le groupe NICE prépare l'arrivée de sa nouvelle box de son écosystème Yubii, basé sur une HC3-Lite dédiée : https://products.z-wavealliance.org/products/4107?selectedFrequencyId=1 L'application est renommée pour une intégration globale... du coup... est-ce qu'ils vont abandonner la marque Fibaro à terme ? C'est probable, cette marque est inconnue en dehors des geeks. On verra bien.

Home Center App 1.12 Update As announced, we would like to inform you about important changes to the Home Center app in the near future. With the next update, on April 20, the app will become an integral part of the Yubii ecosystem, which will provide seamless integration of Yubii Nice devices. The update will bring the new icon and the new name - Yubii Home Center. Key information: Changing the login screen In order to use the application and manage all devices within the Yubii ecosystem, log in with the refreshed login screen. You only need to use your current FIBARO ID account. Communication between the app and the control panel as well as passwords are encrypted, so when you entrust your house to our system, you can be sure that it is safe in every aspect.

Merci à tous C'est cool parce qu'avec vous c'est un peu mon anniversaire pendant 1 semaine

Oui donc ce n'est pas GEA en lui-même, mais l'utilisation qui est faite de GEA.... comme GEA est suffisamment générique pour effectuer la plupart des actions sur la box, fatalement il y a un moment où ça peut poser problème. Comme n'importe lequel des QuickApps que chacun développe dans son coin, on est libre de faire n'importe quoi. Cela dit je trouve que la HC3 aujourd'hui est largement plus robuste qu'au début, il y a 1 an... où il était possible de la crasher en 1 ligne de LUA ! (expérience vécue) @971jmd Sinon ma saturation CPU n'avait rien à voir, puisque c'était uniquement 1 cœur (sur les 4) qui était à 100%, et cela pendant plusieurs heures (et pas juste quelques secondes), et la box continuait de fonctionner parfaitement bien. Aucun dysfonctionnement ou ralentissement constaté, j'ai pris le temps de faire le tour de tous mes QuickApps avant de rebooter la box. Voici ici : Mais, cette semaine j'ai rencontré le problème décrit par certains ici, box figée pendant plusieurs secondes. J'étais en train de travailler sur un QuickApp conséquent, composé de 5 fichiers LUA, c'est au moment de l'enregistrement des fichiers que la box s'est figée, pendant 20 secondes environ. On a peut-être là une piste, comme sur HC2 à un moment donné, je ne serai pas surpris que ça soit l'accumulation d'écritures dans la DB (donc sur disque) qui cause les ralentissements. Et Fibaro devrait se concentrer sur ce problème plutôt que d'accuser les QuickApps des utilisateurs (surtout que les QA des utilisateurs sont souvent mieux développés que ceux de Fibaro même ) Puis c'est revenu à la normale comme si de rien n'était, comme en atteste la courbe ci-dessous. Je n'avais pas le graph CPU temps réel de la box d'ouvert à ce moment là (je ne l'utilise jamais), mais de toute façon il aurait été inaccessible car le box ne répondait plus. Sur le graph Domocharts, qui n'a une résolution que d'une minute, on voit un petit pic, mais ce pic a été trop court (moins de 60s), donc pas suffisant pour voir la courbe atteindre 100% sur les 4 coeurs :

Justement, met des print() dans ta fonction, car là on ne sait même pas si elle est effectivement démarrée ou pas. Un print au début de la fonction, et un print(type(...)) sur les variables que tu utilises pour connaitre leur type. Une variable globale c'est du string par défaut, sauf si tu as mis autre chose dedans lors de sa dernière modification

Quand tu dis que ça ne fonctionne pas, concrètement il se produit quoi ? La variable globale n'est jamais mise à jour ? Est-ce que la règle GEA est bien exécutée toutes les 10 minutes ? Tu vois quoi dans les logs ? N'oublie pas d'activer le mode debug. Et note que tu peux ajouter tes propres logs dans ta fonction perso, avec de simples print() tu peux afficher dans le log ce qu'elle effectue, ça te permet de diagnostiquer en temps réel la valeur des variable, la validation du test de la soustraction, etc

Je crois que c'est une des nouveautés du LUA 5.3, les nombres sont traités en number, et il existe le type integer à part. Le souci c'est que même si tu utilises des integer, LUA va automatiquement les convertir en number dès que tu feras une opération mathématique dessus. Et il n'est pas possible de caster les variables comme on le fait sur d'autres langages. ça m'avait bien surpris au début lors de mes premières migrations de codes LUA depuis la HC2 vers la HC3. Il faut que tu prennes l'habitude de formater tes nombres quand tu veux les afficher (dans le log, dans un label, etc..), avec string.format() Exemple pour un nombre entier : self:debug(string.format("heure : %d", heure)) Autrement, tu peux aussi te créer ta propre fonction générique round(), vu que LUA n'en propose pas nativement. Perso elle est incluse dans ma "librairie" d'outils que j'utilise dans tous mes développements de QuickApps. Exemple : -- -- Round number to specified decimal -- -- Usage : -- local entier = round(123.456, 0) -- local decimal = round(123.456, 1) -- function round(num, idp) local mult = 10 ^ (idp or 0) return math.floor(num * mult + 0.5) / mult end

Il n'y a pas 1 sujet, il y a au moins 90% des discussions du forum qui traitent de la HC3 maintenant, dont plusieurs sujets ouverts de retours d'expériences, question, plaintes, et joies Normalement tout est dans la section dédiée : https://www.domotique-fibaro.fr/forum/122-hc-3/ Attention quand même aux premières discussions d'il y a un an qui ne sont plus d'actualités, la box a beaucoup évolué depuis. Le seul truc qui manque par rapport à l'annonce commerciale, c'est le Zigbee, mais là aussi il y a au moins 2 ou 3 sujets qui en parlent, avec la réponse claire de Fibaro : repoussé à la St Glinglin, voire même annulé, car ils attendent de voir si CHIP aboutie à une offre commerciale. Sinon mon HC2 a aussi plus de 7 ans et elle fonctionne toujours très bien (et une en secours au cas où). Quand je l'ai acheté, je visais 3 à 5 ans de durée de vie, honnêtement on a beau se plaindre de Fibaro et de ses retards de développement, il faut avouer qu'ils font plutôt des produits durables, et ça c'est bien appréciable

Il me semble que ça se produit si tu mets autre chose qu'une string dans une variable. Par exemple un number (ce qui semble être le cas) L'API le tolère tout à fait, mais pas l'interface Web.

Je n'ai que 8 modules Z-Wave sur la HC3, mais déjà beaucoup plus de QuickApps (et une vraie colonie de children ) Hyper content oui, pour développer c'est l'éclate, fini toutes les limitations des VD et les contournements complexes via des Labels/VG/Scènes. Normalement je migre mes modules Z-Wave sur la HC3 le mois prochain.

Effectivement, un WP qui fait 1/4 du trafic à lui tout seul, y'a un malaise Les exclure ne changera rien, ils sont bavards à cause de la charge branchée dessus, et tu le vois bien, 3547 trames de mesure de consommation... Il faut jouer avec les paramètres du modules, pour ajuster au mieux à l'appareil branché dessus. Il faut commencer par lire la doc pour bien comprendre les paramètres, ils sont très nombreux. Et la suite de la discussion aurait plus sa place sur le topic du Wall Plug justement.

Peut être parce que tu as des vrais souci de communication ? Il y a une scène sur le forum officiel pour analyser le trafic Z-Wave, ça permet de voir la charge, de déterminer les noeuds les plus bavards, et de les faire taire (ou du moins de les calmer un peu) Perso j'ai appliqué cette méthode pour un Wall Plug branché sur mon frigo, qui floodait le réseau.

Attention ça c'est sur HC3, je ne sais pas si ça fonctionne sur HC2. A tester...

Pour le getVariable, allez voir dans le code source de GEA L'idée de base est simple : api.get("/devices/" .. ID) puis on parcoure les variables pour récupérer celle qui nous intéresse. On peut aussi en supprimer d'ailleurs. Tout est possible.

La méthode setVariable étant une fonction de la classe QuickApp, elle est automatiquement exportée, donc tu peux l'appeler depuis n'importe où : un autre QA, une scène .... (ou même depuis l'extérieur via l'API HTTP) Le plus simple, avec un truc dans le genre je pense que ça doit fonctionner : fibaro.call(ID, "setVariable", "variable", "valeur")

Ah, ce n'est pas passé inaperçu Merci @fredokl

@Sakkhho 440s ça doit être la valeur que t'a conseillé la box, calculé en fonction du nombre de modules dans ton réseau. Quand tu dépasseras un certain seuil, elle te proposera de l'augmenter encore. Perso j'en suis aussi à 440 secondes, pour 94 modules. @kioneoranga Attention, parce ce que parles de polling et de modules à piles dans la même phrase. Les modules à piles ne sont pas concernés par le polling. J'ai constaté les conditions suivantes pour qu'un module passe en noeud mort sur la HC2 : module sur secteur : s'il ne répond pas suite à un ordre envoyé par la box ou l'utilisateur (turnOff, etc) s'il ne répond pas suite à une demande de polling module à pile : s'il n'y a aucune communication depuis le dernier intervalle de réveil. Puisque pour rappel, un module sur batterie doit forcément communiquer avec la box à chaque intervalle de réveil, ou d'envoi de trame spontanée (mesure de température, mouvement, ouverture, etc) Cas particulier : un module dont on aurait désactivé l'intervalle de réveil (possible sur les modules récents) => il ne passera jamais en nœud mort, normal

Perso je remet systématiquement le polling avec l'intervalle global configuré au niveau de la box (donc plus il y a de modules, plus cet intervalle s'allonge) Mais j'ai vu que sur de gros réseaux (plus de 100 modules), si des latences commencent à se faire sentir, cela indique une saturation, donc il est conseillé de désactiver le polling.

Non la Téléinfo c'est un cas particulier, je te l'ai déjà dit, et c'est documenté en 1ère page. Ce que tu devrais pouvoir faire, dans l'EcoDevice, c'est associer ta production solaire à un sous-poste dédié, ainsi tu pourras facilement aller chercher ce sous-poste avec le QuickApp. Note que c'est purement théorique, je n'ai pas de production chez moi, je ne peux pas reproduire...

Oui il manque une virgule avant le power

Oui c'est compliqué, comme je l'ai mis en avertissement dans le tuto, la bonne configuration nécessite une bonne compréhension du fonctionnement de l'EDRT2 (ou IPX800) et de la HC3, tant les possibilités sont nombreuses. Il faut se creuser un peu la tête, mais les possibilités sont quasi infinies. Surtout quand tu veux faire interagir cela avec DomoCharts ou d'autres QuickApps. Je viens de me rendre compte qu'il n'y a pas d'entrées virtuelles sur l'EDRT2 (c'est uniquement sur IPX800) Mais c'est pas grave, tu peux utiliser n'importe quelle sortie virtuelle ou entrée numérique que tu n'utilises pas. Il y a les liens vers l'API GCE en première page, donc tu peux voir toutes tes sorties virtuelles avec l'URL suivante : /api/xdevices.json?key=apikey&Get=VO Il n'y a rien à configurer, elles existent déjà, et tu ne les utilises pas vu que tu ne semble pas savoir ce que c'est. Donc il suffit de prendre la première.... ou mieux, la dernière, comme ça tu es certain de ne jamais l'utiliser pour de vrai Donc au final un truc dans ce genre là : {device = {name = "APsystem", type = "BinarySensor"}, value = {command = "Get", argument = "VO", pin = "VO128", formula = function(value) return not value end} power = {command = "Get", argument = "P", pin = "INSTANT_POSTE4", formula = function(x) return tools:round(x*1000, 0) end}}, Tu noteras que j'ai mis une formule d'inversion sur la value de la sortie virtuelle 128, c'est juste pour faire joli et que le capteur binaire apparaisse actif dans l'interface de la HC3. Tu n'as plus qu'à mettre une icône avec un appareil allumé et courant qui passe, et ça sera joli.

J'y pense, tu devrais regarder du coté de l'API fibaro:callGroupAction() qui est assez méconnue, ça irait peut être plus vite. C'est d'ailleurs peut être celle qu'utilise Homebridge.

Non les VD, Scènes, et QuickApps sont mono-threadés chez Fibaro. Petite particularité, les scènes sur HC2 : on peut déclencher simultanément jusqu'à 10 instances d'une même scène, ce qui équivaut à 10 processus différents au niveau de l'OS. Mais attention je dis bien processus, et non pas thread, puisque chaque instance de scène est totalement indépendante des autres et a son propre espace mémoire. En résumé, pas de programmation multithread en LUA sur les box Fibaro, et c'est pas plus mal, c'est bien pénible à synchroniser.... Cela dit, je ne sais pas à quoi ressemble ta scène, mais il y a peut être moyen d'optimiser ta boucle pour déclencher les ordres Z-Wave plus rapidement. Un enchainement de fibaro.call() ça va vite... Mais autre souci derrière çà, c'est le protocole Z-Wave, qui ne permet de toute façon pas d'envoyer simultanément plusieurs trames. Les trames sont forcément envoyées en séquence. Par ailleurs, je suppose que le contrôleur (HC2) gère cela au mieux possible pour éviter les collisions de trames et donc la saturation du réseau Z-Wave..... donc la box attends probablement quelques millisecondes entre les envois d'ordres différents vers les modules.... surtout que pendant ce temps là, la box continue de communiquer avec d'autres modules (les relevés de température, consommation électrique, etc) Peut-être même qu'elle attend le retour d'état du premier module avant d'envoyer l'ordre au 2nd module, ainsi de suite... En association direct, je suppose que la télécommande ne se pose pas toutes ces questions, et puis pour éviter de bouffer trop vite les piles, il faut rester éveillé le moins longtemps possible, donc j'imagine bien la télécommande qui envoie tous les ordres en série sans attente entre chacun, puis se rendort bien vite... et tant pis si le réseau sature. Simples suppositions, il faudrait un sniffer Z-Wave pour étudier cela plus en profondeur.

Hum, je n'avais pas pensé à cette utilisation du GoTo, merci pour l'idée (encore une fonction qu'il faudra que j'ajoute dans le QA donc)