Je pensais au début que c’était lié à de mauvais coordonnées GPS pour la référence du soleil.
J’utilise le format 48.858917, 2.335222 et pas 48°51’32.1"N 2°20’06.8"E je ne sais pas si ca peut être une raison.
Même lorsque je définis une heure précise, l’heure prévisionnelle est fausse:
Est-ce que le développeur ou quelqu’un qui aurait des idées a lu ce message?
En l’état, ce plugin est juste impossible à utiliser pour moi.
J’ai vu qu’il était possible d’utiliser les tags #sunset# et #sunrise# pour le soleil.
Je suppose qu’il s’agit simplement de variables string dont la valeur est hhmm pour l’heure de coucher et lever du soleil.
Si je souhaite déclencher un scénario au levé ou coucher du soleil (pour remplacer simupre), je peux créer un virtuel qui vaut False si l’heure est inférieur à #sunrise# et supérieur à #sunset# et True sinon. Est-ce que ca ne risque pas d’être calculé souvent et consommer du CPU ?
Pour les heures planifiées, j’ai quand même l’impression qu’il faut planifier une heure maximum non ? Sinon le plugin n’a pas de fourchette haute et peut donc très bien faire sa planification bien après ton heure de début
Pas besoin de virtuel, la comparaison avec les tag #sunrise# et #sunset# peut se faire dans le scénario.
Le principe est d’exécuter ton scénario à 5h (disons avant le lever du soleil) puis de planifier les actions en fonction du lever du soleil ou du coucher du soleil.
C’est la base … ensuite il faut réfléchir et complexifier
Merci pour la réponse, mon objectif est d’arriver à déclencher quelque chose au lever du soleil.
Si je n’utilise pas de virtuel comme expliqué précédemment, et si je commence un scénario avant que le soleil ne se lève, je ne pense pas qu’une boucle qui attend que l’heure soit celle ou le soleil se lève est optimum en terme d’optimisation de CPU et ressource mémoire.
Je crains qu’une boucle « wait » ne se comporte comme la « pause », comme expliqué dans ce post.
Il faudrait dans ce cas utiliser la commande « A » pour programmer un cron, et mettre dans le champs de démarrage, un string calculé pour que ca corresponde au temps à attendre pour que le soleil se lève. Mais dans ce cas, il faut être sûr du format attendu. Je vois « Hmm » je suppose qu’on a droit à 3 caractères type string, donc à définir en fonction de #time# et #sunset#.
Je n’avais pas vu ta réponse, il faut mieux cliquer sur la flèche « Répondre » au niveau du post de la personne à qui tu réponds
En effet, il ne faut pas faire de wait mais utiliser un A pour programmer l’exécution à une heure précise
Si tu veux que ton évènement se déclenche exactement à l’heure du lever du soleil et bien un simple :
A #sunrise# Alors
#Lever_les_volets#
Si tu veux décaler un peu, utiliser time_op(), par exemple 5mn après le lever du soleil :
A time_op(#sunrise#,5) Alors
#Lever_les_volets#
Si tu veux ajouter une dose d’aléatoire dans l’affaire … alors on ajoute du rand() par exemple un décalage entre 1 et 15mn par rapport au lever du soleil :
A time_op(#sunrise#,rand(1,15)) Alors
#Lever_les_volets#
Etc …
Mais tu as essayé dans le plugin d’ajouter une heure pour mettre une borne haute au calcul du plugin ?
Merci pour la syntaxe de « A » je ne pensais pas que ça pourrait être si simple.
Sinon pour le plugin simupre, je viens de rajouter une limite dans le champ « Début max » mais le résultat m’a pas l’air cohérent entre les 2 exemples ci-dessous:
En effet, il est possible de mettre une durée max dans le champs « Début max », et pas seulement une heure max. Je voulais que mes volets se ferment entre le coucher du soleil + 15 mn et le coucher du soleil + 30 mn. Avec les valeurs ci-dessous, ca a l’air de fonctionner.
Dans la mesure où le format peut être différent (une durée en mn ou un heure hh:mm) il serait bien de prendre quelques exemples dans la doc pour qu’on puisse bien voir comment ca marche. Il serait bien aussi de mentionner dans la doc qu’il faut toujours renseigner la valeur max, sinon ca peut aller jusqu’à +24h (comme on voyait dans mes premiers écrans).
Enfin, dernier point pas 100% clair de mon coté, je comprends qu’on peut aussi agir sur une durée de la commande, mais concrètement, comment ca fonctionne ? Est-ce qu’après la durée, la commande inverse apparait pour éteindre une lampe par ex? Dans mon cas, c’est pour lancer un scénario, est-ce qu’il va le lancer plusieurs fois jusqu’à la fin de la durée ? Sinon, à quoi sert cette durée ? Pour la répétition, est-ce que ca va répéter toutes les minures jusqu’à la fin de la duréé/fin max ? Ce plugin a l’air vraiment bien, mais la doc me semble améliorable.
Ce plugin est puissant, mais le paramétrage n’est pas intuitif au premier abord, il faut jouer avec.
A chaque fois que l’on modifie un paramètre sur enregistrement les heures sont calculées, ce qui permet de vérifier si c’est bien ce que l’on veut.
Un exemple de simulation de présence sur absence le soir:
La simulation sera exécutée si mon téléphone est absent (moi)
Les actions du début de simulation sont allumage des lampes et envoi d’un mail
Les actions de la fin de simulation sont extinction des lampes et envoi d’un mail
Les conditions temporelles:
début de la simulation : heure du coucher de soleil <= heure aléatoire <= heure du coucher de soleil + 30 mn
cela lancer les actions d’entrées
fin de la simulation: 0h30 <= heure aléatoire <= 2h00
cela lancer les actions de sorties
J’ai demandé 2 répétitions:
Le plugin va répartir les 2 répétitions intelligemment entre l’heure du coucher de soleil et 2h00 du matin c’est ce que l’on voit sur le global.
Pour ton cas de gestion de volet:
Il faut une action d’entrée (scénario) pour fermer les volets
En option une action de sortie (scénario) pour ouvrir tes volets par exemple ou rien, en fonction de ce que tu veux.
Ce qui est troublant c’est que l’on peut mettre soit des durées ou des heures dans le paramétrage, le comportement sera différent.
Merci à echo et Bison pour ces précisions.
Voilà quelques jours que j’ai réactivé le plugin et qu’il fonctionne comme je le souhaitais.
Je clos le sujet.
