Lazer

Ah dommage... et étrange à la fois. Essaye peut être de contacter le support Fibaro pour leur poser la question, peut être que les modules du Qubino n'ont pas le bon type, et/ou autre bug...

Ah tiens, ça doit être relativement nouveau cette fonctionnalité d'export de données, je ne l'avais jamais vu ! Mais comme tu peux le voir, il y a 2 onglets : température et énergie. Et c'est tout ! Car les autres types de données (humidité, courant, tension, etc) ne sont pas historisées dans la HC3. En fait je constate que cet onglet d'export ne propose d'exporter que les types de données pour lesquels on a un graphique historique disponible dans l'onglet propriété des modules concernés. Pour ton module Qubino, je ne sais pas... faut déjà voir s'il remonte la consommation d'énergie, je suppose que oui car c'est un peu la base de cette catégorie de modules.

ça ressemble au problème d'association fantôme que j'avais relaté sur le forum. Soit tu peux exclure et inclure à nouveau les modules ce qui aura pour effet de réinitialiser leurs associations, soit tu utilises l'astuce que j'avais décrite ici, si tant est que ça soit possible dans les paramètres du Swiidinter :

Alors en fait c'est pour le G7 N54L que j'utilise l'API, avec la Remote Access Card... ce n'est pas ILO en réalité. Pour le G8, qui utilise le vrai ILO, je n'ai pas encore eu besoin de m'interfacer avec, mais l'API est bien documentée il me semble.

Voilà, la loi de Murphy justement.... après chacun ses attentes / besoins / exigences, je dis juste que pour moi, ce n'est pas acceptable. En outre, à la base, le WOL je l'utilisais pour d'autres usages quotidiens : allumage du PC home-cinéma à partir de la télécommande Harmony, et allumage du serveur secondaire pour les sauvegardes nocturnes. Et quand chaque semaine on a au moins une des machines qui n'a pas démarré à cause du WOL non fiable, c'est rapidement exaspérant, au point d'arrêter de l'utiliser et de trouver d'autre solution. Surtout qu'en comparaison, on a une domotique fiable à 99,99 % grâce au Z-Wave, on devient exigeant

Si seulement... Le WOL j'ai pratiqué, ce n'est pas fiable, bien souvent ça ne fonctionne pas, et en particulier si le serveur n'a pas été éteint proprement (ce qui peut toujours arriver) ou pour X ou Y raison que je n'ai pas su déterminer. J'estime au doigt mouillé que le WOL est fiable à 90%, c'est insuffisant pour moi. Au final je n'utilise plus du tout le WOL chez moi, pour mes 2 serveurs HP j'arrive à les démarrer via l'API de la carte ILO, heureusement ça c'est fiable.

Perso j'ai fait le choix de ne rien éteindre automatiquement, car les coupures de courant sont extrêmement rares par chez moi. Et au pire, je préfère avoir un serveur éteint violemment une fois tous les X années, que d'avoir un serveur éteint qui ne peut plus redémarrer à distance. En effet, après une extinction sauvage, le serveur redémarre tout seul, ce qui n'est pas le cas s'il a été éteint proprement lors du retour de l'alimentation électrique. Parce que loi de Murphy aidant, la coupure de courant, c'est toujours lorsqu'on est loin de la maison, sinon ce n'est pas drôle.

Toutes les fois où je vois quelqu'un sur un forum dire qu'il a un module éloigné qui ne communique pas en directe avec la box, et qu'il ne comprend pas car il a un autre module à coté qui lui arrive à communiquer, ça ne loupe jamais : même réflexion que la tienne. Sauf que.... ce n'est pas si simple. Il ne suffit pas d'avoir 1 module à coté, le réseau Z-Wave c'est maillé, tu ne peux pas imposer la route à utiliser, c'est le réseau qui choisi tout seul, en fonction de plain de paramètres qu'on ne maitrise pas... et les ondes radios sont particulièrement capricieuses. Je suis passé par là moi aussi avec un module au niveau de mon portail qui communiquait 1 fois sur 2... jusqu'à comprendre que c'est le portail lui-même, ouvert ou fermé, qui provoquait le problème. Finalement c'est l'ajout un module beaucoup plus éloigné (fixé sur le mur de cloture avec le voisin derrière la haie dans une boite étanche...), de façon très surprenante, qui a servi de relai, et pas le module "en ligne droite" que je pensais à l'origine. D'où mon conseil d'améliorer le maillage de ton réseau, il n'y a que ça qui fonctionne de façon fiable et durable. Installer des modules en hauteur aide beaucoup aussi, car moins gêné par les écrans.... si tu peux en installer dans le grenier / les combles, ça permet de couvrir une bonne surface de la propriété : jardin, garage, portail, etc

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.