Lazer

Tu ne devrais pas toucher aux associations sans savoir ce que tu fais.... si c'est trop tard et que tu l'as déjà fait, je pense que le plus simple c'est de l'exclure et de le réinclure, la box reconfigurera les bonnes associations (lifeline, c'est à dire le retour d'état du module vers la box) Les associations, il ne faut y toucher que quand tu as besoin de faire communiquer un module en association directe avec un autre module, sans passer par la box, ce qui n'est pas ton cas ici car tu précises bien vouloir gérer le scénario avec la box. Ensuite, pour résoudre ton problème, quand le détecteur est à sa position finale, essaye de le réveiller en cliquant 3 fois sur le bouton, ça devrait le forcer à recalculer une nouvelle route si la communication avec la box ne se fait pas. Si vraiment ça ne fonctionne toujours pas, il te faudra densifier le maillage de ton réseau en ajoutant d'autres modules alimentés sur secteur, car la présence d'un FGD dans le garage n'est peut être pas suffisante.

Oui j'avais bien compris que tu voulais mettre en place ce genre de scénario simple dans GEA, ça ne représente pas de difficulté particulière. Comme dit, c'est pour l'extinction du NAS et d'éventuels autres appareils que se présente la difficulté. Une fois que ça c'est en place, GEA il ne fait qu'appeler la bonne fonction du bon QA, ça tient en une seule règle (enfin 2 règles vu que tu veux aussi forcer l'enregistrement des caméras... pour le coup tu as mon QA Surv Station qui fait déjà le job)

Moi je n'arrête rien. Mais ce que tu demandes n'as pas grand chose à voir avec GEA, mais plutôt à comment exécuter une commande distante sur une machine pour l'arrêter. Si la machine en question n'expose pas une API permettant de faire un shutdown, via un protocole facile d'utilisation comme HTTP, ce n'est pas si simple.

Oui pareil chez moi depuis 2 jours. Stellantis a changé son API : renforcement de la sécurité, enregistrement préalable auprès de leur filiale Mobilisights, utilisation d'un certificat, ... Sur les intégrations HA sur Github, c'est aussi la panique à bord, à priori plus personne n'arrive à se connecter... en attendant que quelqu'un trouve une solution, on est bloqué

Hum OK... mais bon... un routeur solaire, c'est avant tout un appareil autonome, composé de 3 éléments principaux : un capteur de courant (pince sur l'arrivée Enedis), un triac de hachage du courant injecté dans les résistances du CE, et une électrique de pilotage de tout le bazar (Arduino, ESP, etc) Si je comprends bien, tu cherches à déporter l'électronique de contrôle dans la HC3... ça ne peut pas bien fonctionner, dit autrement, ça ne peut que mal se passer Pour être efficace dans sa récupération de l'énergie avant qu'elle ne reparte vers le réseau, sans pour autant soutirer de l'énergie depuis le réseau, le routeur solaire doit analyser plusieurs dizaines de fois par seconde ce qui se passe : la mesure du courant Enedis d'une part, et le hachage du courant vers les résistances. Au minimum 100 fois par seconde (50 Hz c'est la fréquence du secteur, donc pour hacher chaque demi-période, alternance négative puis positive, il faut le faire 100x par seconde) Si tu déportes ce boulot dans la box domotique, forcément, c'est impossible d'aller à cette vitesse. Donc d'une part tu as un routage beaucoup moins efficace (comme dit, une partie repart vers le réseau, et/ou tu soutires une partie depuis le réseau en fonction des passages nuageux, des autres consommateurs de la maison, etc) Et même si tu te satisfait de cette imperfection, tu vas au devant d'un autre problème. Car tu vas tout de même chercher à aller le plus vite possible, donc collecter le plus rapidement possible les données depuis la pince, qui est en Z-Wave dans ton cas, puis d'envoyer des ordres au hacheur (en Z-wave aussi ? Je ne sais pas ce que tu as prévu là...) Donc là tu vas complètement saturer le réseau Z-Wave, qui va littéralement s'effondrer. Je rappelle (enfin, c'est tellement méconnu par les utilisateurs que c'est une découverte à ce niveau là) que le protocole Z-Wave, contrairement au Wi-Fi, de par ses spécifications, doit être en "silence" au minimum 99% du temps. Le "temps de parole" accordé aux échanges entre les modules et le contrôleur doit être inférieur à 1%.... la raison, c'est justement de permettre une bonne réactivité lorsqu'un module veut envoyer une trame, et éviter les collisions de paquets, donc réémission, et donc latence voire perte de paquets. Et là on en revient au sujet du topic... si latence sur le réseau, il y a 2 hypothèses : - mauvais maillage, donc réémissions de trame, puis recherche de route alternative, et ultimement paquets perdus => solution : améliorer le maillage du réseau - réseau surchargé => solution : rendre les modules moins bavard Et dans un réseau Z-Wave, les modules les plus bavards, ce sont souvent ceux qui remontent des métriques de consommation électrique, car ça varie sans cesse, et parfois très rapidement. Je disais plus haut dans le topic que j'ai eu le cas avec des Wall Plugs, donc commencer par faire un tour dans les paramètres pour alléger la charge réseau. Maintenant sur la HC3 on a enfin le retour du panneau de diagnostique, ce qui permet d'identifier rapidement les modules les plus bavard, afin de les calmer.

