Lazer

Accès Internet Fibre Comme je le disais, j'ai profité en septembre 2025 pour passer en même temps sur un routeur UniFi Cloud Gateway Fiber et un abonnement Bouygues B&You Pure Fibre à 8 Gbit/s (avec Option Debit+ éligible). J'ai demandé au chat, gratuitement, la fourniture d'un ONT Nokia XS-010X-Q, ce qui me permet de me passer totalement de la BBox, rangée dans son carton (dommage, on paye quand même l'abonnement à 3€ par mois) Ainsi, je récupère l'IP publique directement sur l'interface réseau de mon routeur UniFi, plus pratique pour les accès VPN et Reverse Proxy (pas de double NAT), mais aussi pour la mise à jour automatique du DNS Dynamique par l'UCG-Fiber car l'IP n'est pas garantie fixe chez B&You (même si elle ne change jamais en pratique) Par ailleurs, par rapport à mon ancienne Freebox en mode Bridge, ça coute moins cher en abonnement mensuel, ça simplifie le câblage, ça prend moins de place dans le coffret, ça consomme moins et ça chauffe moins. Et aucun souci avec le réseau Bouygues, je n'ai eu aucune coupure, aucune baisse de débit constaté depuis 4 mois. C'est bien simple, c'est plus stable que chez Free (j'avais mis la Freebox V6 Revolution sur un Wall Plug pour forcer le reboot à cause d'un bug connu mais jamais résolu chez Free...) Que du positif Sur l'UCG Fiber, j'ai activé les protections de sécurité : Détection d'intrusion (IDS) et Prévention d'intrusion (IPS), en pratique j'ai autour de 5 Gbit/s réels lors des speedtests, même si je ne suis pas encore en mesure d'en profiter car mon réseau interne est toujours en Gigabit lorsque j'écris ces lignes. Pour encore plus de simplicité de câblage, et de réduction de la consommation électrique (l'ONT Nokia consomme et chauffe beaucoup, mesuré à 9 Watts à lui tout seul, à cause du port RJ45 à 10 Gbps, c'est pas pour rien que j'en ai parlé précédemment), j'hésite à le remplacer complètement par un SFP+ à insérer directement dans le routeur UniFi. Avantage, la fibre de l'opérateur rentre directement dans le routeur, sans aucun équipement intermédiaire. La procédure existe et est documentée, mais pas évidente, de plus il faut acheter le SFP+ qui n'est pas donné. Je donne quelques informations ici pour le référencement, peut être que j’approfondirai ce sujet ultérieurement. Il faut utiliser l'un de ces modules SFP+ XGS-PON : WAS-110 X-ONU-SFPP Quelques liens utiles : Masquerade as the Bouygues S.A Bbox with the WAS-110 or X-ONU-SFPP¶ [Forum lafibre.info] Remplacer sa Bbox Fibre par un équipement personnel Accès Internet 5G de secours Comme je l'ai mentionné précédemment, je souhaite ajouter un accès 5G de secours. C'est quelque chose que j'avais déjà eu par le passé, lorsque j'avais la fibre Orange avec une SIM 4G prêtée. J'avais alors acheté un routeur Huawei et c'est mon ancien routeur Ubiquiti EdgeRouter qui gérait le failover. J'avais arrêté lors du passage chez Free car ils ne proposent pas de SIM gratuitement. Maintenant UniFi propose une solution tout intégrée avec le modem UniFi 5G Max qui a en plus le bon goût d'être dual SIM si jamais on veut ceinture bretelle et parachute. Il est alimenté en POE, et peut donc être connecté directement sur l'un des ports 2.5G POE de l'UCG-Fiber, on peut difficilement faire plus simple ! J'attends qu'il soit de retour en stock pour m'en prendre un. Mais, le problème avec les accès 5G grand public, c'est que l'adresse IP n'est pas publique, rendant l'accès aux services hébergés à la maison inaccessibles depuis Internet lorsque la connexion bascule sur la 5G. Les opérateurs pratiquent le Carrier-grade NAT. La solution aujourd'hui est de se tourner vers des services comme par exemple Cloudflare. Il existe une offre gratuite pour les particuliers parfaitement adaptée à cet usage. Il y a un semble de service, mais j'y vois 2 avantages principaux qui me concernent : Rend les services hébergés à domiciles accessibles quelque soit l'adresse IP publique, en cas de changement d'adresse IP publique liés à l'opérateur Fibre, ou bien bascule sur la 5G en IP privée Apporte de la sécurité : filtrage des requêtes effectué par Cloudflare contre les attaques connues protège contre les attaques par déni de service (DDoS) masque notre adresse IP publique qui devient inaccessible par scan, sans connaitre le nom de domaine idéalement on peut carrément fermer tous les ports de notre routeur et devenir totalement invisible à tout scan. Inconvénient toutefois, on dépend d'un tiers, dont il faut avoir confiance tant pour la disponibilité (les pannes en 2025 ont fait pas mal de bruit), que pour la sécurité. En effet, pour que l'accès devienne possible depuis l'extérieur sans devoir ouvrir de port, il faut installer un service en local, dans un container, qui initie un tunnel chiffré sortant depuis notre réseau vers le réseau de Cloudflare. Ce tunnel devient alors la seule porte d'entrée vers notre réseau interne. Pour conserver un bon niveau de sécurité, au moins équivalent à mon niveau actuel, voire meilleur, je vais conserver ma DMZ (VLAN isolé), et je mettrait le point d'entrée du tunnel dans cette DMZ. Ainsi, toute connexion arrivant par le tunnel Cloudflare, continuera de passer par les firewalls (celui du routeur, et celui présent que chaque VM de la DMZ), et les 2 reverse proxy (un normal, et un avec filtrage applicatif WAF) A ce sujet, voici un schéma d’architecture, un peu ancien, de mon infra réseau, mais dans les grandes lignes ça n'a pas trop changé : On voit les flux https et OpenVPN qui rentrent dans la DMZ sur les Reverse Proxy, y sont filtrés, et si autorisés, peuvent aller vers les serveurs Web eux-mêmes également en DMZ, ou bien rentrer dans le LAN pour les services perso internes (box domotique, etc). Actuellement la redondance est assurée par une adresse IP virtuelle (protocole VRRP) entre les VM identiques qui tournent sur chaque serveur HP G7 et G8, mais ma nouvelle infrastructure serveur en haute-disponibilité sera l'occasion de faire évoluer cela. On y reviendra. Au final, j'estime qu'entre la connexion Fibre et la connexion 5G de secours, le passage par les services de Cloudflare, et la fermeture des ports sur mon routeur, j'obtiendrai une infrastructure qui sera à la fois plus résiliente, mais aussi plus sécurisée. Accès VPN à domicile J'utilise principalement OpenVPN, bien que ça ne soit pas la solution la plus performante du moment (c'est WireGuard qui est à la mode), elle présente l'immense avantage de pouvoir fonctionner sur le port 443, le même que les serveurs Web HTTPS. Sur mon serveur, j'ai un démon SSLH qui écoute sur ce port 443, et selon s'il détecte une connexion OpenVPN ou bien HTTPS, il redirige les paquets vers les démons OpenVPN ou HAProxy qui écoutent en local sur leurs ports respectifs. La finalité d'utiliser le port 443, c'est de pouvoir passer au travers la majorité des proxy filtrants en entreprise. En effet, certaines entreprises bloquent les ports autres que 443, ce qui empêche toute connexion VPN. Étant mobile dans le cadre de mes activités professionnelles, c'était un problème important pour moi. Passerelle SMS Cette passerelle SMS est utilisée par la domotique pour les notifications critiques. Cela fonctionne toujours avec un vieux smartphone Android, l'application JPI, et un abonnement Free Mobile à 0/2€ par mois. Je ferai des tests quand j'aurai le modem UniFi 5G, mais si je peux envoyer des SMS avec celui-ci, alors je pourrai arrêter la passerelle SMS actuelle.

