CHACON ET DI.O - Githubissues

Il faut pour ces types récupérer le'rfQuality': 'x' pour identifier le bouton des groupes sinon remonte sous même ID. Le "G" All_ON ou All_OFF remonte sur le bouton 1 !

ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-60", "floorNoise": "-101", "rfQuality": "10", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "5", "id": "810327680", "subTypeMeaning": "ALL_ON"}}}

ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-65", "floorNoise": "-100", "rfQuality": "8", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "5", "id": "810327680", "subTypeMeaning": "ALL_ON"}}}

 ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-66", "floorNoise": "-100", "rfQuality": "8", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "4", "id": "810327680", "subTypeMeaning": "ALL_OFF"}}}

Pour CHACON DIO InfoType 1 pour différencier le Bouton G [ALL] de la Tlde ( il a ID le même que le 1er Bp) Lors de la création ID dans _"/config/customcomponents/rfplayer/rflib/infotypes.py"

    fields_found["id"]=infos["id"]
    fields_found["command"]=fields_found["subType"]
## Voir pour différencier le Bouton G [All] dans un ID particulier Test sur ALL_ON ou OFF car sinon reprend l'ID du Bp1
    if fields_found["command"] == "ALL_ON" or fields_found["command"] == "ALL_OFF":
        fields_found["id"]=infos["id"]+"G"

    if fields_found["id"]!="0" or allowEmptyID:
        return fields_found

