Bug dans la méthode d'envoie

[Doubledom45]

Il y a un bug dans la méthode d'envoie vers le Rfplayer self.send_raw_packet

Il faut envoyer l'ID avant le protocole

Voir Béta 16 [https://github.com/Doubledom45/HA_Rfplayer_Beta]

[Doubledom45]

Mais il y a un problème avec le JAMMING ! que ce soit en détection ou level ou simulate, au vue de sa configuration. Je vais faire faire une modification dans le protocole pour le JAMMING [avec tout les cas d'envoie]

Un truc du genre:

   def send_command(
        self,
        protocol: str,
        command: str,
        device_address: str = None,
        device_id: str = None,
    ) -> None:
        """Send device command to rfplayer gateway."""
        if device_id is not None:
# modif envoie cde Protocol ID si edisioframe ( commande enregistré dans ID)
            if protocol == "EDISIOFRAME" :
                self.send_raw_packet(f"ZIA++{protocol} {device_id}")
# modif envoie cde Protocol sans ID si jamming ( commande )
            elif protocol == "JAMMING" :
                if command == "ON" :
                    self.send_raw_packet(f"ZIA++{protocol} 5")
                elif command == "OFF" :
                    self.send_raw_packet(f"ZIA++{protocol} 0")
                elif device_id == "0" :
                    self.send_raw_packet(f"ZIA++{protocol} {command}")
                else:
                    self.send_raw_packet(f"ZIA++{protocol} {command}")
            else :
# modif d'ordre d'envoie
                self.send_raw_packet(f"ZIA++{command} ID {device_id} {protocol}")

        elif device_address is not None:
# modif d'ordre d'envoie
            self.send_raw_packet(f"ZIA++{command} {device_address} {protocol}")
# modif pour raw sur edisioframe dans command Edisioframe + hexa
        elif protocol == "EDISIOFRAME":
            self.send_raw_packet(f"ZIA++{command}")
#####
        else:
#bug jamming id=0
            if protocol == "JAMMING" :
                self.send_raw_packet(f"ZIA++{protocol} {command}")
# modif d'ordre d'envoie
            else :
                self.send_raw_packet(f"ZIA++{command} {protocol}")

@Aohzan @gce-electronics Je verrai pour modifier les commentaires :upside_down_face:, afin que tu puisses accepter un "Pull requests" sur la version GCE.

@+DoM(Ô¿Ô) :vulcan_salute:

[prahal]

@Doubledom45 from api doc v1.15 page 14 both: COMMAND PROTOCOL ID/ADDRESS COMMAND_PARAMETER and COMMAND ID/ADDRESS PROTOCOL COMMAND_PARAMETER are valid at least for:

ON
OFF
DIM
ASSOC
DISSOC
ASSOC_OFF
DISSOC_OFF
TOGGLE (edisio only)
Only X10 & CHACON:
ALL_ON
ALL_OFF

Why change the existing order?

Examples :
ON A3 RTS QUALIFIER 1
DIM ID 12 CHACON %40
ON KD101 ID 90500
ASSOC X2D868 F7

[Doubledom45]

Voir autre version en cours de test , bien plus élaborée, je suis en train de voir pour autorisé les ID < 256 en enregistrements ( en attendant que GCE autorise les vrais ID, bloqué par le Firmware [sauf Parrot et EDISIOFRAME...) Exemple pour DOMIA avec ID = D3 fait un switch.domia_d3 qui envoie la commande ON (ou OFF) DOMIA D3

[DarkosGahan]

Bonjour Doubledom,

Avant tout, un tout grand merci pour ton travail et tes efforts pour intégré le RFPLAYER dans HA

je suis en train de tester l'intégration que tu renseigne dans ce mail. J'ai des volets SOMFY RTS, lorsque j'utilise ma télécommande, le volet est bien détecté par ton intégration. lorsque j'ouvre ou ferme un volet je vois bien que ton intégration "voit" la commander passer.

MAIS :) l'entité créée automatiquement dans HA ne fonctionne pas. je vois bien qu'une commande est envoyée (voir le logbook) mais le volet ne réagit pas.

je peux te donner plus de détails si besoin et meme t'aider à travailler a une solution au besoin.

Vincha

On 28/03/2023 09:47, Doubledom wrote:

Voir autre version en cours de test https://github.com/Doubledom45/HA_RFPLAYER_TEST , bien plus élaborée, je suis en train de voir pour autorisé les ID < 256 en enregistrements ( en attendant que GCE autorise les vrais ID, bloqué par le Firmware [sauf Parrot et EDISIOFRAME...) Exemple pour DOMIA avec ID = D3 fait un |switch.domia_d3| qui envoie la commande |ON (ou OFF) DOMIA D3|

— Reply to this email directly, view it on GitHub https://github.com/gce-electronics/HA_RFPlayer/issues/23#issuecomment-1486375501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJE56AO4YPHPU3VPJFHKYIDW6KJSFANCNFSM6AAAAAARW2IRXA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Doubledom45]

Est-ce que tu peux me contacter en MP sur HA Fr @Doubledom

[prahal]

@Doubledom45 a noter aussi que la command est toujours en premier. Car il y a une feinte dans la doc de l'api ... JAMMING est un protocole mais aussi une commande (mais ce n'est pas la même chose). Donc pas besoin de faire un coup "command protocol" et l'autre "protocol commande", il faut juste envoyer JAMMING comme commande (avec son threshold).

[prahal]

@Doubledom45 aussi pour éviter les quiproquo, dans switch.domia_d3 D3 n'est pas un ID valide (c'est une pseudo adresse X10). C'est-à-dire le champ "device adress" au lieu de "device id".