Réseau local Voici le schéma de l'infrastructure que je vise à court terme : J'ai récemment reçu les switchs USW-Aggregation et USW-Prod-HD-24-PoE. Il me manque encore le USW-Pro-Max-24-PoE (dès que je trouve un prix correct), et le modem 5G de secours U5G-Max (quand il sera de retour en stock) Jusqu'à présent, le cœur de réseau, composé des 2 switchs Cisco et du routeur UCG-Fiber, se trouvaient dans mon coffret réseau fait maison dont j'avais partagé les photos sur mon topic de bricolage : Avec mes nouveaux besoins, notamment autour des serveurs dont on parlera plus tard, le cœur de réseau sera dorénavant éclaté en 2 endroits : toujours le coffret réseau et également un nouveau rack dédié situé à la cave. Raison pour laquelle on voit 2 gros switchs de 24 ports. L'objectif de tout ça est d'avoir un cœur de réseau en 10 GbIt/s (et même 20 G si on compte l'agrégation des liens, non représentée sur le schéma), et de pouvoir distribuer du 10 G entre Internet et les serveurs, et éventuellement vers les switchs dans les pièces de la maison, puisque tout le réseau est câblé en Grade 3s). Ou bien des vitesses intermédiaires de 2.5 Gb, largement suffisant pour des postes de travails. Important, on conserve la rétrocompatibilité 100 Mbps pour les périphériques légers (box domotique, caméras IP, etc) Et tous les ports des nouveaux switchs de coeur de réseau proposent du POE. Il y a quelques années je trouvais cela superflu, mais je me rend compte que mes besoins évoluent et que de plus en plus d'appareils sont maintenant nativement alimentés en POE (y compris les petits switchs de table), c'est tellement plus simple en terme de câblage électrique, et en plus on bénéficie de la redondance d'alimentation amené par l'onduleur (on y reviendra sur ce sujet tant il est important dans ma future infra serveur) Dores et déjà, j'utilise tous les ports POE de mon switch Cisco, donc j'ai besoin d'évoluer. C'est moins urgent, mais ultérieurement j'ajouterai des bornes Wi-Fi 7, mais ce n'est pas très urgent, je me satisfait des débits du Wi-Fi 5, car l'essentiel de mon réseau est construit autour du câblage, donc les PC et équipements critiques sont tous câblés. Le Wi-Fi sert pour les appareils mobiles (téléphone, tablette, console, etc), pour lesquels la stabilité est plus utile que le débit. Dans mon bureau, d'où je tape ces lignes sur mon PC, je manque de ports sur le petit switch US-8, il est probable que dans l'année je le remplace par un modèle plus conséquent, me permettant par la même occasion de passer en 2.5 ou 10 G. Parlons du 10 Gbit/s justement. On le voit sur le schéma, l'interconnexion entre les switchs se fait avec des câbles DAC (Direct Attach Copper), qui sont des câbles Twinax en cuivre avec un SFP soudé à chaque extrémité, et directement inséré dans un slot SFP+ disponible sur chaque switch. Avantage des câbles DAC : faible cout, faible consommation électrique (de l'ordre de 0.5W par connexion), faible latence Inconvénient : limité en distance : généralement maximum 3 mètres avec un câble DAC passif, au delà il faut un câble actif. De plus, leur forme avec SFP soudé rend le passage en gaine compliqué voire impossible. Raison pour laquelle, sur de la distance intermédiaire, on passe en câble cuivre à 4 paires torsadées (avec le fameux connecteur RJ45), ou bien en fibre optique (avec connecteurs LC venant se brancher sur un SFP+) qui peut potentiellement aller à des distances très importantes. Entre le coffret réseau situé dans l'entrée et ma cave située juste en dessous, j'ai moins de 3m de distance, donc pas de souci. En outre, j'avais anticipé il y a 1 an quand j'avais percé pour passer les câbles électrique de très grosse section pour l'installation onduleur + batterie solaire, en prévoyant large avec des gaines à grosse section en réserve. Mais le problème du RJ45 en 10G, c'est que ça consomme énormément, ça chauffe. J'ai personnellement mesuré 2 Watts par port avec un SFP+ RJ45 10G de chez Ubiquiti, mais sur les forums j'ai vu des gens qui rapportaient des consommation encore supérieure dans certains cas, notamment sur les anciennes cartes réseaux dans les serveurs. On y reviendra justement sur les serveurs, car justement le 10G sera connecté en câbles DAC pour une meilleure efficacité énergétique, une meilleure latence, et un cout financier plus faible. Je n'ai à ce stade pas l'intention de mettre de fibre optique chez moi.

