Lazer

Alors il faut : 1/ commencer par offrir un week-end bien-être tout frais payé à sa femme, pour avoir la paix 2 jours afin de pouvoir tout casser (rapide), puis tout reconfigurer (long) 2/ avoir le numéro de téléphone d'une bonne pizzeria en livraison à domicile, car tu n'auras pas le temps de cuisiner (fonctionne aussi avec les sushi...) 3/ un stock d’aspirine pour le mal de crâne après la nuit blanche (fonctionne aussi avec le paracétamol...) 4/ un partage de connexion 4G opérationnel entre ton téléphone et ton PC, car ça sera ton seul moyen de demander de l'aide à ton ami Google quand tu auras tout cassé Bon le switch Cisco ce n'est pas trop un problème, c'est indépendant du routeur. Pour passer la box en bridge et configurer le routeur, prévoir de reconfigurer : - le serveur DHCP avec toutes les leases statiques (perso j'ai configuré le routeur AVANT de le mettre en prod avec toutes les leases statiques après avoir relevé les MAC address à la main). - les redirections de ports WAN => LAN - firewall - serveur NTP, etc - attention au téléphone IP / Base DECT, à la fonction NAS intégré de la box opérateur, au partage d'imprimante, à la TV, etc... (que des services que j'ai accepté de perdre) Perso j'ai passé 2 ou 3h à configurer totalement l'Ubiquiti, puis 1 minute à basculer : Freebox ADSL mode routeur => Orange Fibre ONT + Ubiquiti (sans Livebox donc) Ensuite pour le failover 4G, il faut prévoir un second week-end, donc retour au point n°1 Car les tests sont forcément disruptif à un moment donné, même si ça fonctionne, tu as quelques secondes de coupure le temps du failover puis du failback. Par contre si ça ne fonctionne pas, tu vas avoir besoin des points n°2, 3, et 4. Là par contre je n'ai pas réussi le failover du premier coup (en fait si, le failover fonctionnait, mais pas le failback, obligé de rebooter le routeur)... en fait c'était un bug corrigé 15 jours plus tard par Ubnt. ET quand je vois l'expérience de @jjacques68 avec ses Netgear et TPlink, j'ai l'impression que le Dual WAN failover ce n'est jamais simple.

Le "refresh" fait plusieurs cycles de charge/décharge complets, en mesurant la capacité de l'accu à chaque cycle. C'est utile pour des vieux accus usés, ou qui ont été stockés longtemps sans utilisation => ils ont perdu de leur capacité. Le refresh fait autant de cycle que nécessaire tant que la capacité remonte. Lorsqu'il estime que la capacité ne montera plus, il arrêtera les cycles. C'est de la régénération en fait. Sur des vieux et gros accus AA >2000mAh, en cycle lent de 100mA, ça prend plusieurs jours.

Permet de vider totalement la batterie avant de la recharger, pour luter contre l'effet mémoire existant sur les NiMh (même si c'est moins gênant que les vieilles Nickel Cadmium) Si tu as le temps, idéalement il faut préférer un cycle complet de décharge puis recharge à 100%, avec un courant le plus faible possible. C'est le mieux pour la durée de vie des accus. La charge rapide est à proscrire dans tous les cas, sauf besoin de recharger en urgence (c'est valable aussi pour les téléphones....)

T'es pas en Belgique ?

Noeuds sécurisés et effets sur le maillage

C'est parce qu'il n'aime pas sa box

Faut rajouter 1000€ d'iPhone pour configurer l'Intercom, ce n'est pas un bon plan pour toi.

Je connais quelqu'un dont la pile a duré environ 1 an.... En extérieur avec le froid, il est évident que la durée de pile va être divisée par 10.

Faudrait que je mette un watchdog.... Pas eu le temps de regarder aujourd'hui.

argl.... pareil heureusement que tu surveilles ! J'essaierai d'étudier ça prochainement.

il m'a offert un paquet de bonbons Haribo dans le colis... une tentative empoisonnement ?

