Normal ton chemin n’est pas bon, il faut je pense utiliser :
require_once dirname(__FILE__) . '/../data/php/user.function.class.php';
Cela vient probablement de certains de tes blocs codes, difficile à répondre comme ça…
1 « J'aime »
Est-ce normal que dans les blocs code des scénarios :
dirname(__FILE__)=/var/www/html/sc
Cela ne peut-il pas être préjudiciable pour le core de Jeedom ?
Oui c’est parfaitement normal et il n’y a aucun risque pour le core de Jeedom : le seul code sous Jeedom s’exécutant dans ce contexte étant le code saisi dans le bloc code du scenario.
1 « J'aime »
Update du framework SC v0.992c en ligne 
Changelog v0.992c :
- Mise à jour de la librairie sc jpi en v0.9926 afin de supporter en natif les actions de JPI v0.9926.
- Compatible avec Jeedom v3.xx et Jeedom v4
Pour améliorer l’affichage des blocs codes et des logs :
Pour installer le framework SC c’est ICI
1 « J'aime »
Salut !
Je voulais savoir si il existait, soit dans SC soit de base dans Jeedom, la possibilité de récupérer toutes les commandes d’un type générique.
Je m’explique : J’aimerais faire des scénarios du type « éteindre toutes les lumières » ou « fermer tous les volets ». Et à part lister 1 à 1 toutes les commandes de chaque équipement dans un virtuel, ou rechercher toutes les commandes et les ajouter dans un scénario, je ne vois pas de moyen générique et facilement maintenable de faire ça.
Non ce n’est pas possible sans aller dans la bdd de jeedom pour lister les modules.
Mais c’est surtout qu’il n’y a pas de méthode générique simple applicable pour tout le monde.
Ex: tout ce qui est relais : cela peut être une lumière ou une commande de chauffage ou n’importe quoi d’autre…
Quand à la répartition (objet parent) des modules c’est pareil, certains peuvent la faire par type de module, d’autre par pièces…
Perso je maintien des tableaux à la main, une fois fais ce n’est pas très compliqué à maintenir (on n’ajoute pas 50 modules tout les jours).
Ex pour les lampes de mon rez-de-chaussée :
Update du framework SC v0.993 en ligne
Changelog v0.993 :
- Mise à jour de la librairie sc jpi en v0.993 afin de supporter en natif les actions de JPI v0.993.
- Le chargement de librairie ne fonctionnait pas dans un scénario lancé en mode synchrone au sein d’un autre scénario => corrigé
- La fonction du chargement de librairie retourne désormais la librairie et relance la fonction d’autostart (si définie et disponible) même si la librairie a déjà été chargée plus haut dans le code
- La fonction sc->pause retournait systématiquement une erreur dans le log à tord => corrigé
- La fonction sc->pause n’effectuait pas la bonne durée de pause avec une valeur (chiffre avec virgule) < 1 => corrigé
- La fonction sc->pause accepte désormais une valeur à virgule jusqu’à 10s (au delà la valeur est arrondie à l’entier le plus proche)
- La fonction sc->pause accepte désormais une valeur <= 0 (et dans ce cas ne fais rien)
- 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
2 « J'aime »
Punaise, plus de 2 ans que ce framework existe, et je ne le découvre que maintenant…
Merci à toi, je vais l’essayer de ce pas, et peut-etre virer le plugin JPI du coup… 
Bonjour,
Sans vouloir tout remettre en cause, et après avoir lu l’essentiel du sujet, je me demande toujours qu’elle est l’utilité réelle du framework SC, maintenant qu’en Jeedom V4 il existe de base le bloc code dans les scénarios ?
Merci d’avance pour vos réponses.
Il était déjà là en v3, voir v2 
Jamais essayé sinon, vois pas bien non plus.
Je n’ai connu que la V4. Pas de domotique avant ^^
Le framework SC s’utilise justement dans les blocs code !
Il sert à faire ses scénarios directement en code php afin d’éviter les trucs illisibles ou trop complexes à faire en mode block.
La syntaxe est ultra simple et uniforme et toutes les fonctions Jeedom sont supportées, et il n’est pas nécessaire de connaitre les classes Jeedom. Le debug est amélioré, et il y a une correction d’erreur sur chaque fonction et un log claire pour chaque fonction. Dans un gros scénario complexe il est du coup ultra simple de corriger les erreurs de fonctionnement ou même de syntaxe, surtout quand on doit faire une correction 6 mois plus tard (bien moins simple sans le framework voir même parfois impossible).
Une action = une ligne, le code est donc beaucoup plus court et plus lisible.
Il apporte aussi des fonctions via les bibliothèques intégrées (pilotage complet de JPI avec fonction ASK, fonction pour générer un lien de téléchargement valable x seconde, fonction pour trouver le nom d’une commande en fonction d’une valeur…, etc…)
Perso je fais tout mes scénarios avec depuis que j’utilise Jeedom et j’en suis très content (je fais donc tout en bloc code).
Après tout est très bien documenté avec des exemples (lien dans le 1er post)
Mais bon après chacun reste libre de l’utiliser ou non.
edit:
Voici l’exemple d’un log de scénario complexe (un des scénarios de mon alarme) qui gère des digicodes avec des options selon les personnes (caméras off ou non, blocage des tablettes, de la reco vocale…)
Je ne me verrai pas faire ça avec des blocks Jeedom, et certaines choses de toutes façons ne seraient pas possibles, et en bloc code sans le framework ce serait impossible à maintenir et à débuguer correctement tout les cas de figures (il y en a beaucoup selon les modes d’alarme et qui active/désactive l’alarme)
Bonjour @dJuL
en regardant ton exemple Exemple de vérification des lumières sur la doc, il ne serait pas possible de faire la même chose mais en prenant tous les équipements en sélectionnant une catégorie ?
ça évite de faire évoluer le code quand on ajoute une nouvelle lumière
Merci
//DEBUG OFF
//Variable du message
$message = '';
//Tableau des commandes info de l'état des interrupteurs à vérifier
$interrupteurs_etat = array(
'#[Salon][Lumière Plafond][Etat]#',
'#[Salon][Lumière Table][Etat]#',
'#[Chambre][Lumière][Etat]#',
'#[Salle de bain][Lumière][Etat]#',
'#[Couloir][Lumière][Etat]#'
);
//Contrôle de l'état des interrupteurs dans une boucle
for ($i = 0; $i < count($interrupteurs_etat); $i++) {
//Si interrupteur sur ON incrémentation du message
if ( $sc->getCond($interrupteurs_etat[$i] . ' == 1') ) {
//Récupération de l'equipement
$interrupteur = $sc->getEquipement($interrupteurs_etat[$i]);
//Incrémentation du message
$message .= 'La Lampe ' . $interrupteur . ' est allumée. ';
}
}
//Si une ou plusieurs lampe(s) est/sont allumée(s) envoie le sms
if ($message) {
$sc->setCmd('#[Media][FREE SMS][Mon Tel]#', $message);
}
Bonjour,
Je ne sais pas si ta demande est toujours d’actualité mais tu as la fonction :
cmd::byGenericType($_generic_type, $_eqLogic_id = null, $_one = false)
Bonjour @tomdom
Comment utilises tu cette fonction pour parcourir tous les generic ? J’ai essayé d"adapter le code de djul, mais mes connaissance sont limitées en PHP, j’ai cette erreur "Call to a member function ```
byGenericType
bien sur si c'est possible de le faire.
merci
//DEBUG OFF
//Variable du message
$message = ‹ ›;
//Tableau des commandes info de l’état des interrupteurs à vérifier
$array=array();
foreach(cmd::byGenericType($_generic_type, $_eqLogic_id = null, $_one = false) as $key =>$value
{
$array[$key] = $value ;
}
)
$interrupteurs_etat = array($key);
//$interrupteurs_etat = array(cmd::byGenericType($_generic_type, $_eqLogic_id = null, $_one = false));
//Contrôle de l’état des interrupteurs dans une boucle
for ($i = 0; $i < count($interrupteurs_etat); $i++) {
//Si interrupteur sur ON incrémentation du message
if ($interrupteurs_etat[$i] . ’ == 1’) {
//Récupération de l’equipement
$interrupteur = $sc->getEquipement($interrupteurs_etat[$i]);
//Incrémentation du message
$message .= 'La Lampe ’ . $interrupteur . ’ est allumée. ';
}
}
//Si une ou plusieurs lampe(s) est/sont allumée(s) envoie le sms
if ($message) {
$sc->setCmd(’#[Telephonie][Pushalarme][Tous les devices]#’, $message);
}
Salut !
J’avais presque oublié que j’avais posté ce message du coup j’avais laissé tomber.
Mais je vais essayer, car oui ça m’arrangerait pour rendre plus générique certains scénarios
Ok je vais voir pour rajouter ça dans la prochaine version
Super, merci
Je peux par exemple retourner un tableau avec tout les tags d’équipements d’une catégorie sans les ‹ # ›. Afin d’ajouter juste la commande à la fin.
Mais attention car cela ne sera pas facilement exploitable pour tout les équipement.
Par exemple il y a des modules doubles avec 2 commandes On 1 et On 2 à la place de juste On.
Ou Etat 1 et Etat 2 à la place de Etat…
Et je ne parle même pas si on a renommé des commandes…
Voila pourquoi il n’y a pas je pense de solutions universelles pour retrouver tout les équipements d’une catégorie et les traiter facilement ensuite.
Pour palier à ce problème, peut être que la meilleurs solutions serait une fonction qui renvoient directement toutes les commandes d’un certain type, d’un équipement d’une certaine catégorie, et dont le nom de la commande commence par « »
Bonjour,
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 ?