Lazer

1) En mode failover only si WAN1 était HS et redevient opérationnel tout le flux repasse à nouveau par WAN1 => je confirme 2) Si bien sûr, c'est tout simple puisque ça dépend de la table de routage, donc on a bien accès à l'adresse IP du routeur pour le manager. Par contre, il faut que la table de routage du routeur 4G soit correcte, ce qui implique de lui ajouter une route statique vers le LAN, sinon comme il ne le connait pas par défaut, il va envoyer les trames vers son WAN... donc tu ne recevra jamais les réponses aux pings et autres requêtes http que tu vas lui envoyer. Bref, c'est du routage IP tout ce qu'il y a de plus standard (même si ce n'est pas évident à comprendre au début) 3) On peut changer tous les paramètres, et même configurer un script de détection personnalisé pour les usages les plus avancés. Précision : je parle pour EdgeRouter, pas pour les routeurs Unifi, qui sont bridées au niveau des fonctionnalités. Et c'est encore pire sur les nouveaux modèles basés sur UnifiOS (Dream Machine, UXG) La force de la gamme EdgeRouter c'est de s'appuyer fortement sur le sous système Linux et d'y laisser libre accès, cela permet donc de customiser à volonté. Unifi à l'inverse est plus simplifié et est censé se paramétrer uniquement via l'interface Web du Controller. Ce sont 2 philosophies différentes, même si le hardware est le même. Maintenant je me demande comme mprinfo s'il ne vaut pas mieux te tourner vers la gamme Unifi, surtout si tu veux ensuite ajouter des AP... tu aurais un ensemble plus cohérent et plus facile à administrer, et je doute que tu aies besoin des fonctionnalités spécifiques de la gamme EdgeRouter.

Non surtout pas le Fibaro FGR avec le module Velux KLF-050, car les 2 sorties du module FGR sont obligatoirement câblées sur le 230V... ce qui grille instantanément le KLF-050. @steven en avait fait l'amère expérience.... C'est donc bien le FGS-222 qu'il faut utiliser (et non pas le FGS-223 qui a lui aussi ses sorties câblées en 230V), car il permet de faire 2 contacts secs, ce qui est nécessaire pour le FGS-222 Les tutos de Steven et domotique-store sont corrects. Perso je fonctionne comme ça chez moi aussi depuis quelques années. Pour la configuration dans Jeedom, je passe mon tour.

ça fait quelques jours que c'est comme ça. ça va et ça vient... Surement encore notre hébergeur OVH qui joue avec son datacenter... ils ne savent pas maintenir une prod stable 24/7/365 Mais pourtant on les aime bien, parce que c'est pire chez les autres.... alors on fait avec

ça c'est sûr que de parler Fibaro sur un site infesté de fanboys intégristes Jeedom, ça fait débat

C'est tout à fait ça !

Comme d'habitude tu viens troller Relis bien ce que j'ai écris, je parle de Wi-Fi grand-public. Si tu parles de Wi-Fi pro, alors on pourrait tenter de faire fonctionner toutes les caméras de tes entrepôts en Wi-Fi, juste pour rigoler 5 minutes.

Il y a plus de 15 ans, je lisais un article dans Décision Micro (le magazine que lisent les DSI.... ça fait peur de voir qu'ils prennent leurs décisions avec ce genre de support) d'un pseudo expert du dimanche qui promettait que l'avenir était à la suppression des câbles et au WI-Fi généralisé dans les datacenters. Donc 15 ans après il a tout faux, et on continue de câbler plus que jamais. Les technologies radios ne sont adaptées qu'aux usages mobiles (téléphones, voitures, IOT, etc) et vont le rester très longtemps. Quand tu vois que 2 caméras IP suffisent à écrouler un réseau Wi-Fi standard (celui d'une box opérateur comme Free/orange/etc)....

Oui les constructeurs, j'y songe, mais les places sont chères, d'autant plus qu'ils s'appuient de plus en plus sur leurs partenaires, et que les conditions de travail sont de moins en moins intéressantes. J'avais fait des entretiens chez EMC avant le rachat par DELL... finalement je suis content de ne pas y être allé. Je suis très spécialisé IBM, et même si les employés ont accès à des technos de fous, les conditions de travail chez eux sont de pire en pire. Ce qui est en vogue actuellement, ce sont les éditeurs de logiciels surtout. Toutes les startup connues et moins connues. Oui la bureaucratie, ce qui fait que je préfère les petites boites de services aux grosses multinationales. Après j'ai des clients qui adorent, et qui détesteraient faire mon métier. Donc y'en a pour tous les goûts Même si globalement, j'ai tendance à penser que sur la durée, les conditions de travail se dégradent globalement dans toutes les boites. Plus que jamais, y'a que le pognon pour les actionnaires qui prime.

ça je suis bien d'accord.... Mais pour avoir commencé ma carrière chez un client final (un groupe qui a fini par rejoindre le CAC40), c'est pire. Je préfère largement les sociétés de service. Il faut savoir choisir, comme tu dis la plupart sont des marchants de viandes. Quand on est passionné par la technique, c'est là qu'on s'éclate le plus. Et c'est un peu pour ça que j'ai mon datacenter à domicile, vu qu'on ne nous en donne pas les moyens au bureau... pourtant on est censés s'auto-former, mais juste avec du web-learning, la bonne blague. Là où je suis j'ai effectivement une grande liberté. Et quand on ne me la donne pas, je la prend. Le télétravail, ou les horaires (que je ne respecte pas du tout) n'ont jamais été un critère de discussion pour moi. C'est à prendre ou à laisser. On me paye pour faire un travail, pas pour faire de la présence. Quand je dis ça, le manager se tait et accepte mes conditions. Et tout le monde est content. Valable aussi chez les clients, mais faut être un peu plus diplomate là bien sûr Les commerciaux sont toujours la population la plus estimée dans le cœur des dirigeants, pour une raison toute simple : ce sont eux qui ramène le pognon. Et ce sont eux qui partent avec leurs clients en cas de démission. Donc ça leur laisse une très grand autonomie. L'ingénieur, à l'inverse, il coute cher. Outre son salaire, il réclame toujours plus de moyens pour travailler (la R&D, la formation, tout ça coute cher, et certains dirigeants ne savent pas investir)

Ouh là, t'es syndicalisé toi ? ça me rappelle un pote (qui bosse dans une grande boite française du CAC40) dont les syndicats sont tellement chiants qu'ils imposent une visite au domicile AVANT d'autoriser le télétravail du salarié, pour s'assurer qu'il a un bureau ( = une pièce) dédiée à cette activité. Comme il est en appart, il a été obligé de virer le lit qui servait de chambre d'ami pour le remplacer par un clic clac afin de justifier que ce n'est plus une chambre à coucher. Vraiment n'importe quoi, le télétravail est une facilité pour le salarié de travailler à domicile, organiser son temps, et même gagner du temps (suppression des temps de transports, gain de productivité, etc) Chez lui donc, c'est tout l'inverse... bon au final il a quand même fini par avoir son autorisation de télétravail après avoir justement remplacé le lit. Mais ce qui est comique c'est qu'il travaille sur le canapé avec le portable sur les genoux. Tout cela hors confinement bien sûr, la situation actuelle est exceptionnelle. Moi je ne demande rien, je m'en fous que l'entreprise me paye mes charges, tout ce que je demande c'est de pouvoir travailler où je veux, quand je veux, et en étant le plus productif possible. Mais clairement, ce n'est pas le souhait de la plupart des gens. De toute façon le simple fait d'être chez moi me fait déjà économiser le prix du repas du midi, et rien que ça c'est énorme. Et je ne parle même pas du transport.

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é.