Lazer

Ah, j'avais loupé cette discussion (sur une partie du forum officiel où je ne traine pas...) ça a du sens, car @jang parle justement de l'instanciation de la classe QuickApp. Cela dit, ça n'explique pas pourquoi l'erreur apparait si le code LUA ne fait jamais référence à la variable QuickApp.logLevel. Je pense que c'est parce que, comme je tentais de l'expliquer plus haut, le code fait des appels pas très conventionnels à des fonctions d'affichage des logs (c'est à dire sans passer par self.xxx(...) ou hub.xxx(__TAG, ...), et c'est à l'intérieur de ces fonctions que l'erreur se produit. Mais comme ce sont des fonctions proposées par Fibaro, on n'a évidemment pas accès à leur code LUA. Je persiste à penser que c'est du code mal écrit par son auteur (en plus tu confirmes que c'est toujours le même), qui ne doit pas respecter les bonnes pratiques d'écriture de QuickApp à la mode Fibaro, si bien qu'après une mise à jour, ça fonctionne moins bien... J'ai fait une rapide tentative de reproduire le problème chez moi, avec des pcall() pour identifier la ligne qui pourrait poser problème, mais sans succès, je n'arrive pas à reproduire. En même temps, si on arrive à reproduire, c'est qu'on a trouvé l’instruction problématique et ça sera donc facile à corriger. Bref, sans se lancer dans un débogage complet du code des QA partagés par son auteur sur le market, la solution de contournement donnée fonctionne, mais je n'aime pas ça, ce n'est pas propre, à mon avis ça ne protège en rien contre de futurs bugs similaires. Espérons que l'auteur nettoie le code de ses QA.

j'ai ajouté l'instruction suivante dès le début de onInit() : print("self.logLevel =", self.logLevel) Et on obtient la valeur 4, qui correspond au niveau de log le plus détaillé TRACE. Ce qui signifie que par défaut, si on ne définit rien, ce sont l'ensemble des logs qui sont affichés, comportement identique à avant. Donc rien à faire pour conserver le comportement par défaut des QuickApp, la rétrocompatibilité est assurée A la réflexion, ce que je ne comprends pas ce sont les erreurs rencontrées par @fel-x Je n'ai aucun QuickApp ayant présenté ce comportement sur ma box de test, donc ce doit être des QuickApps que je n'utilise pas... aucune idée de comment ils ont été codés, mais probablement pas très proprement pour générer ce genre d'erreur. Ce qui aurait été intéressant que tu regardes, c'est essayer de comprendre l'origine de l'erreur (quelles sont les lignes qui déclenchent les erreurs) plutôt que de demander à une IA de te trouver une solution de contournement, qui n'est pas la bonne en plus.... EDIT : sur le forum officiel j'ai trouvé un seul message similaire, qui concerne un QA Velux dispo sur le Marketplace, que je n'utilise pas : https://forum.fibaro.com/topic/79615-unknown-error-occurred-no-static-loglevel-in-class-quickapp/