Ici on va parler de mon Homelab Je vais décrire mon projet en cours de construction. Mais d'abord, un rapide rappel de l'existant, qui tourne depuis une bonne dizaines d'années. Réseau : Un mélange de 2 switchs Cisco en cœur de réseau (un switch de 28 ports 1Gb, et 10 ports POE), ainsi que divers petits switchs UniFi répartis dans la maison, et 3 bornes d'accès UniFi d'ancienne génération (Wi-Fi 5) Avant cela, j'avais des petits switchs Netgear, mais que j'ai remplacé au fil du temps par les petits switchs Unifi. Deux raisons à cela : instabilité des switchs Netgear (parfois des plantages : port qui passait offline), une interface Web d'administration d'un autre temps et incompatible avec les navigateurs modernes, rendant complexe la configuration dès lors qu'il fallait propager des VLANs. Les switchs CISCO, eux, sont parfaitement stables, et l'interface d'administration est fonctionnelle (Web et CLI). Le contrôleur UniFi a pendant très longtemps tourné dans une VM Linux Debian, mais depuis fin 2025 j'ai remplacé mon fidèle routeur Ubiquiti Edgerouter 5 POE après plus de 10 ans de bons et loyaux services (dont j'ai eu à remplacer la clé USB interne 1 fois, ce qui me rappelle la box Fibaro HC2) par un routeur UniFi Cloud Gateway Fiber, en même temps que le passage à un abonnement Bouygues B&You Pure Fibre à 8 Gbit/s. J'ai demandé la fourniture d'un ONT Nokia, ce qui me permet de me passer totalement de la BBox. Donc le contrôleur UniFi tourne maintenant dans la Cloud Gateway Fiber pour plus de simplicité. La gestion des mises à jour est également considérablement simplifié, 1 clic sur un bouton et 5 minutes après c'est terminé. Tandis qu'avec le contrôleur en VM, j'avais parfois eu des complications n"cessitant de bidouiller un peu (base MongoDB notamment), et de mémoire j"ai eu 2 fois besoin de restaurer la VM tellement ça c'était mal passé. L'objectif des évolutions à venir sera de basculer le réseau intégralement en UniFi, car l'administration centralisée depuis le contrôleur est vraiment simplifiée, ergonomique, et très complet (monitoring, etc) Remarque sur le routeur : j'ai attendu très longtemps avant de remplacer mon EdgeRouter par un UniFi Cloud Gateway, car d'une part, avant le UCG Fiber, je ne trouvais aucun modèle dont les caractéristiques matérielles me convenait (prêt à faire du 10 Gb, donc durable pendant quelques années), et d'autre part l'absence de Zone Based Firewall était un point bloquant, bien que ça existait déjà 10 ans avant sur la gamme EdgeRouter. Maintenant que la gamme UniFi évolue dans le bon sens, tant matériellement que logiciellement, j'estime que c'est le bon moment pour s'y investir à fond. Age des équipements : Cisco SG300-28 : 10 ans Cisco SG350-10MP : 8 ans UniFi AP 1st gen : 11 ans UniFi UAP-AC-PRO : 9 ans UniFi UAP-nanoHD : 7 ans Informatique : Deux micro-serveurs HP, un premier Gen7 N54L qui me sert de sauvegarde, et un second Gen8 avec un processeur Intel Xeon E3-1265L v2 qui me sert de serveur principal. Les 2 serveurs tournent sous ESXi 5.5, une ancienne version qui était 100% supportée (drivers, etc) avec ces générations de serveurs. Chaque serveur dispose de 16 Go de RAM, ce qui me limite actuellement pour de nouveaux besoins. Le processeur commence également à être limite lors de certaines tâches intensives. En terme de stockage, dans le G8, qui utilise une carte RAID Smart Array P222 j'ai actuellement 4 disques durs : 12 To, 20 To, 20 To, et 24 To. Soit un total de 76 To décimaux, ce que j'appelle des To "commerciaux". Lorsque j'achète un nouveau disque, après un test de surface pendant plusieurs jours, il remplace un disque existant qui va dans le serveur secondaire pour les sauvegarde. Je n'ai aucune grappe RAID, ce ne sont que des disques indépendant (JBOD, même s'ils sont techniquement configurés en RAID-1 de 1 seul disque à cause du principe de fonctionnement de la carte contrôleur RAID), c'est la sauvegarde sur le 2nd serveur qui apporte la sécurité des données. Mais outre la limitation en performance, je suis limité par le nombre de slots disques disponibles, raison pour laquelle je suis toujours obligé d'acheter la plus grosse taille de disque disponible, ce qui coute relativement cher. De plus, le matériel est vieillissant, j'ai eu un crash d'un vieux SSD Samsung qui contenait le datastore, et l'ILO commence à donner des signes de faiblesse (l'Intelligent provisioning et le Smart Array Manager ne sont accessibles au boot, je suis donc obligé de faire la configuration RAID en ligne de commande sous ESXi) Il est donc temps de faire évoluer ce serveur principal, vers une infrastructure plus performante, plus résiliente, et plus durable. Age des équipements : HP G7 N54L : 12 ans HP G8 : 11 ans A noter, le serveur principal est dans la maison, et le serveur de secours est dans le garage, physiquement séparé de la maison, ce qui apporte une bonne protection des données contre la majorité des désastres (vol, incendie, etc)