[prahal]

@Doubledom45 pour les messages de commits je pinaille mais cela me permettrai de ne pas avoir à ouvrir chaque commit pour voir ce qu'il fait. Il faudrait écrire ce que tu as résolu comme problème ou quelle fonctionnalité tu as ajouté ou modifié dans le sujet, et optionnellement décrire pourquoi et donner plus de détails ce sur quoi tu as travaillé dans le corps, au lieu de donner le fichier sur lequel tu as travaillé (ce qui est disponible dans le détail du commit et n'est pas essentiel).

[Doubledom45]

@Doubledom45 a noter aussi que la command est toujours en premier. Car il y a une feinte dans la doc de l'api ... JAMMING est un protocole mais aussi une commande (mais ce n'est pas la même chose). Donc pas besoin de faire un coup "command protocol" et l'autre "protocol commande", il faut juste envoyer JAMMING comme commande (avec son threshold).

Ce n'est pas une feinte ! Je comprends pas trop ce que tu veux dire ! Je ne fais plus de PR ici de toute façon, pour l'instant ! Je connais assez bien la Doc de L'API, le mode JAMMING est assez compliqué à expliqué, pour celui-ci je n'envoie que la suite "protocol commande" Que ce soit avec (0 à 10) ou SIMULATE (x) !

[Doubledom45]

@Doubledom45 aussi pour éviter les quiproquo, dans switch.domia_d3 D3 n'est pas un ID valide (c'est une pseudo adresse X10). C'est-à-dire le champ "device adress" au lieu de "device id".

On peut envoyer soit en mode ID soit en pseudo address X10. D3 est un ID valide , le RFPLAYER permet d'envoyer un ID (si <256, n'est pas modifier par le Firmware). Je parle d'ID pour pouvoir inscrire un switch avec ce même ID, plus parlant dans HA !

[prahal]

@Doubledom45 a propos des IDs j'avais supposé que ce n'étaient que des entiers. Comme D3 est alphanumérique je pensais qu'il était un ID invalide.

Par feinte je veux dire: JAMMING SIMULATE se découpe en commande = JAMMING et command parameter = SIMULATE . Il n'y a pas de protocole.

Alors que JAMMING est bien un protocole valide. Mais ce n'est pas parce qu'il y a JAMMING en premier dans un send_raw_packet qu'il y a un protocole en premier. Dands ce cas c'est la commande JAMMING et non le procotole JAMMING.