Cherche "routeur solaire" sur Google, il y a plein de modèles à tous les prix et niveaux de simplicité/complexité. Au contraire chez moi, je trouve mon réseau parfaitement stable sur HC3, alors que j'avais parfois quelques latences (mineures heureusement) sur mon HC2. Et c'est d'autant plus remarquable que j'ai dépassé les 100 modules Z-Wave sur HC3. Et je suis toujours avec le moteur v2 sur HC3, qui est le même que sur HC2 avec quelques évolutions mineures. Pour Fibaro, ou plutôt Nice, je ne sais pas bien quelle est la stratégie... Quant au Z-Wave, article du jour de @cedriclocqueneux : https://www.maison-et-domotique.com/145737-mort-du-protocole-domotique-z-wave/

Ah bah oui tient.... une idée de comment afficher la chose proprement ? (à part basculer du coté obscur ) Je constate tout de même que tu utilises mon QA, et même plus que moi, vu que je ne l'ouvre jamais (les notifications le matin me suffisent)

Jojo : c'est le Walli Controller, il ne commande aucune charge, c'est juste une télécommande, il peut bien fonctionner sur piles uniquement. Achille85 : tu peux faire une association directe depuis un module à batterie vers un module sur secteur, ça ne pose aucun souci, vu que l'appareil qui reçoit l'ordre (le FGS) est toujours alimenté, donc en écoute du réseau. Ce qui n'est pas possible, c'est de faire une association directe vers un module sur batterie, car comme il est endormi, il n'écoute pas le réseau et ne peux recevoir aucun ordre (sauf s'il fonctionne en mode FLIRS, mais c'est rare car seuls certains modules le permettent, type thermostat par ex) EDIT : pour la procédure d'association d'un Walli Controller avec un autre module, désolé je n'ai pas ce module, donc je ne peux pas reproduire. Fait peut être un tour sur le topic unique de ce module :

Non parce que si tu regardes bien le log de Jojo et le miens, ce sont les dépendances qui bloquent la mise à jour : mongodb essentiellement. J'avais déjà eu le souci par le passé, car j'ai commencé sous Debian 8, c'était le même problème (avec des versions précédentes de mongodb et unifi) D'ailleurs, plutôt que de migrer Debian et de s'embêter avec toutes les dépendances, il avait été plus simple d'installer une nouvelle VM avec la dernière version de Debian, les bonnes dépendances, puis de faire l'installation de Unifi par dessus. Ensuite il ne reste plus qu'à restaurer la sauvegarde réalisée dans Unifi. Bon de toute façon perso je m'en fous, je n'ai pas besoin de la dernière version, comme dit, je peux toujours faire les mises à jour de mes produits. Mais je dis ça pour Jojo, mieux vaux faire une nouvelle install et restaurer les données, plus simple.