J'en ai profité pour faire quelques tests. Il ne faut pas le déclarer globalement comme l'a écris @fel-x plus haut, sinon c'est sans effet sur la suite du code : QuickApp.logLevel = 1 -- Ne pas faire ça Parce que dans ce cas on affecte la valeur 1 à la variable logLevel de la classe QuickApp, mais c'est sans effet sur l’instanciation de l'objet quickApp (notez la subtile différence de minuscule sur le premier caractère), hors cet bien cet instance quickApp qui portera tout le code LUA par la suite. Il faut le faire comme décrit par Fibaro, dès le démarrage du QuickApp dans la fonction onInit(), comme ceci : function QuickApp:onInit() self.logLevel = DEBUG end Attention, l'objet quickApp n'est pas encore initialisé lors de l'exécution de la fonction onInit(), c'est donc bien uniquement self qu'il faut utiliser pour initialiser la variable logLevel. Et plutôt que d'utiliser des chiffres, c'est mieux d'utiliser les variables prédéfinies en majuscule comme documenté par Fibaro. Toutefois je remets les correspondances des valeurs numériques ici : TRACE = 4 DEBUG = 3 WARNING = 2 ERROR = 1 NONE = 0 Dans l'ordre numérique inverse, ce qui me semble plus logique, en premier la valeur qui permet d'afficher un maximum d'information dans la zone de debug, et en dernier le plus restrictif, à savoir aucun affichage du tout. Ensuite, le fonctionnement est assez intéressant. Prenons cet exemple de code, j'ai tout mis dans la fonction onInit(), mais comme déjà précisé seule la définition de self.logLevel doit nécessairement s'y trouver, on peut très bien imaginer que l'affichage des messages peuvent se trouver dans différentes fonctions à la suite du QA : function QuickApp:onInit() self.logLevel = WARNING -- Affichage des logs de niveau WARNING minimum self:trace("self:trace") -- Pas de message self:debug("self:debug") -- Pas de message self:warning("self:warning") -- Message OK self:error("self:error") -- Message OK print("print") -- Message OK hub.trace(__TAG, "hub.trace") -- Message OK hub.debug(__TAG, "hub.debug") -- Message OK hub.warning(__TAG, "hub.warning") -- Message OK hub.error(__TAG, "hub.error") -- Message OK end Ce qu'on constate, c'est que la définition du niveau de log désiré se configure donc dans self.logLevel comme déjà vu, et en conséquence l'affichage des logs se fera ou non pour les différentes fonctions d'affichage de self.xxx(). Je ne sais pas si je suis clair, mais j'ai mis des commentaires dans le code LUA ci-dessus pour comprendre. Ce qui est logique, puisque qu'on a affecté logLevel à self, donc à l'instance quickApp. Tandis que les fonctions print() et hub.xxx(), étant en dehors du scope de l'instance quickApp, ne prennent pas en compte le niveau de log choisi : c'est à dire que les messages sont toujours affichés. Ce mode de fonctionnement est intéressant, car il permet dynamiquement, et très facilement, d'ajuster le niveau de log d'un QuickApp pour déboguer temporairement le code LUA. Exemple concret : Au démarrage du QA, dans onInit(), je configure un niveau WARNING, donc seuls les messages de niveau supérieur, à savoir WARNING et ERROR seront affichés par défaut. Sur mon QA, je crée 2 boutons, l'un donc le code LUA permet uniquement de descendre le niveau de log à TRACE, et l'autre de remettre à WARNING. D'ailleurs on pourrait carrément imaginer l'utilisation d'une liste déroulante vu que c'est disponible depuis quelques temps dans les QA, et ainsi permettre à l'utilisateur de choisir précisément le niveau de log désiré. Et ainsi, dès que l'utilisateur clique sur les boutons, il peut dynamiquement jouer sur le niveau de verbosité de QA dans la fenêtre de log. C'est encore plus pratique que la technique que j'utilise depuis le début qui consiste à mettre une variable nommée debug dans les Variables du QA, car sa modification entraine nécessairement un redémarrage complet du QuickApp. Je vais m'atteler à modifier mes prochains QA en ce sens.

Pardon, je vais pousser mon coup de gueule, j'en peux plus des copier/coller des IA sur les forums qui racontent n'importe quoi (= inventer un truc, probable mais approximatif, donc faux) Que tu utilises l'IA pour tes usages perso aucun problème, mais merci de ne pas venir recopier les erreurs de ces IA sur un forum public (qui servira ensuite à alimenter une IA, qui aura encore plus d'hallucination soit dit en passant... tu vois l'effet pervers) Plutôt que d'avoir ce réflexe de demander à une IA peut être vaudrait-il mieux commencer par lire la doc officielle, pour une fois que Fibaro fait une communication, en plus sur cette même page !!! En occurrence, c'est en majuscule qu'il faut l'écrire, en effet si je prend l'exemple de Warning donné par l'IA, c'est une variable non définie (nil), alors que si on utilise WARNING tel que donné par Fibaro, on obtiens une variable de type number dont la valeur vaut 2.

En gros, oui à peu près, avec des câbles DAC actifs (amplifiés) Sinon 3m max. Souvent les câbles DAC sont utilisés au sein d'un même rack, c'est pratique quand tu as des switch "top of rack". L'interconnexion entre les racks et le coeur de réseau se fait en fibre après. Chez mes clients, dans les datacenters, le plus souvent c'est uniquement de la fibre, même sur de courtes longueurs.... ils ne s'embêtent pas à gérer des produits différents, c'est plus simple. Juste choisir la bonne longueur. En revanche, le 10G sur RJ45, je crois que je n'ai jamais vu en datacenter. Tout est en SFP que ça soit coté switch ou coté serveurs et baies de stockage, du coup, on retourne au choix DAC ou Fibre. Mais pour du résidentiel, je ne vois pas l'intérêt de s'embêter avec de la fibre, à moins d'être super motivé à tirer des fibres sur de longues distances dans le manoir/chateau....

