Lazer

Un peu de confusion..... la vanne thermostatique Fibaro, ça n'a rien à voir avec le chauffage électrique, c'est pour le chauffage à eau (chauffage central avec chaudière). Ton fil pilote, il ne sort pas du mur, mais de ton radiateur : voir le câble de ton Sauter... normalement 3 fils : Phase + Neutre + Fil pilote Pas besoin de thermostat avec ce système, tu laisses le thermostat du Sauter faire son boulot de régulation de température. Donc tu choisis la température de confort, celle pour laquelle tu te sent bien dans la pièce, sur le petit panneau de contrôle. Donc cela se fait dès maintenant, sans domotique. Demain tu ajoutes un micro module fil pilote derrière le radiateur, typiquement un Qubino. C'est du Z-Wave, donc il te faut une box domotique. Une Fibaro Home Center 3 / 3 Lite bien sûr, mais ça peut aussi être Jeedom + Home Assistant avec une clé Aeotec, une box eedomus, etc. Et là tu feras des scénarios en exploitant les 6 modules du fil pilote : confort (la température réglée sur le radiateur donc), et des température inférieures (Conf -1°C, +2°C, Eco, Hors-gel, Arrêt) selon l'heure, l'absence, les vacances, etc. Dans tous les cas c'est le radiateur qui régule la température, grâce à son thermostat intégré. La box domotique ne fait que donner un ordre via le fil pilote au travers du micro-module.

Oui voilà

Regarde sur le forum officiel, mais j'ai l'impression que ce message est apparu avec le dernier firmware. https://forum.fibaro.com/forum/1306-update-5090/ Du coup ça éliminerait la piste de la panne matérielle. Bon sans certitude tant qu'on n'en saura pas plus sur cette affaire... Pour les logs, tu peux quand même tenter quelques heures après, le support te dira si ça leur suffit ou pas.

c'est différent, mais pas tant que ça. Il n'y a pas de meilleur choix, tout dépend de ce que tu veux faire. Si tu la déclares en local, elle ne sera accessible que : - après la déclaration (je veux dire, linéairement dans le sens de la lecture du code, au moment de la précompilation avant exécution) - uniquement dans le même fichier Si tu la déclares dans quickApp, alors elle sera accessible... de partout ! Et oui : - depuis une fonction membre de QuickApp : self.myVar - depuis n'importe où : quickApp.myVar Car en fait, quickApp, qui est l'objet instancié à partir de la classe QuickApp (notez la majuscule), est global, donc accessible de partout. Ses membres (fonctions comme variables... les fonctions étant en réalité des variables) ne sont pas privés, ils sont publics, donc accessibles de partout. Quand je dis partout, je parle du QA. Un autre QA, une scène, etc, n'y ont évidemment pas accès. Ils peuvent juste appeler l'éxécution d'une fonction membre de QuickApp (via le mécanisme fibaro.call)

Oui, j'allais le dire, le type d'un module ne peut pas être changé ! name, visible, room, enabled, etc tout ça tu peux le changer sans souci par contre. La bonne pratique à mon avis est d'identifier chaque enfant d'une façon unique, avec un ID stocké dans une variable du module enfant. Par exemple pour Netatmo, chaque child est identifié par rapport à l'ID du module renvoyé par l'API Netatmo. Pour IPX800 et EDRT2, chaque child est identifié par rapport au numéro du port. Pour Surveillance Station, c'est l'ID de chaque caméra. Etc. Avec cette technique, les mises à jour du QuickApp devraient permettre de retrouver ses petits.

"Serious problem detected" <= ça c'est pour que les autres utilisateurs puissent trouver le message en question via un moteur de recherche, car la capture d'écran ne servira à rien pour le coup. Bref, plusieurs utilisateurs ont remonté ce problème sur le forum officiel, pas de réponse claire pour le moment.... si ce n'est contacter le support afin qu'ils procèdent à une analyse détaillée des logs.

De mon coté les icônes perso n'apparaissent jamais au premier changement d’icône, mais après 2 ou 3 fermetures/réouvertures de l'application... comme si elle ne faisait le rafraichissement que de temps en temps... Par contre pour les devices à plusieurs valeur (multisensor, comme les dimmers), l’icône c'est soit ON, soit OFF, mais l'appli ne montre jamais les valeurs intermédiaires, c'est bien pénible, car ça ne correspond pas au slider qui est juste dessous.

