Je ne comprends pas trop tes remarques. Si une personne veut éteindre toutes ses lumières, elle appelle la commande cmd::byGenericType('Lumière Bouton Off') et elle récupère toutes les actions Off pour ses lumières ou il y a quelque chose qui m’échappe ?
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…
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…
LIBRAIRIE cmd: Ajout de la fonction sc_cmd->getCmds : Permet de trouver des commandes à l’aide de différents filtres optionnels (Nom objet, Catégorie, Nom équipement, Type, Sous-type, Nom commande, Type générique) : http://rulistaff.free.fr/sc/doc/?class-sc_cmd#_getCmds
Corrections typo et exemples
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
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…
LIBRAIRIE cmd: Ajout de la fonction sc_cmd->checkLastZwaveMessage : Permet de vérifier la dernière communication (dernier message reçu) d’un équipement Z-Wave en fonction d’un timeout spécifié : http://192.168.100.1/sc/doc/?class-sc_cmd#_checkLastZwaveMessage
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 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:
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…
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 …