Lazer

@Krikroff en parlant de Beta Privé, cette Beta là en cours qui est sortie il y a 2 mois, ne devait pas sortir en version stable quelques jours plus tard ? J'ai l'impression que Fibaro fait du .... Fibaro On ne sait pas trop si c'est stable, beta, ou betastable

L'utilisateur et le mot de passe ? Euh... J'ai pas souvenir de ça... tu es certain que tu n'utilisais pas une version que tu avais customisé ? Cela dit, l'idée n'est pas bête, je l'ajouterai dans une prochaine version En attendant, oui tu peux tester le code de retour... 401 est le code qu'on reçoit le plus souvent quand le login est incorrect/manquant. C'est ce que j'utilise en tout cas chez moi.

J'avais lu une discussion, ils conseillent de laisser en AUTO car la borne adapte sa puissance en fonction des équipements clients, mais aussi des autres bornes (en fonction des superpositions de canaux) Si tu forces low/medium/high, le risque c'est de dégrader ton réseau, et de reporter l'effort d'émission sur les clients, donc exactement l'inverse de ce qu'on cherche à faire en général. Donc c'est un option à réserver aux experts qui savent exactement ce qu'ils font. Bref, comme souvent, quand on ne sais pas, on laisse AUTO

Si tu coupes le Wi-Fi de la borne, il est impératif que vous mettiez vos téléphone en mode avion, ainsi que tout appareil Wi-Fi qui serait proche de la chambre, comme une station météo, un réveil, un assistant vocal, une TV connectée, etc... Comme tu dois le savoir, le plus gros émetteur d'ondes ce n'est pas l'antenne Wi-Fi/GSM/3G/4G/5G, mais le téléphone (plus précisément, l'antenne émet plus d'onde dans l'absolu, mais ce que le corps reçoit provient du téléphone car il est tout proche du corps... la puissance reçue est divisée par 4 à chaque fois qu'on double la distance... et l'antenne est très loin) Et quand tu coupes la bornes Wi-Fi la plus proche, le téléphone doit émettre d'autant plus fort pour aller chercher une borne plus éloignée, le phénomène est amplifié ! Attention donc. Pour la petite histoire, dans les avions, où les ondes peuvent avoir des conséquences dramatiques, les antennes Wi-Fi sont installées sous chaque rangée de siège. Plus on met d'antenne, mois il y a d'onde émise. Paradoxal ? Non pas du tout, c'est logique, puisque chaque appareil a besoin d'émettre moins fort. L'avion vole en sécurité, le corps humain nous remercie, et les batteries de nos appareils vivent plus longtemps. Le jour où les associations anti-antenne auront compris cela, on aura fait un grand pas dans le bon sens Bref, si tu veux quand même couper le Wi-Fi, à mon avis le seul moyen c'est d'agir sur l'alimentation, donc couper le port Ethernet POE sur lequel est branché la borne. Pour la puissance, il faut toujours laisser en AUTO.

Bravo Il n'y a aucune raison de vouloir supprimer les messages de la console... de toute façon ils disparaissent automatiquement dès qu'il y en a trop, il y a un mécanisme de purge automatique. Si un QuickApp/Scène est trop bavard, il va vite faire expirer les anciens messages (ce qui peut être problématique quand on veut chercher un événement passé dans la nuit par exemple) Non toujours pas d'emails de notification...

Pas de chance... Regarde sur le forum, j'ai partagé un script pour faire des backups automatique chaque semaine depuis un NAS, c'est bien pratique.

Automatic repair, il va te faire une restauration automatique de ta dernière sauvegarde ça m'est arrivé 1 fois (à cause d'un QuickApp que j'avais mal écrit et qui faisait crasher la box à chaque boot)

mouais.... bien possible que ça ne fonctionne pas.... Remarque, la phrase descriptive est ambiguë : " Reconfigurer le maillage en interrogeant le dispositif sur les appareils voisins („RequestNodeNeighborUpdate”). " => du coup on ne sait pas trop si ça force réellement la reconstruction d'une route, ou bien si ça se contente d'interroger et de mettre à jour la liste des voisins (ce qui est peu utile)

