Lazer

Pour moi c'est vite vu, la XL corrige tous les petits trucs qui me prenaient la tête sur la MK3 : - autoréglage de la 1ère couche (pratique quand on bascule souvent entre les 2 plateaux (lisse/poudré), ou qu'on change de buse (0.4 et 0.6mm)) - détection de bouchage de la buse (j'ai eu plusieurs fois le cas avec des PLA Bois, et TPU) - meilleure homogénéité de chauffe du plateau (responsable du warping) Bref, tout ce qui a pu m'occasionner des impressions ratées ou de mauvaise qualité. On se rapproche de l'imprimante plug and play sans aucun réglage @Nico ah top ça il faut que tu nous fasse un suivi du chantier sur ton topic bricolage

Énorme oui, mais elle ne "déborde" pas pendant l'impression, car le plateau est fixe. Du coup l'encombrement devrait être similaire, ou à peine plus grand, que la MK3. En fait elle sera plus large, mas pas plus profonde je pense. Le changeur d'outil est automatique, donc tu peux charger des filaments différents, et le changement se fera automatiquement en cours d'impression.

Elle n'est pas nouvelle, mais j'ai trouvé que la possibilité de lui passer des paramètres permettait de la rendre plus facile à utiliser L'exemple du calcul d'une valeur moyenne est assez parlant. Précision : le nombre de paramètre est indéfini, et peut aller de 0 à N, on n'est pas limité à 2 comme dans cet exemple.

HEIC c'est un nouveau format d'image plus optimisé que le JPEG (qui commence à se faire vieux)... poussé fortement par Apple. Et c'est là que je viens de tilter... Apple... référence d'un module Fibaro inconnue... et bingo, c'est du Homekit, le protocole propriétaire d'Apple, pour lequel Fibaro avait sorti quelques modules à l'époque. Je ne savais même pas qu'ils étaient encore en vente. En tout cas, j'arrête là les conseils avec ces modules, ils n'ont rien à voir avec les modules Z-Wave bien connus. La dernière fois que j'ai conseillé quelqu'un, on a passé un temps fou avant de comprendre que le module en version Homekit ne faisait pas la même chose que le module Z-Wave soit-disant équivalent... et l'utilisateur en question n'a pas pu mettre en oeuvre son projet. Donc plutôt que de conseiller un truc qui risque de ne pas fonctionner, je préfère m'abstenir. Désolé @PlatyGued Bon courage avec ton module Homekit... sinon tu peux passer en Z-Wave... d'ailleurs j'espère que tu es bien conscient de la différence.

Un peu que je l'ai vu passer J'ai précommandé 10 minutes après 2 ans qu'on l'attend cette XL ! Clairement le prix a énormément augmenté par rapport à la pré-annonce, mais entre temps la crise des composants est passée par là Finalement malgré la hausse je vais quand même l'acheter, car vu les tonnes de fonctionnalités embarquées, je vais revendre la MK3s, et la XL sera bonne à tout faire. En mieux d'ailleurs, je n'en doute pas

HEIC.... c'est bien gentil les formats modernes, mais ça ne s'affiche pas sur les navigateurs. Tu peux mettre en JPEG, c'est universel ? ça nous permettra de voir l'image sans devoir ouvrir dans un éditeur externe.

Voici GEA version 7.36 : La condition "Climate" peut maintenant être utilisée en déclenchement instantané (avec une durée = -1) L'option "Function" peut maintenant recevoir des arguments en paramètre Remarques : Attention avec les triggers sur Climate, j'ai l'impression que la HC3 le gère étrangement, dès que l'une des zones de climat change, un trigger est déclenché pour toutes les autres zones.... ça risque d'amener à des résultats surprenants dans GEA. Les paramètres passés en argument de Function permettent de réaliser simplement des actions plus complexes avant. Par exemple, calculer simplement la moyenne de 2 valeurs : -- Affecte la moyenne de la valeur du module 74 et de la température de la météo au module ID 73 : GEA.add( {CONDITIONS}, 30, "", {{"Value", 73, {"Function", function(a, b) return (a+b)/2 end, {"Value", 74}, {"Weather", "Temperature"}}}}) De toute façon "Function" reste réservée aux usages très avancés de GEA, ça peut rapidement devenir très complexe. Copier/coller le contenu du fichier LUA téléchargé par dessus le fichier main dans le QuickApp (ou bien télécharger le QuickApp complet disponible en 1ère page). J'ai également mis la dernière version du fichier de syntaxe en 1ère page. GEA v7.36.lua

Oui en effet.... il faut vérifier si le fil est coupé au raz. Si c'est un très vieux radiateur, sans fil pilote et avec thermostat mécanique (mécanisme à bilame), dans ce cas aucun souci pour le piloter en tout ou rien avec le FGS. C'est ce que je fais sur des très vieux panneaux radiants qu'il me reste (30 ans quand même)

Je pense que ta question aurait plus sa place dans la section "actionneurs et ouvrants" du forum Et avec un petit schéma ça serait plus clair car c'est pas évident de se représenter les numéros des bornes dans la tête...

Euh, ben si je t'ai répondu pour les child

FGBHS ? Tu es sûr ? C'est FGS la référence Quoi qu'il en soit, ce n'est pas la bonne référence, un FGS c'est un relai qui va couper violemment l’alimentation de ton radiateur, et tuer prématurément l'électronique de son thermostat. Il faut utiliser le fil pilote, pour cela l'idéal c'est le module Qubino Fil pilote.

Bienvenue sur le forum

Parce qu'en regardant le JSON on voit bien qu'il s'agit d'une chaîne de caractères.

N'oublie pas les pieux au fond du trou, c'est important.

Modifier la propriété "dead" n'a absolument aucun impact sur le déroulement du code LUA dans le QA. C'est à toi de gérer cet état dans ton code... en gérant les tentative de reconnexion à l'appareil, etc. Le seul impact, il est visuel, et il est géré par la HC3 : elle va mettre à jour l'icône pour informer visuellement l'utilisateur. Dans le même genre, il y a le champ "enabled", qui est modifiable par l'utilisateur pour désactiver un module depuis l'interface Web. En pratique, cela ne bloque pas le code LUA, c'est au programmeur de gérer cet état. Tous mes QA depuis plus d'un an commencent par lire cette valeur, pour éventuellement stopper net leur exécution depuis le onInit() -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then tools.log(self, self.trad.disabled, 0) tools.updateLabel(self, "LabelDebug", string.format(self.trad.label_debug_error, self.trad.quickapp_disabled)) tools:warning("Device", self.name, "is disabled => QuickApp stopped") return end Une autre propriété intéressante, c'est "log" qui permet de choisir ce qu'on veut afficher dans la zone de texte sous l’icône du QA. Cela existe depuis les VD sur HC2 d'ailleurs.

Il me semble que dans le QA GCE je gère déjà l'état dead, mais pas le WakeUp forcé, car il n'était pas encore dispo sur les vieux firmware, à l'époque où je l'ai développé. Gérer l'état dead des child me parait tout aussi important que pour le parent, c'est ce que je fais en tout cas.

Vieux modules éloignés ? A coup sûr c'est le même problème qui a été documenté sur le forum depuis la sortie de la HC3, à savoir la vieille version du SDK bugguée qui est exploité dans le firmware de ces vieux modules Z-Wave (non +) La plupart des FGS, FGD, FGMS, etc d'ancienne génération Fibaro sont concernés dès qu'ils exploitent le maillage (trame qui est routée par un module intermédiaire) Ce problème est censé être résolu sur le moteur Z-Wave v3 de la HC3, sauf que pour l'instant celui-ci est encore en Beta, donc pas du tout conseillé. Bref, à part attendre, il n'y a pas grand chose à faire.... ou alors il faut être très motivé : déplacer les modules pour mettre les vieux à coté de la box, et les nouveaux plus loin...

Cool

Ah je crois que j'ai compris. Tu veux passer le module en état mort (= dead). Je ne suis pas certain de savoir de quelle pastille tu parles, mais lorsqu'un module ne communique plus, il passe donc en état mort. Son icône devient alors grisée avec un symbole radio de dysfonctionnement par devant. Tu peux donc modifier toi même la propriété "dead" de ton QuickApp avec updateProperty pour mettre true/false, exactement comme pour la value. Et tu peux même réagir aux tentatives de réveil : function QuickApp:wakeUpDeadDevice() tools:trace("Tentative de réveil") -- ... ici on tente de contacter le module via IP, Wi-Fi, etc... -- Puis on désactive son état mort : self:updateProperty("dead", false) end PS : exemple de gestion dans mon QuickApp Yamaha MusicCast. PS2 : au moindre problème réseau, le QA passe en dead, c'est un peu pénible... surtout pour les appareils connectés en Wi-Fi dont la liaison est instable par nature. Dans la prochaine version je mettrai un compteur interne et le QA ne passera dead qu'après 2 ou 3 tentatives de connexion infructueuse afin d'éviter le "bagotement".

Bienvenue sur le forum

Elle fonctionne ta règle ? La syntaxe de la condition me semble incorrecte. J'aurais juste mis ça : GEA.add(id["Capteur_Garage"], 10*60, "Porte de garage ouverte depuis plus de 10 minutes", {"Close", id["FGS-214"], 100})

Si tu trouves un modèle STL. Une recherche rapide de ZW074 sur Thingiverse ne donne rien, ce module est surement trop vieux, car on trouve au contraire plusieurs modèles pour les détecteurs plus récents.

Ben... euh... soit j'ai pas compris la demande... soit c'est juste la base de la base d'un QA de type binary (voir les exemples proposés par Fibaro par défaut lors de la création du QA) => self:updateProperty("value", true) (ou false) L’icône suivra toute seule, c'est la HC3 qui le gère EDIT : en fait après relecture c'est ce qu'à expliqué Fredmas juste au dessus

J'ai pas vraiment compris ton problème... Tu peux utiliser le compte principal administrateur depuis l'application, même si ce n'est pas conseillé (pour des raisons de sécurité, mais aussi parce que tu verras tous les modules, y compris ceux que tu n'as pas spécialement envie de voir depuis ton téléphone) Mais en dehors de ça, tout fonctionnera.

Remarque : aussi étrange que cela puisse paraitre, il faut passer une string en argument de updateView. Donc il faut parfois convertir la valeur si celle-ci est numérique. Exemple : local value = 50 self:updateView("slider", "value", tostring(value))