Plugin Time Manager

Voici les informations sur mon nouveau plugin :

  • Nom et id : Time Manager (dkron), le nom est temporaire, je trouve rien de satisfaisant à 100%

  • Langages utilisés : php + dkron

  • Utilise-t-il un démon ? des dépendances particulières ? des crons ? Il utilise dkron

  • Possède-t-il un panel dédié ? Non

  • Payant || gratuit ? payant

Basiquement, le plugin permet de gérer un cron qui marche à la seconde. C’est dkron.
Alors, dans Jeedom ca donne un plugin qui propose 3 types d’équipements :

  • Actions déportées
  • Actions récurrentes
  • Actions planifiées

Pour les déportées, on définit un délai sur l’équipement, par exemple 1:30 pour 1mn30s. Chaque commande de l’équipement est mappé sur 1 ou plusieurs commnde et/ou 1 scénario. Chaque fois qu’on active la commande, elle activera 1mn30 plus tard ses commandes et scénario. Ca c’est fonctionnel en beta. C’est par exemple pour vos lumières sur détecteur de mouvement.

Pour les actions récurrentes, vous définissez la fréquence. Par exemple 30s. Et alors, toutes les 30s, il éxécutera toutes les actions de l’équipement. Un peu un mode scénario récurrent. Disponible ne beta.

Pour les actions planifiées, on choisit une commande info donnant un horaire (par exemple un lever du soleil), on peut y ajouter un décalage (en + ou -). Et alors, à l’heure résultante, il éxécutera toutes les actions de l’équipement. Scénario temporel mode simplifié. En cours d’implé.

A venir pour paufiner, une « condition » sur chaque commande qui devra être valide. Ca servira au conditionnel et par exemple à ne pas éteindre la lumière si un nouveau mouvement a été vu.

Besoin de quelques retours BT déjà. Que les dépendances s’installent bien, que les 2 premiers types fonctionnent.

Salut,
Je veux bien tester ton plugin, je vois une utilisation possible sur ma domotique justement sur mes lumières extérieures.
Je ne le trouve pas dans les bétas.
Comment l’installer?

Edit: Trouvé, il s’appelle Time Management sur le market pas Time Manager.

Oui je l’ai renommer du coup sur le market.
Le type planifié fonctionne aussi.

Me reste les conditions à mettre en place

Comment puis-je le tester?
Pour le nom, j’ai pensé à Timex, je ne crois pas que ce soit déposé vu que plusieurs marques l’utilisent (montres, agenda, …)

Bonjour,

J’ai les dépendances qui ne s’installent pas!
Jeedom 4.0.49 sur Synology avec Docker.

/var/www/html/plugins/dkron/core/class/../../resources/install_apt.sh: line 2: cd: /tmp/jeedom/dkron/dependance: No such file or directory
touch: missing file operand
Try 'touch --help' for more information.
Début de l'installation
/var/www/html/plugins/dkron/core/class/../../resources/install_apt.sh: line 6: ${2}: ambiguous redirect
/var/www/html/plugins/dkron/core/class/../../resources/install_apt.sh: line 24: syntax error: unexpected end of file

C’est bon, c’est passé…
J’ai testé « action retardée » et en log du Dkron_node j’ai eu ça:

time="2020-04-16T13:39:16Z" level=info msg="agent: Sending query" job_name=1413-1587044236 node=jeedom query="run:job"
time="2020-04-16T13:39:16Z" level=info msg="agent: Received event" event="query: run:job" node=jeedom
time="2020-04-16T13:39:16Z" level=info msg="agent: Starting job" job=1413-1587044236 node=jeedom
time="2020-04-16T13:39:17Z" level=error msg="grpc: Error calling gRPC method" error="rpc error: code = Unknown desc = not found" method=ExecutionDone node=jeedom server_addr="192.168.100.100:6868"
time="2020-04-16T13:39:17Z" level=error msg="grpc: Error calling gRPC method" error="rpc error: code = Unknown desc = not found" method=ExecutionDone node=jeedom server_addr="192.168.100.100:6868"
time="2020-04-16T13:39:17Z" level=error msg="agent: Error invoking job" error="rpc error: code = Unknown desc = not found" node=jeedom

Malgré les mots Error cela n’a pas empêché de fonctionner comme il faut.
Merci pour ce nouveau plugin qui va alléger mes scenérios.

@lunarok
2,3 trucs…
Dans la commande, le bouton rechercher scénario ne fonctionne pas.
Quand je créais un nouvel équipement j’ai ‹ 500 : Internal Server Error ›, il faut faire un refresh pour avoir le nouvel équipement.
Je n’ai pas réussi à faire fonctionner l’action récurrente, rien ne se passe.

