Déjà pour moi buster et raspi2 c’est a oublier
On est au raspi4 dc dire ok pour le 3 why not…
En gros a être trop gentil et ouvert a tant d os et de plate-forme on se bloque dans l’évolution positive.
Qd je vois mon infirmière et ces pommes eux se gênent pas pour dire cet ils s’arrête ici pour ce modèle qui a 3ans
+10000000 
Ben, tant mieux si on est tous d’accord 
après, ça n’empêche pas de maintenir la v3.x en terme de bug et faille de sécurité, s’il y en a encore, puisque c’est la version qui fonctionne sur les RPI2 sur Debian jessie etc… Mais, les nouvelles fonctionnalités - et aussi les nouveaux plugins certainement - ne seront plus compatibles v3.
D’ailleurs c’est dommage de ne pas avoir sur github des noms de branches fixe (v3 v4.0 v4.1 … ) Comme c’est souvent fait sur les projets open-source. Si je fais une PR sur le core, je dois le faire sur la branche alpha pour la v4.2 je suppose ?
Je pense qu’il serait bien aussi de commencer à se débarasser dans la documentation des opérateurs non-php qui peuvent poser problème dans de futur version.
Par exemple ici : https://doc.jeedom.com/fr_FR/core/4.0/scenario?theme=dark#Opérateurs%20de%20comparaison%20et%20liens%20entre%20les%20conditions avec les " && / ET / et / AND / and"
Surtout que en php && et and ne sont pas la même chose.
comme || et or ne sont pas pareil.
La précédence n’est pas la même !
Hello
Je vous lit depuis le debsans rien comprendre. 
Par contre, quel sont les opérateurs PHP sur ?
Si je comprends bien : && et ||
C’est bien ça ?
Il est clair que faut à un moment donné mettre une compatibilité version jeedom = version debian/PHP
C’est un tableau de quoi 4-5lignes et encore.
C’est comme ça pour tout. Les téléphones, les ordinateurs, etc.
Donc ça ne me choque pas.
L’idéal c’est un test avant update, c’est peut-être déjà le cas?
Et en gros un message qui dit non non non, pas de mise à jour, votre version Debian et ou PHP n’est pas à jour.
Effectivement corriger la doc serait une bonne chose, les nouveaux utilisateurs n’auront pas à repasser sur leur scénario.
Oui tu peux commencer a remplacer les ET par && et les OU par || dans tes scénarios et virtuels 
Voilà pas de bras pas de chocolat 
Voila. Je suis prêt.
Un autre expression qui marche pas :
hourDiff(str_replace(":","",substr(#[Bob][Réveil des Volets][Date de début]#,-5)),#[Maison][Heliotrope][Lever du Soleil]#)
#[Maison][Heliotrope][Lever du Soleil]# n’est pas valorisé avec sa valeur mais avec son ID #713#
Pour que ça fonctionne, il faut forcer l’évaluation
hourDiff(str_replace(":","",substr(#[Bob][Réveil des Volets][Date de début]#,-5)),intval(#[Maison][Heliotrope][Lever du Soleil]#))
hourDiff est une fonction custom, qui fait juste la différence en minutes entre 2 heures (H1M1 - H2M2)
Hello,
il y a une liste des fonctions custom à ajouter comme celle-ci ?
La fonction setTags, celle de remplacement des commandes objets …
Hello
Pas certain de comprendre la question…
Si l’idée c’est de faire le préchargement avant Symfony, alors les fonctions custom sont normalement /var/www/html/data/php/user.function.class.php
C’est la bonne interprétation ?
Ha non je voulais dire les fonctions du core jeedom alors 
HourDiff est une fonction du Core Jeedom ou bien une custom de ton cru ?
Hourdiff est une custom à moi. Le reste c’est du core. Ici c’est juste la complexité de la formule qui fait que le 2ème argument n’est pas traité automatiquement : Hourdiff ne reçoit pas 2 strings ou numériques contenant des heures, mais directement l’id comme deuxième argument, # inclus avant et après => #713#
Intval() force sans doute l’appel setTag()
Ok, la on atteind des sommets, on mixe les fonctions Core (pour la substitution des #tags# ) les fonctions pure php (replace et substr) et fonctions custum… Dans quel ordre sont évaluées toutes ces fonctions ? ça changera bien sur le résultat
Je suppose que la substitution des #tags# jeedom est faite en 1er pour que ça marche, ensuite l’évaluation des fonctions PHP, et en dernier l’évaluation des fonctions custom ?
( en passant, tu devrais p-e mettre les fonctions natives substr et replace dans ta fonction au lieu de laisser l’évaluation à jeedom…)
Les custom sont chargées par le core jeedom (include), donc là il n’y a pas de substition, l’évaluation au sens php connaît tout
Concernant substr etc à mettre dans ma fonction custom, puisqu’on a pas toujours la main sur le format des commandes info, ça m’obligerait à avoir une fonction par type de formats des paramètres… Avec en plus les combinaisons des 2 paramètres ? Techniquement c’est faisable mais c’est pas gérable
Je ne suis pas sur de comprendre ton exemple alors:
intval est une fonction native PHP et ne sait pas évaluer un nom de commande jeedom tel que #[maison][heliotrope][soleil]# cela est évalué par une fonction Core Jeedom.
Donc Jeedom doit faire ses substitutions de variables avant l’évaluation de l’expression par PHP ce qui parait logique.
D’après ce que tu dis donc, si tu ne met pas intval(), ta fonction custom reçoit le tag jeedom non transformé ? Et avec intval tu force jeedom à évaluer le tag pour avoir son ID ?
J’ai pas voulu dire que le intval évaluait l’id, mais que le fait de l’avoir dans l’expression rendait sa traduction (de l’id) par setTag possible
Tout à fait
Pour info la v4.1 sera limité à Buster. Donc php7.3
Du coup on peux updater Symfony !!