OK, on parle bien de la même chose, tu as restauré l'image de base (factory) qui est stockée dans une partition dédiée de la mémoire interne. Le terme "factory reset" n'a jamais existé chez Fibaro, bien que ça soit un terme souvent utilisé dans le langage commun. Après, même si tu pouvais écrire une image factory fraichement téléchargée depuis Internet, je ne suis pas sûr à 100% que ça fonctionnerait. Car à ce stade, rien n'indique que ça ne soit pas l'espace mémoire cible qui ne soit pas défectueux. Dans ce cas, tu aurais beau écrire toutes les images factory que tu veux, qu'elles proviennent de celle stockée en interne ou depuis Internet, ça n'y changerait rien. En attendant, comme dit, il faut attendre l'aide de Fibaro. PS : Le terme Factory prête à confusion. Littéralement ça veut dire usine, mais ça ne nous avance à rien, car les box vendues ont été fournies avec plusieurs versions usines. Dans la mémoire interne de la box, tu as plusieurs partitions. Pour simplifier on va en retenir 2 : - Une qui contient l'image de base (appelle là factory si tu veux) qui était celle disponible au moment de la fabrication de ta box. - Une partition de travail, c'est sur celle-là que le système boote, stocke ses données, icônes, etc. Quand on reboote la box en mode Recovery, on peut restaurer l'image de base sur la partition de travail. On peut aussi, toujours depuis ce même menu Recovery, charger une image provenant d'internet. Elle est "factory" aussi puisqu'elle vient de chez Fibaro.... mais à une version différente ! Ou pas d'ailleurs, car on pourrait très bien recharger la même version. En fait, les box Fibaro, ce sont de vrais ordinateurs. C'était particulièrement vrai avec la HC2. Pour un ordinateur, on n'utilise pas le terme factory reset, quand ça crashe, généralement on réinstalle complètement la machine... c'est assez similaire chez Fibaro finalement.