Attention hein, je parle de câble DAC, ce n'est pas de la fibre. Un câble DAC c'est un câble twinax en cuivre, c'est la solution la plus économique, la plus performante, et la moins consommatrice d'énergie, pour relier des équipements entre eux (switchs ou machines). Mais on est limité par la distance (3m avec un câble DAC passif, un peu plus avec un câble actif), et c'est bien là le seul intérêt de la fibre optique : pouvoir couvrir de longues distantes. Non Tout comme je n'ai pas besoin de switch, d'ordinateur, de smartphone, d'internet.... c'était mieux avant, n'est-il-pas ? En fait, on le verra quand je présenterai mon infra en détail, le 10G c'est surtout pour les serveurs et accès Internet. Et c'est largement suffisant, ça coute moins cher, et ça consomme moins. Récemment on avait cette discussion sur un autre topic au sujet de la HC3, et j'expliquais que c'était un avantage que la HC3 soit en 100M et pas en 1Gb.

Perso je vais éviter autant que possible le 10GbE en RJ45. L'objectif c'est que tout le 10G soit sur câble DAC. D'où le switch Aggregation en coeur de réseau, et les 2 ou 4 slots SFP+ sur chaque switch 24 ports. Déjà ça coute moins cher, et surtout, le plus important, la consommation est largement inférieure. Car le 10G RJ45 c'est assez méchant.

Oui c'est l'objectif. J'ai un Unifi Switch Aggregation en chemin, qui sera mon cœur de réseau sur lequel viendra aussi se connecter le Cloud Gateway Fiber déjà en fonctionnement, et idéalement il me faudra aussi un Pro Max 24 PoE.

En fait je voulais partir sur de l'AMD ZEN5, les Epyc 4005 qui sont sortis en 2025, car le rapport performance prix est imbattable, au moins 2 fois supérieur à Intel sur cette gamme de processeurs dédiés aux petits serveurs. Mais... l'absence d'optimisation énergétique, et donc la consommation électrique au repos, m'ont fait peur. Du coup, je reste sur une valeur sure, Intel Xeon 6300, qui est déjà largement plus performant que le Xeon E3-1265L v2 de mon HP Gen8 actuel. Mais... quoi qu'il en soit, la consommation électrique sera largement supérieure à mon serveur actuel, ne serait-ce parce qu'il y en aura 3 déjà. Bon, ça ne veut pas dire que ça consommera 3 fois plus, mais j'estime à environ 2 fois plus. Mais ça, on verra en pratique le moment venu. Après... la consommation électrique n'est plus vraiment un problème dans mon cas, entre les panneaux solaire et la batterie, je suis autonome environ 6 mois par an. Reste les 6 autres mois, mais vu que cette consommation génère de la chaleur, qui chauffe la maison, au final ce n'est pas perdu. Et oui et aussi, c'est pas tant l'infrastructure serveur qui va faire monter la consommation, c'est surtout le réseau. Car passer du Gigabit au 10 Gigabit, ça fait sérieusement augmenter la consommation. J'ai déjà reçu un Unifi Pro HD 24 PoE, qui tourne à plus de 25 Watts sans rien connecté dessus ! Belle bête cela dit, totalement surdimensionné pour mon usage, donc absolument indispensable. J'en reparlerai du réseau.

J'ai choisi ASRock Rack (la gamme pro de ASrock), car la disponibilité de Supermicro en Europe c'est compliqué...

Ah oui en effet, j'avais pas fait attention aux dimensions Remarque, c'est du costaud, surement très durable.

