Lazer

Pour info, suite à la discussion sur le forum officiel, un développeur Fibaro est connecté sur ma box de test en ce moment même pour étudier le problème CPU lié aux relevés d'énergie, donc c'est bon signe

La sonde de température, c'est le truc qui coute rien et que tous les fabricants intègrent à tous leurs modules, même quand ce n'est pas adapté. Le cas des micromodules Qubino, mais aussi les détecteurs d'ouvertures aux fenêtres (froides), les détecteurs de mouvements aux plafond (chaud), etc.... donc pour moi c'est avant tout une fonctionnalité marketing à défaut d'être utile. Dans ton cas, c'est d'autant plus inutile que la sonde sera dans la boite du micromodules, derrière le radiateur, pas du tout le bon endroit pour prendre une mesure de température. A la limite, si tu pouvais tirer une rallonge de plusieurs mètres pour aller installer la sonde sur le mur opposé à 1.5m de hauteur, là tu aurais une vraie mesure, représentative de la température d'ambiance de la pièce. Dans tous les cas, cette mesure de température, qu'elle soit judicieusement placée ou non, ne te sera pas utile pour la régulation si tu exploites les ordres du fil pilote. Car c'est le radiateur qui fera sa propre régulation de température avec son thermostat interne. Cela dit, une sonde de température dans une pièce, c'est toujours utile : - pour connaitre la température, faire des graphs, des statistiques, remplir le dashboard de l'application mobile, geeker, etc - anticiper la chauffe dans un scénario plus avancé. Si la température d'ambiance est inférieure de 1°C à la température de confort, tu lanceras le radiateur plus tard que si le delta est de 3°, l'objectif étant d'avoir la bonne température au moment où tu vas arriver dans la pièce (heure du doucher, heure du diner, de la douche, etc selon les pièces)

Bienvenue sur le forum

Bizarre, je n'ai jamais vu ça.

Bienvenue sur le forum

Oui, David, le créateur du blog et du forum a annoncé il y a plusieurs mois qu'il arrêtait complètement toutes ses activités domotiques.... Une page se tourne...

Effectivement, tu as mis le doigt dessus, une histoire de taille de bit.... Le VD et le QA n'ont aucune ligne LUA en commun, j'ai entièrement repris l'écriture à zéro. Sauf... la librairie qui gère la crypto, que ni moi ni @ADN182 ne maitrisons, elle provient d'Internet. Nous l'avons pris à des endroits différents, mais je pense qu'au final c'est bien le même auteur original. Perso j'ai utilisé la version packagée et testée par Tinman pour HC3.

Je pense que tu dois être le premier à tester ce QuickApp sur HC3 Lite.... j'ai la même impression que toi, ça semble provenir de LUA. Pas de la version, qui est surement la même, mais plutôt d'une limitation liée aux ressources disponibles, car il te dit qu'il a besoin de nombre flottants à plus de 53 bits, ce qui est assez énorme.... Malheureusement cela vient de la librairie sha2lib, donc la cryptographie, le code n'est pas de moi, je ne sais pas le débogguer.... C'est bien dommage ça, car la HC3 Lite serait finalement plus limitée qu'on ne le pensait au début.

10% ça va encore, on est loin des 100% d'augmentation sur les cartes graphiques et les disques durs... merci les cryptomonnaies Zigbee, c'est mois cher, mais on sait pourquoi maintenant : ce protocole est mort, il vit ses derniers mois. C'est surtout les produits Matter & Thread qu'il faut attendre.... j'espère que ça ne va pas prendre de retard vue la situation....

Justement, j'ai découvert très récemment que GEA sur HC2 n'utilisait pas les infos de l'API Weather de la HC2, mais uniquement les infos du module n°3.... qui est donc toujours YR Weather Cela sera corrigé dans la prochaine version de GEA sur HC3... Mais sur HC2... je n'y touche plus. Il faudrait que tu ailles lire directement les propriétés de ton module Weather Provider, avec l'option "Property". Par exemple : {"Property", 123, "Temperature"} (non testé) Ou bien, tout simplement, la Value du module enfant associé à ta station Netatmo.... ce que j'ai toujours fait sur HC2, donc ça fonctionne.

OK... donc non à ma connaissance ce n'est pas possible.

