Pour information j’ai basculé la version TESTEUR sur la version en cours 2024.3
Vous devriez voir mise à jour sur HACS, sinon forcer dans l’actualisation menu
Bonjour
J’associe des volets roulant somfy rts mais problème suite a une erreur de manipulation deux volets se sont associe ensemble sur la même commande
Jai donc via les outils de développement rubrique service tente d’envoyer la commande de dissociation mais aucune réaction du volet a chaque commande pourtant je l’exécute bien avec le même device adresse que le deuxième volet
Que puis je faire merci
Ps depuis que je suis passe sur cette version je ne peut plus supprimer aucune entité liées au plugin en bas de chaque fenêtre le bouton « supprimer » est grise et ne fonctionne plus est ce normal y a t’il un autre moyen de supprimer les mauvaise création
Bonjour,
J’essaie de comprendre ce qui est disponible comme plugin HA RFPlayer et j’avoue que c’est un peu difficile à suivre.
Je suppose que la version d’origine vient d’ici gce-electronics/HA_RFPlayer
Ensuite il y a quelques fork
Et surtout un gros refacto du code d’origine du coté de Doubledom45
Le problème c’est qu’il y a 4 repo dont un fork et un archivé.
Ensuite un autre qui s’appelle doubledom45/TEST-RFPLAYER et qui s’annonce comme la nouvelle version mais avec un nom de test ca n’est pas très engageant. Et doubledom45/HA-2024.3-RFPLAYER donc un nom qui correspond à quelque chose de plus stable mais dont le message dit que ca n’est que pour les tests.
De mon coté j’ai fait une PR pour essayer de fixer ce qui ne marchait pas sur le repo d’origine avec la dernière version de HA. Mais en y réfléchissant je pense qu’il vaudrait mieux passer plus d’énergie sur le code de Doubledom45 qui me parait fonctionnellement plus abouti.
Si quelqu’un peut éclairer ma lanterne sur les différentes implémentations disponibles je suis intéressé.
Bonne journée
Prend la version test-refplayer
Est-ce qu’il y a une volonté de re intégrer cette nouvelle implementation dans le repo gce ?
Ou alors le code d’origine gce n’est plus vraiment maintenu ?
Et si test-rfplayer a vocation à être la nouvelle implementation de référence pourquoi l’appeler test-* ?
Salut,
A mon avis la situation est simple.
Si le repo s’appelle test, c’est sans doute parce que la partie validation/test/release reste à faire/finaliser (même si les retours semblent bons )
Donc logiquement, ça ne sert pour l’instant à rien de faire un PR dans le repo de gce
Quant à dire si le projet de CGE est encore actif, c’est de son coté qu’il faut poser la question, mais tu peux te faire ton idée
Ce qui est certain, c’est que le contributeur initial ne fait plus grand chose
Salut…
@Aohzan essai de continuer les tests, mais j’ai pas trop le temps de m’y remettre sur la version GCE.
Pour ma version restera en test tant que je n’ai pas assez de remontée d’info, aprés on essaira de faire un mix avec @Aohzan sur la version GCE
Salut …
Si tu veux discuter de ta modification, pas de problème , je ne suis pas trop disponible en ce moment, mais tu peux laisser ton idée !
De mon côté, c’est sur mon temps perso et j’utilise très peu mon rfplayer faute d’équipement notamment (j’ai seulement des prises et une télécommande), du coup c’est compliqué de tester et valider les demandes.
Ce qui est sûr c’est qu’il ne faudrait qu’un repo pour avancer tous dans le même sens.
Soit on essaie de merger la bonne version de @Doubledom dans le repo GCE officiel en priorité si c’est celle ci la mieux, soit tu réouvres ta PR @racletteparty
Ma modification n’avait pas beaucoup plus d’ambition que faire marcher le plugin avec la dernière version de ha pour des sondes oregon.
J’avais vu passer d’autres repos. Mais le nom test m’avait pas donné envie de regarder plus loin.
Depuis j’ai fait un essaie de cette version test mais c’est beaucoup trop verbeux a mon gout. Énormément d’entités créées qui me sont d’aucune utilité. Et le automatic add est pourtant intéressant pour découvrir les device id surtout avec oregon qui renouvelle à chaque changement de pile.
Après pour le plugin, je pense qu’il vaut mieux un périmètre limité mais bien testé plutôt que d’essayer d’être extrêmement exhaustif sur des devices que personne ne peut tester.
Slt…
Sur la version de TEST, j’essaie de remonter le maximum d’information pour vérifier ce que je ne peux pas forcement Tester ! Mais on a toues les attrib !
Pas facile sur certain device de savoir ce que chacun veux ! il peut y avoir doublon ou superflu dans les [attrib] de ces devices en attendant …
Si on peut decouvrir les device id en debug et ensuite faire du declaratif en yaml dans la config pour sélectionner uniquement ce qu’on veut, ca peut le faire aussi.
Ce qui m’intéresse avec du declaratif c’est de mettre un entity id indépendant du device id pour pouvoir gérer la continuité d’historique apres remplacement de pile sur sensor oregon. Après il y a peut être une autre manière de faire que je connais pas.