fel-x

Oui, même sans les poules... ou alors cette porte peut très bien servir de chatière... ou de boite-aux-lettres pour Amazon que tu ouvres quand le livreur est là.. ou juste de déco parce que c'est cool Comme dit l'expression : L'inutile et le superflu sont plus indispensables à l'homme que le nécessaire.

Petit update pour les intéressés et @Gayna28 Omlet a sorti un nouveau modèle de boitier pour la porte, il ne faut pas tout changer, juste le boitier. Celui-ci se connecte au Wifi et est pilotable à distance. Ils ont aussi un API désormais. Il m'en a couté moins de 50 Euro (avec un code promo) https://www.omlet.fr/porte-automatique-intelligente-pour-poulailler/ Je me suis inspiré de ceci : https://community.homey.app/t/omlet-smart-automatic-chicken-coop-door-automation-using-homey-script/115988 et j'ai traduit en Lua (enfin pas moi, mais chatGPT) pour intégrer la porte et ses commandes dans ma HC3 ; ça marche super bien. Je peux partager le code au besoin...

Tu as raison @Lazer, j'ai remarqué que l'état ne change que sur la box qui envoie une commande. Je peux donc contrôler mes modules depuis la HCL ou la HC3, mais c'est tout à fait bancal. Bref c'est comique mais c'est inutile. Je vais le signaler à Fibaro et remettre la HCL aux paramètres d'usine pour la recycler.

Pour info, la migration de ma HCL vers HC3 s’est bien déroulée… et la dernière étape qui pourtant est sensée être automatique (mise en mode lecture seule de la HCL) n’a pas eu lieu. résultat : je peux contrôler mon réseau avec les deux box en même temps !!! J’ai lu quelque part que ce bug arrive parfois. je vais en profiter pour garder la HCL comme « esclave »

Non tu as raison, les deux box « light » (HCL et HC3L) ne partagent pas le même chip (ZW300 pour HCL et ZW700 pour HC3L) alors que la HC3 dispose du ZW500. Le système de migration mis en place par Fibaro (mode « donneur ») pour sa HCL fonctionne bien. J’ignore pourquoi il ne peut pas être appliqué à la HC3L… En tout cas ça a été explicitement indiqué par un officiel de Fibaro sur leur forum (ici). Je suppose que c’est une incompatibilité dans les firmwares ou Chip ZW qui bloque. Quand je pose la question à ChatGPT, il suggère que ça pourrait aussi être une stratégie commerciale… mais je pense sincèrement que c’est une question de firmware ou chip ZW. lis la comparaison ici

Je parlais des HC2 et des HCL. Moi je suis encore sous HCL et je dois donc obligatoirement attendre le bon vouloir du Support pour lancer la procédure de migration. Les HC2 peuvent le faire par eux-même. J'ai lu que toi tu avais une HC3L... Les HC3L ne peuvent pas du tout migrer je pense à cause d'une incompatibilité de leurs puces Z-Wave. C'est expliqué ici.

La documentation est en lien dans mon post : https://manuals.fibaro.com/document/hc3-migrating-data-from-hc2-hcl/ Une HC2 peut migrer vers une HC3 directement; l'utilisateur peut faire la mnoeuvre tout seul quand il le veut. Une HCL/HC2L doit d'abord être passée dans ce mode "donneur" par le support de fibaro. Elle devient apte à trasnférer sa configuration vers une HC3, mais elle fonctionne en mode dégradé. Ayant une HCL je ne peux pas faire la migration tout seul, je dois attendre l'action du support de Fibaro. Et j'attends depuis des jours et tu vas voir qu'il vont la passer en mode "donneur" pendant mes congés dans 3 semaines et je ne pourrai plus rien contrôler à distance. Leur méthode est foireuse. Et c'est là que je demande quel est leur temps de réaction habituel ?

Salut, en parlant de migration ça fait plus d'une semaine que j'ai demandé par email (et ouvert un ticket en parallèle sur support.fibaro.com) pour qu'ils passent ma HCL en mode "ARTIFICIAL DONOR" C'est la procédure obligatoire pour migrer depuis HCL vers HC3 Aucune réponse jusqu'à présent et je me demande quel est leur temps de réponse moyen ? Ils disent dans leurs instructions qu'en cas d'échec de la migration, il ne faut surtout pas la relancer et les contacter. Ca ne m'inspire pas confiance si je dois attendre 3 semaines avec une migration en échec que ces gens daignent répondre.