En série oui. Non rien à voir avec le bypass, au contraire, là on essaye de limiter le courant de démarrage. Et oui, il faut en utiliser surtout avec le transfo des LED, les transfos c'est pire que tout au niveau pic de courant, particulièrement les modèles chinois (tous ceux qui sont sans marque, c'est à dire 99% du marché) Si tu installes le limiteur de courant que t'as montré Did, tu n'auras pas besoin de changer le FGS, les relais ne devraient pas recoller. En revanche, si tu continues à l'utiliser tel quel, il pourrait bien recoller à la prochaine utilisation, ou la suivante, etc.

Hum; j'en ai un, mais il n'est pas inclus en ce moment....

Je n'ai pas compris la question... tu veux dire que tu voudrais des variables énumérées dans les QuickApps ?

Oui c'est ça, relai collé, c'est un grand classique avec les LED et leur fort courant d'appel. Je confirme, même module que Did, à installer en série entre la sortie du relai et les LED, et plus aucun souci.

Vu la valeur délirante, ça ressemble à un dépassement de buffer ou un truc dans le genre. Donc tu es certain d'avoir choisi la bonne taille pour l'option (1, 2, 3 ou 4 octets) ? Dans le doute, supprime l'option, enregistre, puis tu la recréer en mode lecteur seule, tu enregistre, il va interroger le module, et remplir correctement avec la valeur par défaut et la bonne taille d'option. Autre chose : tu peux faire la mise à jour du firmware de ce module si tu as une clé Aeotec.

Pas de chance.... J'ai ouvert un topic sur le forum officiel, si vous voulez bien aller appuyer la demande : https://forum.fibaro.com/topic/54715-high-cpu-usage/

Voilà une des raisons pour laquelle il me semble important de typer correctement ses QA, afin que la fonction principale du QA (exemple : ON/OFF, Variation, etc) soit accessible directement sans avoir besoin d'ouvrir la vue du QA. Aller cliquer sur des boutons devrait être utilisé en dernier recours (à la mode Virtual Device sur HC2) Autre sujet, mais la domotique ça sert surtout à automatiser, donc le recours à l'application mobile devrait être réduit autant que possible. Perso à chaque fois que j'utilise mon téléphone, c'est plutôt pour vérifier à distance que d'agir. Et puis les fois où je peux pas faire autrement, je prends le téléphone et j'ouvre la vue du QA, mais finalement c'est assez rare.

Non, c'est bien la première option que j'ai en tête : inclure cette boucle RefreshStat pour chaque QA qui souhaite tirer parti d'un "trigger" D'où le test de charge, pour m'assurer que ça ne plombe pas la box. Sur ma box de production, avec 3 QA qui exploitent ce principe et beaucoup d'événements, ça ne pose aucun souci. La 2nde option, un QA qui centralise tous les triggers, puis les redispatch vers les autres, est l'approche choisie par @jang avec son Webhook QA : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/6/?tab=comments#comment-202423 Je principe est top, mais perso je ne suis pas fan, à cause de la dépendance entre les QA (maintenance plus complexe, et il devient très compliqué de partager ses propres QA avec la communauté s'il faut monter une usine à gaz pour les utiliser)

Il me semble que les modules conservent leur dernier chemin même après un reboot électrique.... du coup la solution de couper le disjoncteur ne permet pas de reconstruire le réseau.

ça m'arrive de temps en temps sur l'appli, sous Android, la page du QA est blanche.... puis ça refonctionne un moment plus tard... sans que je ne comprenne pourquoi.

C'était au cas où la boucle pose problème, et fasse planter la box, car j'étais en phase de test et j'en ai lancé plusieurs dans différents QA simultanément, pour tester la montée en charge. Si la boucle avait été en démarrage automatique dans le QA et fasse rebooter la box en boucle, je n'aurais jamais pu m'en sortir (expérience vécue lors d'un autre test...) Mais maintenant qu'on sait que ça fonctionne, tu peux utiliser ta boucle normalement dans ton QA, avec un lancement automatique. Ton setTimeout me semble OK

Si j'installe une HC3 avec tes icônes dans ma voiture, est-ce que je serai prioritaire aux carrefours comme les bus ?

Justement, tu as un exemple de code utilisable dans le topic en question. Il faut juste ajouter ton propre traitement dans la boucle là où j'ai laissé des commentaires. Sinon, en QA déjà existant sur le forum, il y a GEA, mais pas vraiment le meilleur exemple, tellement le code est complexe.

Oui avec l'API refreshStates, mais pas simple : La façon de faire standard de Fibaro, c'est d'utiliser un trigger dans une scène. Mais quand tu veux faire ça dans un QuickApp, soit tu utilises une scène qui appelle le QA (un peu lourd à maintenir, à cause de la dépendance entre les ID), ou bien avec la technique que j'ai donnée au dessus.