Possibilité de "forcer" le choix d'un modèle

[jbromain]

Tcharp38: Pour mémo, le modele est choisi grace à la signature Zigbee de l'équipement. Sauf cas tordu il ne peut y avoir d'ambiguité. Ce sujet concerne donc

• l utilisation d'équipements inconnus pour les impatients et surtout connaisseurs
• le support d'un cas tordu ou l'equipement s'identifi avec la signature d'un autre

Hello,

Comme évoqué sur un autre ticket, je propose qu'on puisse choisir le modèle (JSON) à appliquer à un équipement, directement sur l'IHM. Afin d'éviter une mauvaise utilisation, je propose que cette possibilité soit ouverte uniquement:

• si l'équipement est actuellement non reconnu (modèle JSON par défaut)
• OU si on est en mode "Développeur"

Concrètement, un bouton "Choisir le modèle" sera ajouté à coté du modèle, sur la page de l'équipement. Ce bouton afficherait au préalable des explications sur la fonctionnalité, et permettrait ensuite de choisir le modèle dans la liste de tous les JSON d'Abeille.

Une fois le changement validé, cela déclencherait l'action "Mise à jour" (déjà existante) afin de configurer les commandes de l'équipement à partir du modèle choisi.

Je peux me charger de ce développement (si ok, assigne-moi sur cette issue).

J'ai commencé à regarder le code, et a priori ce sera essentiellement en JS + requête Ajax.

[tcharp38]

Je sens du boulot la derriere, en particulier beaucoup d effets de bord.

Je pose des mots en vrac principalement pour moi, pour m'aider à y voir + clair

• le processus d'identification est basé sur la signature Zigbee
• ce processus est fait à chaque annonce (device announce)
• le modele est cherché d'abord dans les modeles locaux (devices_local) puis les modeles officiels (devices)
• si le modele existe en local ou officiel mais qu'il est different de celui choisi que fait on ?
• d'ailleurs dans ce cas... comment eviter perte de temps au support ?
• non pour le mode dev.. je ne souhaite pas répandre cette utilisation
• cette requete doit permettre de répondre aussi au cas foireux ou la signature zigbee d'un device est pourrie. Heureusement tres tres rare. Dans ce cas device identifié avec mauvais modele.

Pas sur d'avoir fait le tour des pb engendrés mais a murir Tu peux toujours proposer des updates

[jbromain]

Hello,

Merci pour tes retours, ça m'inspire quelques commentaires pour poursuivre la réflexion.

le processus d'identification est basé sur la signature Zigbee

Oui, et ça doit rester comme ça pour le cas général; si un équipement est référencé dans Abeille (= il possède son propre json), alors il faut l'utiliser par défaut lors de son inclusion. Car ça signifie que ce modèle a été testé et validé.

ce processus est fait à chaque annonce (device announce)

Effectivement. C'est un point à avoir en tête. (Voir proposition ci-dessous)

comment eviter perte de temps au support ?

Pour moi cette fonctionnalité devrait justement réduire le besoin de support, à condition de la faire correctement bien entendu. En donnant de la souplesse, les utilisateurs avancés sont plus autonomes, et ça ne change rien pour les autres.

cette requete doit permettre de répondre aussi au cas foireux ou la signature zigbee d'un device est pourrie. Heureusement tres tres rare. Dans ce cas device identifié avec mauvais modele.

Je ne savais pas que ce cas arrivait, mais du coup oui, ce sera géré.

Proposition de fonctionnement

1. Si un équipement est inclus mais non connu d'Abeille (pas de json) (comme ça m'est arrivé il y a quelque jours avec la prise Ledvance).

L'interface affiche: "Votre équipement a bien été ajouté à votre réseau Zigbee, mais Abeille ne connait pas de modèle. Vous pouvez essayer de le configurer en choisissant manuellement un modèle dans la liste, ou utiliser l'Assistant de découverte afin que l'équipe Abeille puisse intégrer cet équipement au plugin."

2. Si un équipement est inclus et connu d'Abeille, on ajoute simplement un bouton "Choisir manuellement un autre modèle" à coté des bouton "Mise à jour"/"réinitialiser".

3. Dans les deux cas, si l'utilisateur choisit manuellement un modèle dans la liste, les actions suivantes sont effectuées:

