Correction d’un bug avec la fonction variable de Jeedom, un caractère était retiré de la valeur par défaut si la variable n’existe pas dans le moteur d’expression.
Compatible avec Jeedom v3.xx et Jeedom v4
Pour améliorer l’affichage des blocs codes et des logs :
PHP Warning: require_once(/var/www/html/sc/../../data/php/user.function.class.php): failed to open stream: No such file or directory in /var/www/html/sc/sc.class.php(2059) : eval()'d code on line 1
J’en profite pour te signaler deux erreurs récurrentes dans les logs
PHP Warning: Use of undefined constant rssi - assumed 'rssi' (this will throw an Error in a future version of PHP) in /var/www/html/sc/sc.class.php(2059) : eval()'d code on line 24
PHP Warning: Use of undefined constant uptime - assumed 'uptime' (this will throw an Error in a future version of PHP) in /var/www/html/sc/sc.class.php(2059) : eval()'d code on line 25
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.
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).
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
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…
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 ?