2023-03-05 13:31:07.324 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] received data: ZIA33{ "frame" :{"header": {"frameType": "0", "cluster":
2023-03-05 13:31:07.357 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] received data: "0", "dataFlag": "0", "rfLevel": "-86", "floorNoise": "-107", "rfQuality": "5", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "1", "id": "810327680", "subTypeMeaning": "ON"}}}
2023-03-05 13:31:07.359 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680typ_typ', 'subType': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:07.360 DEBUG (MainThread) [custom_components.rfplayer] device_id not known, adding new device
2023-03-05 13:31:07.360 DEBUG (MainThread) [custom_components.rfplayer] event_type: sensor
2023-03-05 13:31:07.361 DEBUG (MainThread) [custom_components.rfplayer] event_id: CHACON_810327680typ_typ
2023-03-05 13:31:07.361 DEBUG (MainThread) [custom_components.rfplayer] event: {'id': 'CHACON_810327680typ_typ', 'subType': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:07.361 DEBUG (MainThread) [custom_components.rfplayer] device_id not known, adding new device
2023-03-05 13:31:07.362 DEBUG (MainThread) [custom_components.rfplayer] {'sensor': <function async_setup_entry.<locals>.add_new_device at 0x7f7c1c39a0>, 'command': <function async_setup_entry.<locals>.add_new_device at 0x7f7c4612d0>, 'cover': <function async_setup_entry.<locals>.add_new_device at 0x7f7b3679a0>}
2023-03-05 13:31:07.362 DEBUG (MainThread) [custom_components.rfplayer] <function async_setup_entry.<locals>.add_new_device at 0x7f7c1c39a0>
2023-03-05 13:31:07.393 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680cmd_cmd', 'command': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:07.393 DEBUG (MainThread) [custom_components.rfplayer] device_id not known, adding new device
2023-03-05 13:31:07.394 DEBUG (MainThread) [custom_components.rfplayer] event_type: sensor
2023-03-05 13:31:07.394 DEBUG (MainThread) [custom_components.rfplayer] event_id: CHACON_810327680cmd_cmd
2023-03-05 13:31:07.394 DEBUG (MainThread) [custom_components.rfplayer] event: {'id': 'CHACON_810327680cmd_cmd', 'command': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:07.394 DEBUG (MainThread) [custom_components.rfplayer] device_id not known, adding new device
2023-03-05 13:31:07.395 DEBUG (MainThread) [custom_components.rfplayer] {'sensor': <function async_setup_entry.<locals>.add_new_device at 0x7f7c1c39a0>, 'command': <function async_setup_entry.<locals>.add_new_device at 0x7f7c4612d0>, 'cover': <function async_setup_entry.<locals>.add_new_device at 0x7f7b3679a0>}
2023-03-05 13:31:07.395 DEBUG (MainThread) [custom_components.rfplayer] <function async_setup_entry.<locals>.add_new_device at 0x7f7c1c39a0>
2023-03-05 13:31:07.417 DEBUG (MainThread) [custom_components.rfplayer.sensor] Add sensor entity {'id': 'CHACON_810327680typ_typ', 'subType': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:07.418 DEBUG (MainThread) [custom_components.rfplayer.sensor] Add sensor entity {'id': 'CHACON_810327680cmd_cmd', 'command': 'ON', 'value': 'ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:09.225 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] received data: ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-86", "floorNoise": "-107", "rfQuality": "5", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "0", "id": "810327680", "subTypeMeaning": "OFF"}}}
2023-03-05 13:31:09.226 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680typ_typ', 'subType': 'OFF', 'value': 'OFF', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:09.229 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680cmd_cmd', 'command': 'OFF', 'value': 'OFF', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:12.324 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] received data: ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-86", "floorNoise": "-107", "rfQuality": "5", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "5", "id": "810327680", "subTypeMeaning": "ALL_ON"}}}
2023-03-05 13:31:12.326 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680Gtyp_typ', 'subType': 'ALL_ON', 'value': 'ALL_ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:12.329 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680Gcmd_cmd', 'command': 'ALL_ON', 'value': 'ALL_ON', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:13.962 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] received data: ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-86", "floorNoise": "-107", "rfQuality": "5", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "4", "id": "810327680", "subTypeMeaning": "ALL_OFF"}}}
2023-03-05 13:31:13.964 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680Gtyp_typ', 'subType': 'ALL_OFF', 'value': 'ALL_OFF', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}
2023-03-05 13:31:13.967 DEBUG (MainThread) [custom_components.rfplayer.rflib.rfpprotocol] got event: {'id': 'CHACON_810327680Gcmd_cmd', 'command': 'ALL_OFF', 'value': 'ALL_OFF', 'unit': None, 'platform': 'sensor', 'protocol': 'CHACON'}

Cela à l'air d'être OK

Maybe we should also rename the command for the remote G button from ALL_ON/ALL_OFF to ON/OFF. Either way, I know no means to group the remote button device ids together so an ALL_ON/ALL_OFF command applies to the whole group. So I think we could treat the CHAON DIO remote G button (ie the G pair of buttons, one for ON and the other for OFF) as a normal button with an ON/OFF command.

Salut ... Le Hic c'est que ce bouton remonte avec un identifiant comme le Bp 1 , c'est pour cela que j'ai gardé ! de plus il faut que les récepteurs soient codés avec ce Bp G

@Doubledom45

Le Hic c'est que ce bouton remonte avec un identifiant comme le Bp 1 , c'est pour cela que j'ai gardé ! de plus il faut que les récepteurs soient codés avec ce Bp G

Je ne comprends pas ce que cela veut dire. Tu veux dire que tu as gardé ALL_ON/ALL_OFF car l'identifiant du bouton 'G' est celui du bouton '1'? Mais quel est l'utilité de garder ALL_ON/ALL_OFF si nous avons déjà ajouté 'g' à l'identifiant du bouton 1?

Que veux dire de plus il faut que les récepteurs soient codés avec ce Bp G ?

PS: veux tu dire que un jour le firmware du rfplayer pourrait accepter que l'on envoie le device id d'origine du bouton de la télécommande Dio déjà appairé au récepteur ? Car si j'ai bien compris avec le firmware actuel (à cause de la réglementation française apparemment ?) si nous renvoyons le device id reçu du bouton de la télécommande au rfplayer le firmware refuse de le transférer. Donc de toute façon pour agir sur un récepteur il faut appairer le récepteur avec un device id ou une adresse device différente de celle de la télécommande. Donc le fait que les récepteurs soient codés avec le bouton G ne nous concerne pas car nous ne pouvons pas actuellement renovyer le device_id du bouton G (ie celui du bouton 1 avec la commande ALL_ON/ALL_OFF)

De toute façon, je n'ai pas appairé mes appareils avec le bouton G, seulement avec l'un des trois autres boutons et mes appareils s'éteignent quand même quand je presse G ... je ne sais pas comment ceux appairés avec les boutons 2 et 3 font car l'id est seulement celui du bouton 1 avec ALL_ON/ALL_OFF. Ce serait intéressant de trouver commetn ils font dans leur firmware pour détecter que c'est le bouton 1 qui est sur la même télécommande que le bouton 2 ou 3 qui les contrôle qui a été appuyé. Peut être que dans ce cas nous pourrions simplement mettre els boutons 1, 2 et 3 à ON/OFF quand G est appuyé au lieu de créer un bouton G (que l'on ne sait pas après dans HA lier aux boutons 2 et 3, seulement au bouton 1 avec l'id du bouton G).

Donc le rfplayer ne supporte les télécommandes qu'en réception et pas en retransmission (sauf peut être à enregistrer la trame reçue dans un enregistrement parrot sur le rfplayer et d'appeler cette enregistrement parrot depuis HA.

En fait device_id n'est supporté que si ce n'est pas un device id envoyé par un appareil et que si il ne dépasse pas le nombre de valeurs possible avec un device address (une adresse pseudo X10) donc 255. Je ne vois pas l'intérêt d'avoir le device_id dans le code send_command. Le device address fait le même travail et au moins il est clair si l'on enlève le device id que l'on n'a pas la possibilté d'envoyer le device id reçu.

Salut .. Pour reprendre la fonction ON (ou OFF) et ALL_ON (ou ALL_OFF) suivant l'initialisation du groupe , les ALL permettent de faire fonctionner tout le groupe !

Pour le device_id , il est vrai que pas trop d'intérêt (sauf le nom, pour ne pas passer par un renommage dans HA) il lui faut sinon un pseudo X10, on parle ici seulement pour la création de l'entité dans HA , donc ce sera le Device addressqui devra être utilisé seul pour l'envoie de la commande , donc obligatoire initié si on se sert de l'ID autre que le pseudo X10.

Pour reprendre la fonction ON (ou OFF) et ALL_ON (ou ALL_OFF) suivant l'initialisation du groupe , les ALL permettent de faire fonctionner tout le groupe !

Je n'ai pas essayé mais tu veux dire que si j'appaire chacune de mes prises avec un device address (ou un device id en dessous de 255) et que j'envoie ALL_ON avec le device address du bouton 1, j'allumerais toutes mes prises ?

Je me demande encore comment les prises appairées avec les boutons 2 et 3 font pour savoir que quand la télécommande envoie ALL_ON avec le device id du bouton 1 elles doivent s'allumer. Si nous pouvions reproduire ce comportement avec le device id en dessous de 255 ou le device address du bouton "1" il y aurait en effet un intérêt à garder ALL_ON/ALL_OFF plutôt que de créer un bouton "G" dans homeassistant avec une command ON/OFF au lieu de ALL_ON/ALL_OFF. Je veux dire que nous n'avons pas de moyen de savoir quels boutons sont contrôlés par le bouton "G" dans homeassitant (surtout si il y a plusieurs télécommandes avec plusieurs boutons "G" qui ne s'appliquent qu'à leurs boutons "1", "2" et "3" à eux). Avoir une commande ALL_ON/ALL_OFF n'a pas d'utilité dans ce cas. Mais en effet si un jour le rfplayer supporte d'envoyer les device id d'origine cela servira.

Actuellement je n'envoi pas de trame pour le bouton "G". J'envoi une trame pour chaque bouton "1", "2" et "3" avec ON ou OFF lorsque je détecte que le bouton "G" de la télécommande a été appuyé. (en plus je veux utiliser le télécommande Dio pour contrôler des prises zigbee, donc même renvoyer l' ID d'origine du bouton "1" avec ALL_ON/ALL pour contrôler trois prises zigbee simultanément ne m'aiderait pas)

Je n'ai pas essayé mais tu veux dire que si j'appaire chacune de mes prises avec un device address (ou un device id en dessous de 255) et que j'envoie ALL_ON avec le device address du bouton 1, j'allumerais toutes mes prises ?

Il faut initier la commande ALL_ON sur chaque prise que tu as besoin !

Je me demande encore comment les prises appairées avec les boutons 2 et 3 font pour savoir que quand la télécommande envoie ALL_ON avec le device id du bouton 1 elles doivent s'allumer.

C'est parce qu'elles ont été initié, c'est un peu comme une cde de groupe en mode RTS ! C'est le subtype qui contient la commande 0: OFF, 1: ON, 4: ALL_ OFF, 5 : ALL_ ON Le Rfplayer prend l'ID du Bp 1 (avec un subtype différent), tu peux faire le décodage en Hexa pour vérifier ! Mais pas forcer d'avoir la prise cder par le Bp1 qui réagisse à cette cde ALL . Effectivement on ne peux pas savoir les prises qui ont été initié avec cette cde ALL ( nous n'avons que l'info de la cde G ), bien que certaine prises sont émulée automatiquement avec le ALL !

Suivant info de l'API une cde HEXA sera décodé

du type: 00 00 00 B3 95 07 04 01 01 00 8C 9E 4C 30

Frame Type 00

Cluster 00

Fréquence 00=433

rfLevel B3 , notation négative [FFFF FFB3] =-77dB

floorNoise 95, notation négative [FFFF FF95] =-107dB

rfQuality 7

protocol 04 => Chacon

infotype 01

subtype 01 => cde ON si on veut le ALL on ajoute 4

ID 008C9E4C30 => 304C9E8C = 810 327 692

Pour info avec son équivalence pour le RFXCOM , il faut prendre l'hexa en binaire avec rotation circulaire gauche, récupérer les 3 premiers octet et le dernier octet devenant le 1er C1 327A 3000 => 00C1327A

Mais en effet si un jour le rfplayer supporte d'envoyer les device id d'origine cela servira.

Toujours en attente de suivi par Patrick de GCE, pour modification du firmware !

C'est parce qu'elles ont été initié, c'est un peu comme une cde de groupe en mode RTS ! C'est le subtype qui contient la commande 0: OFF, 1: ON, 4: ALL OFF, 5 : ALL ON Le Rfplayer prend l'ID du Bp 1 (avec un subtype différent), tu peux faire le décodage en Hexa pour vérifier ! Mais pas forcer d'avoir la prise cder par le Bp1 qui réagisse à cette cde ALL . Effectivement on ne peux pas savoir les prises qui ont été initié avec cette cde ALL ( nous n'avons que l'info de la cde G ), bien que certaine prises sont émulée automatiquement avec le ALL !

Si j'ai bien compris lors de l'appairage entre la télécommandez et chacune des prises, il y a deux appairages simultanés: le device id du bouton appuyé avec ou ON/OFF et le device id du bouton '1' (même si c'est le bouton '2' qui est appuyé) avec ALL_ON/ALL_OFF. Cela peut se confirmer en écoutant le traffic via le rfplayer pour voir cet échange double lors de l'appairage d'une prise avec avec la télécommande. Merci beaucoup.

As tu observé ou vu un enregistrement de traffic qui confirme cela ? Je veux vérifier mais cela sera dans plusieurs mois à mon avis.

Je pense que dans ce cas nous pouvons créer des ensembles contrôlés pas ALL_ON/ALL_OFF de taille arbitraire. Ce qui est très pratique. Le code du composant rfplayer pourrait même par défaut envoyer une commande supplémentaire lorsque l'on appaire avec un device id/devicee_address et une commande ON/OFF pour aussi appairer avec un device id/device address qui serait une entité de groupe de boutons et une commande ALL_ON/ALL_OFF. Nous pourrions avoir un device id/device address de groupe par défaut et un choix pour créer un autre groupe (avec son propre device id/device address), ou choisir un des groupe non par défaut déjà créé.

Cela ne résout pas mon problème qui est de détecter quels entités senseurs avec un id différent du bouton "1" doivent passer à on ou off quand je reçois le device id du bouton "1" avec ALL_ON/ALL_OFF. Mais la gestion pourrait être commune : si l'on peut définir un type d'entité comme étant un senseur qui correspond à plusieurs autres boutons, nous pourrions aussi assigner à ces autres boutons à l'ensemble correspondant à ce device_id/device address d'ensemble de bouton.

Je n'ai pas souvenir que homeassistant ait cette notion de senseur correspondant à plusieurs senseur, cad qu'il permette de publier sur plusieurs senseurs desinataires quand un senseur reçoit une commande (ceci en assignant ces senseurs destinataires à ce senseur/entité parent). Dans ce cas il faudrait trouver un moyen d'implémenter ce comportement.

crazymikefra / HA_RFPlayer

CHACON ET DI.O #10