[Framework SC] les scenarios en php

Utilisation du core de Jeedom Scénarios
,
44

tuto2
tuto2945×602 32.7 KB

45

Ah oui c’est vrai que j’ai jamais utilisé les types génériques, car ils n’étaient parfois pas à jour ou non défini sur certains équipements… Mais je vais rajouter ça également, ça laissera le choix de la méthode.
J’ai fait une fonction pour retrouver n’importe quelle commande avec des filtres facultatifs : nom objet, type (action ou info) , sous-type (binaire, curseur…), et nom de commande.
Elle fonctionne pour toutes les commandes (virtuels et commandes ou le type générique n’est pas renseigné). L’avantage c’est qu’elle permet également de filtrer par objet / pièce et sous-type.
Je vais rajouter une autre fonction pour le faire par type générique ou voir si j’ajoute un paramètre supp à la fonction…

46

Ah oui voilà également un autre pb, si on a des lumières sur des modules relais ou prise par exemple, il faut avoir changé manuellement le type générique dans les commandes sinon on a pas le bon résultat…

Sinon c’est plutôt cmd::byGenericType('LIGHT_OFF') pour que ça fonctionne.

De toutes façons je vais également rajouter le filtrage par type générique, comme ça ça permettra de tout faire…

:wink:

47

Oui. J’ai repris le texte de l’interface web, je n’ai pas été voir le code des types génériques :wink:

48

Update du Framework SC v0.993b en ligne :slightly_smiling_face:

Changelog v0.993b :

Pour améliorer l’affichage des blocs codes et des logs :

Pour installer le Framework SC et/ou voir la doc c’est ICI

Note: le Framework SC est comme son nom l’indique un Framework. Outre le support de JPI, il permet d’améliorer le débug, d’harmoniser et de significativement simplifier la syntaxe des scénarios dans les blocs code. Biensûr qu’on peut tout faire à la mano sans l’utiliser, exactement comme on peut faire du javascript sans jQuery, Angular ou MooTools…

2 « J'aime »
49

Update du Framework SC v0.993c en ligne :slightly_smiling_face:

Changelog v0.993c :

Pour améliorer l’affichage des blocs codes et des logs :

https://community.jeedom.com/t/personnalisation-avancee-dark-sobre-light-jeedom-v4/10345/

Pour installer le Framework SC et/ou voir la doc c’est ICI

Exemple d’utilisation des 2 nouvelles fonctions :

//Charge la librairie cmd
$sc->load('cmd');
 
//Récupère les équipements actifs zwaves sur batterie
$eqLogics = $sc->cmd->getZwaveBatEquipements();
 
//Vérifie la dernière communication de chaque équipement :
foreach ($eqLogics as $eqLogic) {
  $eqLogicOk = $sc->cmd->checkLastZwaveMessage($eqLogic);
  if ($eqLogicOk) {
    //équipement OK, dernière com il y a moins de 8 heures
  }
  else {
    //équipement KO, dernière com il y a plus de 8 heures
    $message = "L'équipement" . $eqLogic . " ne répond plus depuis plus de 8 heures";
    //Envoie SMS ou mail...
  }
}

le log:
image

Note: le Framework SC est comme son nom l’indique un Framework. Outre le support de JPI, il permet d’améliorer le débug, d’harmoniser et de significativement simplifier la syntaxe des scénarios dans les blocs code. Biensûr qu’on peut tout faire à la mano sans l’utiliser, exactement comme on peut faire du javascript sans jQuery, Angular ou MooTools…

1 « J'aime »
50

Update du Framework SC v0.993d en ligne :slightly_smiling_face:

Changelog v0.993d :

  • Modification de la fonction sc->setCmd :
    - Ajout du support des commande action de sous-type select (liste)
    La valeur peut être le texte associé à la valeur ou bien directement la valeur elle même (non sensible à la casse).
    - Si l’action provoque une exception (ex: équipement désactivé) le scénario continue désormais son exécution.

  • Corrections typo

  • Petites corrections et optimisations

  • Compatible avec Jeedom v3.xx et Jeedom v4 / v4.1

Exemple avec cette commande liste :

image

$sc->setCmd('#[test][test][liste]#', 'nuit'); //OK => Nuit
$sc->setCmd('#[test][test][liste]#', 'night'); //OK => Nuit
$sc->setCmd('#[test][test][liste]#', 'toto'); //ERREUR -> Valeur introuvable

Pour améliorer l’affichage des blocs codes et des logs :

Pour installer le Framework SC et/ou voir la doc c’est ICI

1 « J'aime »
51