Il y a un gros bug dans le code du composant rfplayer en cela qu'il considère qu'il y a soit une commande, soit un protocole, soit un device id, soit un device address. Hors dans l'API il n'y a que commande et paramètre. Dans les paramètres il y a protocole, device address, device id, "%x" et aussi ON pour parrotlearning (alors que ON est une commande mais il ne s'agit pas de la même entité). Dans l'API rfplayer touts les commandes commences par "commande" puis des paramètres de commande. Mais dans le composant HA homeassistant il n'y pas de champ pour rentrer autre chose que commande, protocole, device id et device address. Donc pas de place pour un paramètre "%x", un paramèter BURST ou un paramèter ON (je ne parle pas la commande ON pour être dans le détail). Donc je bidouille du code pour ajouter un command_parameter en plus. Je ne promet rien en terme de produire quelque chose mais du coup send_raw_command devient toujours "{command} {optional protocol} {optional device id | device adress} {optional command_parameter}". Parcque ce que je vois jusqu'à maintenant c'est du code qui devient de plus en plus complexe pour ne pas ajouter ce command_parameter. Par example EDISIOFRAME qui est une commande est implémenté comme un protocole alors qu'avec une commande EDISIOFRAME et les paramètres d'EDISIOFRAME dans command_parameter et protocole vide c'est conforme à l'api rfplayer. Pour l'api, JAMMING SIMULATE n'est pas une commande mais un paramètre la commande JAMMING. EDISIOFRAME ne prend pas un device id qui n'est pas préfixé par ID mais un paramèter qui st une série de valeurs hexdécimales séparées par des espaces (il peut prendre aussi des valeurs décimales pour la partie transmission ce qui est la cas ici).

Le code suivant fait très bien l'affaire avec command_parameters:

      def send_command(
          self,
          command: str,
          protocol: str = None,
          device_address: str = None,
          device_id: str = None,
          command_parameters: str = "",
      ) -> None:
          """Send device command to rfplayer gateway."""
          device_parameter = ""
          protocol_parameter = ""

          if protocol is not None:
              protocol_parameter = f" {protocol}"
          if device_id is not None:
              device_parameter = f" ID {device_id}"
          elif device_address is not None:
              device_parameter = f" {device_address}"

          self.send_raw_packet(f"ZIA++{command}{protocol_parameter}"
                               f"{device_parameter} {command_parameters}")

Sinon à force d'empiler les bidouilles pour contourner le fait qu'il manque un paramètre dans le code au lie de le corriger pour correspondre à l'api, on va finir par ne plus pouvoir modifier une ligne de code sans produire une régression (et de plus le code devient illogique, donc incompréhensible pour les nouveaux constributeurs, je veux dire pourquoi EDISIOFRAME est de temps en temps "ZIA++{protocol} {device_id}" et d'autre fois "ZIA++{protocol} {command}"), dans deux ans personne ne saura s'il y avait une bonne raison ou si c'était un choix arbitraire.

Le gros du travail pour ajouter command_parameter c'est de vérifier le composant rfplayer pour tous les appels avec protocol en paramètres car d'après l'API protocol n'est que rarement utilisé dans l'api donc optionnel surtout pour le sensor et number JAMMING.

Pour les PR je considère que faire plein de repository qui sont tous un upstream différent et ne pollinisent pas entre eux est contre productif et produira du code de moins bonne qualité qui ne sera pas maintenu dans la durée (je parle sur 5 ans, évidemment un repo paut avoir beaucoup de contribution pendant quelques mois puis fini car passé à un autre projet ... je vois une différence entre mainteneur et développeur. Il faut les deux).

[Doubledom45]

Salut. Il est vrai que l'envoie des commandes est pas très orthodoxe. Il n'est pas facile de tester tout les cas si pas le matériel en face ... Pour EDISIOFRAME, c'est un protocole (commande) que je connais bien (j'ai travaillé avec Ziblue pour la reconnaissance ). Au début je pensais plus simple d'envoyer tout par la commande avec "protocol" vide, ensuite j'ai modifié pour envoyer la cde en HEXA avec la saisie du "protocol" et de l'ID pour retrouver plus facilement dans les entités de HA.( c'est pour cela que EDISIOFRAME est devenu "protocol"). La création d'une entité pour HA directement (sans passer par un Yaml) ou pour test est plus simple si tout dans même ligne, c'est pour cela le "protocol" vide . Tout cette partie est faites pour Outils de développement

Il est vrai qu'il faudrait définir le système d'envoie une fois pour toute, avec la bonne procédure :

