Problème de temporisation d'entrée.

héhooo y a quelqu un?
100 sms c est 24 euros...ormis le fait fait que c est du vol au prix d un sms de nos jours, mais c est un autre sujet... c est réglé ce soucis j ai pas envie de passer pour un pigeon en recreditant pour me les faire croquer pour rien ? la j ai plus d alerte en attendant...

Il y en a marre que MyFox nous réponde "Vous êtes une minorité" à chaque bug ! Visiblement on est bien plus que ça, puisque tous les possesseurs de la solution Myfox ne sont pas inscrits ici.

Vous mélangez avec les messages au dessus qui datent de février et qui sont un autre bug qui a été corrigé depuis.

Effectivement, nous voyons que vous êtes plusieurs personnes touchées et nous travaillons activement sur le sujet (qui est donc un nouveau sujet, sur lequel je ne me suis pas encore exprimé).Il est possible que le service clients revienne vers chacun d'entre vous pour avancer sur les investigations.

Si vous voulez des infos, pas de pb !!

MyFOX a écrit:

Il y en a marre que MyFox nous réponde "Vous êtes une minorité" à chaque bug ! Visiblement on est bien plus que ça, puisque tous les possesseurs de la solution Myfox ne sont pas inscrits ici.

Vous mélangez avec les messages au dessus qui datent de février et qui sont un autre bug qui a été corrigé depuis.

Effectivement, nous voyons que vous êtes plusieurs personnes touchées et nous travaillons activement sur le sujet (qui est donc un nouveau sujet, sur lequel je ne me suis pas encore exprimé).Il est possible que le service clients revienne vers chacun d'entre vous pour avancer sur les investigations.

Non je ne mélange pas du tout je parlais de mon problème (entre autres) de déclenchement intempestif dont je suis selon myfox responsable. Un rapide tour sur le forum permet de constater d'après les nombreux messages récents que je ne suis pas aussi seul que myfox voudrait le faire croire.
Vous continuer à arroser de mépris vos clients (qui payent votre salaire je vous le rappelle) en affirmant que nous somme "plusieurs" ! Je vous invite à faire une règle de 3 en prenant en compte le nombre de personnes qui se sont plaintes ici, le nombre de vos clients, et le % de clients qui sont inscrits ici. Vous verrez que nous ne sommes pas "plusieurs" mais "nombreux".
Pour terminer, ce qui nous intéresse ce n'est pas de savoir si le problème est en cours de résolution, ça c'est la moindre des choses, mais plutôt si nos sms vont être recrédités, et quand.
Cordialement,

MyFOX a écrit:Il est possible que le service clients revienne vers chacun d'entre vous pour avancer sur les investigations.

Merci pour la réponse et si vous avez besoin d'informations complémentaires ou d'un beta testeur, n'hésitez pas

J'invite tous ceux ayant perdu des crédits à cause de ce bug à contacter le service clients à ce sujet. Celui-ci vous re-créditera ce qu'il manque.

MyFOX a écrit:J'invite tous ceux ayant perdu des crédits à cause de ce bug à contacter le service clients à ce sujet. Celui-ci vous re-créditera ce qu'il manque.

Ne vaut-il mieux pas attendre la résolution du problème ? D'autres crédits risquent d'être perdus entre temps...

Le bug des suites ininterrompues de SMS a été résolu.

c est quoi l adresse email svp ?

Merci pour votre retour, je suis également à votre disposition pour des tests

Depuis aujourd'hui je constate une amélioration, en effet la temporisation d'envoi des emails est prise en compte ce qui donne le temps de désactiver l'alarme via le clavier à badge.

Néanmoins cela ne résolu pas mon problème car j'ai un scénario qui s'active dès l'ouverture de la porte d'entrée (tag) et je pense qu'il serait bien d'ajouter un timer soit sur le scénario soit par équipement de sécurité. A moins que ceci soit déjà réalisable et que je ne l'aurai pas vu.

Quand pensez-vous ?

Vous pouvez décaler le lancement d'un scénario dans sa construction :

- dernière étape "Actions du scénario"
- dernier onglet "Déclenchement du scénario"
- deuxième case à cocher : "Différer l'exécution du scénario", puis sélection le nombre de secondes

Notez toutefois une chose : si vous avez un scénario qui se déclenche à l'ouverture et que vous désactivez l'alarme, le scénario se jouera dans tous les cas, qu'il y ait un délai ou non, que le système soit désactivé correctement ou non.