Tiens au fait j'ai (encore) changé de boite, je suis retourné dans la même qu'avant, si tu t'en souviens. Promox : oui et aussi des outils "pro", comme le Datacenter Manager qui vient de sortir et permet de centraliser l'administration, le monitoring, les mises à jour, etc... bref les outils indispensables pour administrer une ferme de serveurs, qui manquaient jusque là. La 5G en backup avec IP publique (donc SIM M2M), plusieurs fibres, le SDWan tout ça c'est très bien en entreprise, mais complètement inaccessible aux particuliers. Alors qu'un accès Fibre à domicile, avec une SIM 5G à pas cher d'un abonnement grand public (donc IP privée), on peut tous avoir ça pour pas cher.... mais comme dit, le souci, c'est que l'IP de la 5G est inaccessible depuis Internet, c'est du CG-NAT (Carrier-Grade NAT). C'est là que Cloudflare apporte un gros plus, et puis pour un usage perso c'est gratuit. Pour héberger de petits sites Web, c'est parfait à mon avis. Sinon, il y a plein d'alternatives plus ou moins équivalentes : Tailscale, Twingate, etc... Mais leur argument principal, ce n'est pas la gestion de la redondance des connexions, mais la sécurisation des connexions : filtrage en amont, etc. Encore une fois, quand je vois le désastre récent du groupe La Poste, je me dit que ces entreprises devraient faire quelque chose...

Il n'y a que le port 8000 d'ouvert sur ce portier ? Pas de port plus classique en 80 ou 443 ? Sinon la technique c'est de faire un telnet directement sur ce port TCP 8000, et tu vois quelle réponse tu obtiens.... si tu trouves une chaine de caractère caractéristique, c'est celle qu'il faudra mettre dans la configuration. Autre solution, utiliser le mode debug = true du QuickApp, je ne me souviens plus très bien, mais de mémoire il doit t'afficher dans le log toute la sortie détaillée obtenue après l'ouverture du port. Sinon, j'ai aussi en monitoring certains appareils qui ne répondent rien du tout sur leur port TCP, dans ce cas, je ne matche aucune chaine de caractère, la simple ouverture du port suffit à confirmer que l'appareil est encore présent sur le réseau. Un peu comme un ping.

Le 2nd rack existe déjà en fait, c'est le site de secours justement, mon garage qui est à 15m de la maison. Donc à part quand Poutine appuiera sur le bouton rouge, je suis à peu près protégé contre tout type de désastre (pas de tremblement de terre en IDF, et le jour où je serai inondé la TV montrera en boucle les images de la Tour Eiffel et de Montmartre qui dépassent de la mer ) L'alimentation électrique c'est prévu, 3 sources distinctes, pour chaque serveur. J'aborderai ça plus en détail ultérieurement, et c'est même la première réflexion qui m'a fait me tourner vers un cluster à 3 noeuds pour la haute disponibilité. Le nouveau rack, ça sera pour héberger le matos principal dans la maison, pas loin du rack des batteries.... (les batteries justement, alimentation redondante, tout ça, encore une fois on y reviendra plus tard) Cloudflare, c'est marrant car ça fait rire tout le monde depuis les 2 pannes mondiales récentes. N'empêche que ça apporte plein de bénéfices, dans mon cas : Amélioration de la sécurité : permet de fermer complètement les ports sur le routeur filtrage des requêtes web anti D-DOS (coucou la Poste, ils en auraient eu bien besoin ces 3 dernières semaines.....) Amélioration de la disponibilité : permet d'assurer le failover entre la fibre et la 5G, car en 5G on n'a pas d'IP Publique, donc impossible d'y héberger un site sans rebondir par un tunnel sortant vers un fournisseur externe, ce que Cloudflare permet nativement. Au final, quand on met tout dans la balance, Cloudflare apporte plus de bénéfice que de contraintes, même si sur le principe on aurait tendance à préférer se passer d'un tiers. Après, si Cloudflare est HS, c'est pas mes quelques sites Web perso et le forum qui feront grande différence, il y aura plus urgent. Proxmox commence à pas mal monter en force dans les entreprises, on a pas mal de client qui nous le demande, et dans les boites de services, pour l'instant on a des armées de consultants spécialisés en VMware, mais on manque de compétence en Proxmox. ça fait quelques années que je surveille l'évolution de Proxmox, et c'est impressionnant comment ça évolue dans le bon sens, tant pour un usage en production d'entreprise, qu'à la maison pour geeker. Monter ce cluster à la maison, outre couvrir mes besoins persos pour les 10-15 ans minimum à venir, permet aussi de me former à de nouvelles technologies. Et CEPH a aussi plein d'autres usages que le stockage hyperconvergé des hyperviseurs. Dans le monde scientifique notamment. Tu as eu bien raison (de la chance aussi, niveau timing) pour les licences perpétuelles versus la souscription, quelle plaie...

Si jamais cela peut être utile, j'attache à ce message la doc technique en PDF des prises Greenwave, je ne sais pas si elle se trouve encore en ligne. Technical Doc for the powernodes.pdf