Oui c'est pour ça que je suis resté avec mes bornes existantes. Et puis aussi parce que tous les appareils qui ont besoin de débit sont câblés chez moi, le Wi-Fi c'est uniquement pour les appareils mobiles type téléphone, objets connectés, etc, là je ne fais pas de téléchargement avec tout ça...

Ici mon controller tourne encore sur une vieille Debian 9, du coup impossible de faire les mises à jour depuis plusieurs mois, je suis bloqué en version Unifi 7.2.95 ça n'empêche pas de faire la mise à jour des firmwares de mes appareils (AP et switchs) existants, mais tant que je ne suis pas bloqué, je ne me presse pas pour faire la mise à jour de Debian + Unifi Controler. Et dire que je n'ai toujours pas de Wi-Fi 6 chez moi... ouh c'est la honte root@unifi:~# cat /etc/debian_version 9.13 root@unifi:~# apt update && apt upgrade Ign:1 http://archive.debian.org/debian stretch InRelease Hit:2 http://archive.debian.org/debian-security stretch/updates InRelease Hit:3 http://archive.debian.org/debian stretch Release Hit:4 https://dl.ui.com/unifi/debian stable InRelease Reading package lists... Done Building dependency tree Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@unifi:~# apt list --upgradable -a Listing... Done unifi/stable 8.0.26-24388-1 all [upgradable from: 7.2.95-18699-1] unifi/now 7.2.95-18699-1 all [installed,upgradable to: 8.0.26-24388-1] root@unifi:~# apt upgrade unifi/stable Reading package lists... Done Building dependency tree Reading state information... Done Selected version '8.0.26-24388-1' (Ubiquiti Networks, Inc.:stable [all]) for 'unifi' Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: unifi : Depends: mongodb-server (>= 1:3.6.0) but 1:3.2.11-2+deb9u2 is to be installed or mongodb-10gen (>= 3.6.0) but it is not installable or mongodb-org-server (>= 3.6.0) but it is not installable Depends: openjdk-17-jre-headless but it is not installable or temurin-17-jre but it is not installable E: Broken packages root@unifi:~# dpkg -l mongodb-server Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-========================-=================-=================-===================================================== ii mongodb-server 1:3.2.11-2+deb9u2 amd64 object/document-oriented database (server package)

Exactement. Techniquement le support peut effectivement recharger un backup local dans le cloud, il faut leur demander gentiment et tomber sur la bonne personne, en fonction de la parité des jours, des phases de la lune, et de l'âge du capitaine ! Donc ça peut dépanner si on a oublié de faire un backup Cloud ou s'il est vraiment trop vieux (normalement il est effectué automatiquement à chaque mise à jour de firmware)

Pas de modèle (template en anglais), c'est que ce module est trop nouveau et que Fibaro n'a pas eu le temps d'intégrer la liste des paramètres, leur commentaire, leurs paramètres, dans l'onglet dédié du module. Le fait de ne pas avoir de modèle pour un module ne gène en rien son bon fonctionnement, c'est le cas pour de nombreux autres modules de différentes marques (liste non exhaustive : Aeotec, Neocoolcam, Qubino, etc...) Tu peux ajouter les paramètres manuellement dans l'onglet dédié, en t'aidant de la doc constructeur pour connaitre leurs numéros. Pour la table de routage du réseau, voir ici : Sinon tu as le panneau de diagnostique intégré dans la HC3 pour identifier les modules avec des erreurs de trames Z-Wave, même si c'est encore assez nouveau et pas très complet. En tout cas le problème que tu décrits ressemble fortement à un problème de réseau insuffisamment maillé, il faut que tu ajoutes d'autres modules sur secteur un peu partout dans ta maison pour améliorer ça. En Z-Wave, plus tu ajoutes de modules, mieux ça marche (contrairement au Wi-Fi)