C'est quelque chose que nous allons modifier dans une future mise à jour : la bonne désactivation de l'alarme pourra annuler le scénario (comme elle annule aujourd'hui la sirène et l'envoi de l'alerte).

Merci de votre retour.

Oui j'avais bien identifié que l'on pouvait différer le scénario mais comme vous le dites cela n'empêche pas son exécution si désactivation de l'alarme par exemple.

J'attends donc une mise à jour futur pour que la désactivation de l'alarme annule le scénario.

Bonjour,
Peut on envisager une petite nuance sur ce sujet.
Il est proposé ici d'annuler un scénario sur désactivation de l'alarme. Pourquoi ne pas plutôt faire évoluer la notion d'intrusion.
Concrètement, aujourd'hui, le déclenchement sur détection d'intrusion se joue dés le premier mouvement d'un tag. Une exécution différée décalera le lancement du scénario quelque soit de tag stimulé. Il est donc proposé de pouvoir annuler ce déclenchement sur désactivation de l'alarme.
Résultat : que l'on ouvre la porte d'entrée ou la baie vitrée, on a un délais pour désactiver l'alarme. Hors, si je suis en alarme totale, je voudrais avoir un délais si j'entre par la porte d'entrée, mais je voudrais activer un scénario (fermeture des volets) dés le premier coup de pied de biche dans la baie vitrée. Pas trop d'intérêts de laisser l’intrus entrer et l'enfermer dans la maison:shock: 

Est il possible donc de considérer que le risque d'intrusion coïncide avec l'activation de la sirène (donc mouvement tag + délais pour la porte d'entrée, mouvement tag sans délais pour les autres)

Merci

Si j'ai bien compris votre demande, vous devriez pouvoir faire cela avec les scénarios. Exemple :

- scénario : sur événement
- détection d'un capteur mouvement/présence : TAG porte-fenêtre
- condition : si le niveau de sécurité courant est "Armement total"
- actions : automatismes, volet porte-fenêtre / fermer

Ca ne conviendrait pas ?

Bonjour,
Ça semble pouvoir faire l'affaire.
Mais, sauf erreur de ma part ...
On ne peut sélectionner qu'un seul capteur par scénario.
Il faut donc :
---- Un scénario par capteur, sauf pour la porte d'entrée, avec une exécution immédiate.
---- Un scénario pour le capteur de la porte d'entrée, avec une exécution différée, qui pourra être annulée si l'alarme est désactivée (après mise à jour)

Donc, pour 10 TAGs, ça fera 10 scénario.
Alors que si le scénario pouvait être lancé avec la mise en route de la sirène, on pourrait profiter des tempo des tags, ce qui ferait 1 scénario, quelque soit le nombre de détecteurs.

L'idée est donc "simplement" de pouvoir exécuter des scénario quand la sirène se déclenche.
Je me doute bien que c'est plus simple à dire qu'à faire, mais ça serait tellement pratique!  
Merci

Ok compris, je le note en suggestion.

En fait ça revient à dire que l'on ne veut pas que l'alerte d'intrusion soit considérée comme une intrusion par la centrale s'il y a une temporisation sur le détecteur et que la protection est désactivée avant la fin du délai imparti. Cela a déjà fait l'objet de multiples suggestions par exemple ICI (même si à mon avis la solution proposée dans l'illustration n'est pas la bonne solution : il ne faut pas d'un nouveau paramètre pour régler encore une autre temporisation spécifique pour les scénarios, mais une seule temporisation qui permet de ne pas considérer comme intrusion si la protection a été désarmée dans le délai imparti et donc ne pas envoyer d'alerte ni déclencher les scénarios).

Se baser sur le fait que la sirène sonne ou non est un mauvais calcul par exemple que se passe t il si l'on a les avertissements sonores activés ? Les scénarios vont-ils se déclencher lorsque j'arme/désarme mon alarme? non ce qu'il faut c'est définir la notion d'intrusion clairement (peut-être en ajoutant celle d'intrusion potentielle) et de clarifier le workflow d'évènements/réactions associés exemple:

Alx44 a écrit:En fait ça revient à dire que l'on ne veut pas que l'alerte d'intrusion soit considérée comme une intrusion par la centrale s'il y a une temporisation sur le détecteur et que la protection est désactivée avant la fin du délai imparti. Cela a déjà fait l'objet de multiples suggestions par exemple ICI (même si à mon avis la solution proposée dans l'illustration n'est pas la bonne solution : il ne faut pas d'un nouveau paramètre pour régler encore une autre temporisation spécifique pour les scénarios, mais une seule temporisation qui permet de ne pas considérer comme intrusion si la protection a été désarmée dans le délai imparti et donc ne pas envoyer d'alerte ni déclencher les scénarios).

Se baser sur le fait que la sirène sonne ou non est un mauvais calcul par exemple que se passe t il si l'on a les avertissements sonores activés ? Les scénarios vont-ils se déclencher lorsque j'arme/désarme mon alarme? non ce qu'il faut c'est définir la notion d'intrusion clairement (peut-être en ajoutant celle d'intrusion potentielle) et de clarifier le workflow d'évènements/réactions associés exemple:

Bonjour,
De mon point de vue, la définition d'une intrusion est d'avoir un intrus qui entre dans le domicile  
Et la définition d'un intrus est une personne non identifiée --> il faut donc avoir quelques secondes pour s'identifier avant de parler d'intrusion  

