J’ai installé mon Jeedom sur un RPi5 et donc RPiOS Debian 12.
Oui, je sais, Debian 12 n’est pas officiellement supporté mais ne sachant si c’est l’origine du problème, je pose la question tout de même.
(Jeedom dernière vertsion Stable 4.4.9)
J’ai crée un virtual action de type Liste (tout simple):
Comme j’aimerais que ce virtuel soit piloté par le plugin Jeemate, je tente de lui affecter un Type Générique et je me retrouve avec une liste qui ne comporte rien qui puisse ressembler a un Type Générique de type Mode (liste):
Et aucun autre type utilisable, tous « exotiques » …
Le type générique standard « Générique » n’est plus dispobible ???
Je ne sais plus par cœur mais ca ne me dit rien un type mode pour une list; t’es sur que ca existe?
Ca fait longtemps ça il me semble, en même temps ça sert à quoi un type générique « generic »? Les types génériques sont là pour décrire une commande: c’est un interrupteur, une prise etc
En fait, ce virtuel existait depuis longtemps dans ma configuration et je le pilotais depuis longtemps à partir de Jeemate.
Mais la j’ai migré vers Debian 12 et impossible de reparamétrer mes virtuels pour qu’ils refonctionnent avec Jeemate.
Oui, avant, il me semble que je n’avais aucun problème pour trouver un type générique pour une Liste.
Et je suis pratiquement certain qu’il existait un type générique … générique tout simplement pour les cas non identifiés.
C’est quand même de base de choisir un Mode dans une liste … Non ?
en effet certains types génériques sont non accessibles depuis que Jeedom a filtré la liste en fonction des types de commande. Et quand ils étaient déjà configurés sur des commandes, alors l’ancien type générique n’est plus visible en affichage sur la commande.
Par exemple,
pour un équipement type thermostat provenant d’un plugin qui utilise le type select pour gérer des modes, il n’est à présent plus possible de lui affecter le type thermostat_set_mode
Il faudrait ajuster les types génériques ici (par exemple pour le mode thermostat)
Idem probablement pour tout ce qui est alarme etc
Tout à fait d’accord, pour les types générique info et action, cependant c’est vrai que bcp l’utilise à tout va, et du coup c’est le meme souci pour generic_action qui n’accepte plus qu’un seul type de commande ‹ other ›
Je comprends l’ajout de ce filtre par contre il aurait fallu aussi ajuster la définition des types génériques, pour ne pas gêner l’existant, ce qui malheureusement fait perdre l’intérêt de ce filtre
Je manque de temps pour proposer un PR.
C’est possible de contourner en modifiant le fichier config, par exemple en ajoutant ‹ select › dans array, en faisant attention, par contre ce sera écrasé à la prochaine maj jeedom.
donc pas vraiment conseillé, mais ça peut dépanner vite fait…
Si on prend l’exemple que j’ai pointé plus haut, pour THERMOSTAT_SET_MODE
Tu peux te dépanner en remplacant
array('other')
par
array('other', 'select')
Et là tu auras de nouveau accès à ce type générique pour une commande mode de type select pour un thermostat. Et j’ai déjà croisé chez des utilisateurs des modes thermostat qui étaient gérés par slider. Donc il faudrait aussi ajouter slider pour des modes…
Même manip, pour GENERIC_ACTION du coup, dans le même fichier sur ton jeedom. Tu peux meme lui ajouter slider, message si besoin
array('other', 'select', 'slider', 'message')
A la prochaine maj, si cela n’a pas été corrigé dans le core, alors rebelote, tu ne l’auras plus dans la liste, et quand tu iras dans ta commande, generic type sera vide, mais c’est juste en affichage sur jeedom, car il sera tjs configuré dans la commande
Je reviens sur ce sujet pour solliciter si c’est possible la prise en compte par les dévs Core Jeedom du besoin exprimé.
J’avoue ne pas avoir très bien compris ces histoires de filtre en fonction des types de commande.
En tout cas, chez moi, je subis une regression ou alors je n’ai pas compris comment utiliser les nouvelles fonctions pour m’en sortir ?
Il me semble qu’utiliser une simple action Liste (‹ select ›) pour choisir un mode parmi N me semble le B.A.BA d’une action domotique ?
Et pouvoir la taguer avec un Type Générique Mode me semble être légitime également.
A part le ‹ Aucun › (qui ne répond pas au besoin évidement), quand je vois ce qui est proposé comme type possible (voir screenshot ci-dessus), j’hallucine un peu ?
Donc question à l’équipe Jeedom: est-ce possible de revoir la copie ?
Encore merci à @scalz pour ses propositions de solutions de contournement mais, pour moi, une modification qui est supprimée à chaque mise à jour du Core n’est pas vraiment une solution
Ah ! Merci pour l’info et l’évolution Jeemate correspondante.
J’espère un moyen pour moi de retrouver l’usage de Jeemate et mon pilotage Jeedom par téléphone.
Ceci étant, et pour les raisons exprimées ci-dessus, je maintiens que la gestion des génériques dans la version actuelle de Jeedom m’est incompréhensible !
Mais peut être que je suis un alien
peut etre que @Loic a un avis ?
(désolé de te ping mais je crois avoir vu que tu avais fait le commit).
A mon avis,
soit il faut retirer le filtre dans la dropdown selection de type gen
soit il faut retirer la propriété subtype dans la partie config, mais du coup ça revient au même.
Car les utilisateurs, et les plugins ont déjà leurs commandes configurées, et ce filtre est « bloquant » pour eux.
Comme j’ai expliqué, d’une part pour certains équipements ils ne peuvent plus sélectionner le type gen correct, sans devoir changer les subtypes sur leurs commandes.
D’autre part, quand le type gen était déjà config, alors il n’est plus affiché dans la config de la commande si le subtype de la commande n’est pas bon
De notre coté, sagitaz a déverrouillé ce filtre, directement dans la dropdown du plugin Jeemate, donc pour Jeemate ce n’est pas bloquant, mais Jeemate n’est pas le seul plugin à utiliser les types génériques et dans ce cas les utilisateurs passent par la dropdown Jeedom.
Bonjour
J’ai absolu Rien compris en gros vous voulez affecté des type générique à des commande qui n’ont pas un sous type qui correspond à ce type générique ?
en effet c’est le souci rencontré par les utilisateurs (dans la plupart des cas, ce ne sont pas les utilisateurs qui set le subtype sur les commandes, mais les devs de plugins), et donc avec ce filtre ils se retrouvent coincés pour par exemple mettre THERMOSTAT_MODE dans certains plugins etc, puisque que comme je disais certains plugins gèrent les modes en utilisant other, select ou meme slider.
Et le probleme n’est pas présent que pour thermostat.
Ce n’est pas une critique, mais ce filtre aurait du etre fait dès le début, facile à dire à présent, et les devs de plugins respecter les bons subtypes.
De mon point de vue, ce n’est pas aux génériques types d’être garants du bon subtype des commandes, ils sont surtout utiles pour définir la fonctionnalité de la commande, il aurait mieux fallu de vraies classes équipements, « abstraites » et typées, que les devs de plugins auraient été forcés de respecter/implémenter
Ok je vois mais retirer le filtre est pas une bonne idée ça a été une demande des utilisateurs qui permet de simplifier la configuration. Elle aurait dû être fait au début sûrement comme tout j’ai envie de dire.
Par contre on pourrait imaginer permet plusieurs sous type sur certain générique type ça oui. Je ferais une issue pour ça mais pour le moment comme dit sur un autre sujet il y a trop de pr en attente de validation j’attends que ça soit dépilé pour pouvoir me remettre au boulot.
du coup aux utilisateurs de faire attention en attendant. Si le champ type générique semble vide dans la configuration de votre commande, et que vous vous souvenez avoir config le type générique à l’époque, ne pas essayer d’en configurer un autre car vous écraserez l’ancien.
Et sinon, si vous etes bloqués pour config un type générique sur une commande qui n’aurait pas le bon subtype, alors il est possible de passer par le plugin JeeMate et vous aurez accès à tous les types en attendant.
Je comprends et j’aimerais pouvoir corriger plus vide. Mais la j’ai quasiment 20 pr en attente de validation côté jeedom les merge vont déjà être horrible je peux pas en empiler encore plus
Si vous vous comprenez, tant mieux. C’est un débat de spécialistes qui aboutira, j’en suis sûr, à quelque chose de bien
En tout cas, filtre ou pas filtre, de mon coté, je n’ai toujours pas compris pourquoi sur une commande basique de type liste, on me propose dans le dropdown par exemple « Enregistrement caméra ??? » et non pas le moindre choix qui ressemblerait à une liste (comme « Mode » par exemple).
Générique, comme son nom l’indique, le dropdown devrait au moins comporter un type basique correspondant au sous-type de la commande, enfin je pense …
Merci pour ces échanges, je pense que je peux cloturer le sujet maintenant en attendant la nouvelle version Jeemate.
Citation
En tout cas, filtre ou pas filtre, de mon coté, je n’ai toujours pas compris pourquoi sur une commande basique de type liste, on me propose dans le dropdown par exemple « Enregistrement caméra ??? » et non pas le moindre choix qui ressemblerait à une liste (comme « Mode » par exemple)
Je suppose que lorsque le filtre a été ajouté dans le core, les types génériques du core n’ont pas été correctement (ou pas du tout) vérifiés.
Ou alors lors de la vérification, qqun a pensé à tort, que dans jeedom, un mode doit toujours être de type « Défaut » (other), comme c’est géré par le plugin Mode.
Sauf qu’il n’y a pas que le plugin Mode qui gère des modes. Certains utilisent Liste (select), ou même encore Curseur (slider) pour gérer leurs modes…
Autre exemple, le type GENERIC_ACTION qui est aussi limité par le filtre à « Défaut » actuellement.
Du coup le filtre perd un peu de son intérêt si pour couvrir tous les cas, il faut débrider presque tous les subtypes sur un type générique ^^
Comme dit j’ai bien vu le soucis et des que jeedom aura traité le backlog de pr je me mettrais immédiatement au boulot pour corriger ce soucis le plus rapidement possible.
Je trouve ca un peu déplacé comme réflexion si on est si nul que ca n’hésites pas faire des PR pour améliorer le tout vu que tu sembles plus compétent que nous.
C’est quand meme fou de toujours nous critiquer comme ca on reste des humains derrière qui faisons beaucoup d’erreur (et au vu de vos messages plus que vous) mais on essaye de corriger je ne vois pas en quoi ce genre de phrase est utiles.