Bon sang, mais c'est bien sûr ! Cette solution va donner une LED allumée lorsque la lampe est allumée, ce qui est l'inverse du comportement initial, mais c'est déjà ça. Je vais quand même vérifier s'il est prudent de faire passer des câbles pour du 220V vers les petits ressorts à l'arrière du module LED, celui-ci devant être clipsé derrière l'interrupteur il n'y a pas de place je pense. Et surtout il ne faudra plus que ces ressorts touchent l'alimentation de l'interrupteur.... Comme il fonctionnait sur une phase unique, sans neutre ni terre... je vais aussi vérifier comment il va réagir si on apporte une phase et un neutre. Bref bricolage en vue... j'adore

Haaa là tu m'intéresses Tu aurais un petit schéma de ce que tu proposes ? J'ai sans doute un peu de place pour faire remonter des câbles, mais ça reste du 220V alors je suis réticent à brancher ça à des petits ressorts derrière le cache de la prise.

merci @jluc2808 En effet je voulais le comportement initial (led allumé si lampe éteinte) mais ce ne sera pas possible. Je ne peux pas employer Q2 comme dans ton idée de "gaspiller" un dual switch pour ne contrôler qu'une ampoule et employer une scène pour activer Q2 car il est déjà employé par un autre interrupteur dans le même boitier : S1>Q1 et S2>Q2. S'il est possible d'inverser le fonctionnement du LED (allumé quand ampoule allumée) je serais tenté d'essayer. Mais comment bricoler l'accessoire (ref)?

Pour info, retirer le LED BLUE (il se click et dé-click facilement de l'intérieur de l'interrupteur) rend le tout fonctionnel On peut donc en conclure que le petit LED utilise un courant très léger mais permanent entre L et S1, ce qui empêche le module FGS-223 de détecter une absence de tension sur S1 lorsqu'on coupe l'interrupteur. Je peux vivre avec des interrupteurs qui n'ont pas de lumière bleue, à vrai dire je n'en ai même pas franchement besoin... Mais le challenge est là... comment permettre à ce LED de puiser un mini courant sur L sans affecter S1 ? Est-ce même possible? Avec un bypass ou quelque chose comme ça ? Si des électriciens ont contourné ce problème je suis preneur

merci @jojo Je vais tester le 1) Le 2) est fait depuis longtemps et fonctionne sans souci J'imagine que la présence de ce LED témoin gêne le module et empêche que S2 soit activé par l'activation de l'interrupteur comme le suggère @Lazer Essai demain après le boulot :-) ...

Non en effet, je n'ai pas accès directement au petit témoin Led. Je peux m'en passer et au pire je me fiche qu'il soit allumé ou éteint ou même non fonctionnel. Je voudrais juste que l'interrupteur allume la lampe aussi, ce qui me semble être le B-A-BA de ce module. J'ai deux interrupteurs dans ce boitier d'encastrement, contrairement à mon dessin. L'interrupteur du haut entre dans S1 et l'interrupteur du bas entre dans S2. Q1 part vers la lampe du haut et Q2 part vers la lampe du bas. Je pense que c'est correct, non ? Alors pour quelles raisons aucun des deux interrupteurs n'a d'effet sur les lampes ou le module ?

Salut tout le monde, Je galère avec un FGS-223 sur un interrupteur Niko (interrupteur bipolaire, à témoin lumineux LED bleu). J'ai lu le forum mais mes connaissances en électricité ne me permettent pas de trouver la solution par moi-même. Pour la facilité j'ai fait un schéma, et pour simplifier je n'ai employé que S2 et Q2 (mais en réalité il y a 2 interrupteurs identiques et j'emploie S1 et Q1 pour l'autre lampe) Sans le FGS-223, les interrupteurs Niko ressemblent à ceci et fonctionnent comme attendu; c'est à dire que le témoin LED bleu est allumé si la lampe est éteinte et il est éteint lorsque j'allume la lampe. C'est un système "Niko LED Blue" intégré dans l'interrupteur. Voici le montage du module que j'ai réalisé : Il me semble que le montage soit assez simple et il fonctionne très bien : le module me permet d'allumer et d'éteindre l'ampoule. Là où je sèche c'est sur le fait qu'avec ce montage, l'interrupteur n'a plus AUCUN effet sur l'ampoule ! Actionner l'interrupteur permet d'allumer ou d'éteindre la petite diode bleue, sans aucun changement sur l'ampoule. J'ai bien configuré le paramètre 20 sur "bistable" = option 1 : toggle switch (contact closed - ON, contact opened - OFF) Je pensais que le changement d'état de l'interrupteur allait envoyer l'info à S2, qui est sensé immédiatement envoyer la phase à Q2 ? La présence de cette diode bleue est-elle la source du problème ? Certains ont déjà pu résoudre ce problème sans changer les interrupteurs ? merci

