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 ?
Simplement parce que je ne stocke en variable QUE l’adresse de l’équipement/commande, ce n’est qu’ensuite, dans le script PHP que j’exploite cette adresse. D’où la différence
Merci pour ton explication. Je viens de tester et c’est très clair.
Bonjour,
Je reviens au sujet… Tout d’abord, merci pour le taf sur la version 4. Je pense qu’il y a un vrai bon en terme d’expérience utilisateur. Je suis fan de la version synthèse par exemple. Pour moi (en tout ca mon besoin), je ne vois plus l’intérêt de passer par le mode design.
Pour moi, juste 2/3 trucs, surtout au niveau design :
-
Possibilité du cacher une partie du menu en fonction des utilisateurs connectés. Par ex analyse/ outils/ … Je trouve que ca prends de la place pour rien, et en mode tablette ce n’est pas utile
-
De la même façon, cacher a minima le bouton edit dans on n’est pas admin, voir cacher la barre de recherche car je ne l’utilise jamais (je me demande si des personnes l’utilise …). mais je veux garder le bouton de retour et de mini-menu que je trouve super pratique dans la vue synthèse.
-
Ensuite, comme sur d’autres solutions, la possibilité d’avoir une courbe de tendance sur une commande pour avoir par ex la temp sur 24H …
Hello
Un truc qui serait bien mais je ne sais pas si cela dépend du Core ou du plugin calendrier
Dans la partie Utilisé par, il serait bien de voir aussi les commandes qui sont utilisés dans le plugin calendrier
Je crois aussi qu’il faudra aussi faire la même chose pour les scénarios
Je ne sais pas si cela est faisable
Bonne soirée
Un petit sujet à creuser :
Mettre les fichiers de mise à jour dans le cache mémoire : à mon avis fausse bonne idée. ça n’apporte rien au niveau des perfs, ça bouffe sur la mémoire vive quand est limitée (resize du FS) et on a besoin des fichiers qu’une seule fois. Et ça cause des soucis de mise à jour.
Que ce soit un répertoire tmp, pourquoi pas mais autant prendre sur le FS directement pour ces fichiers
Là çà sort de mes compétences … 
Je pense que tu es tout à fait en mesure de modifier la ligne ajoutée pas jeedom dans le /etc/fstab …
de
tmpfs /tmp/jeedom tmpfs defaults,size=256M 0 0
en
tmpfs /tmp/jeedom/cache tmpfs defaults,size=128M 0 0
Et peut-être même que 128, c’est encore trop mon cache utilise 5Mo
Donc en dehors de tes compétences non, de tes attributions peut-être
EDIT : finalement j’ai mis 32 ici
Bonjour,
La v4 fut quasi-exclusivement esthétique, cela serait bien qu’une prochaine version se focaliser sur le fond.
Exemple, les génériques types pourraient être grandement améliorés. Les utilisateurs passe un temps fou à renseigner les types et cela ne se répercute pas systématiquement sur les plugins impliquant de nouveau à repasser par une configuration spécifique.
Il y a probablement le fait que tous les types ne sont pas disponibles, mais il doit y avoir d’autres raisons ou usages possibles. Si le corps permet plus de standardisation et d’automatisme de la configuration, cela apporterait un énorme gain d’ergonomie et de simplification à Jeedom.
L’association automatique d’un widget si l’utilisateur le souhaite et le définit, la configuration effective sur l’ensemble des plugins ( assistants vocaux, protocoles domotiques …).
Et il doit y avoir d’autres usages potentiels à condition que les types soient le plus exhaustif possible et revu pour être un point central de la configuration et plus uniquement une solution de contournement qui a été introduit pour les assistants vocaux par exemple et l’app Mobile.
Les designs 3D pourraient disparaitre.
Et il faudrait reprendre les points déjà remontés en aout dernier avec des propositions de revue du code pour en simplifier la maintenance et le développement tiers, car même Jeedom SAS et son principal (voir unique) contributeur ne maitrisent plus. Nous avons souvent le droit à je ne maitrise plus d’où cela vient, c’est trop compliqué … et c’est probablement normal avec l’accumulation de PR depuis des années.
Donc en gros une version 4.x ou 5 avec pour fond un grand nettoyage du code, revue des fonctions, standardisation (le sujet des simples et doubles quotes a déjà été évoqué, fonctions inutiles, nouvelles fonctions), serait un gain de stabilité, de facilité de développement de plugin en se basant sur ces standards, fonction, types … et probablement permettrait un usage facilité et moins fastidieux de la configuration pour les utilisateurs.
Le topic en question : https://community.jeedom.com/t/contributeurs-core/37365/10
Ce n’est pas la première vois que des bouteilles sont lancées à la mer.
Ayons un espoir que cette dernière soit récupérée et donne une visibilité sur le fond à moyen ou long terme. Nous aimons la solution, mais il est normal de s’inquiéter de tous ces points en regardant les autres solutions open source qui avancent à grands pas et qui font de plus en plus d’ombre sur Jeedom.
2 « J'aime »
Wow 
A te lire TES vérités sont universelles… Tu as l’air bien omniscient et ayant toutes les solutions à tous les problèmes mêmes ceux qui n’existent pas.
Mais à part ça tu proposes quelque chose de concret ? Tu fais des PR ? Tu debug des plugins ?
Parce que bon arriver en disant y’a rien qui va, tout est bon à jeter mais sans aucune proposition concrète en contrepartie pour ma part je trouve ça ridicule. Je ne vais pas perdre de temps à démonter tes élucubrations dont seul toi est convaincu (v4 fut quasi-exclusivement esthétique 
).
Pour le post relatifs aux contributeurs, rassures toi ce n’est pas passé inaperçu mais ça ne se fait pas en un claquement de doigt, l’équipe a des priorités et des délais à tenir aussi comme toute entreprise. A mon sens pour être contributeur, il faut être force de proposition et non dans le négativisme à tout bout de champ.
Voilà, je ne voulais pas répondre mais dur de laisser passer un tel message (encore)…
Hello,
Je trouve que tu es un peu extrême dans la réponse. Si effectivement la v4 ne contient pas que des évolutions esthétiques, il faut quand même avouer que c’est la partie la plus notable. Le passage de 4 à la 4.1 n’est pas aussi ‹ visuel › …
Quant à dire que @sbo considère que tout est à jeter… c’est une interprétation, au même titre que l’affirmation sur l’esthétisme.
Et puis, il cite quand même des éléments qui sont tout à fait véridiques : la trop forte complexité de certaines parties du code, le renoncement à la correction pour tout un tas de raisons (maitrise, temps, effet de bords)… Moi j’ajouterai qu’il y a plein de fonctions qui ne sont pas traités jusqu’au bout : Le design 3D est un exemple, GSH un autre. C’est certain, rien n’est simple et on ne peut demander à Loic de maitriser 100% du code sur 100% des technos mises en oeuvre.
Pour finir, il me semble avoir lu il y a pas si longtemps la volonté d’ouverture d’esprit du forum, de l’équipe jeedom etc… Alors sous prétexte de ne pas être dev, de pas proposer de PR, de pas faire de débug, on aurait pas droit d’exprimer son avis ?
Alors peut-être que tout n’est pas vrai, d’un coté comme de l’autre, mais si c’est pour se tirer dans les pattes, ça ira pas bien loin
2 « J'aime »
Sauf que son avis est toujours très négatif, avec beaucoup de contre vérité et manque de remise en question pour moi. Il assène sa vérité, j’assène la mienne y’en a pour tous les goûts comme ça.
Et la V4 n’a pas été que de l’esthétique mais énormément de simplification des fonctions justement entre autre.
Je n’ai pas prêté attention ni jugé ses connaissances ou son statut, les personnes qui veulent aider peuvent toutes le faire si elles le veulent peu importe leur niveau. D’ailleurs si j’avais fait attention à ça j’aurai souligné que l’équipe avait fait un appel aux beta testeurs il y a plusieurs mois concernant la refonte du plugin rfxcom qui est restée lettre morte elle aussi, ca marche dans les 2 sens on dirait.
Bref je ne voulais pas répondre et encore moins entrer dans une polémique.
C’est clair, c’est pas le but de polémiquer 
Si choses à corriger il faut le faire.
Maintenant ça reste mon ressenti sur l’instant.
Quant au beta test de rfxcom, ayant été un des contributeurs aux tests, on peut en parler en PM ou dans un sujet dédié si tu veux…
Bonsoir,
On parle de moi ou de Jeedom ? Faut-il toujours être mielleux pour apporter une critique ?
Ceux qui essayent, avec probablement plus de tact, de proposer se voient déboutés. Le sujet en question (et il y en eut d’autres), expose ceux qui soumettent des PR qui ne sont rarement ou jamais validés ou refusés. Ceux qui proposent de l’aide ou des évolutions n’ont jamais de réponse.
Je me doutais que mon post allait réveiller les défenseurs de la veuve et de l’orphelin.
Il est demandé dans ce post ce que nous aimerions voir dans Jeedom.
Et j’en fais des propositions, au contraire de ce que tu insinues, suite aux retours fréquents qui n’ont jamais de réponse. Si il faut être développeur pour cela, je vous prie de bien vouloir m’en excuser.
il faudrait lire attentivement la réponse qui te fait autant bondir, et te mettre en tête que c’est quelqu’un qui souhaite voir Jeedom perdurer et évoluer.
Mais les retours épidermiques à la critique ne rassurent pas.
Comme mes propos choquent, je m’abstiendrais de répondre à l’avenir.
PS : tu peux modérer mes réponses.
Cordialement,
1 « J'aime »
Hello,
Je vais pas partir dans un débat qui a tort ou raison entre salviaf et Sbo car je n’en connais qu’un des deux, ça serait partial et je me le prendrais dans les chicos 
!
Force est de reconnaître que quand je passe, je vois souvent des réponses de Loîc qui indique soit :
je vais partir
je sais pas ou c’est
je sais pas le corriger
En soit c’est pas grave si la main est passée à X ou Y personne(s).
Je maintiens mes 2 pauvres plugins perdus au milieu du reste, mais le peu de retour que je vois d’autres solutions qui quand l’utilisateur l’installe lui donne déjà pas mal de choses présentes dans sa maison sans rien faire, je trouve ça bien pour du non geek.
Je sais juste que le core manque de doc quand on n’est pas né avec PHP dans la tête et que le temps manque pour lire tout.
Ne rien commenter permet de se protéger et se rendre indispensable, sauf pour les bons qui vont s’en sortir, ou les moins bons qui ont du temps :).
On devait en tant que Dev avoir des mails de comm, soit ils sont automatiquement jetés à la poubelle par ma messagerie, soit ils ne sont pas envoyés du tout. Je ne sais pas, personnellement ce qui est fait sur la V4, ni si je dois me conformer sur un quelconque point.
Je sais ce que c’est que le travail en société, je vous rassure :), mais je déteste ne pas traiter un sujet jusqu’au bout, j’entends par la, avoir de la doc, des tutoriels, des procédures si besoin.
On ne peut pas tout mâcher, genre générer un scénario d’allumage des lumières de manières automatiques pour les gens, même la meilleur IA aura besoin d’input pour faire quelque chose de personnalisé à un moment, ou sinon laisser un apprentissage et donc avoir l’utilisateur qui est patient.
Exemple : allumage de la lumière sur mouvement à partir de 7h en automatique
Si l’utlisateur coupe tout le temps la lumière, l’IA peut rajouter 5 min par 5 min jusqu’à savoir que l’utilisateur n’appui plus. On n’a pas besoin de ce niveau de fonctionnalité à l’heure actuelle.
Pour la doc, je suis d’accord avec je ne sais plus qui, mais la traduction, j’ai arrêté, si Jeedom veut s’ouvrir au monde, c’est pourtant nécessaire d’être lisible en plusieurs langues. Même si c’est « mal » traduit, la trame sera compréhensible, on ne lâche pas quelqu’un devant un problème sans avoir ni tenant ni aboutissant, les gens savent qu’ils veulent domotiser leur habitat.
Bref, il y a eu du graphisme, et potentiellement d’autres choses. Est-ce qu’une vision plus core/code peut être lancée .
Le graphisme peut encore avancer, mais il y a déjà du gros de fait sur cette partie.
Et pour moi, le moteur de scénario de jeedom d’un point de vue création de scénario est sa plus grande force !
Ainsi que la souplesse disponible dans les scénarios/ fonctions que l’on peut stocker dans le fichier qui va bien pour s’en resservir n’importe ou dans les scénarios.
Le moteur de widget j’ai pas adhérer au nouveau, j’avais un gros widget en cours pour les ouvrants, je l’ai laissé tomber avec la V4…
Idem avec le widget hygrothermographe ajouté dans le core mais en enlevant une partie des fonctions qu’il avait. ça m’a découragé pour les widgets.
Idem, je ne cherche pas à partir ailleurs, mais on peut essayer d’avancer dans le bon sens pour simplifier deux trois choses.
TaG
2 « J'aime »
Avec le temps, la critique a été chassée et bannie de jeedom. Même lorsqu’elle est constructive.
Nextcloud est né du rejet de la critique, si les PR ou avis extérieurs étaient mieux considéré, peut être qu’il n’y aurait pas eu cet épisode tragique puisqu’au final ça a fait perdre des ressources a jeedom.
Pareil pour les power user ou les beta des premiers temps, vouloir améliorer jeedom (but de la critique) fini par clasher.
Les propositions si elles ne sont pas comprises sont hautainement écartées.
Et pourtant en même temps, la charge est de plus en plus lourde sue l’équipe officielle qui ne s’agrandit pas aussi vite que celle-ci s’accroit (et aussi que les contributions bénévoles s’étiolent)
Et on constate une dette technologique de plus en plus pesante et présente. Les smart ne sont pas passée en buster encore. Loïc admet de plus en plus ne pouvoir corriger des bugs ou ne vouloir toucher au core.
Pourtant c’est bien ce qu’il manquerait a jeedom une refonte et une vraie ‹ critique › de fond.
Entre la v1 et aujourd’hui il y a les assistants et on le voit un focus sur ce que jeedom appelle les types génériques. Peut être qu’il faut simplifier et orienter le fonctionnement autour d’instances de ces types, un équipement multiprise pourrait être par exemple 4 instances de prise avec la configuration du widget et visibilité centré sur cette instance et pas repartit sur 3 voir plus de commandes.
A une époque il n’y avait pas de type générique, même pas de logicalid, revenons a cette époque ou jeedom savait bondir en avant.
5 « J'aime »
Depuis le 24 novembre il est possible de passer la Smart en buster : [RTEX] Jeedom Smart Recovery mode - passage en Buster Jeedom V4
akenad
1 « J'aime »
@lunarok nextcloud ?!? je vois ce que tu voulais dire mais je crois que c’etait pas ca …
à te lires tu me viellis en 2015 jeedom était ce que tu décris toujours une pas en avant avec des betas tous les jours et des stables regulirement. etait ce bien?? ou etait ce destiné à des utilisateurs plus avancé ??
a l’époque on etait que quelques centaines de geeks et pas quelques miliers d’utilisateurs, cela rend la tache plus difficile pour Loic et la team.
cela dit je suis d’accord avec toi le rejet de la critique ne fait pas avancer le Schmilblick. mais la critique gratuite et le dénie ne servent à rien non plus (je ne parle pas de toi, les tiennes sont généralement constructive)
Jeedom reste une solution qui « déchire sa race » (© @lunarok) et merci encore à @Loic pour cela
Hello @kiboost
ça serait pas mal pour les utilisateurs d’avoir un listing des commandes envoyées à influx via
A moins que ça existe déjà ?