Bah bien sûr que tu ne peux pas le modifier dans l'API... quelle drôle d'idée. C'est une information remontée par le device. Tu devrais relire tout le topic depuis le début, je pense que tout cela est confus dans ton esprit

Ah non pas du tout EDIT : tu débranches tout le monde, puis tu n'allumes que les modules par lesquels tu veux imposer le passage. Bon, vraiment nul comme technique

Je crois que c'est plutôt 5 rebonds.

Si tu n'es pas sûr du script, tu vérifies dans le JSON du module, les infos proviennent de là. Peut être que tu as déplacé ce module (ou intercalé un obstacle entre lui et la box), donc il a trouvé un nouveau chemin qui fonctionne. Et même si ce chemin est plus long, il le conserve, c'est normal. Le Z-Wave ne prévoit pas la recherche de la meilleure route. Le protocole prévoie juste de trouver la meilleure route à un instant T (la différence est de taille). Une fois trouvé une route fonctionnelle, il la conservera éternellement, tant qu'elle mène à bon port. Il n'y a pas de recalcul dynamique tant que ce n'est pas absolument nécessaire. D'où l'intérêt de voir la carte, et de forcer le recalcul pour les quelques modules qui te paraissent anormal. En fait d'après ce que j'ai compris, les modules Z-Wave maintiennent en permanence une liste de leurs voisins (avec la puissance du signal associée) En revanche, la route est statique, c'est à dire qu'une fois trouvé un chemin, le module l'utilisera toujours, tant qu'elle fonctionne, et ce même si ce n'est pas la meilleure route (parce qu'entre temps, un obstacle a été supprimé, ou un autre routeur présentant un meilleur signal a été ajouté) Il y aurait 2 façons de modifier cette route : - Si la première route ne fonctionne plus, alors il utilisera l'ancienne route (qui est mémorisée également).... sinon (aucune des 2 routes ne fonctionne) alors il en cherchera une nouvelle. - Le contrôleur Z-Wave a demandé le recalcul d'une nouvelle route (mais normalement on n'a jamais besoin de le faire... en tout cas perso en 7 ans et 94 modules, je n'ai jamais eu à le faire). Le recalcul des routes peut être assez gourmand (trames d'exploration du réseau), et s'il est demandé pour plusieurs modules, la conséquence est pire que tout : le réseau peut s'écrouler. Donc attention ! Bref, le recalcul des routes quand il est nécessaire est effectué automatiquement et surtout de façon transparente pour l'utilisateur. A mon avis le seul cas de figure problématique doit se poser quand un module bagote entre ses 2 routes mémorisées et qu'elles sont toutes les 2 de mauvaise qualité. Dans ce cas, forcer la reconstruction doit être utile. J'espère que je ne dis pas trop de bêtises, c'est en tout cas ce que j'ai retenu des exposés savants de @robmac : Z Wave Routing Basics Z Wave Routing Basics: Retry Strategies Z Wave Routing Basics: Application/Binding Retries, Heal and Explorer Perso mon astuce, c'est qu'à chaque fois que j'inclue un module, je le fais à coté de la box (donc en vison directe sans passer par un routeur), et ensuite je vais l'installer à sa position définitive. Donc il se débrouille tout seul pour trouver une nouvelle route si nécessaire, sinon c'est qu'il peut continuer à communiquer en direct avec la box, sans passer par un routeur, ce qui est encore le mieux. En fait, le meilleur conseil qu'on puisse donner, c'est d'inclure les modules à proximité de la box, puis de les installer à leur emplacement définitif. Cela maximise les chances de communication directe sans utiliser de saut via des routeurs. D'ailleurs, quand on a une grosse installation, c'est même indispensable, car le trafic normal du réseau gêne l'inclusion si le module est trop loin (ça prend trop longtemps (plusieurs minutes) voire ça n'aboutit jamais) => inclure le module près de la box permet de maximiser la bande passante et d'inclure plus vite (l'inclusion est un processus extrêmement bavard)

