sur mon NUC de test je ne vois pas une perte de performance par rapport à un scénario (mes quelques scénarios sont relativement simples). C’est sur que la machine est surdimensionnée pour de la domotique aussi. Donc point positif
bug de fonctionnement durant mes tests rapides . Call to a member function getHumanName() on boolean qui fait sortir l’application quand je sauvegarde mes déclencheurs. Je lance une trace (log)
interface. Les champs des noms des déclencheurs , des actions, … sont vraiment à reprendre pour les agrandir. Actuellement seuls 5 caractères sont visibles à un instant donné. Donc améliorations à apporter coté ergonomie.
Hum… ennuyeux ! Je viens d’essayer de reproduire mais pas encore réussi. Es-tu en Jeedom v3 ou v4 ?
Oui je veux bien les logs détaillés alors !
Cette fonction getHumanName() est globalement utilisée pour les logs… J’ai relu partout où je l’ai utilisée et je suis tombée sur rien d’évident…
Le soucis c’est que je voulais faire tenir tout sur une seule ligne, pour les déclencheurs et pour les actions (incluant les champs de message…). Alors forcement ça raccourci la place pour chaque champs !
Pour l’instant, j’ai pas tellement envie de refondre complètement les actions faites à travers les modes+scénarios, mais je vais faire l’exercice de remplacer mon trigger « retour à la maison » qui se base sur 2 scénarios un peu merdiques (pour éviter les répétitions dues aux déclenchements multiples et traiter la tempo)… Avec le confinement, c’est pas la meilleure période pour tester ça me semble le bon sujet pour comparer
EDIT :
J’ai commencé …
A priori il n’y a pas moyen de faire une comparaison avec autre chose qu’un numérique … Les modes par exemple c’est du texte… Evolution possible ?
Dans le cas de plusieurs déclencheurs, j’ai l’impression que chacun est indépendant. Personnellement j’aimerai bien un « ET » global …
Je viens de jeter un oeil au code, à priori c’est une des deux lignes ou tu as $sequencing->getHumanName() après avoir fait un $sequencing = sequencing::byId(... qui peut retourner un boolean si pas trouvé (j’ai pas vérifié en détails mais le cast dans le core utilise unserialize qui lui peut retouner un bool)
c’est préférable de tester que tu as bien reçu un objet après avoir fait le byId
Ah cool, je vais ajouter le test alors ! Merci pour le debug !
Toute évolution est possible ! Mais oui aujourd’hui c’est juste du numérique (ou booléen…)
En fait pour Mode ou autre de ce type je pensais plutot que ca serait mode qui appellerait la séquence, c’est pour ca que j’ai ajouté une commande de déclenchement par l’extérieur. Donc dans Mode tu fais l’appel de la séquence et non pas dans séquence tu « écoutes » Mode… Ça va comme ça aussi, non ?
Pour quoi d’autre il y aurait besoin de tester du texte ?
Oui c’est possible aussi, j’y avait pas vraiment pensé… Dans ce cas un choix au début de savoir si on prend « ET » ou « OU » pour tous ? Genre une case à cocher à côté de « Ajouter un déclencheur » ?
Si c’est un « ET », à chaque déclencheur
Ça y est j’ai mis le doigt sur la genèse du problème.
J’ai supprimé l’action pré-créée Déclencher depuis l’onglet Avancé-Commandes et c’est ça qui provoque le plantage au moment de la sauvegarde.
Finalité de ces deux commandes Action Déclencher et Arrêter dans cet onglet ?
Possible, je sais pas trop :
Pour l’instant j’utilise beaucoup Mode pour traiter toute une liste d’actions, un peu comme ce que je pourrais faire avec ton plugin … en testant l’état ppur traiter ou non les répétitions
Donc ça marcherai si je remplace le contenu de mode par des actions + éviter les répétitions dans ton plugin MAIS l’avantage du mode c’est aussi de savoir ce retour d’état + un chouette widget… ce que ton plugin ne fait pas (et c’est pas le but je pense).
Donc pour l’instant ça coince pour moi
En fait, tu es déjà presque dans ce cas puisque tu peux chainer 2 conditions via un ET/OU sur un même déclencheur.
En ne laissant qu’un seul test sur le déclencheur mais en ajoutant le ET/OU avec le déclencheur (optionel) de la ligne dessous, il n’y a plus de limitation. En contre partie, pour reproduire le fonctionnement actuel ça imposerai de faire 2 lignes avec le même déclencheur…
Ouh la non, surtout pas malheureux !! C’est maintenant que tu vas avoir des erreurs à chaque appel de ta page de configuration (Justement Call to a member function getHumanName() on boolean !!)
Ces commandes permettent d’appeler ou d’arrêter la séquence via l’extérieur du plugin, elles sont créées 1 fois lors de la création de ton équipement. D’ailleurs il faut absolument que j’interdise de les supprimer (ou que je mette en place un test d’existence avant de les utiliser… oui ca sera mieux !)
C’est bizarre que tu ais justement cette erreur quand ces commandes existent et pas d’erreur quand tu les as supprimées… C’est quoi ta version de jeedom et ton HW ?
Oui ok, normal alors ! J’avais cru comprendre l’inverse ! Donc non, il ne faut surtout pas les supprimer ! Mais je vais quand même ajouter un check comme dit par @mips pour la prochaine beta
Mode un chouette widget ?? Je dois pas l’utiliser comme il faut, chez moi j’ai que des pauvres boutons pour lancer un mode ou un autre, exactement comme pour mon plugin (avec 2 boutons « Déclencher » et « Arrêter »). Moi j’ai ça pour Mode :
Ok le mien fait par rêver non plus, mais c’est le même genre :
Et qu’est-ce que tu entends par « retour d’état » sur Mode ?
Je suis retourné voir la doc de Mode voir si je n’avais pas loupé des updates (je dois utiliser depuis 2016 ou qqch comme ça…), mais vu que la doc tiens sur 1 page non scrolable sans une copie d’écran, j’ai visiblement rien loupé
Pour lancer uniquement des actions immédiates, je pense pas que mon plugin soit une meilleur solution que Mode. L’intérêt principal du mien c’est l’enchaînement et de pouvoir couper le déroulé.
Oui mais justement ça fait redonder les commandes. Actuellement chaque ligne de capteur va créer une commande « info » avec 1 listener et chaque commande info est historisée, là ça va faire 2 historiques pour la même commande c’est vraiment pas beau…
Gérer un « ET »/« OU » entre chaque condition c’est un peu compliqué parce que ça impose de connaître l’ordre entre les capteurs pour gérer la priorité (x ET (y ou z)) pas pareil que (x ET y) OU z)…
Par contre demander 1 fois pour tous s’il faut gérer la liste en « ET » ou en « OU » ça c’est jouable !
Actuellement avec le « OU » j’évalue uniquement la condition du trigger qui nous a déclenché, si c’est un « ET », même pas besoin de savoir qui est le déclencheur on évalue tout pour tout le monde…
Ca irait comme ca ou ca sert à rien si c’est pas du cas par cas ?
Pour le widget du mode, il y a celui du core : Mode/state qui est pas mal…
ça ajoute les icones (avec ou sans couleur) et avec la durée de la commande. C’est pas la révolution par rapport au template de base, mais c’est quand même pas négligeable
Simplement ça :
Autrement dit, tu sais quelle séquence a été déroulée.
Ton plugin ajoute des fonctionnalités indéniables, sans pour autant en avoir un besoin systématique.
Dans mon usage => déclenchement immédiat et délai avec en plus un contrôle des répétitions.
C’est exactement ce que j’utilise dans mon trigger de « retour » : Détecter ta présence, lancer des actions immédiates (relancer le chauffage),attendre 2 minutes et te dire bonjour via GoogleHome.
C’est facile à faire globalement. Là ou c’est moins simple c’est d’éviter de répéter 2 fois le message et/ou de relancer 2 fois le chauffage parce que les déclencheurs ont un timing plus court que les 2 minutes de toute la séquence
Certes mais là encore impossible de gérer 3 états par exemple
Oui j’ai pas forcement en tête le fait de devoir gérer les combinaisons de ET/OU avec les priorités. Donc un ET/OU Globale ira très bien…
Plus compliqué, un mix des 2 … chaque ligne avec son opérateur sur 1 action + opérateurs entre actions . En les lisant séquentiellement, la pseudo priorité y est. ((Action1=1 OU =0) ET (Action2 =3 ET >1))… Maintenant est-ce utile ?..
Oui en effet, c’est joli ! Je connaissais pas, merci pour l’info !
Ah oui ok, il te dit où il est quand tu lui demandes.
Oui je pense que ca pourrait etre utile pour certains cas particuliers mais justement, peut-etre trop particuliers ! Pour les trucs à 3 états (2 états ca permet de faire des bornes, ca doit bien couvrir 90% des usages !) ou les conditions vraiment complexe autant passer par un scenario pour faire le calcul du déclenchement et qui appellera la séquence du plugin.
Yes, je pense aussi !
Donc petit recap pour la prochaine beta :
ajouter les tests d’existence des cmd avant de les appeler pour éviter l’erreur de @Yves19
@Mips, la bonne méthode c’est de lever une exception si après le byId j’ai pas reçu un object :
$sequencing = sequencing::byId($_options['eqLogic_id']);
if (!is_object($sequencing)) {
throw new Exception(__('EqLogic inconnu. Vérifiez l\'ID', __FILE__));
}
// ICI la suite de mon code
Ou de s’assurer que j’ai reçu un objet pour continuer (et sinon rien) ? :
$sequencing = sequencing::byId($_options['eqLogic_id']);
if (is_object($sequencing)) {
// ICI la suite de mon code
}
Ça dépend un peu du contexte, perso soit je lance une exception, généralement dans les config, pour remonter les erreurs à l’utilisateur ou alors un « return » silencieux (avec log) dans un traitement pour continuer sur la boucle suivante par exemple.
Mais donc ça dépend vraiment si continuer le process à du sens où pas là où t’en es dans ton code.
Je l’ai 4 fois dans le code, 2 fois dans des fonctions appellées par des cron et 2 fois dans des fonctions appellées par des triggers, donc jamais quand l’utilisateur est censé être devant son écran pour voir l’exception.
Donc j’ai pris le choix 2 avec une erreur « silencieuse » dans le log !
C’est quoi ta version de jeedom et ton HW ?