• Changement du modèle dans la configuration de l'équipement
• Ajout d'une configuration "isModeleManuel: true" <== c'est la clé pour éviter les effets de bord
• Configuration de l'équipement avec le nouveau modèle (comme si on avait cliqué sur "Mise à jour")

4. Lorsqu'un équipement se réannonce:

Dans le code existant, on ajoute un contrôle: si l'équipement existe, et qu'il a la configuration "isModeleManuel: true", on n'essaye pas de le ré-identifier à partir de sa signature. On garde le modèle qui a été choisi; ça me parait indispensable, car les équipements se réannoncent à tout moment (par exemple après une coupure électrique).

5. Pour repasser en mode "automatique":

Si l'utilisateur a choisi manuellement un modèle, l'information est clairement affichée sur l'interface: "Vous avez choisi manuellement le modèle de cet équipement. Cliquez ici pour repasser en automatique."

Tu peux toujours proposer des updates

Tu connais le projet (nettement) mieux que moi, donc si tu n'es pas convaincu je ne vais pas me lancer dans le développement ;)

[tcharp38]

Ok dans un premier temps tu peux te focaliser sur l'interface pour ajouter la selection d'un autre modele existant. La problématique a une partie commune avec l'utilisation d'un modèle local vs officiel. Mais je veux faire qqch de simple qui ne demande pas de support. Donc je compte limiter les cas de figure.

Reste bien sur le master pour proposer une update et refais un pull juste avant pour etre sur que le merge se passe bien.

[jbromain]

J'attaque.

Comme je bosse sur desktop\php\Abeille-Eq-Advanced-Device.php, je peux en profiter pour faire un peu de ménage dedans ?

[tcharp38]

Tu peux. Je verrai bien à quoi tu fais allusion.

[tcharp38]

Salut @jbromain Je pousse pas mal d'updates en ce moment mais je ne suis pas allé jusqu'au bout du test de cette fonctionalité. N'hesite pas à repousser pour completer mais réaligne toi bien sur le master juste avant de pousser sinon c'est cuit.

[jbromain]

Hello,

Yes, je pars en vacances demain mais je regarde en rentrant (1er septembre). Je m'occuperai de mettre le dernier fichier aux normes de codage (code et commentaires en anglais) et modifier le nom de paramètre comme partout ailleurs.

Les autres fichiers, j'ai passé en revue tes modifs et tout me semble OK.

Pour tester, par contre, je ne sais pas trop comment je pourrai le faire tant que c'est pas poussé en bêta, à moins qu'il y ait une astuce ? (si possible pas trop risquée: je n'ai qu'une install de domotique pour l'instant, pas de plateforme de test; c'est un projet ;)).

[tcharp38]

Bonnes vacances Penses à te réaligner au retour avec les nouvelles mises à jour. A plus

[tcharp38]

Salut @jbromain Une fois que ton dernier push qui est dans la beta du jour est bien testé, je voudrais qu'on stoppe pour faire une stable. Donc on clot ce sujet et priorité a toute regression par rapport à la stable precedente. Merci

[tcharp38]

@jbromain @kaleofr Vous etes les 2 seuls interessés par cette fonctionalité. Je vous laisse tester la beta et me dire si vous voyez un quelconque pb.

Merci

[kaleofr]

A première vue c'est ok.

[tcharp38]

@jbromain @kaleofr Je ferme le sujet considérant que c'est assez propre mais à réouvrir au moindre souci.

[tcharp38]

@jbromain Je réouvre le sujet. Ca ne fonctionne pas pour moi et d'autres. "jeeDialog" n'existe pas encore dans la version officilelle du core donc on ne doit pas pousser ça.

Merci de revoir la copie et reutiliser bootbox en attendant.

[jbromain]

Hello, mince, je n'avais pas vu dans la doc que ce n'était pas une fonction stable. J'essaye de corriger ça très vite.

[tcharp38]

Bah je viens de le découvrir aussi en sugérant à un utilisateur de tester. Merci

[tcharp38]

Salut @jbromain Juste pour te mettre la pression :stuck_out_tongue_winking_eye: , je considère que cette correction est la derniere importante avant de transformer la beta en stable. J'ai mis en pause tous mes autres gros changements.

[tcharp38]

Nouvelle beta pour demain 231027-BETA-1 Merci @jbromain