Sowliny

Un optocoupleur est aussi envisageable.. Mais il faut un minimum de support "circuit imprimé" de type Veroboard.

Bonsoir, Si les SORTIES du FGBS-222 peuvent accepter jusqu'à 30V, ce n'est pas le cas des entrées IN1 et IN2. Donc : - d'une part, celles-ci n'acceptent EN MODE "ANALOGIQUE" qu'une tension entre 0V et 10V, donc incompatible avec une sonnette 12V (sauf à intercaler une commande secondaire qui enverrait du 10V - trop lourd pour ton application et inélégant - sauf peut-être un diviseur de tension avec un transistor de commande...). - d'autre part, ces entrées, EN MODE "STANDARD" (on va dire) sont commandées EN LES METTANT A LA MASSE du FGBS (soit GND de l'alimentation). Cela implique donc là aussi un "étage" intermédiaire qui serait commandé par la sonnette. Par exemple un simple transistor, un (petit) relais 12V, ou encore un relais "Reed"... Je te prépare un crobard si tu veux...

@Patrickdu34, je ne pourrai pas t'en dire plus, comme je n'ai pas la doc sous les yeux. Ce qui m'a fait pencher en ce sens, c'et l'indication 24V "+" et 24V "-", ce qui indique une tension polarisée (continue). Facile a voir avec une LED (et sa résistance) : si elle s'allume dans un sens et pas dans l'autre, c'est donc une tension continue. Sinon nous aurions eu le symbole "~" qui désigne l'alternatif. En ce qui concerne ta deuxième détection, le FGBS possède deux entrées - tu pourrais peut-être t'en servir s'il n'est pas trop loin ?

Oui, mais c'est un prix obsolète - la page fait partie des archives du site en question.

Très bien pour le 12 VDC, c'est avec cette tension que j'alimente mes FGBS (+Smart Switch bien sûr). Cela permet dans certains cas d'utiliser une petite batterie (plomb-gel) et panneau photovoltaïque pour la charger. Mais je pense que la carte ne FONCTIONNE PAS en 24 VAC mais en DC. La tension alternative doit être redressée, filtrée, etc... sur la carte elle-même. Il doit être assez facile de repiquer une tension DC compatible avec le FGBS; avec sa très faible conso, cela ne devrait pas poser de problème. Je dis "assez facile", car j'ai l'habitude de ce genre de repiquage... Ou plus simplement sur le connecteur "Alimentazione accessori - sorties 50 & 51 " que j'ai vues sur le schéma ?

A l'époque, oui... J'ai même trouvé sur un forum une bidouille entre HC1 et Vera. J'ai trouvé les infos précédentes sur un site de vente polonais..

Bonsoir, Je vais peut-être faire un flop, mais je viens de trouver par hasard sur le web, une photo et une description succinte de la première (?) box fibaro, la HC1 ! Voici la chose : Juste pour le fun... Mais comme je l'ai dit au début, c'est peut-être un sujet bien documenté sur le fofo (malgré que je n'aie rien trouvé...).

Je suis aussi en 5.090.17, et sans souci majeur apparent. Je dis souci majeur, car depuis la dernière vraie stable, je rencontre outre des erreurs de com avec les modules plus fréquentes qu'auparavant, une absence de retour des "fibaro.debug("trace"...." lors des tests de scènes. Enfin pas vraiment, ces messages apparaissent (bien) plus tard, souvent pendant la nuit, comme si la box était "saturée" par le boulot à effectuer. Pourtant les jauges proc et mémoire restent très correctes. Outre le fait qu'une simple erreur de module comme celle rencontrée par @Iceman suffit à mettre la pagaille dans une "simple" mise à jour, cela indique bien à mon sens qu'il y a encore beaucoup de travail "de fond" à effectuer. Nonobstant le fait que je ne code que des scènes encore actuellement avec peut-être leur lot "d'incohérences"...

Oui, effectivement c'est très beau ! Cependant, ça me paraît plus tenir du diaporama que d'une info locale pertinente. Mais bon, je n'émet cet avis qu'après avoir la capture de @Lazer... J'ai aussi reçu la beta 5.091.41 - mais ma box n'étant pas en test, je vais lâchement m'abstenir de tenter une m.à.j. avant quelques jours. Par exemple, après avoir lus quelques commentaires plus haut, le non-redémarrage "AFTER" persiste. Pour éviter de menus emm...

D'accord avec @ROBBEJP. C'est vrai que j'attends une géolocalisation qui fonctionne vraiment (à moins que j'aie raté quelque chose ? - j'ai laissé tomber depuis un bon bout de temps déjà). Mais désormais la "gestion environnementale" est implémentée, et c'est quelque chose qui risque de m'intéresser... Si toutefois c'est quelque chose qui : a) fonctionne; b) présente un intérêt réel; c) et ne soit donc pas un gadget commercial. Je ferai la m.à.j. ce weekend, tranquillement.

