Lazer

Je n'ai pas regardé le fonctionnement de ses librairies. Je parlais juste du fonctionnement de base des QuickApps sur HC3. Chaque fonction peut recevoir les arguments de notre choix, et ça c'est cool. Par contre il y a une limitation, une fonction appelée dans un autre QA ne peut pas retourner une valeur. Il me semble que les mécanismes proposés par @jang permettent cela. (une fonction appelée dans le même QA peut bien retourner une valeur en revanche, ça marche)

Oui pareil, on en a parlé sur un autre topic, à priori ça concerne la caméra Welcome. Reste que Netatmo n'a toujours pas fermé son API historique.... pourvu que ça dure

C'est un sujet qui a été souvent abordé par le passé. Depuis la HC2, puis la HC3, j'ai toujours eu le réflexe de limiter autant que possible les écritures. Tout ce qui est stocké dans la box l'est sur son SSD interne (sur HC2 il avait la forme d'une clé USB interne, sur HC3 c'est une puce soudée sur la carte mère... comme sur les smartphones ou les PC ultra-portables de la marque à la pomme) Donc ce sont des cellules Flash, qui s'usent. Même si l'algo interne du SSD va répartir les écritures sur l'ensemble des cellules (wear-leveling), la durée de vie n'est pas infinie. Par expérience en 10 ans de box HC2, sur le forum on en a vu très peu dont le SSD est arrivé en fin de vie (ce sont d'autres composants qui meurent avant, dans cet ordre : alimentation, pile du BIOS, carte mère) Bref c'est toujours une bonne idée de limiter les écritures. Pour l'usure, mais aussi pour les performances. En effet j'avais fait un benchmark il y a pas mal de temps, il y avait un rapport de l'ordre de 1 à 10 entre une lecture et une écriture. Donc tous mes codes font une lecture préalable de l'ancienne valeur, et n'écrivent la nouvelle que si elle est différente. Bien plus efficace ainsi. A noter sur sur HC2 les labels des modules virtuels sont persistants (stockés dans la DB), donc même problématique que les variables globales. Sur HC3 en revanche, les labels des QuickApps sont éphémères, ils ne sont pas stockées. Le recours aux variables globales est devenu très rare, car la communication inter-QuickApps peut se faire directement par passage d'arguments lors d'appels d'une fonction, bien plus efficace ainsi.

Toujours pas installéééééééé de mon cotéééééé Un jour, peut être....

Il avait peut être atteint l'age de départ en retraite, lui Je me souviens que ce problème avait existé sur HC2... les modules qui disparaissent tout seul. Exclusion automatique de la part du module, ou bien de la box ? Pas rassurant en tout cas.

Oui c'est clair... comme tu dis, c'est pour la Welcome je pense.

Chez moi la station météo fonctionne toujours avec l'ancienne API.... pourvu que ça dure

Sorry I did not work on a new plugin addon version compatible with Python 3. Honestly I don't even know if I will have enough time one day... this is very low priority for me.

Top, merci (effectivement j'ai déplacé dans la section QuickApp, car on y centralise tous les.... QuickApps justement ! )

Je pense que tu n'as pas tort, la reconfiguration douce ça communique "lourdement" avec le module, donc micro-saturation temporaire du réseau Z-Wave, ce qui n'est jamais bon. Et ça triture aussi la base de données dans la box HC3, donc à un moment ça peut amener des potentielles corruptions (comme ça a été le cas dans le passé chez Fibaro...) L'idée de passer par un paramètre est bonne, mais si au niveau de l'Arduino tu n'as aucun moyen d'intercepter le nouveau paramètre sans éviter l'écriture sur l'Eeprom, il est clair qu'elle va s'user... après 1 fois toutes les 48h ça me parait acceptable.

Bienvenue sur le forum

Je n'ai pas eu cette chance Il faudrait chercher sur la page Github pour voir s'ils ont mis à jour les nouveaux modes (lavage, etc)... mais c'est toujours un peu compliqué vu que Xiaomi/Roborock ne documente pas son API, donc c'est fait par rétro-ingénierie.

ouh là là c'est bien compliqué tout ça... pourquoi ne pas utiliser simplement du 1.5mm² ? Il ne t'en faut que quelques centimètres pour aller de l'interrupteur au module (normalement installé dans la boite derrière l'interrupteur) Sinon tu n'as pas les caractéristiques de ton 0.8mm² ?