salut à tous, J'emploie ce thermostat SRT-321 depuis près de 11 ans (j'avais fabriqué de fausses-piles mais ça ne s'adapte pas avec esthétique dans mon salon, alors il tourne sur des AAA) Je constate qu'il perd parfois la connexion avec la box, qui se trouve pourtant à 5 mètres à vol d'oiseau. Hier encore, après un backup (donc reboot) de la box HCL en vue de migrer sur HC3, je vois qu'il est déconnecté. Il n'y a plus les petites ondes et il est marqué comme mort. Impossible de le réveiller par la box, donc tourne-vis... switch numéro 1 en mode "installer"... réveil forcé durant 30 secondes ("Li") ... mais RIEN. Je ne compte plus le nombre de fois chaque année que je suis dans le même cas et je sais que je dois juste l'exclure et l'inclure, puis reconfigurer (nom et pièce) comme j'aime. J'ai lu que lors de la migration vers HC3 de toute façon il faudra le ré-inclure car il ne passe pas dans le processus de transfert comme les autres modules. Ma question est simple: est-ce toujours une galère pour le réveiller depuis la HC3 pour ceux d'entre-vous qui l'emploient encore? Sinon quelle alternative de +/- même taille et sur piles pouvez-vous (chaudement) recommander ? merci & bonne année

Bon alors j'ai trouvé la solution. Ce n'est écrit nulle par dans les documentations ou les forums mais : Une variable PEUT servir de TRIGGER à une scène sur HCL MAIS... le changement de variable n'est détecté QUE SI il est provoqué par une scène. Le changement manuel dans le panneau des variables ou un appel http pour changer la valeur de la variable, NE SONT PAS pris en compte. exemple de script qui donne la valeur 4321 à la variable "TEST_VARIABLE" : curl --user email:password -X PUT -H "Content-Type: application/json" -d "{\"name\":\"TEST_VARIABLE\",\"value\":\"4321\"}" "http://BOX_IP/api/globalVariables/TEST_VARIABLE" > /dev/null 2>&1 Voilà. Ca évitera à d'autres de perdre du temps à essayer. Solution de contournement : J'ai modifié mon script bash pour qu'il change les valeurs des variables, puis vérifie toutes les conditions, et le cas échéant, active la scène qui m'envoie une alerte. A nouveau il faut savoir que c'est un appel http à cette scène, ce qui fait que peu importe les conditions 'IF', seul le 'THEN' sera exécuté. Je peux donc décocher tous les triggers et laisser cette scène en mode MANUEL : J'aurais pu mettre n'importe quoi comme condition dans cette scène; mais pour la propreté j'ai laissé les mêmes conditions qui sont vérifiées par le script bash : # Récupération de la variable NotifPVEnvoyee depuis Fibaro notif_envoyee=$(curl --silent --user user:password "http://BOX_IP/api/globalVariables/NotifPVEnvoyee" | jq -r '.value') # Vérification si la notification a déjà été envoyée if [ "$notif_envoyee" == "0" ] && (( $(echo "$prod >= 5" | bc -l) )); then # Activation de la scène 157 sur Fibaro pour envoyer la notification curl --user user:password -X POST "http://BOX_IP/api/scenes/157/action/start" > /dev/null 2>&1 fi Bref, c'est faisable. Je reste persuadé que un Raspberry + une HCL peuvent contourner toutes les limites ;-) A+ Fel-X

Merci d'avoir regardé de plus près. Oui j'ai bien sûr testé avec une seule condition (sur la variable Production PV) en supprimant la seconde (variable NotifPVEnvoyee). Que ce soit en cochant la case trigger ou non pour la variable Production PV, ça ne marche pas. Idem en laissant les 2 conditions et en essayant les 4 combinaisons de cases triggers (2 cochées, 0 cochée, 1 cochée et l'autre pas, 1 pas cochée et l'autre oui) Suis-je en droit de conclure que qu'une variable ne peut pas servir de trigger sur HCL ? Et à qui poser la question . Support Fibaro ? Merci jojo

