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.
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…
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);
}
}
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);
}
}
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 :
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 :
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.
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
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 …
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 :
Ajout de fonctions concernant le nouveau plugin zwavejs (équivalentes à celles déjà existantes avec openzwave)
Changelog v0.995b :
Mise à jour de la librairie sc cmd en v0.995a :
Ajout de la fonction cmd-> getZwaveJsBatEquipements : Trouve les équipements Z-Wave (zwavejs) fonctionnant sur batterie.
Ajout de la fonction cmd-> checkLastZwaveJsMessage : Vérifie la dernière communication d’un équipement Z-Wave (zwavejs).
Ajout de la fonction cmd-> refreshZwaveJsValue : Force le rafraîchissement des valeurs d’une classe d’un équipement Z-Wave (zwavejs).
Ajout de la fonction cmd-> refreshZwaveJsValues : Force le rafraîchissement de toutes les valeurs d’un équipement Z-Wave (zwavejs).
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
Ce code envoi des sms (une seule fois par équipement même si on n’intervient pas pour régler le pb, grâce à une variable) et un email si un équipement ne communique plus sur le réseau depuis 24h.
Mise à jour de la librairie sc jpi en v0.9955 afin de supporter en natif les actions de JPI v0.99551.
Ma de la doc des fonctions auto générées afin de respecter l’ordre du menu actions de l’interface web de JPI, ainsi que les sous-menus (maintenant affichés dans la description). ex:
Petites corrections et optimisations
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
Bonjour @dJuL ,
C’est moi où depuis la dernière version du core jeedom, les logs ne s’affichent plus correctement ?
Je ne sais pas si c’est lié à Framework_SC on non :-/ ou s’il faut une màj de ce dernier
