Aller au contenu
Moicphil

Fibaro - Motion Sensor - Fgms-001

Recommended Posts

tu ne sais pas envoyer des commandes au FGMS.

De quelle alarme parles-tu Fibaro ou autre ?

 

Le mieux pour protéger sa maison est d'avoir une vrai alarme dédiée et reconnue comme telle par les assureurs.

Ensuite, ta domotique s'y connecte pour prendre des actions non-primordiales, en fonction de l'état reçu de la vrai alarme :

  • intrusion : allumer les lumière,s, démarrer l'enregistrement des caméras, envoyer des photos, ...
  • armement : éteindre les lumières, TV, sonos, démarrer simulateur de présence, ..
  • désarmement : informer si courrier dans la boite au lettres, ....

En fait toutes des choses que qi elle ne fonctionnent pas, ce n'est pas la mort.

 

Mais des détecteurs d'ouverture, si c'est sur pile, ce n'est pas fiable. S'ils sont sur secteur, il suffit de couper le courant pur qu'il n'y ait plus d'alarme. Alors qu'avec une vrai alarme, il y a des batteries de secours fiables, tu es informé en cas de coupure de courant, ...

Partager ce message


Lien à poster
Partager sur d’autres sites

donc FMGS c'est bien pour allumer les lumières du couloir (et encore j'ai des ratés)

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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à)

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ) 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Screenshot_20190521-111933.jpg

Partager ce message


Lien à poster
Partager sur d’autres sites

 Bonjour @Fur,

Je pense que ça englobe les détecteurs de mouvement, les contacts de porte mais aussi les modules universels FGBS.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

a priori c'était plus un bug. Le cas ne se présente plus.

 

Merci quand même ;-)

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ???

Screenshot_20190613-232202.jpg

Partager ce message


Lien à poster
Partager sur d’autres sites

J'observe également parfois un comportement similaire, si quelqu'un a une solution, je suis preneur 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites

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

Partager ce message


Lien à poster
Partager sur d’autres sites

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é 

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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.

image.png.7910af0812584e36a7c5886f959422bd.png

 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
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.

Partager ce message


Lien à poster
Partager sur d’autres sites

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 ?

Partager ce message


Lien à poster
Partager sur d’autres sites

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)

Partager ce message


Lien à poster
Partager sur d’autres sites

×