Aucun problème recensé de ce côté-là,. J'ai 5 FGMS (toutes générations confondues) qui ne me soucient absolument pas (pour une fois... ). (sauf un, assez ancien, que je dois réactiver manuellement à chaque coupure de courant - il est sur alim. usb avec un convertisseur 3.3v) Les détections sont correctes, de même que les valeurs remontées, aini que leur réactivité très satisfaisante. Hors propos, j'ai aussi deux Aeotec SmartSensor 6 (pour l'humidité) sans problèmes non plus.

J'ai peut-être trouvé une (première) piste : la scène était paramétrée sur "manuel" et non pas sur "automatique". Cela dit, je pense avoir encore suffisamment de neurones fonctionnels pour éviter ce genre de gag. Cela fait plusieurs fois que je rencontre ces modifications qui se font sans "bruit" - bug ? Bon après quelques déclenchements, il apparaît que c'est bien la cause de mes soucis. Etrange...

Ce message n'a rien à voir avec les Smart Implant... mais après avoir recherché dans la section HC3, je ne trouve pas de piste sur le sujet suivant : Le trigger "cron/interval" ne semble plus du tout fonctionner... Voici ma syntaxe (sortie en droite ligne de "manuals/fibaro") : { type = "date", property = "cron", operator = "matchInterval", value = { date = { "*", "*", "1", "1", "*", "2020" }, interval = 900 }, isTrigger = true } Rien de plus simple, mais aucun déclenchement. J'ai essayé avec "*", "*", "*", "*", "*", "*", sans plus de succès. J'utilise ce trigger dans une autre scène avec plus de succès (quoique, les déclenchements sont franchement erratiques la plupart du temps) Quelqu'un aurait-t'il une idée ?

Tiens, je ne connaissais pas ce format - vraiment très moderne alors... Pour ma part quand je commande un radiateur un quelque chose de plus "sensible" du point de vue commutation (en dehors bien sûr du fil pilote), j'utilise des relais opto-électroniques avec zero-crossing - bon, c'est plus volumineux... Ou alors, comme cela avait été le cas pour un précédent chauffe serviette, une prise murale et un WallPlug (avec les contingences du volume de sécurité).

PS : je "publierai" bientôt dans la section DiY, ma réalisation d'une commande d'alimentation de radiateur (à bain d'huile) basé sur un Smart Implant, en fonction de la température et de l'humidité (pièce d'hivernage de jeunes bonsaïs).

Merci à vous ! Je cumule donc certainement ces deux problèmes, quoique le plus important soit effectivement ce problème des "vieux" modules. Qui ne sont pas "+". Dans une vie antérieure (avec la HC2), ils servaient à la commande de fils pilote. Je vais donc envisager le "rapatriement" près de la mère box et/ou leur remplacement par des modèles "+". Avec peut-être aussi l'installation d'un relais z-wave Aeotec, intercalé entre la maison et la grange? Pour le moment le seul désagrément engendré est un petit "retard à l'allumage" de l'éclairage extérieur (couplé à des détecteurs Steinel).

Je pense que tu peux faire la mise à jour sans inquiétude. Ma HC3 est en prod depuis maintenant plus d'un an, et malgré les vicissitudes des débuts, accomplit bien ses missions. Les FGS-nnn qui rencontrent des soucis (mais pas systématiquement) sont des modules (Fibaro) qui ont déjà un peu "de bouteille" et vécu un changement de box. Mais c'est certainement l'environnement qui perturbe le z-wave (vieille maison en rondins et grange en bois également), ce qui doit provoquer un amortissement du réseau (sans oublier les toitures métalliques). Cela malgré la présence de maintenant 4 modules qui devraient se relayer. Et sans compter le présence d'un "barda" conséquent dans la grange, dont de nombreux et volumineux artefacts métalliques. La commande des modules (d'éclairage par exemple) se fait toujours à travers une fonction incluse dans les diverses scènes. Celle-ci commence par envoyer l'ordre "turnOn", teste le résultat, et si ok effectue un "return". Dans le cas contraire, elle procède à trois nouveaux essais (au maximum) pour effectuer la commutation. Mais il ne s'agit pas d'une salve de trois ordres ! Un délai entre chaque commande, qui double à chaque essai infructueux. In fine, si la commutation échoue, les paramètres ( id du module, etc...) sons inscrits dans une VG. Avec bien sûr un suivi "trace" et un "push" en cas d'échec. En général, la commutation est effectuée au 2ème ou 3ème ordre...

Je confirme : aucun souci de com avec le Smart Switch, au terme d'environ 2 heures de bascule de 2 switchs et de lecture des capteurs associés. Bien sûr, cela n'est pas un test sur le long terme, mais prouve déjà je pense, que ça "passe bien" entre HC3 (dans la maison) et un Smart Switch situé au fond de ma grande à environ 25m. La box est bien en 5.090.

Pour le moment, la communication est correcte (le Smart Implant est en version 5.20) Une scene de test actionne successivement les deux commutateurs, puis les éteint quelques instant après. Le capteur de température interne est disponible, ainsi que celui du DHT22 câblé en entrée (de même bien sûr que le taux d'humidité). Je verrais bien si cela occasionne des erreurs de com. Manuellement, aucun souci. Les commutations "répondent" bien.

Je n'ai pas de Smart Implant en activité actuellement - j'en remets un en fonction pour vérifier... Cependant, depuis cette mise a jour (ainsi que pour les 2 beta précédentes) je note une augmentation sensible (c'est à dire une dizaine par jour, voire plus) des incidents de communication avec des FGS, dédiés à éclairage, en grande majorité.

Quand je parlais de reboot, c'était simplement le redémarrage après la mise à jour. Je m'étais mal exprimé...

Chapeau bas... Mise à jour parfaitement réalisée, en un temps record, et avec un reboot "after" sans aucun problème !

Dans l'attente des résultats de la mise à jour, je dirais à décharge que les procédures de backup sont bien plus fluides et rapides qu'aux premiers "pas" dans ce monde de la HC3...

Comme je disais plus haut : bref. Je vais faire la.mise a jour...

Pas pressé non plus dans ces conditions de passer au Z-wave 3... En "temps normal" je ne demande même plus de reboot à partir de l'interface - ça part en sucette à chaque fois (comprendre reboot non effectué correctement, et/ou "foirage" de l'interface. J'effectue un shutdown à partir du bouton arrière de la box, débranchement de la prise quelques secondes et ensuite redémarrage en rebranchant la prise - car j'ai eu des expériences non concluantes sans débrancher. Bref. La nécessité de reboot se fait quand même rare au fur et à mesure de l'évolution des m.à.j.