Lazer

C'est bien un bug de la base de données, le JSON d'un module correct montre bien les associations : - interfaces "zwaveAssociation" et "zwaveMultiChannelAssociation" - liste des associations actuellement configurées : "interfaces": [ "polling", "zwave", "zwaveAssociation", "zwaveConfiguration", "zwaveMultiChannelAssociation", "zwaveSlaveRouting" ], "properties": { "associations": "[{\"endPointId\":0,\"groups\":[{\"groupInfo\":{\"commands\":[],\"name\":\"\",\"profile\":\"\"},\"id\":1,\"multiChannel\":{\"bitAddressable\":false,\"max\":5,\"set\":[],\"view\":[]},\"singleChannel\":{\"max\":5,\"set\":[1],\"view\":[1]}},{\"groupInfo\":{\"commands\":[],\"name\":\"\",\"profile\":\"\"},\"id\":2,\"multiChannel\":{\"bitAddressable\":false,\"max\":5,\"set\":[],\"view\":[]},\"singleChannel\":{\"max\":5,\"set\":[1],\"view\":[1]}},{\"groupInfo\":{\"commands\":[],\"name\":\"\",\"profile\":\"\"},\"id\":3,\"singleChannel\":{\"max\":1,\"set\":[1],\"view\":[1]}}]}]", Tandis qu'il n'y a rien de tout cela pour le FGBS problématique : "interfaces": [ "polling", "zwave", "zwaveSlaveRouting" ],

Voici un problème que j'ai mis longtemps à résoudre.... attention pavé, mais c'est pour expliquer le cheminement de la résolution d'incident. J'ai un Wall Plug qui se comportait de façon très étrange depuis pas mal de temps. Il s'agit du Wall Plug permettent d'alimenter le chargeur de mon vieux smartphone dédié à la passerelle SMS (avec JPI) Normalement ce wall plug se coupe et s'allume uniquement via un scénario dans JPI, en fonction de l'état chargé / déchargé de la batterie. Cependant, j'avais constaté depuis un certain temps le comportement étrange, du wall plug, qui se coupe ou s'allume un peu n'importe quand, sans respecter les actions données par JPI. Pire, je l'ai entendu (le petit relai) claquer rapidement plusieurs fois de suite, à n'importe quelle heure, même lorsqu'il n'y a aucun mouvement dans la maison, aucun scénario, rien ( *** Vous verrez à la fin que c'est un détail d'importance) Suspectant d'abord un bug dans JPI, j'ai d'abord totalement coupé JPI pendant plusieurs jours => le wall plug continue son fonctionnement aberrant ! Je vérifie tous mes scénarios sur la HC2 (en fait essentiellement GEA) pour m'assurer que l'ID du Wall Plug ne soit utilisé dans aucune scène, sait-on jamais... => rien à signaler Le firmware du Wall Plug est à jour : Je fais une reconfiguration douce du Wall Plug => ça n'améliore pas les choses : Je ne fais pas la reconfiguration complète du module afin de ne pas perdre mes ID et devoir tout reconfigurer : Dans la même logique, je ne fais pas non plus d'exclusion/inclusion du module. Je vérifie tous les paramètres du Wall Plugs => ils sont à leur valeur par défaut, rien d'anormal. Je commence alors à soupçonner un autre module d'être en association directe avec ce Wall Plug. Je vérifie ses associations, même si c'est peine perdue car l'écran montre les association vers un autre module, pas les association venant d'un autre module => rien à signaler : Mais alors comment trouver d'où provient le problème ? Me souvenant de vieux bugs rencontrés par les utilisateurs de Zibase aux tous débuts du Z-Wave, je pense alors à un module qui émettrait des trames d'alarme en broadcast, lesquelles seraient alors interprétées par le Wall Plug. Je m'assurer de désactiver toute réaction aux alarmes (ce qui est le cas par défaut) sur le Wall Plug, mais cela ne change rien : Et là, aujourd'hui, miracle Au moment où j'entends la voiture de Madame rentrer, j'entends également le relai du Wall Plug faire ses petits claquements répétés. Immédiatement, je repense à l'association directe, provenant du module branché sur le portail. Bingo, il s'agit d'un Fibaro FGBS Universel de première génération, installé là depuis de nombreuses années (sur la HC2 avec le firmware v3... ), donc l'une des entrées s'active sur l'ouverture du portail, et l'autre entrée s'active sur les cellules de franchissement. Et c'est l'entrée dédiés aux cellules qui pilote le Z-Wave via association directe, le panneau d'événement qui montre la réaction instantanée des 2 modules à la même seconde (une fois filtré... ce qui n'est pas une mince affaire quand on a 92 modules qui causent beaucoup) : *** Et là on comprends mieux la remarque du début, dès qu'un chat se frotte sur la grille du portail à toute heure du jour et de la nuit, le Wall Plug fait clignoter sa LED et claquer son relai. Totalement hallucinant Bon maintenant yapuka désactiver l'association directe Oui... mais non Parce que la HC2 me dit que ce module ne supporte pas la fonctionnalité des associations : WTF Tous les modules Z-Wave supportent les associations, et j'ai bien vérifié mes autres FGBS Universels, on a bien le bouton permettant de configurer les associations. Même un FGBS encore plus acien qui a été inclus avant celui-ci. => Je soupçonne dont le processus de migration vers la v4 (oui c'est vieux) qui a dû bugger et oublier de reconfigurer proprement ce module dans la base de données de la HC2. A noter que j'ai un autre module, un RGBW de première génération, inclus à la même époque environ, qui refuse de faire sa mise à jour de firmware... j'imagine que cet autre module doit également avoir des erreurs dans la base de données de la HC2. Bref, comme pour le Wall Plug, je n'ai aucune envie d'exclure et de réinclure ce module et devoir changer les ID, etc... Et sachant que la Reconfiguration Douce du FGBS n'est même pas proposée dans l'interface. L'astuce que j'ai alors employé en partant du principe que l'association directe vers le Wall Plug allait rester en place, c'est de m'assurer que cette association n'aura pas d'effet. Pour cela, on modifie les paramètres 5 et 6 du FGBS pour qu'ils n'envoient qu'une trame d'alarme générique au lieu d'envoyer un ordre ON/OFF (BASIC_SET) au Wall Plug. Comme on s'est assuré précédemment que le Wall Plug ne réagisse pas aux Alarmes, l'association directe n'aura alors plus de conséquence : => Et ça fonctionne Je suis allé jouer au chat en me frottant sur les cellules et le Wall Plug n'a pas aboyé : Il reste quand même un immense mystère dans tout cela, c'est comment le FGBS a pu s'associer tout seul avec le Wall Plug. Mystère et boule de gomme Une chose est certaine (en fait j'avais déjà pris ma décision mais cette expérience ne fait que la confirmer), lorsque je basculerai vers la HC3, je ferai une nouvelle installation, et pas une migration du réseau Z-Wave existant. De toute façon, vu que les ID des modules changent pendant la migration, et qu'il faut réécrire tous les scénarios (Scènes, QuickApps), je n'ai pas trop saisit l'utilité de cette migration telle que développée par Fibaro dans l'urgence. Si c'est juste pour éviter d'aller triple cliquer sur les modules, et conserver des bugs de configurations, ça n'en vaut pas la peine.

Ton message n'est pas très cohérent, puisque d'abord tu dis que tu es loggué super-utilisateur, puis tu dis que tu n'as plus les droits admins, puis finalement tu as quand même réussi à le faire. M'enfin tu as donc réussi c'est l'essentiel

Ton problème est très classique et revient souvent sur le forum.... donc tu désarmes le capteur et le tour est joué.

Je pense que tu devrais arrêter de citer systématiquement mon message puisqu'il précède le tiens Je ne fais que te donner des pistes, je n'ai aucune certitude. Mais le fait qu'elle te donne une tension à vide très différente de la tension en charge peut effectivement indiquer une pile HS.

Hum OK je vois. Mais dans ton cas, le plus simple c'est de faire un Recovery après installation de la nouvelle carte mère, puis mise à jour, et enfin restauration de ta configuration. C'est le plus simple je pense. Le processeur j'en doute, les CPU Intel sont quasi impossible à cramer. En général, c'est la pile du BIOS, ou bien la barrette de RAM, ou encore l'alimentation. Tu la brancheras sur la table, sans rien branché dessus (pas de carte fille, pas de clé USB) avec juste un écran sur la prise VGA/DVI/HDMI pour voir si tu as un affichage. Il faudra quand même laisser une barrette de RAM, la plupart des cartes mères n'affichent rien si aucune RAM n'est installée. Regarde dans le doc Intel de ta carte mère aussi, pour faire un reset complet du BIOS, ça peut aider.

Quels 2 fichiers, tu as un lien ? Je ne me souviens pas. Je pense que le remplacement de carte mère est assez standard, il faudra juste que tu sois précautionneux en ouvrant la boite et en glissant la carte mère en dehors du boitier, de mémoire fait attention au câble d'antenne.

La HC3 évolue extrêmement vite, il y a une vraie volonté de faire évoluer la box. Le change log de 2 premiers firmware est déjà parlant. Et il y a pas mal de nouveautés à venir. Tout va tourner autour des QuickApps, qui remplacent à la fois les Virtual Devices et les plugins. Les QA permettent d'intégrer nativement tous les objets externes, donc station Netatmo, aspirateurs, multimedia, etc etc. Et on ne sera pas limité par les développements minables des plugins officiels de Fibaro, on pourra bénéficier des supers QA développés par la communauté. Comme par exemple le QA Sonos de Krikroff. GEA dépend de la possibilité de faire tourner plusieurs instances de scènes en parallèle. Aux dernières nouvelles c'était encore en cours de discussion et non approuvé par Fibaro, mais je garde espoir En tout cas c'est un pré-requis à une mise en production d'une HC3 chez moi en ce qui me concerne. J'ai un peu moins de 200 lignes de scénarios en GEA, je n'ose même pas imaginer le nombre de milliers de lignes de LUA si je devais traduire tous mes scénarios à la main.

Ah non mais ça n'explique pas le waiting (je ne sais pas pourquoi ta box fait ça au reboot), mais c'est pour expliquer les bases du fonctionnement des paramètres/polling/réveil des modules.

Non ce n'est pas la même chose. Rappel de la section pour les nuls :

6 ans et demi pour la mienne Le souci c'est qu'il n'y aura de nouvelles fonctionnalités sur la HC2. Déjà si on a des mises à jours de correctifs de bug et sécurité on pourra s'estimer heureux. Donc pérenniser une installation existante en achetant une HC2 de spare a du sens, mais concevoir une nouvelle installation (ou une extension majeure) en HC2 est assez aberrant. J'adore le concept et le nom que tu lui a trouvé Mais je n'y crois pas, outre les protections que Fibaro n'a pas manqué de mettre en place, la nouvelle HC3 tourne sur processeur ARM, tandis que la HC2 fonctionnait en x86. Et comme on n'a pas le code source, impossible de recompiler. Par ailleurs Fibaro a introduit il y a pas mal de temps une mise à jour du firmware du micro-contrôleur situé sur la carte fille de la HC2 (la carte fille gère les LED, la puce Z-Wave et son antenne, ainsi que quelques bricoles...). Si la carte fille ne détecte pas le logiciel de la HC2, il y a un watchdog qui reboote la box. Ce qui implique qu'il n'est même plus possible de convertir la HC2 en box autre, tel que Jeedom ou Home Assistant. On peut toujours virer la carte fille et installer une clé USB Aeotec à la place bien sûr, mais on perd la puce Z-Wave intégrée et son antenne. Rappel de l'architecture interne de la HC2 :

Et bien c'est parfait ça, tu as le même mécanisme de vanne que moi. Tu peux donc utiliser un FGR, et tu mets le marron sur la sortie 1 et le noir sur la sortie 2 (ou l'inverse) et tu pourras contrôler l'ouverture/fermeture de la vanne sans aucun risque d'activer les 2 sorties simultanément. Laisse tomber les scénarios LUA farfelus, ça va forcément bugger et créer un court-circuit.

Heureusement que je t'ai dit de ne pas utiliser de FGS...

Attention, Bluetooth LE (Low Energy) uniquement, ils n'ont jamais parlé de Bluetooth au sens large. Quant au RTS c'est pareil, il me semble bien que ça n'a jamais été annoncé, c'est une supposition de ta part Nico. Le 433 MHz va servir en priorité pour piloter les vieux automatisme Nice. D'un autre coté ils n'ont pas dit qu'ils n'ajouteraient pas le RTS, donc l'espoir est permis

Tu as le schéma de câblage de ta vanne ? Parce que si c'est comme la mienne, c'est à dire qu'elle a 3 fils (1 neutre, 1 phase ouverture, et 1 phase fermeture), le tout en 230V, alors tu peux utiliser un module pour volet roulant FGR. Dans ce cas il ne faut pas utiliser du FGS, car tu ne pourras jamais garantir que les 2 contacts ne sont pas activés simultanément (part du principe que ton scénario sur ta box domotique va forcément bugguer, loi de Murphy inside). Tandis que le FGR est programmé au niveau de son firmware pour n'avoir jamais les 2 sorties actives simultanément (c'est soit l'une, soit l'autre, ou aucune des 2)

Merci pour la confirmation @yoim C'est toppissime ça, donc on peut avoir l'alimentation 230V via l'onduleur, et le courant continu en direct sur le secteur EDF. Comme ça on supprime 2 SPOF d'un coup : le transformateur du routeur, et l'onduleur. L'inverse fonctionne aussi : le 230V en direct sur EDF, et le courant continu sur une alimentation secourue, ce qui est surement un meilleur calcul, car le rendement des onduleurs est toujours mauvais (à cause de la double conversion), et le signal jamais parfait (sinusoïde approchée). Si toute leur nouvelle gamme propose l'alimentation continue en option, ça devient vraiment pro

Je crois que c'est pour une alimentation redondante en courant continu. Comme chez Cisco. À confirmer...

Preview intéressante de l'UXG-Pro : UniFi Next-Gen Gateway (UXG-Pro) Preview Il se confirme donc : - processeur ARM, donc nouvel OS appelé "UnifiOS" basé sur Buildroot (comme la HC2...). Ubiquiti abandonne donc sa base historique sur Vyatta (Debian) utilisé sur les EdgeRouters et les Unifi Security Gateway / Pro. Il y a tout à redévelopper, donc moins de fonctionnalités pour l'instant. A prendre en compte (valable également pour les Dream Machine / Pro qui sont également basées sur UnifiOS. - l'UXG-Pro n'aura pas de controller intégré ni aucune fonctionnalité de type Protect (enregistrement vidéo). Il s'agit du vrai remplacement de l'Unifi Security Gateway Pro (USG Pro) - on peut s'attendre à voir débarquer un UXG simple en remplacement de l'USG actuel Intéressant, le graph de performance des UDM / Pro actuels face aux anciens USG / Pro. On peut supposer que l'UXG Pro aura les mêmes performances que l'UDM Pro : Bref, pour un usage avancé, tout ce qui est basé sur le nouvel UnifiOS (UDM, UDM Pro, UXG Pro) c'est encore trop jeune... mais c'est l'avenir car le potentiel est important. (Comme une HC3 quoi) En résumé : - UDM / UDM Pro : usage petite PME / grand public avec tout intégré (switch, point d'accès Wi-Fi, controller, enregistrement vidéo, ...) - UXG / UXG Pro : usage pro / amateur avancé : réel remplacement de la gamme USG actuelle, le routeur reste un routeur, et ne fait que ça. Il faut ajouter à coté un switch, controler, une borne Wi-Fi, etc.

Bon anniversaire @Domodial

Mais mais mais mais... que se passe-t-il ? Cette vidéo est en anglais !!! PS : Google connait mes préférences (mieux que moi-même parfois ), il m'a déjà proposé cette vidéo lors de sa publication

Je n'ai jamais/pas encore développé sur HC3, mais d'un point de vue purement LUA quand je vois que tu déclares la variable requestBody en local dans la fonction onInit(), cette variable ne peut pas être utilisée dans turnOn() Un petit rappel : De façon générale quand tu développes et que tu as des messages d'erreurs, pensent à ajouter un maximum de traces (fibaro:debug() ou son équivalent sur HC3) pour afficher le contenu des variables que tu manipules sur ton écran. Tu verras que ça explique 99% des erreurs, car tu ne manipules en fait pas la bonne donnée que tu pensais avoir.

Bienvenue sur le forum

Bienvenue sur le forum

Pas assez cher, il est passé où le prestige ?

@GnarlyYoyo j'ai fusionné ton topic avec celui existant, cette marque de moteur n'étant pas très populaire, autant regrouper la discussion et éviter de disperser l'information. En plus, si tu lis le topic, tu trouveras surement réponse...