Bienvenue sur le forum

Ou simplement un QA de type binarySwitch qui ne fait rien Et là tu peux en créer autant que nécessaire.

Oui c'est sûr, surtout pour tous ceux qui rechargent leurs voitures la nuit.... au lieu de payer 5x moins cher que l'essence ça ne sera plus que 4x... bon finalement ça va vu sous cet angle Mais ça reste contraire au principe de Tempo, qui veut inciter les usagers à décaler leurs consommateurs, c'est pour ça que je me dit que la CRE pourrait jouer avec les tarifs HT pour conserver une certaine logique entre les 6 tranches.

Tu as les mêmes fréquences qu'avant (2.4 et 5 GHz), mais en plus ils ajoutent le 6 GHz. Cette fréquence permet un débit encore supérieur, mais une portée plus faible (typique des hautes fréquences). Mais comme ça ne remet pas en cause le 2.4 et 5 GHz, c'est sans inconvénient.

Ah bah tiens, merci, je n'avais pas vu cet article, et c'est exactement le calcul que je voulais faire, sauf que je n'ai pas trouvé le temps aujourd'hui, j'ai passé trop de temps à ne rien faire C"est bien ce que je craignais avec ma compréhension du mécanisme de TICFE, la mauvaise nouvelle c'est que HC Bleu est très fortement impacté... On se console avec la bonne nouvelle, HP Rouge bouge assez peu. Mais attention hein, ça n'est que des calculs théoriques, qui ne prennent pas en compte les décisions que va prendre la CRE sur les tarifs hors-taxes. En fonction des problématiques d'équilibrage du réseau en heures creuses et de pointes, ils peuvent très bien décider de bouger ces tarifs HT.... en fonction de comment ils veulent inciter les gens à décaler leurs consommation... ça sera la surprise....

Tant qu'à faire une nouvelle installation, pourquoi ne pas installer directement la nouvelle U7-Pro ? 198 € sur le Store officiel de la marque, ça te coutera moins cher que de remplacer les U6 dans quelques années, et au moins tu seras tranquille pendant très longtemps. Comparatif des performances théoriques entre les générations, et en fonction du nombre de stream (sachant que la très grande majorité des appareils clients (ordinateurs, ...) sont limités à 2 steams max) :

Et de toute façon, même si le QA EDRT2 plante, ce n'est pas un souci, puisque je le répète pour la Nième fois, mon QA Tempo est prévu pour gérer le cas de plantage : indisponibilité des serveurs EDF, RTE, téléinformation (donc indirectement Enedis) ça fait déjà 3 sources d'informations. Plus on lui ajoute de source d'info, plus ça va le rendre fiable. En effet, on ne peut pas appliquer le calcul de probabilité exposé précédemment, puisque pour fonctionner, mon QA Tempo a besoin d'une seule source minimum. Pas des 3 simultanément. Et ça, ça change tout. Au leu de devenir de moins en moins fiable à mesure qu'on lui ajoute des sources, au contraire, il va devenir de plus en plus fiable. Je le redis, je l'ai conçu de telle sorte à ce qu'il soit le plus robuste possible, car là on commence à parler pognon. Entre une journée rouge optimisée à 15 kWh, et une autre sans optimisation à 45 kWh, ça fait 33 - 11 = 22 € de différence, je trouve ça assez significatif. Surtout si la blague du bug se répète plusieurs jours d'affilée... Donc s'agirait pas que GEA fasse n'importe quoi avec les conditions à sa disposition. Tiens, d'ailleurs, dis donc... GEA il dépend de tous les autres QA pour fonctionner ? Et pourtant, on ne va pas inclure le code LUA de tous les autres QA du forum dans GEA, ça n'aurait aucun sens