Il faut utiliser net.HTTPClient()

Et bien c'est simple. Par exemple, tu as les 241, 199, 187, 47, 66, 762, etc... qui passent par au moins 1 saut, voire 2 (ce qui est franchement mauvais... ils sont si éloignés que ça ces modules ?) A l'inverse, par exemple 332, 296, 292, etc... sont en communication directe avec la box, donc c'est tout bon, ne touche pas à ceux là

Bravo Et bien maintenant tu vois tous les devices qui ne communiquent pas en direct avec le contrôleur. Il faut que tu pointes ceux qui seraient éventuellement des vieux modèles avec le SDK tout pourri Et comme je t'ai dis, si tu en trouves, tentes une reconstruction, dès fois qu'ils arrivent à communiquer en direct, il me semble que c'est censé améliorer les choses si je me souviens bien de ce qu'avait dit @TonyC à l'époque

IIS ça existe encore ? Je savais pas. Tu n'as pas un NAS avec un serveur Web standard (Apache, Nginx, LightHTTPd, etc)

Ouais et faut démonter le plateau aussi si tu veux faire l'upgrade complet MK3S+.... perso j'ai abandonné (= je n'ai pas passé commande) Ah.... la Maker Faire pour la fin d'année.... allez on y crois PS : ma photo de la CoreXY que j'ai prise chez Prusa à Pragues, c'est un prototype qui n'a surement rien à voir avec la vraie XL en cours de développement. Ce qui est marrant c'est que cette photo est devenue virale dans le petit milieu de l'impression 3D, en faisait une recherche je l'ai retrouvé sur des forums anglo-saxons de mecs qui se demandent si c'est un vrai leak. Par dessus une autre photo de la même fausse XL a été trouvée, bien plus ancienne et sur une autre étagère, tendant à prouver que ce proto remonte a bien avant le début du développement de la XL. Bref, comment lancer un faux leak malgré soi ... je me suis bien marré quand j'ai découvert les discussions

Prends bien la dernière version dans le fil de discussion Et suite sur le topic en question si tu as besoin d'aide

Punaise t'avais raté ça ? ça fait plus d'un an qu'on en parle de cette XL.... la dernière grosse info c'était le changer d'outil, c'est à dire la possibilité d'imprimer en multi matériaux sans les contraintes du MMU2S Selon les finances au moment où elle sortira, il se pourrait bien que je commande le jour de sa sortie (sinon faudra attendre 6 mois / 1 an avant qu'elle soit dispo, je pressens un gros succès commercial)

Je ne l'ai jamais fait, donc je ne sais pas Mais je t'ai dis plus haut de commencer par afficher ton diagramme réseau. Très clairement, la reconstruction de réseau n'est pas recommandée pour le plaisir (au risque de faire tomber tout le réseau....) Donc tu commandes par afficher ta table de routage, et ensuite, et seulement pour les modules qui passent par des relais, tu tentes une reconstruction.

Dans le menu idoine (idem que HC2, ce n'est pas nouveau, même si on n'a jamais besoin de l'utiliser en temps normal) : PS : ne fait surtout pas le réseau complet, il faut choisir juste un device qui pose souci

Et oui (fusion des sujets....) Justement pour le LAN regarde plus haut dans les discussions

Essaye de demander la reconstruction de la route uniquement pour les modules qui posent problème, avec un peu de chance ils trouveront une route directe et s'y tiendront, sans passer par le maillage, permettant de contourner le bug. Tu peux visualiser ta table de routage ici :

Même problème ici, je pensais que j'avais un anti-spam un peu trop zélé, mais visiblement je ne suis pas le seul @Moicphil tu as la possibilité de voir ce qui se passe sur la console d'admin ? Ou @Yohan ?

@mprinfo va te retrouver le lien, il avait partagé un script pour identifier tous les devices ayant la mauvaise version du SDK Z-Wave