pepite Posté(e) le 14 mai 2019 Signaler Posté(e) le 14 mai 2019 Suggestion : ton retour visuel avec un rubal led ou une lampe, ou des Hue ;-) Quand tu armes l'lalrmes, tu allumes ton ruban de la couleur désirée et quand tu éteins, tu chages la couleur. Et hop un retour visuel, mais si tu pars en vacances plusieurs jours, tu les laisses allumer ?
Fur Posté(e) le 14 mai 2019 Signaler Posté(e) le 14 mai 2019 Merci pour la réponse. De fait y a la piste d'une lampe et d'un ruban, mais je me demandais s'il n'existait pas une solution plus économe. Le témoin peut s'allumer que après l'ouverture de la porte.
Lazer Posté(e) le 14 mai 2019 Signaler Posté(e) le 14 mai 2019 Il faut que tu relises les tutos dispos sur Internet sur les bases du Z-Wave, tu comprendras pourquoi ce protocole est le meilleur pour de la domotique sans fil, mais aussi pourquoi il n'est pas utilisable en alarme (ses forces en domotique deviennent des faiblesses en alarme.... c'est 2 mondes différents) Un FGMS, donc, sur batterie, ne se réveille qu'à intervalle régulier, il n'écoute pas le réseau, tu ne peux pas le piloter à distance. Tu peux aller faire un tour dans la section pour les nuls du forum, il y a un mini-tuto sur le sujet des modules sur batteries. Pour signaler un événement, tu as effectivement les solutions des lampes Hue ou rubans RGB en couleurs, ou simplement faire clignoter une ampoule dimmable classique au plafond, ou encore de faire parler via TTS une enceinte connectée, ou alors une sirène domotique muti-tons qui peut être configurée en sonnerie douce (type carilon.... voir cher Aeotec, ou 2 ou 3 autres marques, on en a déjà parlé sur le forum ça et là)
Lazer Posté(e) le 14 mai 2019 Signaler Posté(e) le 14 mai 2019 En complément, la signalisation que tu as vu dans le publicité FIbaro, cela peut être 2 choses, qui n'ont rien à voir avec une détection d'intrusion..... et de toute façon la lueur est tellement faible qu'elle ne ferait même pas fuir une princesse : - lors d'une détection de mouvement, l'oeil s'alume - lors qu'on bouge le capteur, l'oeil clignote aux couleurs de la police. C'est rigolo. Mais encore une fois totalement inoffensif, et puis de toute façon, jamais un voleur ne volera tes capteurs de mouvements
Fur Posté(e) le 21 mai 2019 Signaler Posté(e) le 21 mai 2019 Merci pour toutes vos réponses. Bon évidemment maintenant que j'ai acheté le matos, c'est un peu tard pour partir sur un autre système. Je vais donc plus me baser sur les détecteurs d'ouvertures de portes. Pour signaler l'armement et le désarmement, je vais plutot partir sur la génération d'un "bip" avec la sirène. (Faut juste que j'appréhende la gestions des paramètres pour un device sans template, mais ca sera p-e un autre topic si je galère :-p )
Fur Posté(e) le 21 mai 2019 Signaler Posté(e) le 21 mai 2019 Par contre, j'ai encore une question concernant le FGMS, liée à l'application mobile. Dans la catégorie détection, on voit les différentes pièces avec un détecteur, et s'il "voit" du mouvement il y a un petit témoin vert qui s'allume. Mais pour une pièce, ce témoin est toujours allumé, et par contre quand je consulte ses infos, il me dit etre en veille depuis plusieurs heures. Qu'est ce que ce cela veut dire ? Merci
Did Posté(e) le 21 mai 2019 Signaler Posté(e) le 21 mai 2019 Bonjour @Fur, Je pense que ça englobe les détecteurs de mouvement, les contacts de porte mais aussi les modules universels FGBS.
Fur Posté(e) le 22 mai 2019 Signaler Posté(e) le 22 mai 2019 a priori c'était plus un bug. Le cas ne se présente plus. Merci quand même ;-)
Fur Posté(e) le 13 juin 2019 Signaler Posté(e) le 13 juin 2019 Bonjour, Je reviens vers vous avec le bug de mon capteur. Assez régulièrement il "freeze" en mode ON. (Voir image jointe) En gros il est bloqué en mode Actif (oeil ouvert) mais avec un décompte de plusieurs heures Alors que dans les fait je n'arrete pas de bouger puis de m'arreter devant. Le device lui-même se comporte bien (l'oeil fait de la lumière quand je gigote devant), mais du coté du HCL rien ne change, ca reste comme sur la capture d'écran. Une idée ???
jojo Posté(e) le 19 juin 2019 Signaler Posté(e) le 19 juin 2019 J'observe également parfois un comportement similaire, si quelqu'un a une solution, je suis preneur
Fur Posté(e) le 19 juin 2019 Signaler Posté(e) le 19 juin 2019 Voici la réponse recu par le service Fibaro: Citation Hello Nicolas, My apologies for this inconvenience, In this case, please delete this sensor from your system, reset to default settings, include again and restore your app ‘token’, as in instruction below: Please reinstall all your mobile apps to refresh authorization token for them. Please follow below procedure: a) Delete app from your iPhone (with all files, configuration etc) b) Now go to web interface: - delete your mobile device, go to Configuration – Access Control – Mobile Device list and delete you mobile device from the list. - restart your gateway c) Install mobile app back and and configure it once more. d) Log into the system using this app J'avoue ne pas bien comprendre le lien entre la suppression du capteur du système pour le réinstaller, et leur histoire de token ou il faut désinstaller toutes les applications mobiles
Lazer Posté(e) le 19 juin 2019 Signaler Posté(e) le 19 juin 2019 C'est clairement une réponse générique du gars qui n'a rien compris, ou plutôt n'a rien cherché à comprendre. Pour moi ce problème est clair : problème de signal Z-Wave. J'ai typiquement eu ce problème avec différents capteurs (pas forcément des FGMS) qui étaient en limite de portée. Le premier changement d'état passe bien (la détection de mouvement), mais le second passe 1 fois sur 2 (la remise à 0 du mouvement). Bref, je préconise d'améliorer le maillage du réseau en ajoutant des modules relais (= sur secteur) dans les environs des capteurs qui posent soucis.
Fur Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 mmmh je n'avais pas pensé à la puissance du signal, car le système ne m'a jamais mentionné le capteur comme déconnecté. Mais en effet, ca me semble cohérent. Je vais essayé en installant un FGS212 à proximité.
Lazer Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 En fait la HC2 n'a aucun moyen de savoir si le capteur est dans la portée ou hors de portée.... car il s'agit d'un capteur sur pile, donc "endormi", c'est à dire qu'il n'écoute pas le réseau. La box ne peux pas le joindre à intervalle régulier (polling) pour interroger son état. Donc c'est bien le capteur qui envoie en statut en cas de changement d'état (mouvement début/fin), ou de température, luminosité, etc. Seulement si tu es en limite de portée, le capteur a des chances de ne pas pouvoir joindre la box, et les trames Z-Wave se perdent dans le réseau. Normalement le mécanisme de retour d'état est censé éviter ce genre de situation, car selon la norme il peut faire jusqu'à 15 tentatives d'émissions pour joindre sa cible. Cependant je soupçonne : - que certains modules, notamment ceux sur pile, limitent la ré-émission de trames pour économiser la batterie - envoie leurs trames avec une priorité faible, si bien qu'en cas de congestion du réseau à ce moment là, la trame se perd et n'arrive jamais à la cible (je sais que c'est le cas des rapports de puissance des Wall Plugs) - ne respectent pas parfaitement le protocole Z-Wave Je ne dispose pas des outils pour confirmer ou infirmer mes hypothèses....
Fur Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 Fort intéressant tout ca, merci bien. Cela dit, il y a quand meme le systeme de time out "signalé comme mort" qui indique si le device ne répond pas aux intervalles de réveils. Mais comme je le comprends, ici c'est plus des pertes du signal envoyé
Lazer Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 Tu devrais relire le petit topo que j'avais fait à ce sujet dans la section pour les nuls. Car là tu mélanges le polling et le réveil, qui sont 2 choses qui n'ont rien à voir, puisqu'ils concernent des devices différents (polling pour les devices sur secteur, réveil pour les devices sur batterie) La phrase "le device ne répond pas aux intervalles de réveils" n'a pas de sens, puisque par définition un device sur batterie (donc avec un intervalle de réveil), ne répondra jamais aux sollicitations de la box. En effet, le réveil se fait toujours à l'initiative du module sur batterie. Pour déterminer un module comme mort, la box procède comme suit : - module sur secteur : interrogation (pollling) régulière du module, paramétré dans les propriétés générales de la box (plus on a de modules, plus on élargi l’intervalle afin de ne pas saturer le réseau en "pings" inutiles), sous réserver que le polling n'est pas été désactivé dans les propriétés d'un module en particulier. Si le module ne répond pas suite à la tentative de polling, ou suite à la tentative d'envoi d'un ordre (on, off, dimmer, etc), alors la box le marque comme mort. - module sur batterie : comme dit, la box n'a aucun moyen de joindre le module, donc elle attend. Elle connait l'intervalle théorique de réveil du module, puisque qu'il est stocké dans ses propriétés (visible dans l'onglet adhoc) lorsque l'utilisateur l'a paramétré. Statistiquement, si le module n'a pas contacté la box depuis plus longtemps que l'intervalle de réveil, alors elle part du principe qu'il est théoriquement mort (plus de piles, etc...). C'est amusant pour un module tel que le Fibaro Button pour lequel on peut désactiver l'intervalle de réveil (pour préserver les piles, c'est d'ailleurs une très bonne idée). Dans ce cas le module ne passera jamais en noeud mort.
Fur Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 Je vais aller lire ca sans faute ;-) Mais il y a un truc que je ne suis pas du coup. Il me semble que pour les devices sur batterie, configurer "l'intervalle de réveil" ordonne au device lui-même de faire un ping vers le HC. Et si le HC ne le recois pas dans l'interval déterminé (et si "signalé comme mort" est flaggé ON) il l'affiche comme déconnecté. J'ai d'ailleurs eu le coup avec un capteur d'ouverture de porte qui est trop loin. En configurant comme cela, il me renseignait la perte de communication.
Lazer Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 il y a 12 minutes, Fur a dit : Il me semble que pour les devices sur batterie, configurer "l'intervalle de réveil" ordonne au device lui-même de faire un ping vers le HC. Et si le HC ne le recois pas dans l'interval déterminé (et si "signalé comme mort" est flaggé ON) il l'affiche comme déconnecté. Oui voilà, c'est cela même C'est ce que je disais juste au dessus, mais c'est peut être plus clair avec tes mots. Pour pinailler un peu, ce n'est pas un "ping", mais c'est un peu plus évolué. Lors du réveil, le module se signale au contrôleur Z-Wave en lui disant : "Hey toi, je suis réveillé, et je vais t'écouter pendant quelques secondes, juste au cas où tu aurais quelque chose d'intéressant à me dire, avant de me rendormir". C'est à ce moment là que la HC2 peut envoyer des nouveaux paramètres au module. C'est la raison pour laquelle, après avoir modifié les paramètres d'un module depuis la box, il faut aller réveiller le module. Le réveil est la seule façon de transmettre les nouveaux paramètres au module.
Fur Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 Okéééééé ca devient limpide ;-) Merci beaucoup. Et donc du coup pour en revenir à mon FGMS, la le problème si je comprends bien, c'est que parfois le signale qu'il envoit n'arrive pas à destination ? Mais alors comment se fait-il qu'il ne rate aucun contact de réveil avec le HC ?
Lazer Posté(e) le 20 juin 2019 Signaler Posté(e) le 20 juin 2019 Rien ne te dis que le contact de réveil se fasse réellement. Après je ne suis pas spécialiste du protocole, mais peut être que le réveil ré-envoie réellement les trames 15 fois jusqu'à ce que la communication passe, ce qui ne serait pas le cas pour la signalisation de fin de mouvement (voir mes 3 hypothèses données plus tôt)
Ghoosti Posté(e) le 4 septembre 2019 Signaler Posté(e) le 4 septembre 2019 Bonjour à tous, Je possède 5 FGMS MAIS en v3.2, est-il possible de les passer par une MAJ en v3.3 ? Merci pour votre retour
Nico Posté(e) le 5 septembre 2019 Signaler Posté(e) le 5 septembre 2019 Je viens de regarder, j'en ai pas mal en 2.8 Il ne m'a jamais proposé de mise à jour. Mais tu dois avoir une version Zwave+.
fabori Posté(e) le 21 décembre 2020 Signaler Posté(e) le 21 décembre 2020 Bonjour. Comment trouver physiquement un module d’après la configuration (détecteur de mouvement « oeil » Fibaro). j’ai dû le poser dans une boîte (dépose travaux) mais je ne sais pas où. Le système me signale que la batterie est bientôt déchargée... Y a-t-il un moyen de savoir vers quel autre module il est proche ? Merci par avance pour vos conseils.
Lazer Posté(e) le 21 décembre 2020 Signaler Posté(e) le 21 décembre 2020 Aucun moyen, c'est un module sur batterie, il est endormi, tu ne peux même pas le faire clignoter. Il va falloir chercher .... dans ta mémoire
Messages recommandés