C'est du 230V. Le souci n'est pas tant la tension que le courant qui passe dedans, car c'est la section qui permet d'absorber un certain courant (sinon échauffement => incendie) Et en l’occurrence, le courant du bouton de commande connecté sur S1 ou S2 est très faible, du 0.8mm² ne devrait pas poser de souci. Mais pour revenir sur la tension, il faut quand même s'assurer que la gaine (isolante) de ton fil électrique permet d'isoler le 230V.... car si c'est du câble prévu pour du 12V par exemple, ça ne va pas être bon.

Voir ici pour ajouter une interface : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/8/#comment-202936 Et ici @tinman s'est lancé dans une exploration des interfaces existantes et de leur impact sur les propriétés des devices : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/58/#comment-227370 Mais voilà, le truc c'est que ça agit sur les propriétés des devices (visibles dans leur JSON, et peut également altérer le visuel dans l'IHM), mais pas sûr que ça puisse t'aider dans la communication avec le module Z-Wave.

Tu devrais peut-être poser la question sur le forum officiel, avec un peu de chance tu auras une réponse, car en effet la question est pointue. Même si j'ai peu d'espoir que ça soit possible, pas sûr que Fibaro ait prévu ce cas de figure... ou alors via une API (bien) cachée.

Suite du retour d'expérience de @lhpp sur l'Ecocompteur WES ici :

C'est pareil, les fonctions Fibaro debug/trace/warning/error peuvent prendre plusieurs paramètres, elles font automatiquement une concaténation des chaines de caractères, avec ajout d'un espace entre chaque. Relis le code, tu verras que self_debug est une variable initialisée au debut, avant de rentrer dans la boucle infinie. Ce sont des micro-optimisations, toutes les fonctions appelées régulièrement sont ainsi stockées dans une variable locale, accessible plus rapidement qu'une variable globale. On a eu pas mal de discussions sur le forum à ce sujet, l'appel d'une variable globale (donc une fonction, puisqu'une fonction est une variable en LUA) prend du temps car le compilateur doit parcourir la super-table _G à la recherche de l'élément désiré. Et c'est même encore pire quand on recherche self.debug, car il faut également parcourir les sous-tables (self dans le cas présent) A toi de le découvrir en l'affichant à l'écran (dans un self.debug par exemple) Son contenu diffère en fonction de l'événement remonté.

Bienvenue sur le forum

Merci les copains

Ce sont des "astuces" LUA. Si event.data n'est pas défini, alors... local id = event.data.id ...va planter. Donc ... local id = event.data and event.data.id ... permet de protéger l'exécution de la commande, puisqu'on affecte event.data.id à la variable id seulement si event.data existe Ensuite, le debug commenté... c'est juste un débug commenté ! A remplacer par du code utile.

J'ai déjà eu du mal pour réactiver le polling sur certains modules. Essaye de le faire depuis le module parent (si ce n'est pas déjà le cas) où bien depuis l'un des modules enfants.

Tu es sûr que c'est une version Z-Wave, et pas Homekit ? Fibaro en a fabriqué à un moment, pour l'écosystème domotique propriétaire d'Apple.

OK bienvenue sur le forum Maintenant je me souviens avoir vu 2 topics en doublon hier et j'en ai supprimé un.... donc tu peux recréer un nouveau sujet dans la section adéquate (ouvrants > Support) pour ta question concernant les BSO. L'application Yubii est effectivement assez peu ergonomique... mais tout le monde (enfin je pense) réalise la configuration depuis l'interface Web de la box, avec son PC. L'application mobile, c'est surtout utile en déplacement, pour surveiller / contrôler sa maison à distance.

Drôle de présentation