Update du Framework SC v0.993e en ligne :slightly_smiling_face:

Changelog v0.993e :

  • Ajout de la fonction sc->toId :
    Remplace tous les #tag# dans une chaine par l’id (#id#) des commandes et / ou des équipements.
    Inverse de la fonction toHuman(), cette fonction permet de convertir les noms ‹ humains › (#tag#) des commandes et des équipements vers les #id# correspondants.

  • Refonte du Framework et de toutes les librairies afin d’éviter certains problèmes lors des inclusions de fichiers php ou de class persos dans le bloc code et lorsqu’on mix ces fonctions persos et celles du framework.

  • Corrections typo

  • Petites corrections et optimisations

  • Compatible avec Jeedom v3.xx et Jeedom v4 / v4.1

Pour améliorer l’affichage des blocs codes et des logs :

Pour installer le Framework SC et/ou voir la doc c’est ICI

Sauf bug signalé ou fonction spécifique demandée, ou nouvelles version de JPI avec nouvelles actions, cela devrait être la dernière maj pour un petit moment…

1 « J'aime »
52

J’avais le fameux problème des timeout Jeedom non viables pour les modules zWave su batteries (Il faut absolument mettre à jour une commande) :

Après une semaine de test je suis satisfait de mon scénario de vérification des équipements Z-Wave sur batterie :

image
image852×580 38.6 KB

48 heures de timeout ça répond à tous les types de modules sur batteries que je possède (FLiRS qui envoient par défaut au minimum un message par 24h si rien d’autre à envoyer, ou classiques qui envoient par défaut un message toutes les 6h)

En cas de module défaillant, j’utilise une variable Jeedom pour ne pas être spammé de sms tous les jours à 14h si je suis par exemple en vacances (un seul SMS est envoyé).
Si le SMS est en erreur (au cas où), la variable n’est pas définie.
J’envoi également un email au cas où (tous les jours pour le coup tant que le module est dead car ça ne me gêne pas).
La variable Jeedom utilise l’id de l’équipement comme nom (ex: TIMEOUT_eqLogic128), et comme valeur la date à laquelle le premier défaut est constaté.
Elle est ensuite détruite si le module communique à nouveau.

Ps: J’utilise un bloc A dans un scénario qui se lance très tôt tout les matins et gère toutes les automatisation de la journée, en fonction des horaires de levée coucher de soleil notamment, mais un déclenchement journalier directement par Cron peut être suffisant.

Le code brut :

$TIMEOUT = 2880; //48 Heures

//JPI DEVICE FOR SMS/EMAIL
$JPI_GSM_DEVICE = 'http://192.168.100.7:8080';
$GSM_TO = '{MY_NUMBER}; {LEA_NUMBER}';
$EMAIL_TO = '{MY_EMAIL}';

$jpi = null;
$sc->load('cmd');
$message = "L'équipement %s n'a pas envoyé de message depuis au moins 48h (vérifier les piles) !";
$eqLogics = $sc->cmd->getZwaveBatEquipements();
foreach ($eqLogics as $eqLogic) {
  $varName = 'TIMEOUT_' . str_replace('#', '', $sc->toId($eqLogic, false));
  if (!$sc->cmd->checkLastZwaveMessage($eqLogic, $TIMEOUT)) { 	
    if (!$sc->getVar($varName)) {
      if (!$jpi) {
      	$jpi = $sc->load('jpi', $JPI_GSM_DEVICE);
      }
      $messageToSend = sprintf($message, $eqLogic);
      $result = $jpi->sendSms($GSM_TO, $messageToSend);
      if ($jpi->STATUS($result) == 1) {
        $sc->setVar($varName, Date('d/m/Y'), true);
      }  
      $sc->pause(3);
    }
    $jpi->sendMail($EMAIL_TO, 'Alerte Timeout - ' . $eqLogic, $messageToSend);
  }
  else {
    $sc->unsetVar($varName);
  }
}
53

Dans le même genre, as-tu quelque chose pour les autres devices sur piles (zigbee, Bluetooth)
Merci

54

Non désolé, n’ayant pas de module zigbee ni le plugin il m’est impossible de l’implémenter.
(La fonction checkLastZwaveMessage interroge le daemon Z-Wave pour vérifier le dernier message de l’équipement)

D’ailleurs je me rend compte qu’il y a une erreur dans le code que j’ai posté.
Rien de bien grave, mais si le sms a déjà été envoyé, et que le module est toujours ko, le mail provoquera une erreur les jours suivant car certaines variables ne sont pas instanciées.

Voici le code corrigé :

$TIMEOUT = 2880; //48 Heures

//JPI DEVICE FOR SMS/EMAIL
$JPI_GSM_DEVICE = 'http://192.168.100.7:8080';
$GSM_TO = '{MY_NUMBER}; {LEA_NUMBER}';
$EMAIL_TO = '{MY_EMAIL}';

$jpi = null;
$sc->load('cmd');
$message = "L'équipement %s n'a pas envoyé de message depuis au moins 48h (vérifier les piles) !";
$eqLogics = $sc->cmd->getZwaveBatEquipements();
foreach ($eqLogics as $eqLogic) {
  $varName = 'TIMEOUT_' . str_replace('#', '', $sc->toId($eqLogic, false));
  if (!$sc->cmd->checkLastZwaveMessage($eqLogic, $TIMEOUT)) { 	
    $messageToSend = sprintf($message, $eqLogic);
    if ($jpi === null) {
      $jpi = $sc->load('jpi', $JPI_GSM_DEVICE);
    }
    if (!$sc->getVar($varName)) {   
      $result = $jpi->sendSms($GSM_TO, $messageToSend);
      if ($jpi->STATUS($result) == 1) {
        $sc->setVar($varName, Date('d/m/Y'), true);
        $sc->pause(2);
      }  
    }
    $jpi->sendMail($EMAIL_TO, 'Alerte Timeout - ' . $eqLogic, $messageToSend);
  }
  else {
    $sc->unsetVar($varName);
  }
}
55

Update du Framework SC v0.993f en ligne :slightly_smiling_face:

Changelog v0.993f :

  • LIBRAIRIE cmd : Ajout de la fonction sc_cmd-> refreshZwaveValue : Permet de forcer le rafraîchissement d’une valeur d’un équipement Z-Wave :
    http://192.168.100.1/sc/doc/?class-sc_cmd#_refreshZwaveValue
    La classe, l’instance et l’index de la valeur à rafraichir se retrouve dans la liste des commandes de l’équipement :
    image
    Par défaut c’est la valeur du niveau de batterie qui est utilisée.

  • Mise à jour de la librairie sc jpi en v0.9938 afin de supporter en natif les actions de JPI v0.998.

  • Corrections typo

  • Petites corrections et optimisations

  • Compatible avec Jeedom v3.xx et Jeedom v4 / v4.1

Pour améliorer l’affichage des blocs codes et des logs :

Pour installer le Framework SC et/ou voir la doc c’est ICI

Exemple de l’utilisation de la nouvelle fonction sc_cmd-> refreshZwaveValue :

image

Code :

$TIMEOUT = 1500; //25 Heures

//JPI DEVICE FOR SMS/EMAIL
$JPI_GSM_DEVICE = 'http://192.168.100.7:8080';
$GSM_TO = '{MY_NUMBER}; {LEA_NUMBER}';
$EMAIL_TO = '{MY_EMAIL}';

$jpi = null;
$sc->load('cmd');
$message = "L'équipement %s n'a pas envoyé de message depuis au moins 24h (vérifier les piles) !";
$eqLogics = $sc->cmd->getZwaveBatEquipements();
foreach ($eqLogics as $eqLogic) {
  $varName = 'TIMEOUT_' . str_replace('#', '', $sc->toId($eqLogic, false));
  $sc->cmd->refreshZwaveValue($eqLogic);
  $sc->pause(3); //Pause le temps que la valeur se mette à jour (pour les modules FLiRS)
  if (!$sc->cmd->checkLastZwaveMessage($eqLogic, $TIMEOUT)) { 	
    $messageToSend = sprintf($message, $eqLogic);
    if ($jpi === null) {
      $jpi = $sc->load('jpi', $JPI_GSM_DEVICE);
    }
    if (!$sc->getVar($varName)) {   
      $result = $jpi->sendSms($GSM_TO, $messageToSend);
      if ($jpi->STATUS($result) == 1) {
        $sc->setVar($varName, Date('d/m/Y'), true);
      }  
    }
    $jpi->sendMail($EMAIL_TO, 'Alerte Timeout - ' . $eqLogic, $messageToSend);
  }
  else {
    $sc->unsetVar($varName);
  }
}

Ce scénario s’exécute une fois par jour à 14h00
Avec cette nouvelle fonction j’ai pu réduire le timeout de vérification à 24h avec une fiabilité de 100%.
En effet pour les modules classiques, le refresh est forcé une fois par jour (et effectué au prochain réveil automatique du module).
Pour les modules FLiRS le refresh est instantané, mais les 25h de timeout de la fonction checkLastZwaveMessage permettent tout de même de laisser une chance de raté au module jusqu’au lendemain.
Du coup la vérification du dernier message reçu du module devient 100% fiable quelque soit la techno du module, et en cas de batterie qui lâcherait sans avoir eu le temps d’envoyer son niveau faible, ou de module défaillant, là on est tranquille.

Cette nouvelle fonction sc_cmd-> refreshZwaveValue peut également servir à forcer le refresh d’un état de n’importe quel module Z-Wave. :wink:

56

Bonjour, nouveau ici, je commence à développer en PHP et avant d’installer le framework SC et comme je ne vois plus de message depuis mars 2021 je me demande si celui ci est toujours maintenu et compatible avec la version actuelle de Jeedom 4.2.21 ?
Merci
Cordialement

1 « J'aime »
57

Oui, pas de problème avec la 4.2.21.

58

Super et merci pour cette réponse ultra rapide. Le framework sera t’il maintenu à l’avenir ? J’espère que oui car de ce que j’ai vu ça semble etre une vraie perle mais évidemment ça crée une dépendance …

59

Pas d’info sur la maintenance de ce framework ? C’est important pour que je puisse prendre une décision …

60

Vu que je l’utilise en production, il est forcément maintenu sinon je n’aurais plus rien qui fonctionne chez moi…

4 « J'aime »
61

Merci, c’est juste bon de le savoir, il n’y avait plus de message sur ce forum depuis mars 2021, alors je m’interrogeais, me voilà donc rassuré.

1 « J'aime »
62

Update du Framework SC v0.995a en ligne :slightly_smiling_face:

Changelog v0.995a :

  • Ajout de la fonction sc-> event : Permet de pousser une valeur dans une commande de type info de maniere arbitraire.

  • Ajout de la fonction sc-> setColoredIcon : Active ou non la coloration des icônes de widgets en fonction de leur état.

  • Ajout de la fonction sc-> changeTheme : Permet de changer le thème Jeedom (sur tous les navigateurs actifs).

  • Mise à jour de la librairie sc jpi en v0.9952 afin de supporter en natif les actions de JPI v0.99525.

  • Refonte de la doc (et maj de son lien dans les logs) qui ne marchait plus en locale depuis certaines maj de la sécurité de Jeedom

  • Corrections typo

  • Petites corrections et optimisations

  • Compatible avec Jeedom v4.xx et Jeedom v3.xx (certaines fonctions récentes ne fonctionneront pas sous Jeedom v3)

Pour améliorer l’affichage des blocs codes et des logs :

Pour installer le Framework SC et/ou voir la doc c’est ICI

5 « J'aime »
63

Update du Framework SC v0.995b en ligne :slightly_smiling_face:

Changelog v0.995b :

  • Correction de la fonction sc-> persistLog : Le log n’était pas purgé après chaque appel, ce qui avait pour conséquences de réécrire tout le journal du scénario après chaque appel à la fonction.
    Ajout également d’un paramètre optionnel afin de ne pas écrire dans le journal lors de l’utilisation de cette fonction.

  • Mise à jour de la librairie sc jpi en v0.9952b :
    Ajout de la fonction jpi-> KEEP_ALIVE : Permet de maintenir indéfiniment une session « KeepAlive » avec JPI (Empêche JPI d’avoir des pertes de réseau)

  • Corrections typo

  • Compatible avec Jeedom v4.xx et Jeedom v3.xx (certaines fonctions récentes ne fonctionneront pas sous Jeedom v3)

Pour installer le Framework SC et/ou voir la doc c’est ICI

Pour utiliser la nouvelle fonction jpi-> KEEP_ALIVE, il faut utiliser un scénario dédié, qui tournera en tâche de fond indéfiniment.
Bloc code du scénario :

//Cette action s'utilise dans un scénario dédié
//(Ne surtout pas lancer ce scénario en mode synchrone !)
 
//Charge la librairie jpi
$jpi = $sc->load('jpi', 'http://192.168.0.10:8080');
 
//Démarre la session KeepAlive
$jpi->KEEP_ALIVE();
 
//Rien ne sera exécuté ici, l'action ne se terminant jamais…

Le journal du scénario est mis à jour pendant l’exécution du scénario :

image
image790×443 52.5 KB

On peut également voir la connexion dans le journal de sécurité de JPI :
image

Pour garder ce scénario actif en permanence, utiliser ces déclencheurs :

image

–
A savoir que cela ne prend quasi aucune ressource, ni côté Jeedom, ni côté JPI.

3 « J'aime »