Toute l’activité

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)

Ah vraiment... ils ne peuvent pas intervenir à distance ? Bon je vais croiser les doigts et espérer qu'ils soient coopératifs. PS : Je tourne sur Jeedom depuis de nombreuses années, avec depuis peu une toute petite partie sur Home Assistant. C'est une box que je souhaitais utiliser pour mettre à jour le firmware de mes nombreux modules Fibaro.

On ne peut plus mettre les boxs à jour soit même, il faut envoyer en SAV pour le faire, malheureusement. J'ai du le faire pour une de spare que j'avais acheté il y a qques temps : Si version trop ancienne, tu ne peux plus monter.

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.

Yes, tout à fait. Mais comme dit, gâche de serrure en entrepôt ça survit pas longtemps

J'ai bien fait un factory reset dont voici la procédure : https://manuals.fibaro.com/knowledge-base-browse/recovery-mode-on-home-center-lite/ Mais si j'avais un fichier d'un firmware récent, je pourrai utiliser l'option du milieu : repair from file

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.

Bien la aussi tous en POE, seul la serrure est alimenté en 12V

ma vue est merdique, mais il ne me semble pas y avoir lu qu'on parlais de "Factory reset" (et ici il parle de factory reset via le mode recovery, cétait juste pour être sur qu'il avait bien commencé par un Factory reset.)

@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....)

Support contacté par mail, je vous tiendrai au courant. Après si l'un d'entre vous retrouve un firmware dans ses archives, je suis toujours preneur :-)

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.

Merci pour ton aide. Tu as raison, je vais tenter de contacter Fibaro en espérant qu'ils soient coopératifs.

J'vais ceci dans ma doc, http://updatehcl.fibaro.com/<# version 4.083> mais il faut maintenant un compte. Autre idée : demande au support Fibaro de t'aider/t'envoyer ce que tu veux

J'avoue avoir déjà essayé l'IA pour essayer de m'en sortir. Factory reset déjà fait. Mais impossible de trouver un firmware, d'où ma demande.

n'en déplaise à certain, l'AI donne parfois des solutions intéressantes (à interpréter, évidemment). Je commencerait par un "factory" rest. recherche Google : Factory reset Fibaro HCL ensuite download du firmware:

Bonjour, Je rencontre un soucis avec une box Home Center Lite que je viens d'acheter d'occasion. N'ayant pas les login et mdp de connexion, j'ai voulu faire un recovery. Hors la version local est 3.601. La box reste donc après ricovery bloqué sur la page 503 server unavailable. Je suis bien embêté :-(. Après recherche, il faudrait que je puisse updater la box avec un fichier de firmware récent, à priori : 4.120 ou 4.130 ou 4.150 ou 4.180 ou 4.600 oi 4.630. Est-ce que l'un d'entre vous aurait ce firmware et pourrait me le transmettre ? Merci pour vôtre aide.

Top, nous on pose ça au boulot (Par contre on met juste des lecteurs de badges NFC). Et on utilise pas de serrure, je suis pas fan car trop de casse, du coup on a pris leur système avec aimant, qui fonctionne au top et toujours alimenter en POE+ : Un seul cable RJ sur le switch POE+ gère une porte au complet, juste top de chez top en câblage.

Après moi je n'ai pas de datacenter

suite a mes problème avec mes danalock: Je viens de mettre une serrure abloy slim atic sur la porte du RDC https://www.faille-industrie.fr/controle-d-acces/verrouillage/serrures-electrique/serrure-electromecanique-encastree/serrure-kel467-p64618 Je l'ai récupéré sur un de mes chantier (car hors de prix pour un particulier) Je viens de recevoir de chez unifi un G6 Entry, qui a la possibilité d'ouvrir la porte soit par identification facial, soit par wallet sur un iphone ou apple watch, soit par carte NFC, soit par identification de plaque numérologique Il est aussi possible de recevoir les appel sur smartphone et de prendre la conversation et d'ouvrir la porte a distance, ou sur un intercom unifi https://eu.store.ui.com/eu/en/category/door-access-readers/collections/doorbell-entry/ products/uvc-g6-entry?variant=uvc-g6-entry Et j'ai ajouté un Door Hub Mini pour le déverrouillage de la serrure https://eu.store.ui.com/eu/en/category/all-door-access/products/ua-hub-door-mini Je rajouterais un smart implant pour connaitre l’état de la serrure, verrouillé ou pas (pênes sortie), et la possibilité d'ouvrir la port avec la HC3 avec la sortie du smart implant Je rajouterais plus tard un intercom unifi https://eu.store.ui.com/eu/en/category/all-door-access/products/ua-intercom-viewer Si tous est concluant je ferais la même chose pour le portail, G6 Entry + Door Hub Mini il me restera a remplacer le danalock de la porte d'entrée par un nuki V1, ou V2 pour clore le chapitre contrôle d’accès Dommage qu'il n'y est pas de système filaire pour gérer un cylindre européen, pour tous avoir avec la solution unifi

Merci pour ses réponses, je vais essayer de trouver une serrure+ bridge en V1, si non je tenterais une V2

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.

Ce sont 3 QA du même auteur : https://marketplace.fibaro.com/items/openweather-weather-provider https://marketplace.fibaro.com/items/sma-pv-power-sensor https://marketplace.fibaro.com/items/sma-pv-energy-meter Je l'ai prévenu personnellement. Car je ne trouve rien dans son code qui tente de régler le niveau de debug... Une autre QA qu'il a écrite (https://marketplace.fibaro.com/items/velux-active-shutters-integration) a été rapportée avec le même bug, mais je ne l'emploie pas. On est bien d'accord, ce sont uniquement des QA proposées par lui qui plantaient à la mise à jour, et les miennes par exemple, ou GEA en l'occurence n'ont aucun problème.