[2020-04-16 16:35:34][DEBUG] : API Return
[2020-04-16 16:35:34][DEBUG] : Set delayed action http://192.168.11.360:1000/plugins/dkron/core/api/dkron.php?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&type=recurrent&id=135 with @every 00:01:00
[2020-04-16 16:35:34][DEBUG] : Body Array (     [name] => 135     [displayname] => Jeedom 135     [schedule] => @every 00:01:00     [disabled] =>      [retries] => 0     [concurrency] => allow     [executor] => http     [executor_config] => Array         (             [method] => GET             [url] => http://192.168.11.360:1000/plugins/dkron/core/api/dkron.php?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&type=recurrent&id=135             [timeout] => 10             [expectCode] => 200             [expectBody] => OK         )      [metadata] => Array         (             [plugin] => dkron             [type] => recurrent             [id] => 135         )  )
[2020-04-16 16:35:34][DEBUG] : API Return Job contains invalid value: can't parse job schedule: failed to parse duration @every 00:01:00: time: unknown unit : in duration 00:01:00.

Serait-il possible qu’une action sur la commande d’une « action retardée » relance le timer du début?

Normalement ca c’est bon

tiens effectivement je vais regarder pourquoi il dit ca

L’erreur 500 tu l’as eu sur quoi ?

Pour le type récurrent, il faut mettre 30s par exemple pas le format 00:00:00, je sais pas si je l’ai mis dans la doc…
Moi ca marche, action récurrente toutes les 30s

L’erreur 500 je ne l’ai plus avec la dernière MAJ.
Par contre toujours pareil avec le type récurrent.

[2020-04-16 20:54:05][DEBUG] : API Return
[2020-04-16 20:54:05][DEBUG] : Set delayed action http://192.168.100.360:1000/plugins/dkron/core/api/dkron.php?apikey=xxxxxxxxxxxxxxxxxxxxxx&type=recurrent&id=140 with @every 30
[2020-04-16 20:54:05][DEBUG] : Body Array (     [name] => 140     [displayname] => Jeedom 140     [schedule] => @every 30     [disabled] =>      [retries] => 0     [concurrency] => allow     [executor] => http     [executor_config] => Array         (             [method] => GET             [url] => http://192.168.100.360:1000/plugins/dkron/core/api/dkron.php?apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxxx&type=recurrent&id=140             [timeout] => 10             [expectCode] => 200             [expectBody] => OK         )      [metadata] => Array         (             [plugin] => dkron             [type] => recurrent             [id] => 140         )  )
[2020-04-16 20:54:05][DEBUG] : API Return Job contains invalid value: can't parse job schedule: failed to parse duration @every 30: time: missing unit in duration 30.
time="2020-04-16T18:54:05Z" level=error msg="not found" node=jeedom

30s :slight_smile:
Je vais revoir l’affichage pour avoir des champs séparé heure minute et seconde, ça évitera des soucis de saisie

PS pour scénario oui je sais que ça passe pas. Ce point là, la possibilité d’une condition de validation et pouvoir saisir des options pour les commandes. Avec pourquoi pas le faire par commande + global sur l’équipement

:roll_eyes: Effectivement, cela fonctionne beaucoup mieux ! J’y avais pensé à mettre le ‹ s › mais pas pu essayer.

Je vais « verrouiller » un peu plus les champs de saisie temp. Ca m’évitera des galères en support aussi.
Voilà ce que ca donnera pour les actions décalées par exemple :

Ce n’est pas plus mal d’avoir fait comme ça, cela évite des erreurs et c 'est plus simple.
Par contre je n’ai pas pus faire fonctionner avec une condition ainsi que le mode cumul ! c’est normal?!

Là condition marche pas encore, j’ai juste ajouter le champ pour commencer les tests

Pour le mode cumul ou non, je vais renommer. Mais ca fait ca : case cochée, programmation multiples en parrallèles. Case non cochée : une seule programmation mise à jour par la réutilisation de la commande

Pour info :

Sur les actions retardées :
mode multiples lancement et simple sont ok. En mode simple, chaque activation remplace la précédente. Mode cumul, il rajoute à chaque activation le délai au futur déclencheur
Il est aussi possible d’utiliser une variable pour définir le décalage

Global :
les conditions fonctionnent, mais pas de modal helper pour le moment
condition et options disponibles aussi sur l’équipement en plus des commandes

Planifiées :
Possible de sélectionner des jours de semaines et/ou numéro de semaine
Possibilité de sélectionner une heure manuelle

Ma todo restante :
ajouter build condition

Voilà fini, j’ai mis le helper, donc là pour la V1 c’est pas mal, me reste les tests et retour

Bonjour,
Passage en stable ok !

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.