Bonjour,
ça doit être simple mais je ne sait pas comment faire.
J’ai crée un scenario qui , quand il y a une détection (par un détecteur de présence) a un endroit de mon jardin, ma caméra se déplace a une position voulu. mais j’aimerais qu’elle revienne a sa position initial si le détecteur ne détecte plus rien (mais qu’elle y reste si le détecteur continu a détecter).
Pouvez vous me dire coment faire.
Merci d’avance
Bonjour
Vous pourriez faire un scénario avec en declencheurs l’ensemble de vos capteurs de présence
Un bloc action avec remove inat (voir doc scénario la fonction A / Dans)
Puis faire autant de bloc SI que de capteur de mvt.
Avec comme test si : trigger(capteur 1)==1
Alors : cam en position 1 / sleep 2 / rec d’une video
Si : trigger(capteur 2)==1, etc…
Apres tout vos blocs Si mettre un bloc Dans
Dans : 2 minutes
Position cam = 0
(Si il y a une nouvelle detection, le scénario va se relancer. Effacer le bloc Dans (grave au remove inat du debut) et en refaire un, et ainsi de suite…)
PS : Commande pour une vidéo (en augmentant le délais, vous pouvez avoir une vidéo en "accéléré… le temps « réel » de la vidéo étant « NbSnap » x « delay »)
Merci pour votre réponse rapide.
Ce n’est pas exactement ce que je veut.
Le sleep que j’ai mis c’est pour eviter que la cam prenne des snaps pendant son déplacement et je n’ai qu’un declencheur .
en fait si le declencheur (mon detecteur de mouvement) detecte plusieur fois de suite un mouvement ( car le méchant voleur essaie d’ouvrir la porte) alors la camera reste la et prend des snaps , mais si il n’y a plus de mouvement alors la cam revient a sa position initial.
C’est ça mais…Si vous n’avez qu’un seul déclencheur alors, je comprends pas pourquoi mettre un SI ?
Le scénario démarre car le détecteur = 1 (déclencheur : Capteur == 1)
alors le SI détecteur = 1 est toujours vrai (puisque c’est le fait qu’il soit passé à 1 qui déclenche le scénario)
donc inutile !??
De plus si une personne reste à gigoter devant le capteur, il va rester à 1. le scénario ne va pas ce relancer !
Dans ce cas, avant le dans mettre une action
Wait : Capteur = 0 (temps max d’attente 600 secondes)
Vous avez encore raison, j’ai enlever le SI.
Par contre je ne suis pas convaincu par:
car si le méchant voleur tripote la serrure ( donc que les mains) le capteur risque de passer a 0 et la camera de partir.
Je préfére que la camera reste la pendant 2 ou 3 minutes et enregistre la video dans sa carte SD.
Le plus simple à mon sens
Scénario avec déclencheur == 1 → déplacement de la caméra (une seule ligne dans le scénario !)
Et dans la commande de ton déclencheur, une action sur valeur
Si valeur == 0 pendant plus de 10min alors redeplacementvde la caméra en position initiale
Norbert
Je proposai de mettre le « Wait » AVANT le « Dans » (pas a la place).
Le scenario va donc attendre que le capteur revienne a zero. PUIS lancer le « Dans ». Attendre 2 minutes. PUIS la camera repartira sur sa position (sauf si relance du scenario dans les 2 min).
Ça ajoute donc du temps, pas le contraire….
Apres, le mieux c’est de passer du temps à essayer….
Ne pas mettre le Wait : gigoter devant le capteurs 3 minutes.
Recommencer avec le wait.
Choisir.
(Et…… BIEN lire la doc scénario, car connaître par les outils disponibles donne beaucoup d’idées…. )
Bonne journée et bon tests !
Oui mais…
Sans le Si
Tout mettre sous le remov inat
Le time out a 600 sec (si la personne tripatouille longtemps, autant que la cam reste en place) si le capteur passe a 0 au bout de 30 secondes, il durera que 30 secondes…)
Bonjour Henri, Merci pour ce partage. Je cherche plus d’informations à ce sujet. Je vous suivrai pour mettre à jour les derniers messages.
Je tiens le bon bout , ça doit être mieux ainsi :
Il me semblait qu’il fallait éviter de mettre des " wait" trop long car ça prend de la ressource ou alors je confond avec pause ?
J’ai lut ça aussi mais…
Je suis pas certain que ça soit vrai !
- Une fois j’ai lancé une boucle qui lançait 100 instances avec un sleep de 1 heure chacune. J’ai vu aucun changement sur la courbe utilisation processeur, mémoire, etc.
On m’avait dit que cette démonstration ne prouvait rien. C’est un point de vu. - Je n’ai jamais eu la réponse a la question : que ce passe-t-il en « bas niveau » (les programmes qui gèrent le matériel). Un ami (qui travaille sur ces couches pour androïde (google)) m’a dit qu’il ne pouvait répondre pour Jeedom mais que de nos jours il serait étonné que les ressources soit en attente au niveau processeur -surtout avec un noyau linux-, mais plutôt mise de côté et rappeler à l’heure souhaité (un sleep de 2 secondes représentant déjà des milliers de temps processeur, un « attendre 2 secondes » devient « je reprend la tâche DANS 2 secondes »).
Bref, dans tout les cas, a mon niveau je m’ennuie pas avec ça. Les puristes diront que c’est pas une raison de coder avec les pieds. Là encore, je respecte leurs points de vue, mais c’est pas le miens. Surtout…. Quand peut-être que les mêmes déploieront des trésors d’ingéniosité pour optimiser 3 temps de calcul, vont en perdre 1000 par l’utilisation d’éléments graphiques qui ne servent à rien a part faire joli !
Bref, de bref, c’est comme beaucoup de chose dans la vie. En abuser n’est pas une bonne idée, se l’interdir un peu extrême….
Pour ton scénario. Une fois qu’il fonctionne bien.
- Tu pourrais le faire évoluer en intégrant une boucle qui fait que si le capteur continue de détecteur. Tu reçois une alerte toute les minutes, t’avertissant que la détection dure anormalement longtemps.
Je te laisse y réfléchir…. - Tu pourrais également prévoir un bouton virtuel « activer / désactiver la fonction detection porte ». Qui te permettra d’arrêter les alertes et la détection si tu le souhaites. (Perso j’ai deux « Vues » accessibles sur l’appli mobile qui rasssemble les infos / options de l’alarme pour intérieur / extérieur qui contiennent notamment un widget Marche/Arret pour chaque capteur)
Mais…. Pas de pression. Mon Jeedom a 4 ans, et…. il n’est pas fini !
Bonne journée !
Merci pour tes conseils.
Oui effectivement je peut faire evoluer mon scenario.
Les possibilités sont infinis, c’est pour ça que j’adore Jeedom.
Bon Dimanche.