bonsoir
j’ai besoin de votre avis sur mon scénario présence nut et wifi .
le problème est que mon nut a des petite perte de communication de quelque minutes donc j’ai fait ca
est ce que mon scénario et juste
bonsoir
j’ai besoin de votre avis sur mon scénario présence nut et wifi .
le problème est que mon nut a des petite perte de communication de quelque minutes donc j’ai fait ca
est ce que mon scénario et juste
Bonsoir,
Avant même de juger de l’efficacité de ton scénario, je vais me permettre des propositions d’optimisation de ta 1ère boucle. Même si en final tu ne les gardes pas, considères çà d’un point de vue pédagogique
.
Si je ne me trompe pas sur la signification de tes commandes, ton test ici n’est pas utile :
En effet : si #[MAISON][presence flo][etat]# est à 1, le ALORS ne se fait pas. S’il est à 0, le ALORS s’exécute et l’exécution de #[MAISON][presence flo][present]# fait que #[MAISON][presence flo][etat]# passe à 1.
En final, [etat] fini dans tous les cas à 1. Autant ne pas faire de test et remplacer le SI/ALORS par l’action #[MAISON][presence flo][present]#.
Idem avec le test de présence Wifi sur le téléphone de Flo.
Ainsi simplifier, on voit mieux le problème de ce SI/ALORS #[MAISON][nut flo][Present]# == 1.
Pour ma part, je me dis que si tu as la possibilité de vérifier la présence de Flo via nut OU via la présence de son téléphone sur le wifi, il faudrait que tu utilises ce teste pour ta boucle SI.
+1 avec SebT. Par ailleurs, quel déclencheur as-tu choisi pour ton scénario ?
Ton SINON, indépendament de la cohérence de l’ensemble, peut aussi être amélioré.
Tu rafraîchis le wifi du téléphone de Flo, mais ce n’est pas utile dans l’état car tu ne testes ensuite que la présence de son nut.
Tu as une boucle à 5 itérations, avec test de la présence du nut. Si à un moment donné, le nut devient présent, le scénario s’arrête alors (commande STOP), mais sans passer #[MAISON][presence flo][etat]# à 1.
Pour aller plus loin : comment souhaiterais-tu coordonner le nut et le wifi ? Cherches-tu à déclarer la présence de Flo que si l’un ET l’autre sont présents ? Mais, du coup, est-ce vraiment utile de tester 5 fois le nut s’il ne répond pas une première fois ?
Ce n’est pas une question piège. La réponse dépend de ton installation et de ce que tu souhaites faire, notamment parce le wifi du téléphone a plus de portée que le bluetooth du nut, et que par exemple tu ne veux peut-être pas que Jeedom considère Flo présent(e) si il/elle est dans le jardin à portée de Wifi mais pas à portée de bluetooth (présence dans la maison strictro-sensus).
Ton scénario déclenche sur quoi ?
la présence de mon nut
Il se trouve que je travaille aussi sur un scénario de présence.
Je n’ai pas encore de traceur, donc j’utilise pour l’instant le wifi de 2 téléphones. Séparément, ils ont des pertes de communication. Mais en les croisant, j’évite ces ratés, comme toi qui cherches justement à le faire en croisant le traceur nut et le wifi.
Par contre, j’ai pris l’affaire par un autre angle que le tien. Vois si ça peut te convenir…
Je déclenche sur chacun des wifis des 2 téléphones :
Le scénario (version allégée) est le suivant :
J’utilise le système ET/OU à plusieurs conditions dont parlait SebT.
En substituant ton nut à un de mes téléphones dans ce scénario, ça donnerait chez toi :
– Déclenchement du scénario si le nut change d’état ou si le wifi du téléphone change d’état.
– Flo absent(e) si le nut ET le wifi passent en absent.
– Flo présent(e) si le nut OU le wifi passe en présent.
Ainsi, si le nut perd la communication mais que le téléphone est toujours détecté via son wifi, Flo reste « Présent ». Et vice-versa.
En arrivant au domicile, Flo passe en « Présent » dès que l’un des deux est détecté. Pas nécessaire que ce soit les deux à la fois. Ce qui permet d’être plus réactif.
Ce scénario encaisse les pertes temporaires de communication des 2 éléments (mais pas si ça se produit au même moment !). Il encaisse aussi la panne d’énergie ou l’extinction de l’un des deux, ou l’oubli de l’un des deux loin du domicile. Bien sûr, dans ces cas-là, il ne repose que sur le nut ou le téléphone, et il est moins fiable.
Tu t’embete Pour rien, tu pouvais mettre directement dans la case valeur de ta commande virtuelle : commande 1 OU commande 2
Ca aurait fait exactement pareil que ce que fait ton scénario.
exemple:
et dans valeur j’ai:
#[Freebox][Réseau][Telephone laurent]# OU #[Jeedom][Mini bleu][Present]# OU #[Jeedom][Téléphone laurent][Statut]#
Effectivement, bien mieux et très synthétique
. À voir si ça convient à flowd38.
Pour moi, non. Mon scénario réel (la version non allégée !) prend en compte d’autres actions et tests, à commencer par un test sur ma Livebox qui plante et redémarre de temps en temps, provoquant l’absence simultanée pour Jeedom des 2 téléphones alors que le porteur des-dits téléphones n’est pas nécessairement absent…
Par ailleurs, je vais installer la possibilité de choisir « Automatique/Absence forcée/Présence forcée » pour le virtuel de présence. Je ne peux donc pas mettre le test directement dans la valeur. Je dois passer par mon scénario que je pourrais désactiver ou pas.
merci de vos conseils
je voudrais rajouter le géolocalisation avec application jeedom mobil .
je vais voir ce que je peu faire
C’est sur la liste aussi pour moi… mais en pause. Peut-être l’as-tu déjà lu ici ou là, mais l’appli mobile est en cours de réécriture. Et ce n’est pas un mal pour justement la géolocalisation qui pause des problèmes de remontée vers Jeedom. Il y a des témoignages de bon fonctionnement, mais il y en a aussi un paquet de mauvais.
Restent les alternatives à l’appli mobile de Jeedom, tels que l’utilisation de Geoloc iOS et iOS iCloud sur iOS, Tasker sur Android. Ça marche bien apparemment.
Bonjour,
J’ai suivi votre exemple et il marche très bien.
Cordialement,