Bon, j'ai trouvé un super brouilleur de Wi-Fi. Le sèche cheveux ! Madame vient de l'utiliser à quelques mètres d'où j'étais posé le PC sur les genoux. Ça a coupé le Wi-Fi net ! Dès qu'elle a éteint l'appareil, le Wi-Fi est revenu immédiatement ! Impressionnant.... le moteur là dedans doit émettre une quantité de pollution électro-magnétique dingue.

Oui c'est sûr, mais perso là où il sera installé, il sera tout seul, et j'aime autant avoir un monitoring. Et puis installer un capteur Z-Wave, il faut gérer les piles, ou mettre des fausses piles + alimentation, etc. Ce capteur EMP c'est la solution de facilité, on branche, et ça marche. Par ailleurs, on peut définir des seuils d'alerte et extinction automatique avec la carte de management. J'ai acheté la mienne en reconditionné chez un vendeur Belge : https://www.ebay.fr/itm/Eaton-116750224-001-Powerware-UPS-EMP-Environmental-Monitor-Probe-EXCL-CABLES/282292194888 Il lui en reste une, j'ai fait une offre qui a été acceptée à 60€, vous pouvez essayer 55€. PS : j'adore, tu parles plus souvent de revente que d'achat ! Perso quand j'achète, c'est pour mon usage, pas pour le revendre.

Non mais en neuf laisse tomber, les prix sont carrément abusés.

Sinon y'a toujours la possibilité d'afficher les valeurs dans les labels du VD, ainsi que dans des VG.

Je n'ai pas encore attaqué la nouvelle version du VD, car : - je n'ai toujours pas fini l'installation de mon onduleur au nouvel emplacement (escalier qui mène à la cave, où il sera au frais et pourra faire du bruit) - j'ai installé la sonde EMP (Environmental Monitoring Probe) branchée avec un simple câble RJ45 sur le port dédié de la carte de management IP. Sympa,, ça donne la température, l'humidité, et 2 entrées contact sec. Son seul défaut être d'être hors de prix pour un module aussi simple, il faut la trouver en occasion sur eBay. L'objectif est que la prochaine version du VD puisse relever ces informations et les injecter dans des Fake Devices.

mouais, je comprends, mais comme je l'expliquais sur le topic du reverse proxy, changer les ports est une mauvaise technique de sécurité, que tous les débutants font en premier (car facile), mais qui s'avère inutile. Si quelqu'un pénètre ton réseau, même pas besoin de sniffer, avec un port scanner (nmap), il identifie les ports ouverts en quelques secondes. En clair, tu t'embêtes pour rien.

Euh perso, j'avoue, je n'ai pas choisi Fibaro pour ne pas qu'ils récoltent de données (ce qu'ils font au travers de Google Analytics, et probablement au travers du Fibaro ID / home.fibaro.com). C'est pour l'indépendance : - au cloud - à internet - à un service d'abonnement Bref, tout ce qui pourrait s'arrêter de fonctionner du jour au lendemain (volontairement ou involontairement) Je veux juste une domotique qui soit fiable et perenne, quoi qu'il arrive. Si ça collecte des informations, j'ai 2 choix : - j'accepte de vivre avec (ce que je fais pour l'instant.... comme tout le monde.... mais au moins j'en suis conscient, et je limite les fameux objets connectés (TV, cafetière, sonde pour lit, bracelet, etc)) - j'applique une politique de sécurité pour filtrer tout ça... et là ça se complique fortement.... création d'un VLAN IOT, firewall Deny All, et application de règle au cas par cas pour les objets qui doivent obligatoirement accéder à Internet).... bref cela demande beaucoup de temps, que je n'ai pas eu jusqu'à présent.

Non c'est extrêmement simple, il suffit pour Fibaro de réactiver les Plugins utilisateurs, fonctionnalité qui existant et fonctionnait très bien sur le firmware v4 Beta de la HC2, et qui a été retiré pour une raison qui m'échappe, et que Fibaro refuse de remettre en service... cela fait environ 3 ans qu'on attends. Si vous pouvez leur faire changer d'avis.... on serait tous heureux sur ce forum.

