Pourquoi ?
Toute façon mon pi de dev a cramé. Je regarde pour un nuc avec proxmox 
Mais plus de bugfix pendant qql jours, sorry
1 « J'aime »
C’est justement l’objectif des versions alpha etc d’essayer de prévoir les ennuis.
Php 7.4 est passé stable donc ça a du sense mais debian n’y est pas encore passé à ma connaissance hors c’est la distrib de référence pour jeedom donc il me semble qu’on a encore le temps
La debian 10.7 arrive en décembre … et elle embarquera probablement php 7.4
1 « J'aime »
Je compatis mois c’est tout mon serveur Proxmox qui est planté
Le disque principal c’est bloqué et je n’arrive plus a reinstallé proxmox sur l’autre disque les partition son bloqué
Bon courrage pour la suite
Hello,
En lisant le sujet Mes 5 grands conseils domotique (les erreurs à éviter) et la remarque de @kiboost que je partage à 200%, ça pourrait valoir le coup de se pencher sur ces 3 fonctions
- Au niveau du nommage, on doit pouvoir faire plus explicite =>
- Au niveau ergo, on pourrait faire plus homogène : d’un coté une popup basique (si tu as pas l’ID sous la main, tu es comme un con)
de l’autre un sélecteur plus user friendly
Donc pourquoi par faire un « wizard » ?
PS : je l’aime cette nouvelle liste indentée des objets !! 
1 « J'aime »
Oui j’y pensais justement. A voir en 4.2 …
Je ne comprend vraiment pas cette logique de tout complexifier en doublant tous les équipements 
Je suis de ton avis : à petite échelle et quand on débute, c’est (peut-être) valable… Ensuite c’est trop lourd !
Pour le wizard, la remarque de @Thibaut_T sur les blocs code est pas bête
Tu peu les trouver avec la recherche de la 4.1 je pense. Après parser des blocs code utilisateur c’est velu quand même … bloc code c’est déjà un user avancé il doit savoir ce qu’il a mis en place.
Les deux ne sont pas incompatibles : un remplace via regex #ID1# => #ID2# (en forçant que des chiffres) directement sur les expressions des scenarioExpression avec type code ça doit pas être loin de faire tous le boulot
Tu peux pas faire çà tu va remplacer d’autres trucs … faudrai parser des byId(xx) et encore si je fait byId($monId) c’est mort …
Salut,
J’ai fait le test récemment sur cette commande remplace et sauf si j’ai déliré ça m’a aussi changé le nom de la commande dans des bloc code avec cmd::byString
C’est pour ça que je partais pas sur la recherche du nom de la fonction… Il faut pas oublier qu’on connait le modif fixe au départ
Techniquement si tu as écrit #1234# dans ton code, n’importe ou, même en commentaire, le remplacer par #5678# ça passe (c’est plus ou moins ce qu’on ferait lors de l’edition du fichier manuelle avec chercher/remplacer)
un exemple de bloc code perso :
$skyEqRoot = '#[Maison][Sky Conditions]';
$jourfr = array('Dimanche','Lundi','Mardi','Mercredi','Jeudi','Vendredi','Samedi');
$Jour = $jourfr[date('w')].' '.date('d');
cmd::byString($skyEqRoot."[Jour]#")->event($Jour);
$SunEl = $_SunPos->elevation;
$SunAz = $_SunPos->azimuth;
cmd::byString($skyEqRoot."[Elevation]#")->event($SunEl);
cmd::byString($skyEqRoot."[Azimuth]#")->event($SunAz);
Tu fait comment là ?
çà marchera jamais dans tout les cas, donc le user ne sera jamais sur que çà a marché et devra quand même vérifier…
OK. Effectivement quand tu recomposes les noms c’est effectivement plus difficile à détecter
C’est ce que je dis, avec du code utilisateur ce ne sera jamais fiable. Donc autant laisser l’utilisateur le faire, car si çà update a certains endroit il va se dire c’est ok, et boum en fait non
1 « J'aime »
C’est pas faux !
Il est puni pour avoir écrit un truc pareil, bien fait ! 
A titre d’info, perso j’ai adopté le format suivant pour l’ensemble de mes scénarios (je n’utilise que des bloc code) :
/************************************************************************************************************************
Volets Jour_Nuit - 29
************************************************************************************************************************/
include_once getRootPath() . '/mg/mg.class.php'; mg::init();
/*********************************************************************************************************/
$InfLumExt = '#[Extérieur][Eclairages][Luminosité]#';
$InfLumInt = '#[Salon][Eclairages][Luminosité]#';
$infMvmtEtg = '#[Etage][Mouvements][NbMvmt]#';
$equipGeneralMaison = '#[Maison][Général]#';
$equipMvmtSalon = '#[Salon][Mouvements]#';
$EquipReveil = '#[Chambre][*Reveil chambre]#';
$equipMeteoFrance = '#[Extérieur][Températures]#';
// ******************************************** Suite du code du scénario ***********************************************
include_once getRootPath() . '/mg/VO_Volets_Jour_Nuit.php';
1 - La première ligne intègre une class perso de transposition/normalisation des appels ainsi que toutes les fonctions custom utiles
2 - Les lignes suivantes déclarent TOUT les équipements et commandes Jeedom (et profitent du coup du ‹ renommage › dynamique
3 - La dernière ligne appelle le script PHP (ou autre) qui est ainsi ‹ libéré › des contraintes de renommage
Hello
Désolé du HS. Dans ton exemple je vois :
Alors que moi je fait :
$cmdTemperature = cmd::byString('#[Net][Météo][Température]#');
$TempExt = $cmdTemperature->execCmd();
Quelle est la différence ?