ok à priori vois-tu une erreur dans ma scène ci-dessus? Parfois quand on écrit soi-même un truc, et à force de le relire on en voit pas l'évidence... Alors un regard neuf dessus est bienvenu. Et je vais devoir apprendre le LUA si je passe à une HC3 ? Prochaine étape alors : je contacte Fibaro pour savoir s'ils peuvent garantir une trasnsition de HCL vers HC3 sans bug ni perte... et je préssens la réponse.

jojo, ton stress est passé? problème résolu ? Ma demande est très simple, mais j'ignore si tu peux la tester avec juste un module. Je veux recevoir une notification baptisée "Production PV" dès que la production électrique de mes panneaux PV dépasse 5kWh. J'ai donc créé 2 variables : ProductionPV (valeur numérique à virgule et à 2 décimales, qui est mise à jour toutes les 5 minutes par un script sur Raspberry qui récolte la production du jour des panneaux PV) NotifPVEnvoyee (pour savoir si la notification de production a déjà été envoyée ; 0 si pas encore envoyée, et 1 si déjà envoyée) Les 2 sont remises à ZERO (0) à minuit par un autre script. Ca fonctionne bien et ça permet grâce à la variable NotifPVEnvoyee de n'avoir qu'une seule notification par jour puisqu'elle fait partie de la vérification conditionnelle pour envoyer cette notification. Sinon bien sûr, chaque 5 minutes, je recevrais une notification puisque la production augmente durant la journée et chaque mise à jour de la valeur de ProductionPV serait supérieure à 5 ! Voici ma scène : Et voilà. La variable Production PV est la seule cochée comme "déclencheur", afin d'être surveillée. Si je ne me suis pas trompé, mas scène se traduit comme ceci : Lorsque je presse le bouton "play" de la scène (ce qui par définition ignore les conditions IF, et execute d'emblée le THEN), j'ai bien ma variable NotifPVEnvoyee qui passe à la valeur 1 et la notification sur mon iphone et mon appleWatch. Je peux même le faire plusieurs fois; je reçois toujours la notification et la variable NotifPVEnvoyee reste à 1. Donc en mode manuel la partie THEN de ma scène est fonctionnelle. Mais en mode automatique, il ne se passe RIEN !!! Pour la facilité du test, j'avais modifié le déclenchement à 1kWh (au lieu de 5) pour que ça survienne déjà ce matin, et j'ai surveillé la production qui est passée de 0,00 à 0,2 puis 0,32 puis 0,6 puis 1,1, et là on est à 1,82 ! Je n'ai pas reçu la notification et la variable NotifPVEnvoyee est toujours à 0. A noter qu'une modification de variable manuellement dans le panneau des variables, n'est pas considérée par Fibaro comme un déclenchement. Ça je le sais, c'est connu. Je m'étais alors dit que peut-être la même chose est d'application si la modification de la variable provient d'un script ? J'ai alors créé une petite scène qui se déclenche à une heure précise (13H10) et qui modifie la variable Production PV en lui donnant par exemple la valeur 12,34... Ça devrait être un bon déclencheur non ? Eh bien RIEN ! La variable Production PV a bien pris la valeur 12,34 à 13h10, mais je n'ai pas reçu de notification et NotifPVEnvoyee est restée à 0. Où est l'erreur ? Que faire? merci Fel-X

Bonjour @RUV Je ne sais pas si tu es toujours sur le coup, mais je suis parvenu à récupérer quelques données via l'API de WALLBOX. Je peux te fournir les codes et instructions, sachant que je fais toutes mes requêtes via un script bash sur un raspberry, qui envoie ensuite les valeurs ponctuellement à un module virtuel dans ma HCL. Si tu t'y connais un minimum, tu devrais pouvoir retranscrire ça en LUA pour ta HC2/HC3 Résultat pour le moment : J'ai créé l'icône aussi pour le côté esthétique : Je bosse encore pour découvrir comment le piloter, mais ce n'est qu'une question de temps pour que j'y parvienne ;-) Dis-moi si tu es toujours intéressé... A +

Salut @jojo merci pour ta proposition, peut-être un jour j'accompagnerai madame à Nivelles (elle y travaille tous les jours) et passerai te saluer... Est-ce que la HC3 va m'aider à réussir ce que la HCL ne fait pas ? Je veux dire les scènes et les triggers fonctionneront ? Parce que si la raison est que c'est uniquement bridé sur HCL alors oui la HC3 serait une réponse. Mais si c'est possible sur HCL et que c'est juste une erreur dans ma structure de la scène alors je préfère apprendre et me corriger. Sincèrement, je peux faire fonctionner ma scène depuis Raspberry avec un simple script. Tiens juste pour le fun si ça peut aider quelqu'un, voici des exemples : #!/bin/bash valeur_test = coucou # Mise à jour d'un module virtuel dont l'ID est 123 dans Fibaro curl --user login:password 'http://IP_BOX/api/callAction?deviceID=123&name=setProperty&arg1=ui.Label1.value&arg2='$valeur_test' > /dev/null 2>&1 # Mise à jour d'une variable globale dont le nom est Variable_Bidon dans Fibaro curl --user login:password -X PUT -H "Content-Type: application/json" -d "{\"name\":\"Variable_Bidon\",\"value\":\"$valeur_test\"}" "http://IP_BOX/api/globalVariables/Variable_Bidon" > /dev/null 2>&1 # Récupération de la variable Variable_Bidon depuis Fibaro Valeur_Variable_Bidon=$(curl --silent --user login:password "http://IP_BOX/api/globalVariables/Variable_Bidon" | jq -r '.value') # Activation d'une scène dont l'ID est 321 sur Fibaro curl --user login:password -X POST "http://IP_BOX/api/scenes/321/action/start" > /dev/null 2>&1 Et avec Crontab on peut faire exécuter les scripts à l'heure et/ou la fréquence qu'on veut. En plus ça décharge le CPU de la HCL Donc avant d'aller t'ennuyer chez toi pour me faire convaincre de débourser 400 Euro pour faire ce que je sais déjà faire... je vais attendre de voir si des utilisateurs de HCL peuvent confirmer le bridage des déclencheurs par variable sur HCL ? Bonne soirée !

Salut à tous, Je lance une bouteille à la mer, au cas où il y a encore de bonnes âmes prêtes à aider leur prochain ici. Tout d'abord je suis encore sur HCL, et j'en suis satisfait depuis 10 ans. Je n'ose pas imaginer passer sur HC3 car il me semble que la migration serait trop laborieuse, avec des dizaines de modules qui ne sont pas accèssibles physiquement sans démontage mobilier ou bien soudés dans un bricolage à longue distance de la box. J'ai contourné l'absence de LUA et d'autres fonctions sur HCL, en les exécutant sur un raspberry, et même les caméras non compatibles, je les vois dans mon interface fibaro en récupérant leur flux sur le réseau local via un script PHP aussi sur le raspberry (et Fibaro le réceptionne comme une caméra IP). Ceci pour dire que je ne souhaite pas une solution "passe sur HC3" qui n'est pas assez "débrouille" pour moi Je pourrais illustrer ce qui ne fonctionne pas par des captures décran, mais avant ça, je voudrais savoir si ça en vaut le coup. Car ici aussi je peux contourner le problème en mettant mes variables à jour depuis un script et en lançant l'exécution des scènes depuis le raspberry. Mais ce n'est pas l'idée de ce post. Je voudrais juste savoir s'il est admis que l'usage de déclencheurs (triggers) comme condition dans une scène est impossible et non fonctionnel sur HCL ? Il y a des petites cases pour confirmer si une variable doit bel et bien service de déclencheur ou pas, mais indifféremment du fait qu'elle soit cochée, la routine ne se déclenche JAMAIS : La scène est fonctionnelle en pratique, puisque l'appui manuel (bouton PLAY) de la scène lance bien les actions (on sait que le IF est ignoré, et seul le THEN est appliqué, lors de l'activation manuelle d'une scène sur FIBARO). Seulement voilà, je ne trouve nulle part l'info qui dit que Fibaro ne tient pas compte du changement de variable comme déclencheur pour déclencher une scène. Soit c'est encore une règle implicite à Fibaro, ou uniquement à HCL ? Soit je fais une erreur quelque part... et si on est dans ce cas de figure... je veux bien de l'aide Merci et bon dimanche Fel-X

Salut @RUV Je viens aussi d’installer une Wallbox Pulsar Plus et leur application est pas mal. je voudrais comme toi remonter des infos vers la box fibaro pour les exploiter. Si tu trouves des pistes, je suis preneur quant à @jojo il a pensé que tu parlais d’une box Domotique.. > c’est un chargeur de voiture électrique ;-)

Non c’est le GUI de ma HCL