• La commande ( comme dans l'API)
• Le paramètre ( c'est là le hic suivant si besoin d'autres choses, protocol ?)
• Le protocol ( pour tester les commandes qui en ont besoin)
• Le Device_address ( là aussi souvent amalgame avec ID), il faut parler que d'un device
• Le device_ID ( si on veut un ID particulier dans HA) ne pas confondre avec celui du Rfplayer

Il est compliqué de travailler chacun de son côté, il est vrai ... Je crois que @crazymikefra (Michael) est repartis sur une bonne base, même si quelques bug, ou un peu trop poussé. Ce Rfplayer pouvait être un bon "décodeur" mais le bridage sur l'envoie (Firmware) n'est plus en sa faveur, heureusement que le mode Parrot (compliqué) et EDISIOFRAME permet d'envoyer une vraie trame .

[prahal]

@Doubledom45 pour le système d'envoi pour moi: {commande requis} {protocol optionnel} {device id | device address optionel} {command_parameters optionel} semble gérer tous les cas de l'api. (je n'ai pas tout repointé encore).

Mais ce n'est pas possible si EDISIOFRAME devient un protocole. Je suis d'accord que le code actuel avec commande puis protocole puis device_id|device_address ne permet pas de tout mettre dans commande (si il y a un device_id cela ne marche plus, nous ne pouvons plus mettre le paramètre "ON" de la commande "PARROTLEARN" après l'identifiant du device). Mais si nous ajoutons un commande_parameters que l'on écrit à la fin de la frame ZIA++, il suffit de ne pas envoyer de protocole et maintenant on peut avoir une commande mot simple "PARROTLEAN" comme dans l'api, suivie de l'identifiant du device, puis enfin et son paramètre "ON" dans command_parameters. (il se pourrait que l'orde des paramètres des commandes "ON", "ASSOC", "DIM", etc n'importe pas. M%ais ce n'est pas indiqué dans l'api sauf pour ce petit ensemble de commande.

Par contre, pourquoi fait tu la distinction device_address and device_id du rfplayer et de HA ? À part pour le fait que le firmware du rfplayer bride les ID de 0 à 255 (peut être parcqu'ils indiquent dans l'api que ID 0 = A1 et ID 255 = P16 et comme P16 est la pseudo-code X10 maximale, ils ne veulent peut-être pas aller au-delà pour les IDs.

Pour le fork de @crazymikefra je ne sais pas s'il est destiné à durer sous cette forme car d'après sa réponse dans https://github.com/gce-electronics/HA_RFPlayer/pull/25#issuecomment-1489679736, l'objectif et au final de tout jeter et de repartir de zéro. Mais peut être qu'il envisage de garder une version stable du fork actuel je ne sais pas. Son fork est actuellemnt intéressant mais très instable. J'ai appliqué tes corrections que tu as indiqués dans ses "issues" mais j'ai toujours de problèmes. Les entités sont créées mais au redémarrage de HA elles ne fonctionnent plus. D'après les logs le platform switch est utilisés pour ces entités qui sont des sensors et comme il vérifie dans switch.py si c'est bien un switch et que non son code les efface. Par contre j'aime beaucoup son choix de permettre d'effacer des entités depuis l'UI.

Donc plein de fonctionnalités nouvelles mais en mode alpha. Il faudrait deux branches une au minimum quasi stable et l'autre de développement. Mais je ne sais pas si c'est son objectif. Donc le repository GCE reste pour moi la branche stable.

[crazymikefra]

@prahal Je m'étais un peu mis en pause pour diverses causes personnelles mais je sens que je vais devoir intervenir. Mon fork est stable, je l'utilise au quotidien sur mon installation. Que lui trouves-tu d'instable ? Ok, j'ai dit que je voulais repartir de zéro mais pas complètement, le but du jeu est de conserver au maximum les bibliothèques "rflib", c'est pour cela que nous avons travaillé dessus avec @Doubledom45

Mon approche est la même que j'ai utilisé sur un sujet professionnel, c-a-d : on a une doc, celle du rfplayer, qui nous détaille une liste de protocoles et d'infotypes. De cela, j'ai contruis une série de bibliothèques sur la même architecture. Comme cela, si l'on lit la doc et qu'on la compare à mon code, on s'y retrouve plus facilement à mon gout.

La version Next que je prépare de mon fork, partira des précos de codage exposées par homeassistant et une amélioration de la lisibilté du code. @Doubledom45 et @Aohzan ont fait déjà un bon travail de base, je les salue pour cela. Par contre, j'avoue que se plonger dans le code a été assez compliqué au début car j'avais du mal à identifier comment étaient imbriqués les différents appels entre chaque couche du code. Je compte donc réaliser un code plus clair et plus lisible.

De plus, dans mes deniers updates, j'ai commencé à travailler sur la partie configuration du plugin avec une page de paramétrage. Ok ce ne sont que des ébauches mais je jette au moins les bases et ensuite je verrais pour remettre cela plus propre.

Personnellement, j'ai changé de travail depuis que j'ai attaqué ce sujet et celui-ci me consomme pas mal d'énergie donc j'ai du faire un choix ces derniers temps car une grosse fatigue s'est installée.

Mon code n'est peut-être pas parfait mais, en l'état il est super stable chez moi (ce qui est ma priorité) et je retravaillerais dessus lorsque je retrouverais du temps.

On se retrouve dans cette discussion à la frontière avec la querelle, je ne dirais donc pas plus que ce que je viens d'écrire. Comme tu le dis, cette branche est la stable pour toi mais nous sommes sur un sujet OpenSource, donc chacun apporte sa pierre à l'édifice. Mon code continuera donc à vivre de son côté et, lorsque je le sentirais suffisamment mature, je reviendrais le proposer sur la branche "officielle".

Sur ce, je vous souhaite à tous une bonne soirée.

[Doubledom45]

Mais ce n'est pas possible si EDISIOFRAME devient un protocole.

Je disais qu'il ne fallait plus parler de protocole pour EDISIOFRAME mais effectivement d'une commande .

Pour ce qui de paramètre, il faut que ce soit le vrai paramètre comme dans l'API .Le reste aussi d'ailleurs !

Si besoin de ID x or pseudo-address X10 on s'en sert ensuite ou à la place de paramètre effectivement !

À part pour le fait que le firmware du rfplayer bride les ID de 0 à 255 (peut être parcqu'ils indiquent dans l'api que ID 0 = A1 et
 ID 255 = P16 et comme P16 est la pseudo-code X10 maximale, ils ne veulent peut-être pas aller au-delà pour les IDs.

Cela est du à l'origine à la loi française qui interdisait d'émettre ou de reproduire le même code (autre que sur un octet), que l'on pouvait lire ( il avait fait le mode Parrot pour y palier ! et autorisé le EDISIOFRAME) tu ne peux sinon pas envoyer le vrai code il sera modifier par le Rfplayer (Firmware) j'ai demandé à GCE de lever cette interdiction (car d'autres le font, RFXCOM, lui c'est vrai origine HL).

Si besoin du protocole suivant les commandes, on s'en sert ensuite .

Il y a le problème de quelques "commande" qui ont besoin d'autres choses (% x, BURST x, QUALIFIER x ...)

Voir s'il faut faire liste ou laisser faire ,de toute façon le Rfplayer ne laisse passer que si correctement formaté. De toute façon j'ai mis un protocole vide, qui permet d'envoyer en brut dans la commande .

Pour le fork de @crazymikefra [ Les entités sont créées mais au redémarrage de HA elles ne fonctionnent plus.] C'est pour pouvoir supprimer effectivement les entités plus facilement. Le reste je ne sais pas s'il a fait des modifs depuis les erreurs dans son fork. J'ai modifié sur la copie dans le mien ...

Je commente pas mal de ligne pour s'y retrouver ....

Moi perso je fait une automatisation au reboot de HA pour créé les entités que je me sers et que je veux garder !

Le Jamming est réinitialisé aussi de cette façon, suite à des remarques de quelqu'un !

Pour le distinguo entre ID ou adresse , c'est à mettre dans la meme partie pour le Rfplayer mais mettre un ID pour la création de HA avec une vrai entité ( attention au unique ID) quand même plus simple que renommer ensuite ( ou faire dans Yaml)

Il y a pas mal de cde qui n'ont d'utilité que pour ceux qui connaisse ce Rfplayer. Je voulais initier les cde RECEIVER et REPEATER mais je le fais par HA (Yaml avec sélection d'une liste, que je récupère) Exemple pour les protocoles:

  - platform: template
    switches:
      choix_protocol:
        friendly_name: 'Choix Protocol'
        unique_id: switch.choix_protocol
        turn_on:
            service: rfplayer.send_command
            data:
                command: RECEIVER + {{ states('input_select.choix_protocol') }}
                protocol: ''
                automatic_add: false
        turn_off:
            service: rfplayer.send_command
            data:
                command: RECEIVER - {{ states('input_select.choix_protocol') }}
                protocol: ''
                automatic_add: false

L'objectif des fork de chacun est évidement de mettre à jour celle de GCE, mais si refonte voir avec les initiateurs du projet.

Le rfplayer et RFXCOM commence à devenir dépassé, les gens veulent plus des trucs en wifi ou en MQTT, à voir si la domotique continuera d'évoluer sur le mode Fréquence...

PS : As tu la possibilité d'ouvrir un mode discussion sur ton Fork ou se servir du mien!

Car on s'éloigne du sujet de cette issue. Possibilité sur le Forum de HA France en MP @Doubledom @+ Doubledom

[Doubledom45]

J'ai reporté nos échanges sur mon fork .. Pour continuer cette discussion voir #https://github.com/Doubledom45/HA_RFPLAYER/discussions/1#discussioncomment-5486403

[prahal]

@crazymikefra je suis désolé, je ne voulais pas être désagréable. Par pas stable je pensais au unstable de Debian ou à la branch d'Andrew Morton pour le noyau Linux. Du code qui marche dans la majorité des cas mais pas tous. Je pensais au problème avec"RFLINK H" et "RFLINK V" qui empêchent le composant rfplayer de démarrer https://github.com/crazymikefra/HA_RFPlayer/issues/11 . Je suis très optimiste pour ton fork car je pense que tu travailles profondémment le code.

@Doubledom45 pouvoir supprimer les entités m'intéresse beaucoup. J'ai lu votre discussion sur le repository de crazymikefra à ce propos mais je ne ne connais pas assez HA pour comprendre comment cela est possible tout en gardant des entités fonctionnelles. J'ai remarqué quue quand je presse le bouton de la télécommande son entité se réactive automatiquement (elle est recréée sur l'ancienne je pense, cela me convient). Par contre j'ai un problème qui rend l'ensemble inutile pour moi : je récupère la valeur du senseur de la télécommande pour activer un interrupteur avec une automation HA. Mais avec le code actuel l'automatisation ne propose que "Inconnu" et "Indisponible", pas "Activé" et "Désactivé" (ON et OFF) se qui fait que l'automatisation ne foncitonnne pas. Je ne sais pas pourquoi maiq avec ta Beta 16 cela marchait. Je n'ai pas encore essayé ton nouveau fork basé sur craymikefra par contre. Au fait pourquoi tu ne base pas tes fork sur le fork GCE (bouton fork de github) ?

pour la discussion, le coeur de mon propos est de discuter d'ajouter un command_parameters ou pas au lieu de faire des cas particulier pour beaucoup de protocoles ( ce qui au bout de quelque temps rendra le send_command énorme avec toius les cas particulier), donc ce rapport de bug est dans le sujet. Pour moi résoudre ce bug en ajoutant une commande JAMMING et passer SIMULATE comme command_parameters est important. Cela conditionne tous les développements ultérieurs.

Pour le sujet "Il faut envoyer l'ID avant le protocole" je pense que ce n'est pas nécessaire car les deux sens sont valides. A part la commande qui doit être en premier d'après la doc de l'api, les autres éléments sont tous des paramètres (et pour les quelques commandes ON, OFF DIM, etc l'api précise que l'ordre des paramètes n'a pas d'importance (ID et protocole sont des paramètres du même ordre, il n'y a un ordre pour protocole et ID que parcqu'il faut bien que l'on implémente la concaténation de paramètres dans un ordre dans le code).

[prahal]

@Doubledom45 j'ai mis trop de temps à répondre et tu as copié nos échanges dans la discussion. J'ai voulu ajouter mon dernier commentaire à la discussion mais elle est liimitée aux contributeurs. Je ne peux pas y participer.

A propos de la partie discussion, je suis pour mais pas dans des forks. Car quand un fork est supprimé la discussion aussi. A moins que cela soit un fork "stable" (j'entends présumé rester des années).

[Doubledom45]

OK je vois cela j'avais verrouiller la discussion Désolé

Je suis en train de demander une modification plus simple je pense, sur la façon d'envoyer une cde dans le Rfplayer !

https://github.com/gce-electronics/HA_RFPlayer/pull/31#issue-1649008981

[Doubledom45]

La version de @crazymikefra est je pense très aboutie ! Pour les erreurs du Rflink OK, j'ai modifié sur le mien , il reste sur le sien. Pour ton problème du sensor il faudrait que je regarde ce que tu fais. Passe STP sur le Forum de HA Fr