Lazer

@mprinfo faisait une blague concernant les hub, ça n'existe plus depuis longtemps, c'était à la mode dans les années 90. Aujourd'hui on n'utilise que des switchs (=commutateur en français). La principale contrainte est de définir le nombre de ports dont tu as besoin.... selon le nombre d'appareils à brancher dessus. Vu ton expression de besoin, je dirais que 8 ports sont suffisants. Pour la marque, pour rester simple, je te dirais bien de prendre le premier que tu trouves de marque Netgear ou D-Link, ce sont des valeurs sûres en grand-public. Après le modèle... peu importe, prend le moins cher que tu trouves... sur Mamazon, Fnouc, ou tout autre magasin de ton choix. (et pour @mprinfo : non je ne conseillerai pas d'Unifi à un débutant ) Ensuite pour ta box internet, elle est en 2 boitiers ? Un routeur (avec la connexion Fibre/ADSL) et le lecteur multimedia (connecté à la TV) ? Si tu as un routeur dédié, c'est lui qu'il faut installer dans le coffret réseau du garage... mais du coup, s'il a un switch intégré, tu n'as plus besoin d'acheter un switch dédié, sauf si tu as besoin d'un plus grand nombre de ports RJ45.

Un switch non ? Aurais-tu un schéma, même simplifié, car je ne suis pas certain de bien comprendre où est installée ta box Internet. Normalement dans une telle installation, l'idée c'est d'installer les box Internet (qui dispose d'un switch interne) dans le coffret de communication, puis de distribuer le réseau vers les différentes pièces de la maison. Donc dans la salle à manger, tu peux ainsi brancher ta TV sur la prise murale prévue. Et dans les chambres, les PC ou autre TV, lecteur multimédia, etc.

Graphique de la journée parfaite du 25 mai, où j'ai produit mon nouveau record à 40 kWh. On voit la courbe totale, et les courbes des 2 champs PV : Sud-est : 6 panneaux Nord-ouest : 10 panneaux Donc forcément, la courbe NO monte plus haut que la courbe SE, mais ce qui est intéressant de constater, c'est le décalage des productions dû à l'orientation par rapport au soleil : Sud-est : maxi vers 13h Nord-ouest : maxi vers 14h30 A noter que chez moi, le soleil est à son zénith vers 13h45. La courbe résultante est une belle cloche. On constate un léger plateau sur les 2 courbes, lié à l'écrêtage des micro-onduleurs. Mais c'est très léger (c'était beaucoup plus marqué 1 semaine plus tôt), et d'ailleurs invisible sur la courbe globale. En effet, il a fait déjà relativement chaud ce 25 mai, température moyenne à l'ombre de 16,9°C et maxi à 22,9°C, mais donc beaucoup plus en plein soleil.... comme ce fut une journée parfaite sans nuage, les panneaux n'ont jamais pu refroidir. Sachant que le rendement maximum d'un panneau est donné pour une température de 20°, et qu'il baisse au dessus, on constate que même une température max de 22,9°C a une grosse influence sur la puissance maxi du panneau.... puisque pour rappel, mes panneaux font 405 Wc, mais les micro-onduleurs écrêtent à 295 W, comme on constate un léger plateau sur la courbe, la puissance délivrée par le panneau est à peine au dessus. Je me souviens l'année dernière en pleine canicule que la puissance était très fortement impactée, j'essaierai de faire des graphs comparatifs cette année. Lever du soleil : 05:57 Coucher du soleil : 21:39