Ah oui tient, la minuterie de la cuisine c'est bien le seul truc qui me serait utile.... je reconnais que sortir le téléphone de ma poche pour mettre la minuterie c'est vraiment très compliqué T'es comme mon chef toi, il a même réussi à mettre un Mini dans sa voiture dont il a configuré le même SSID que sa maison pour que le Mini croie qu'il est sur le Wi-Fi local. Et un dans son bureau aussi. Bref, chacun son truc.... perso ce gadget me passe au dessus de la tête. J'espère pouvoir changer d'avis un jour....

Ah mais il marche toujours très bien mon VD, c'est juste que j'aimerais connaitre les nouvelles API... si ça se trouve ils ont ajouté la fonction réveil

J'aurais du dire : "...ça ne sert à rien pour nous". Exemple concret puisque tu parles de musique : Yamaha n'est pas compatible G Home. Et je ne vais quand même pas écouter de la musique avec le son pourri du G Home..... et je n'ai pas envie de passer un temps fou à développer une passerelle bancale à base de "OK Google Dis Jarvis Parle à Fibaro, ...." et j'exagère à peine. Google a vendu donné des millions de G Home Mini en France depuis Noël, j'aimerais bien savoir combien de gens l'utilisent réellement.... à mon avis très peu, et nous n'aurons jamais les chiffres. D'ailleurs mon G Home Mini est toujours sous colophane du coup, j'avais même réussi à l'oublier, je biens d'y penser à cause de cette discussion

J'ai profité d'un peu de temps perdu dans les transports pour lire ce papier. Intéressant, mais ce n'est aucunement une surprise que on s'intéresse au sujet depuis un certain temps. Pour la journaliste testeuse, cela semblait être une découverte,.... j'ai envie de dire, mais quelle naïve, et pourtant je ne dois pas être loin de la vérité si je dis que 95% de la population doit être dans la même situation. Malheureusement, l'article est beaucoup trop long pour que le public la lise, donc bien qu'il soit supporté par la fondation Mozilla, je pense que sa portée sera nulle. Après il faut bien replacer les choses dans leur contexte, ça ne parle absolument pas de domotique, mais plutôt d'objet connectés grand-publics, donc forcément dépendant du cloud et qui récoltent un max d'infos par définition. Ce qui m'a fait surtout sourire, c'est le passage sur la compatibilité entre les assistants vocaux et un très petit nombre d'objets connectés.... obligeant à changer l'objet connecté par un autre ! Quelle arnaque.... une des raisons qui fait que mon Google Home est retourné dans sa boite.... passé la première heure d'amusement, ça ne sert à rien.

C'est un trame de type "broadcast", donc envoyée à tous les modules (comme en réseau Ethernet)... et pour limiter sa propagation, la trame d'alarme n'est pas routée par les modules (toujours comme en réseau Ethernet). Les modules de type capteur (fumée, mouvement, ouverture, inondation, etc) ont la possibilité d'envoyer des trames d'alarme. Par défaut les modules n'envoient pas de trame d'alarme (tu peux vérifier dans les paramètres de tes modules, et dans la doc des modules). Mais Fibaro propose toujours cette fonctionnalité dans tous ses modules capteurs, et on peut l'activer. La Zibase semblait être particulièrement touchée par un bug, qui activait les trames d'alarme sur les modules capteurs.... donc ceux-ci les envoyait au premier événement venu. Comme les modules Fibaro actionneurs (FGR, FGD, FGS, etc) sont configurés par défaut pour réagir aux trames d'alarmes, alors il pouvait se produire ce que tu as constaté. La notion de trame d'alarme date des tous débuts du Z-Wave, et été peu à peu abandonnée.... en fait elle était prévu pour que les modules puissent réagir automatiquement, sans dépendre d'un contrôleur Z-Wave. Aujourd'hui tout le monde utilise un contrôleur Z-Wave sophistiqué (pas de troll, ils sont tous sophistiqués), donc on préfère configurer les scénarios via la box domotique (scène, GEA, etc), ou directement en créant des associations directes entre modules. Il se pourrait donc que l'un de tes capteurs ait activé l'envoie des trames d'alarme.... suite à un bug du firmware par exemple. Bref, aucune certitude que ton problème proviennent de ces trames d'alarme broadcast, mais c'est une piste.

Ah merci du retour, je suis surement tombé sur une première génération.