Lazer

Au début l'UDP était buggué donc inutilisable. Du coup j'avais fait du TCP, avec "socat" qui faisait la "conversion" entre les 2 protocoles. C'était fonctionnel, mais un peu lourd à mettre en place et à maintenir. Parce qu'on dépend de la machine qui fait tourner socat, sous Linux (un Raspberry PI, une VM, ou une HC2 rooté...)

Justement, faut penser au retour au bureau, avec les moyens dérisoires mis à notre disposition (je bosse dans une boite de service, ce sont les cordonniers les plus mal chaussés...), je suis bien content d'avoir une infrastructure disponible 24/7/365 chez moi pour travailler à distance. En fait, c'est un peu du télétravail depuis le bureau. Et je n'ai pas attendu le confinement pour ça. Et je ne parle même pas du poste de travail, à la maison je suis sur un Core i9 avec écran 32" + 24", un fauteuil super ergomique, etc. Au bureau, j'ai un core i5 de portable, donc assez lent. Et encore je suis privilégié, j'ai un écran externe 24". Bref, le télétravail à la maison, c'est la vie @mprinfo tu as fini de faire le lourd, tu me l'as demandé au moins 3 fois en 1 semaine.... Tu sais très bien que ça sera le cas quand Fibaro permettra de faire de l'UDP sur la HC3. Accessoirement, quand j'aurais une HC3....

Vus les longueurs de malade pour remonter de la cave jusqu'au faîte de la maison, puis redescendre sous les tuiles, faire le tour des caches moineaux pour enfin arriver aux caméras, perso j'ai joué à l'économie et je n'ai mis que du Catégorie 5e (et non blindé en plus). C'est du câble tout à fait standard qui supporte le Gigabit sans problème, et surtout ça ne coute pas cher du tout en bobine de 100m (surtout que j'ai reçu 500m pour le même prix ... l'erreur ne vient même pas du vendeur, mais de son fournisseur... donc cadeau pour moi) De toute façon, toutes mes caméras elles sont en 100 Mbps, donc déjà du Gigabit c'est surdimensionné. Je n'ai pas de Cat 6 chez moi, je suis directement passé au Grade 3S pour tout le reste (ordinateurs, serveurs, switchs, domotique, etc). Mais ça coute largement plus cher, et surtout c'est tellement rigide que je ne suis pas certain que j'aurai réussi à passer ça partout sous le toit pour arriver aux caméras. Bref, Cat 5e c'est très bien pour les caméras, largement suffisant et même surdimensionné. Et puis au moins, pas de souci pour sertir un Cat 5e sur un connecteur RJ45 standard. Pas besoin d'utiliser les connecteurs spéciaux pour le Grade 3s (les brins sont trop larges et ne rentrent pas dans le connecteur) Après si tu as du Cat 6 en stock, ou que tu peux l'avoir au même prix, fait toi plaisir, dans 20 ans quand on aura des caméras de vidéosurveillance en UltraHD 16k HDR 24+ avec son Dolby Univers ça sera peut être utile )

Il trolle un peu comme d'habitude

C'est clair, y'a pas de nouveauté là, juste des correctifs, et des templates de modules.... et comme par hasard beaucoup de MCO Home, puisqu'ils viennent d'annoncer leur partenariat. Modules qui fonctionnaient très bien sans template, il suffisait d'injecter les paramètres à la main, qu'on trouve dans la documentation de chaque module. Clairement, la HC2 n'aura plus de nouveauté, on peut s'estimer heureux qu'ils continuent un suivi minimal comme ça...

En fait elle apparait comme un volet, c'est un peu le souci, y compris dans l'application mobile. J'ai changé l'icône afin que ça soit plus parlant. Pour que la calibration des butées se passe bien, j'ai changé les paramètres de détection de consommation, comme c'est une vanne elle consomme très peu de courant comparé à un moteur de volet. Il faudra que tu ajustes en fonction de la consommation de la tienne, pour info moi j'ai mis ça : En bonus, je ferme la vanne en cas de détection d’inondation :

Sauf quand des gens installés à l'ouest de cette zone viennent te voir, dans ce cas elle redevient instable

Oui ça je sais bien que tu ne peux pas modifier une scène, puisque c'est justement ce qui provoque l'erreur 403. Mais tu peux faire soit le stop sur la scène, ou bien désarmer le module fautif non ? C'était bien le sens de mon message.

Si, les modules sur batterie peuvent passer en nœud mort, après un délai supérieur à leur intervalle de réveil (qui est connu de la box). Si un module sur batterie n'a envoyé aucune trame d'événement (mouvement, ouverture, température, luminosité, etc) et qu'il ne s'est pas réveillé, la box en déduit que sa pile est HS ou qu'il s'est trop éloigné du réseau, donc elle le déclare en nœud mort. J'ai certains capteurs qui ont un intervalle de réveil de 1 semaine, donc en cas de panne de pile, ils mettront plus d'une semaine avant que la box ne les déclare en nœud mort. Un cas particulier, ce sont les nouveaux modules Fibaro pour lesquels ont peut totalement désactiver l’intervalle de réveil (pour optimiser la pile) => Button et Keyfob Dans ce cas, les modules ne passent tout simplement jamais en nœuds morts. Là ça n'a rien à voir, le FGBS est un module sur secteur, donc toujours éveillé, en écoute active du réseau (routing slave) Il est donc sujet au polling régulier (sauf s'il a été spécifiquement désactivé), et est censé répondre immédiatement en cas d'ordre envoyé par la box. S'il ne répond pas, c'est qu'il est mort. Ce qui t'es arrivé, c'est juste le comportement normal de tout module alimenté sur secteur (FGS, FGD, Wall Plug, etc)

Ah bon ils ont finalement sorti une v4 stable ?

Si tu as configuré le contrôleur b120i en mode RAID, il ne laisse pas remonter les infos SMART. Donc tu ne peux rien faire. De toute façon le SMART ça ne sert à rien quand tu tiens à tes données, puisque tu fais des sauvegardes.... c'est encore la meilleure chose à faire pour sécuriser.

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