Le fonctionnement de la sirène est cohérent pour une alarme, puisqu'elle ne sonne qu'après avoir laissé le temps de s'identifier. Ce temps peut d'ailleurs être différents sur différents accès, chaque tag étant paramétrable : entrée principale, entrée secondaire avec des délais différents.
Je ne demande pas de nouveau paramètre, mais seulement que les scénario déclenchés sur intrusion se déclenchent réellement sur intrusion, avec un délais A pour s'identifier à une entrée, un délais B sur une autre entrée, aucun délais sur ce qui n'est pas qualifiable d'entrée!
Comme tu le dis, il ne faut pas se baser sur le fait que la sirène sonne, mais plutôt sur ce qui fait sonner la sirène, c'est à dire le couple détecteur/délais ! Les signaux d’avertissements ne sont pas des alertes, mais bien des avertissements, donc indépendants des scénario.
Je pense donc qu'il n'y a rien à ajouter sur l'interface, dés lors, effectivement, que la notion d'intrusion est définie.
Par contre, peut être ajouter la notion de détection sans intrusion, pour par exemple allumer une lampe à l'ouverture de la porte, donc sans intrusion, et, au bout du délais, faire hurler la sirène, fermer les volets (et éteindre la lampe   )

Ton schéma est vraiment bien, a un détail prés : ne pas jouer le scénario inverse lors de "l'annulation de l'intrusion". Parce que si le scénario en cas d'intrusion est de fermer tous les volets, alors qu'un volet sur 2 est déjà fermé : pas de problème. MAIS jouer le scénario inverse reviendrai à ouvrir ce qui était fermé, ce qui n'est pas forcément souhaité. Et oui, si on annule l'intrusion, c'est qu'on a été trop long, ou que le délais était trop court, donc tant pis, on ouvre ses volets à l'ancienne (ou presque)  

En fait le truc c'est que les capteurs n'ont pas d'intelligence, donc si tu ouvres ta porte pour passer ton badge sur le lecteur, lui il détecte une intrusion. Après c'est la centrale qui gère le fait que ce capteur est temporisé ou non. Partant de ce constant c'est pour cela que j'ai créé la notion d'intrusion potentielle qui est état de la centrale qui potentiellement va déboucher sur une véritable intrusion.

Le problème actuellement c'est que le cas de la sirène est géré un peu à part du workflow général (cela permet donc d'avoir le temps de s'identifier avant que l'alarme ne se déclenche). Mais comme c'est un cas un peu spécial le reste ne rentre pas dans le moule et du coup c'est compliqué.

Pas besoin d'ajouter la notion "détection sans intrusion" car tu peux déjà le faire avec les scénarios sur évènement, il te suffit de sélectionner le détecteur correspondant comme déclencheur.

Okay pour le scénario inverse c'est juste une idée que j'ai eue en réalisant le schéma, après ça pourrait toujours servir d'avoir l'option ;-)

Bonjour,

Je vais également y aller de mes petits schémas :

Actuellement :

En simplifiant, actuellement, le fonctionnement me semble être le suivant :
Si une intrusion est détectée par un capteur (TAG, DIR,..), ce dernier envoie l'info à la centrale.
- Si l’alarme est désarmée => rien ne se passe
- Si l'alarme est armée => les scenarii sur intrusion sont lancés + si le capteur en question n'est pas temporisé => les sirènes sont activées + les alertes sont envoyées
- Si l'alarme est armée => les scenarii sur intrusion sont lancés + si le capteur en question est temporisé => lancement de la temporisation
               - A la fin de la temporisation si l'alarme est désarmée => rien ne se passe
               - A la fin de la temporisation si l'alarme est toujours armée => les sirènes sont activées + les alertes sont envoyées

Dans le futur :

Toujours en simplifiant, le fonctionnement que je souhaite est le suivant :
Si une intrusion est détectée par un capteur (TAG, DIR,..), ce dernier envoie l'info à la centrale.
- Si l’alarme est désarmée => rien ne se passe
- Si l'alarme est armée et que le capteur en question n'est pas temporisé => les sirènes sont activées + les alertes sont envoyées + les scenarii sur intrusion sont lancés
- Si l'alarme est armée et que le capteur est temporisé => lancement de la temporisation
              - A la fin de la temporisation si l'alarme est désarmée => rien ne se passe
              - A la fin de la temporisation si l'alarme est toujours armée => les sirènes sont activées + les alertes sont envoyées + les scenarii sur intrusion sont lancés

Globalement, de mon point de vue, il faudrait juste placer l'exécution des scenarii sur intrusion après la fin de la temporisation (s'il y en a une) et non pas avant.
Ça reprend les propositions de cyberzeus et Alx44.
Et, effectivement, pourquoi pas rajouter la possibilité d'inclure des options comme celle proposée par Alx44 (le lancement des scenarii inverses une fois la centrale désarmée,...).

@Steph44

On est bien d'accord, c'est vrai que tes schémas sont plus "vendeurs" que les miens  

Bonjour,

En gros on est tous d'accord  

Il ne reste plus qu'à attendre la mise à jour.

À l'équipe MyFox, avez-vous pu avancer sur le sujet ?