Bienvenue sur le forum

Ah si en plus il est moins cher il n'y a pas à hésiter ! Pour la garantie des vendeurs marketplace, là je ne sais pas trop...

Si ça peut t'aider à faire ton choix : https://smartrobotreviews.com/s/robot-vacuums/roborock-comparison-chart/ A priori le S5 Max semble mieux (normal, c'est le haut de gamme de la génération précédente N-1), à toi de voir si la différence de prix en vaut la chandelle.

This guy looks cool Oh wait, it's me.... very strange bug

Tu as bien créé ton utilisateur dans le panneau d'accès ? Avec un email correct, et défini un mot de passe ?

Le Zigbee devrait arriver en version Beta durant le 1er semestre 2022 aux dernières nouvelles. Donc d'ici à ce que ça fonctionne, j'espère que tu n'es pas pressé. Surtout que Matter & Thread vont remplacer le Zigbee à peu près à la même période, je trouve le timing de Fibaro particulièrement mal choisi. Le Bluetooth, aucune nouvelle depuis la sortie de la box. Et attention, il n'a jamais été question de proposer du Bluetooth, mais uniquement du Bluetooth Low Energy. Donc en gros les badges de détection de présence, en dehors de ça l'intérêt est assez limité. Enfin, si on voit un jour arriver cette fonctionnalité...

Peut être oui, mais pour l'instant je ne vois pas bien comment l'implémenter simplement. On pourrait l'appeler Between, mais dans ce cas on compare quoi ? Une propriété d'un module (et laquelle), une Variable, etc.... Normalement dans la logique GEA les comparaisons se font avec + - ! à la fin de la propriété à comparer. Là tout de suite je n'ai pas d'idée de quelle syntaxe adopter.

for, pairs, et ipairs, permettent tous les 3 de parcourir une table (en fait for est même plus générique que ça) ipairs() s'utilise avec les tables qui ont un index numérique => {"apple", "banana"} pairs() s'utilise avec les tables qui ont un index alphanumérique => {pomme = "apple", banane = "banana"} ipairs est préférable quand c'est possible car : - plus rapide - respecte l'ordre des éléments du tableau... ce qui n'est pas le cas de pairs car il parcoure la table dans un ordre indéfini qui peut changer à tout moment En terme de performance, for est le plus rapide de tous, mais la syntaxe est un peu plus lourde comme on le voit dans l'exemple ci-dessus, ça rend le code moins lisible, donc pas forcément conseillé. Je ne sais pas trop comment expliquer pour _, tu peux aller voir cet échange peut être que ça sera plus clair : https://stackoverflow.com/questions/34475995/variable-in-lua-has-a-special-meaning/34476522 Et là : http://lua-users.org/wiki/LuaStyleGuide

Que veux tu dire pas énumérer les modules ?

Bug dans le plugin Netatmo développé par Fibaro. Voilà une bonne excuse pour passer sur HC3

Tu peux compter le nombre d'éléments d'une table avec # Tes boucles sont une horreur ( ) car tu refais un appel à api.get à chaque passage dans la boucle... niveau performance c'est catastrophique. local parameters = api.get("/devices/"..Walli).properties.parameters for i = 1, #parameters do local parameter = parameters[i] if parameter.id == 10 then local brillance = parameter.lastSetValue print(brillance) break -- pour sortir immédiatement de la boucle, inutile de continuer end end On n'a pas besoin de i (qui est l'index, la clé, ou key en anglais), donc on met _ pour ne pas utiliser cette variable Du coup le code ci-dessous fait la même chose que le précédent : for _, parameter in ipairs(api.get("/devices/"..Walli).properties.parameters) do if parameter.id == 13 then local Brillance = parameter.lastSetValue print("La valeur est "..Brillance) break -- pour sortir immédiatement de la boucle, inutile de continuer end end

Pas à ma connaissance.