Il n'y a jamais vraiment eu de "Factory Reset" sur les box FIbaro, en fait c'est le passage en recovery qui permet de réinitialiser la box. Après il y a une histoire avec les boutons, selon comment on appuie dessus ça va conserver l'IP existante ou reconfigurer l'IP usine par défaut, je n'ai plus l'information exacte en tête mais ça se retrouvera facilement sur le forum ou sur Internet. Mais d'après son problème, étant donné que la box ne fait pas le recovery correctement, on ne peut rien faire de plus.... sans l'aide du support Fibaro. En plus, la HC Lite était une box bien fermée, une boite noire qu'on n'a jamais su dépanner (et pourtant, j'ai souvenir qu'il y en a eu un paquet des bugs sur cette box...), à l'inverse de la HC2 qu'on était capable d'ouvrir, de connecter un écran, rooter, réinjecter l'image du firmware directement sur la mémoire interne, voire même changer la clé USB pour les plus aventureux... souvenirs souvenirs. Donc, toujours pareil en tel cas, se tourner vers le support. L'espoir subsiste.

@jojo avait justement partagé quelques firmware sur un Drive à l'époque, et donné les liens sur le forum, mais c'était pour HC2 uniquement, box sur laquelle on avait l'habitude de bidouiller (à cause de la clé USB Recovery....)

