Update rfpprotocol.py

[Doubledom45]

Modification de la méthode d'envoie, suivant doc API. La partie command devient la vraie commande Command name La partie device_address devient la vraie adresse ( ou ID) pour le Rfplayer ,une partie de parameters La partie protocol devient la suite parameters si besoin.

La partie device_id devient le vrai nom pour HA . Nota : modification du services.yaml pour précision de ce changement ?

[prahal]

@Doubledom45 Je préfère ce code à l'ancien, merci. Il reste que si l'on met tous les paramèters restant dans protocole l'on ne peut plus avoir un combolist avec les protocoles ce qui est très pratique (car cela documente les protocole valide à l'utilisateur).

J'ai du mal à ne pas vouloir une variable supplémentaire command_parameters à mettre à la fin et à avoir protocole qui peut être vide dans les cas (majoritaire dans l'api rfplayer) où il n'y a pas de protocole.

Pour moi ne pas toucher au nombre de variable "device address" "protocol" et "command" est étrange, on s'empêche de rajouter une variable. Mais pourquoi :-) On pourrait même en rajouter plus qu'une. (je pense au cas des commandes REPEATER et RECEIVER qui ont un paramètre à placer avant le protocole).

[prahal]

@Doubledom45 pour les commentaires dans le code, mets les dans le corps du message commit, cela sert à cela (c'est pour cela qu'il faut découper les commit par changement fonctionnel sinon évidemment il n'est plus possible de relier les commentaires dans le commit au contenu du commit).

[Doubledom45]

@Doubledom45 Je préfère ce code à l'ancien, merci. Il reste que si l'on met tous les paramèters restant dans protocole l'on ne peut plus avoir un combolist avec les protocoles ce qui est très pratique (car cela documente les protocole valide à l'utilisateur).

J'ai du mal à ne pas vouloir une variable supplémentaire command_parameters à mettre à la fin et à avoir protocole qui peut être vide dans les cas (majoritaire dans l'api rfplayer) où il n'y a pas de protocole.

Pour moi ne pas toucher au nombre de variable "device address" "protocol" et "command" est étrange, on s'empêche de rajouter une variable. Mais pourquoi :-) On pourrait même en rajouter plus qu'une. (je pense au cas des commandes REPEATER et RECEIVER qui ont un paramètre à placer avant le protocole).

Oui je sais qu'il faudrait ajouter quelque chose si besoin à l'envoie, mais il faut tester tout les cas avant. C'est pour cela que j'ai laisser la possibilité de le faire dans la cde si protocol " " Il faut modifier la liste protocol pour ceux qui ne servent pas ! Faire une liste sur la partie commande serait pas mal non plus !

Donc a voir pour ajouter paramètre pour cas spéciaux! Si vaut vraiment le coup !

Nota: Pour les cde REPEATER et RECEIVER qui ont un paramètre à placer avant le protocole, moi je suis parti sur des entité dans le lovelace, avec tous les cas, bien plus simple que passer par le develop... avec une entrée choix protocol du type: et un swich en Yaml pour le bouton

  - 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

[prahal]

Oui je sais qu'il faudrait ajouter quelque chose si besoin à l'envoie, mais il faut tester tout les cas avant. C'est pour cela que j'ai laisser la possibilité de le faire dans la cde si protocol " " Il faut modifier la liste protocol pour ceux qui ne servent pas !

Je suis d'accord, bonne idée. Je n'avais pas compris ton intention.

Faire une liste sur la partie commande serait pas mal non plus ! Oui très bonne idée !

[Doubledom45]

Faire une liste sur la partie commande serait pas mal non plus ! Oui très bonne idée !

Après il ne faut pas que la partie Outils de développement soit une 'usine à gaz' Surtout faut-il envisagé tout les cas?, ou simplement laisser faire le Rfplayer. C'est vrai que cela donne une idée pour faire un appel au service dans HA.

Pour ce type d'appel il faut passer en mode Yaml de toute façon !

[prahal]

Nota: Pour les cde REPEATER et RECEIVER qui ont un paramètre à placer avant le protocole, moi je suis parti sur des entité dans le lovelace, avec tous les cas, bien plus simple que passer par le develop... avec une entrée choix protocol du type: et un swich en Yaml pour le bouton

  - 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

D'accord tu ne permets pas de mettre plusieurs opérations du coup c'est plus simple. J'étais resté sur les examples de l'api:

RECEIVER + CHACON BLYSS // add CHACON and BLYSS to the current list
RECEIVER - * + CHACON // receive only chacon

Mais cela empêche de faire certaines les combinaisons avec "" et un sous ensemble de protocole à ajouter ou enlever du l'ensemble total. D'ailleurs même mon option d'ajouter une varibale opérateur ne supporte pas ce cas... Il faudrait que l'on puisse envoyer un dictionnaire depuis le formulaire services. {"CHACON":"+", "":"-"} serait bien. Au minimum il fadrait pouvoir avoir un nombre d'entrée du formulaire service dynamique (pouvoir ajouter un nombre variable fois le protocole. Peut-être que c'est faisable avec des entités. EDIT: j'ai compris que l'on peut envoyer "+ *" puis dnas une autre commande "- CHACON", donc cela marche déjà. Ce serait juste un plus pour pouvoir envoyer tout dans une seule commande.

Et on ne peut pas la combox des commandes avec les commandes de l'api tel quel. Cela se résoud plus facilement en ajoutant les commandes "RECEIVER +" et "RECEIVER -" et "REPEATER +" "REPEATER -".

[Doubledom45]

Salut suite sur le Forum Fr si tu veux bien Alban ! Rien n'empêche de faire des "switch" avec autres cde. Le On fait les plus et le OFF fait les moins !