Peu importe ce que tu choisis à la précommande, tu peux modifier au moment de la commande finale. Je pense prendre aussi le modèle avec 2 extrudeurs. Ne pas oublier qu'il y aura des extras. Je prendrai un plateau poudré en plus de plateau lisse, et on verra bien les autres options qu'ils proposeront. Josef a confirmé qu'il y aura une "full-enclosure" en plus de l'espèce d’accordéon dépliable qu'on aperçoit (surtout utile pour les impressions type ABS... perso je n'ai jamais eu ce besoin) La full enclosure, on verra à quoi elle ressemble, sinon je me ferai mon propre meuble en bois massif + plateau lourd en béton. J'en ai marre des tables Ikea Lack empilées, c'est trop léger, ça vibre, ça résonne, ça se balance, c'est bruyant....

Chez moi ça marche Reboot ta box Sinon dans l'appli Netatmo, tu as bien les données ? Car ça peut aussi être la station qui est plantée, auquel cas il faut la rebooter.

Bienvenue sur le forum

Z-Wave il faut une box domotique (telle que la Home Center de Fibaro, mais il y a en a plein d'autres), mais ça te ferait mettre un pied dans la domotique, pas sûr que c'était ton intention à la base (Homekit ce n'est pas de la domotique... tout au plus des objets connectés.... même si les fabricants aiment bien jouer sur les mots... ahhh le marketing) C'est quand même un loisir assez chronophage et couteux (au début on se fit juste ça, puis de fil en aiguille on domotise tout dans la maison) Disons que Fibaro a senti le bon filon et a sorti une version Homekit de ses modules Z-Wave dont il est la référence sur le marché. J'imagine que ça ne leur a pas couté cher de sortir ces modules en version Homekit, sauf que du coup ils sont tous bridés. Ce qui les rend assez peu utile au final... bon après je suppose que pour piloter un radiateur en mode ON/OFF ça doit le faire. J'ai souvenir que l'autre forumeur auquel je pense, voulait ouvrir un portail, et c'était impossible car le module ne permettait même pas de faire une impulsion (ON/OFF très rapide). C'est quand même idiot. Le fil pilote ce n'est pas à toi de l'installer, il est dans le radiateur. Donc si demain tu changes, le nouveau aura le fil pilote (à coté du fil de phase et de neutre... la terre étant généralement absente sur tous les radiateurs modernes, car double isolation de classe II) Dans les maisons modernes, la norme NF-C 15-100 impose de faire remonter tous les fils pilotes au tableau électrique principal afin de pouvoir y installer un gestionnaire facilement. Mais ce n'est pas le cas dans les maisons anciennes, d'où le succès des micro-modules tel que celui de Qubino. On en installe 1 derrière chaque radiateur, ça communique sans-fil en Z-Wave avec la box domotique, et en quelques heures on a domotisé tout son système de chauffage à la maison, c'est quand même assez magique (la domotisation du chauffage est ce qui m'a fait venir à la domotique il y a 8 ans, car il n'existait aucune solution satisfaisant sur le marché à l'époque.... aujourd'hui non plus remarque, c'est assez désolant... les solutions type Nest et Netatmo n'étant pas adaptés aux radiateurs électriques)

Oui. Il faut attaquer l'API directement, mais tu peux faire tout ce que tu veux. Je l'ai fait pour 3 QuickApps partagés sur le forum : - Événements (le nombre de labels s'ajuste automatiquement (création/suppression) en fonction du choix de l'utilisateur (dans une variable du QA) - GEA Alarm (idem que précédemment) - Yamaha MusicCast (création automatique des labels et boutons en fonction des capacités supportées par l'appareil lors de la première découverte de celui-ci) Lire et modifier le design du QA, c'est relativement simple une fois qu'on a compris la logique de l'API. Ce qui est plus délicat, c'est la logique pour le gérer... on a vite fait de se retrouver avec un nombre illimité de labels dans un QA si on ne gère pas la détection correcte des labels déjà existants. Du coup l'essentiel de mes codes LUA tourne autour de cette logique, ça risque de le rendre peu lisible. Si tu regardes mes QA, je te conseille la lecture des 2 premiers que j'ai cité, car le 3ème est clairement beaucoup plus complexe.

Ouais le tarif l'éloigne définitivement des particuliers, sauf passionnés, mais la cible c'est plus les pros / semi-pros, clairement.