Voilà Surtout quand elle te conseille de faire ce qu'il a déjà dit avoir fait dès le premier post. J'allais proposer l'URL de téléchargement direct, mais je me suis rendu compte en la testant de mon coté que les fichiers ne sont plus disponibles..... au moins ton expérience confirme la mienne ! Effectivement seule solution, voir avec le support Fibaro, en espérant qu'ils puissent encore la dépanner.

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

Merci @Nico c'est sympa Mais tu verras que "le" (pardon "les") serveurs que je prépare n'auront rien à envier à ton cluster VMware (d'ailleurs tu ne te fais pas exploser par les renouvellement de licences ?) : 3 noeuds Promox VE en cluster avec CEPH, réseau 10 Gbit/s (J'ai déjà l'uplink 8 Gb pour Internet), failover 5G, et sécurisation via Cloudflare. La partie hébergement de fichiers (NAS) tournera sur TrueNAS avec un gros filesystem ZFS. Le G8 servira pour la sauvegarde, et le G7 sera peut être définitivement arrêté... à voir. Le premier composant que j'ai acheté, c'est la RAM, début novembre, c'était déjà trop tard, mais vu comment ça a explosé depuis, je suis bien content de l'avoir fait.... Depuis j'ai acheté pas mal de choses, il me manque encore les processeurs, alimentations, et quelques bricoles. Ah oui, un rack 19" aussi....

Intéressant cette référence de produit.

Comme tout service dépendant du cloud..... Après, perso, chez moi ce n'est pas gênant, car l'essentiel de mes scénarios critiques ne dépendent plus des sondes Netatmo, notamment tout ce qui est température pour la gestion du chauffage. Il reste juste le pluviomètre pour lequel je n'ai pas (encore) d'alternative, on en avait parlé d'ailleurs, ça me sert d'alerte pour la fermeture des fenêtres en cas d'averse. Le reste, CO2, pression, bruit, etc, tout ça ne sont que des statistiques qui ne me servent dans aucun scénario automatisé.