Si le QA EDRT2 plante, alors le QA Tempo plantera également si j'inclue ma librairie GCE dedans, puisque ça sera le même code, donc les mêmes bugs ! Et même pire, puisque ça utilisera double de ressources CPU + RAM sur la HC3, et aussi sur l'EDRT2 lui-même qui sera doublement interrogé, on n'est pas à l'abri d'effet de bords qui fassent apparaitre de nouveaux bugs qui ne seraient pas apparus avec un seul QA qui interroger l'EDRT2. Donc au final, ça ne sera pas plus fiable, et statistiquement parlant, d'un point de vue calcul de probabilité, c'est des maths, il y a même plus de chance que ça plante... donc bon... non vraiment je préfère conserver une architecture simple et efficace, où chaque QA a sont job à faire. PS : c'est comme les disques en RAID cette histoire, tu as plus de chance d'avoir un problème avec plusieurs disques regroupés dans une grappe RAID qu'avec des disques indépendants... simple calcul de probabilités de niveau lycée. C'est pas pour rien que le RAID 5 a été abandonné il y a pas mal d'année et remplacé par le RAID 6, qui lui même est en passe d'être abandonné et remplacé par de nouveaux algorithmes (Erasure Coding, etc). Dit autrement : on intègre le fait qu'on va avoir X pannes simultanées en ajoutant des protections de partout pour se prémunir contre ces pannes, à la fin on a une sorte d'usine à gaz. Si tu as 1 chance sur 1 million que 1 disque tombe en panne, alors tu as 1 chance sur 500'000 seulement d'avoir une panne avec 2 disques... plus tu en mets, plus ça a de chance de planter. ça c'est pour le calcul mathématique. Ensuite tu ajoutes les effets de bords (vibrations des disques qui entrent en résonance, différence de latence entre 2 disques, etc) qui font que le risque de panne augmente encore beaucoup plus rapidement que le simple calcul de probabilité. La comparaison est peut être un peu exagérée, mais imagine 2 QA qui font la même chose, c'est un peu comme les disques, 2 fois plus de chance de plantage. Et comme ces 2 QA interrogent le même appareil, la similarité, au lieu d'avoir des disques qui entrent en résonance et se gênent mutuellement, c'est un EDRT de l'autre coté qui n'arrive plus à répondre aux requêtes simultanée des 2 QA. Au mieux un ralentissement, au pire un plantage, le serveur Web embarqué dans l'Ecodevice est très léger et dispose de très peu de ressources...

Je vais te retourner la question, et même 2 : pourquoi réinventer la roue d'une part, et faire 2 fois le travail d'autre part ? J'ai déjà un QA qui fonctionne, en exploitant pleinement l'API proposée par GCE. Donc mon QA Tempo va juste relire le contenu de la Variable globale alimentée par le QA GCE. Simple et efficace. D'ailleurs dans ma nouvelle version, je peux maintenant récupérer la couleur du lendemain depuis la téléinfo, à partir de 20h (stocké dans une autre VG), donc ça fait encore une sécurité supplémentaire.

Parce que le QA EDRT2 va déjà chercher les infos de la téléinformation, qui sont des infos locales, indépendantes du cloud. Je l'ai expliqué dans mon tuto, ça permet de continuer à fonctionner même en cas de panne des 2 serveurs (EDF et RTE) et/ou d'Internet. Car il ne s'agirait pas que les scénarios domotiques se plantent un jour rouge, la blague peut vite couter très cher...

Tout ça pour nous montrer que tu as un beau Linky Et j'adore le "Uniquement disponible avec mon QA", un vrai pro du marketing

Non pas besoin de ré-inclure les modules, les sauvegardes de HC2 ont toujours embarqué un dump de la puce Z-Wave, en cas de restauration, on retrouve le réseau Z-Wave intact avec tous les modules. Je le redis ici car je le dis partout, la restauration d'une backup provenant d'une autre box doit impérativement se faire via le cloud Fibaro, car il y a une opération de déchiffrage/rechiffrage des données à l'aide de clés uniques propres à chaque box. Ce n'est pas possible avec un backup local, qui peut uniquement être restauré sur la même box.