Elle existe la fonction fibaro.debug() dans les QuickApps ? Etrange... en tout cas elle ne fonctionne pas comme attendu, vu ton log je soupçonne qu'elle utilise la même syntaxe que dans les scènes, avec le 1er argument pour le TAG, et le 2nd argument pour le texte à afficher. Vu que tu as un résultat nil, ça semble correspondre (tu n'as pas mis de 2nd argument) Utilise plutôt la fonction prévue dans les QuickApps : self:debug() Problème, self est inconnu car ta fonction sendResquest est locale, et non membre de la classe QuickApp. Donc tu as plusieurs options : mettre ta fonction sendRequest dans QuickApp (perso c'est ce que je ferais) function QuickApp:sendRequest(position) attention dans ce cas l'appel de la fonction depuis les boutons se fera comme suit : self:sendRequest("Boite") passer self en argument de cette fonction local function sendRequest(self, position) attention dans ce cas il faudra passer self en 1er argument lors de l'appel de cette fonction : sendRequest(self, "Boite") ou bien utiliser directement quickApp (sans la majuscule, c'est une variable globale qui pointe sur l'instance de ton QA.... perso je ne suis pas fan et je n'utilise cette technique qu'en dernier recours) quickApp:debug("Response: " .. response.data) C'est un peu compliqué tout ça, je n'ai pas trop le temps / courage d'entrer dans les détails, mais tous ces sujets ont déjà été largement étudiés en profondeur sur le forum... noyé dans les différents topics !

Je pense qu'il faut jouer sur le paramètre de protection des commandes locales. Sur ta box, dans les propriétés du module, tu as une case à cocher normalement... tu utilises les outils de dév de ton navigateur pour regarder quelle est la requête utilisée, puis tu peux le reproduire en LUA. Ou bien via GEA, normalement il y a une action dédiée pour ça. Ensuite, il suffit de se faire un scénario qui active / désactive les commandes locales 2 fois par jour.

Le printemps étant enfin arrivé depuis 15 jours, mais alors bien comme il faut, plusieurs jours de ciel bleus, parfois quelques nuages, mais toujours très beau ça change d'avril et la 1ère quinzaine de mai qui étaient pourris comme jamais... Du coup, la production est fantastique, avec seulement 16 panneaux vu que je n'ai pas encore fini d'installer les 4 derniers. Un petit record à 40 kWh tout pile le jeudi 25 mai, et la majorité des autres journées oscillent entre 35 et 39 kWh. Et aujourd'hui, record d'injection à presque 28 kWh. Du coup, mes statistiques de consommation (bleu) versus d'injection (orange) vers le réseau, j'adore gagner plus que je ne dépense Quasiment aucune consommation en heures pleines (bleu clair), majorité d'heures creuses (bleu foncé), vu que ce sont des jours bleus, ça ne représente pas grand chose comparé à ce que je vend à JPME. (en jaune c'est le cout de l'abonnement Tempo EDF) :

Ah ouais, c'est violent le CPU

Il y a des tonnes de conditions et d'actions dans GEA qui "ne servent à rien".... mais si elles existent, c'est qu'à un moment donné, elles ont servi à au moins une personne. Tu peux relire les 482 messages de ce topic, ainsi que ceux dédiés au développement de GEA sur HC2 puis HC3 pour retrouver l'historique complet de la genèse de GEA. Bon courage Intéressant... même si je trouve ça étrange comme façon de procéder. Donc tu as vu, il enchaine 3 actions. Essaye de reproduire à l'identique dans GEA, avec 1 appel de "Call", puis 2 appels de "Property", tout ça dans les actions de la même règle GEA. GEA exécute les actions d'une règle séquentiellement, dans l'ordre dans laquelle elles sont données. Et bien sûr, avec 1 seul ID, vu que "Call" ne supporte qu'un seul ID.

L'erreur te dit que tu appelles la fonction fibaro.encodeBase64() en ligne 11 mais elle n'existe pas. Voici la fonction que tu peux intégrer dans ton code (trouvée sur le forum) : local function encodeBase64(s) -- http://lua-users.org/wiki/BaseSixtyFour local bs = { [0] = 'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z','a','b','c','d','e','f', 'g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z','0','1','2','3','4','5','6','7','8','9','+','/', } local byte, rep = string.byte, string.rep local pad = 2 - ((#s-1) % 3) s = (s..rep('\0', pad)):gsub("...", function(cs) local a, b, c = byte(cs, 1, 3) return bs[a>>2] .. bs[(a&3)<<4|b>>4] .. bs[(b&15)<<2|c>>6] .. bs[c&63] end) return s:sub(1, #s-pad) .. rep('=', pad) end PS : ton code brut, non formaté, le rend illisible donc je n'ai pas essayé d'étudier le reste. Pense à utiliser les balises d'insertion de code la prochaine fois.

Essaye de contacter l'auteur de ce QuickApp via le marketplace de Fibaro, car je doute qu'il intervienne ici.

Nouveau panneau de diagnostique Z-Wave (pour le moteur v2 uniquement pour l'instant). Malheureusement je manque de modules Z-Wave sur ma box de test, ce n'est pas représentatif :

Après la mise à jour, le navigateur est redirigé vers la page 404, qui retourne une erreur... 404 Bug magique Il suffit de retaper l'adresse normale de votre HC3 pour retrouver l'accès.

Dommage en effet. Bon après c'est Qubino, leurs modules ne sont pas réputés pour avoir les firmwares les plus fiables qui soient. Sans compter que Qubino refuse de partager le firmware pour les modules fil pilotes... J'avais relaté mon expérience quelque part sur le forum, un stagiaire avait faillit m'envoyer la mise à jour, mais pas de chance la semaine suivante son chef était revenu et m'avait envoyé balader...

Merci pour ces tests. Mais du coup, j'ai un gros doute là, tu as déjà réussi à modifier la couleur de l'anneau ? Que ça soit en mode bloc, en modifiant le paramètre Z-Wave directement, ou par une autre méthode ? Parce que là j'ai l'impression que tu passes du temps sur GEA alors que si ça se trouve, le problème est ailleurs, au niveau du module... déjà comme tu le soulignes doublement, le nombre d'argument à 0 pour l'action setRingsLightMode, ainsi que la propriété ringLightMode qui reste toujours sur off, ça ne semble pas normal. Je te l'avais dit plus haut, il faut comprendre le fonctionnement de ton module, en LUA s'il le faut, avant de s'attaquer à GEA. Je le rappelle, GEA est juste un "Gestionnaire d'événements automatiques", un moteur de scénario, il ne fait rien de plus que de s'appuyer sur les mécanismes mis à disposition par Fibaro sur la HC3.

Oui les scènes en mode bloc sont ultra limitées. Généralement sur le forum, quand on commence à aborder la question des scénarios évolués, on conseille de regarder du côté de GEA, qui ne nécessite pas l'apprentissage du LUA

OK merci, j'analyserai ça dès que possible. En attendant tu as pu faire le test du Call avec 1 seul ID ? En fait, QA ou module physique, c'est pareil. Si tu modifies la propriété "value" d'un QA, la fonction setValue (ou turnOn, ou turnOff, etc) ne sera pas appelée, et le QA n'aura donc pas agit sur l'appareil qu'il est censé commencer (généralement un appareil sur IP) La bonne pratique pour agir sur les modules (qu'ils soient physique ou virtuel), c'est toujours de passer par les actions (listées comme telles dans le JSON du module) car cela va exécuter le code situé dans la fonction correspondante. A noter, comme je l'ai déjà dit de nombreuses fois sur le forum, toutes les fonctions membre de la classe QuickApp sont automatiquement exportées, dont on peut considérer que ce sont des actions, bien qu'elles ne soient pas nécessairement listées dans les actions du JSON. En revanche, il y a certaines propriétés qui sont juste là pour faire joli... par exemple les champs manufacturer, model, etc... si ça t'amuses, tu peux les modifier en direct, pour le coup ça ne passe pas par une fonction. Mais tout cela n'est pas lié à GEA, c'est lié au fonctionnement général de la HC3.

Bienvenue sur le forum

Si tu ne sais pas, c'est que tu n'en as pas besoin C'est ce qu'on faisait avec les fake devices par exemple, mais c'est du passé, depuis qu'on a les QuickApps, on peut coder proprement.

Un onduleur sur une ligne où tu as des modules fil pilote, et donc des radiateurs électriques ? C'est un monstre de puissance ton onduleur ? Sinon essaye peut être la valeur 1 pour ce paramètre n°30, pour voir dans quel mode il se remet après la coupure de courant.

Bienvenue sur le forum

"unsigned int" généralement. Regarde ce qu'il y a dans la doc de ton module, est-ce que les valeurs permises peuvent être négatives ou bien hexadécimal ? Dans ce cas il faudra choisir le type correspondant.

Ce module 462, c'est un parent ou un enfant ? Est-ce que tu peux essayer avec l'ID du module parent. Ensuite, tu dis que tu as systématiquement un message d'erreur, mais si tu ne dis pas lequel, tu avoueras que c'est compliqué de t'aider Profites en pour activer toutes les traces de debug. Dans la fonction config de ton fichier de config, tu ajoutes les 2 instructions suivantes : GEA.debug = true GEA.lldebug = false Et avant de lancer le test, isole la règle qui fait la modification de paramètre, car le log sera très verbeux, il ne faut conserver que l'essentiel.

Oui tu peux toujours définir manuellement les paramètres des modules Z-Wave, même si la box ne propose pas de template par défaut. D'ailleurs tu peux définir le paramètre et cocher la case "lecture seule" pour interroger le module et ainsi découvrir la valeur courante du paramètre.

Euh... Non... en fait pas sûr de bien comprendre ta demande. Mais si tu veux débugguer le fonctionnement du module, ce n'est pas GEA qu'il faut utiliser, mais le faire à la main en LUA dans une scène dédiée, pour bien comprendre la logique du fonctionnement de ces modules (vu que je n'ai ni Walli Controller, ni BSO, je n'ai aucune idée du comportement attendu) Une fois que c'est au point, même conseil qu'hier, tu pourras le retranscrire dans GEA. Normal, je n'ai expliqué hier pourquoi. Modifier les propriétés d'un module n'agit que sur sa représentation dans la DB, mais ne déclenche aucune action sur le module Z-Wave proprement dit. Et là je viens de comprendre pourquoi, en allant lire le code source. C'est une limitation de GEA, l'action Call ne peut pas prendre un tableau d'ID. Essaye avec 1 seul ID, et ça devrait fonctionner. Si c'est OK, je verrai pour modifier GEA afin qu'il prenne plusieurs ID. PS : la doc de syntaxe ne donne qu'une seul ID pour cette action Call, il n'y a pas d'exemple avec plusieurs ID... du coup la doc est correcte.

Non. Il faut chercher.... pas évident du tout. Souvent quand ça se produit, c'est un scénario qu'on a oublié dans un coin et qui continue d'agir sur les modules. J'ai eu un cas une fois (avec un Wall Plug), c'était une association fantôme qui s'était créée entre 2 modules... j'ai mis plusieurs mois à trouver l'origine du problème !!! C'était sur HC2, qui a connu des firmwares par franchement stables, j'ose espérer que ça ne se reproduira jamais sur HC3.