CHACON SWITCH

[Doubledom45]

System Health details

Suite protection du Rfplayer en interne , antipiratage !

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

On ne peut pas faire un Switch avec des ID > 256

Reproduction steps

1.CHACON switch 1911611264
2.

Cela ne peut pas aboutir sur ce switch , le Rfplayer transformera la sortie ID en un ID < 256
...

Debug logs

INFO (MainThread) [custom_components.myrfplayer.switch] turn on switch.chacon_1911611264_switch

 DEBUG (SyncWorker_3) [custom_components.myrfplayer.rfplayerlib.protocol] sending raw packet: b'ZIA++ON CHACON ID 1911611264\n\r'

Diagnostics dump

No response

[Doubledom45]

Il n'y a aucun programme Add-on qui le permette, il faut passer par une commande Parrot.
EDISIOFRAME le permet mais pas la même chose !

Voir pou les passer en Capteur !

[racletteparty]

When the address is decoded, there is additional logic to extract a group code and unit code for chacon. I could not try extensively but it should be able to extract the id < 256. Then you can use one of the placeholders unit or group to build the rfplayer command

[Doubledom45]

Quand je décode en Hexa Field
Un ON et OFF sur une télécde 54761 Dio compatible Chacon
Le ON ZIA11 00 00 00 A4 95 03 04 01 01 00 80 9E 4C 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Le ON
Le OFF ZIA11 00 00 00 B6 94 08 04 01 00 00 80 9E 4C 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Le OFF

00 Frame Type
00 Cluster
00 Fréquence => 433
A4 RF Level
95 Floor Noise
03 RF Quality
04 Protocol => CHACON
01 Infos Type =>
01 Sub Type Code [0: OFF, 1: ON/Alert ; X10 & CHACON add 4: ALL_ OFF, 5 : ALL_ ON]
00 ? ne sert pas
80 9E 4C 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => 304C9E80 = (x10) 810327680
80 Le 0 correspond au N° du Bp ( j'ai pas des Bp >16) donc je sais pas comment réagi si >16

[Doubledom45]

J'ai fais des tests avec des cdes Bp >16
Je ne les décode pas normalement en Hexa ou JSON
Une erreur depuis le début ! des Add-on
Pour un 24 (18 hexa) il le transforme en 7 ------ > 304C9E87 [87 9E 4C 30]
Représentation RFXCOM --> C1327A:24 le BP en base 10 [ en x00 C1327A18 ]
Pour un 62 (32 hexa) il le transforme en D ------ > 304C9E8D [8D 9E 4C 30]
Représentation RFXCOM --> C1327A:62 le BP en base 10

Pour info j'ai deux Rfplayer et plusieurs RFXCOM pour faire les tests
Le transcodage entre RFXCOM et Rfplayer se fait pour l' ID en ID -1 puis rotation circulaire gauche (2 fois)

[racletteparty]

The code I wrote for decoding that part is here.
https://github.com/racletteparty/HacsMyRfPlayer/blob/main/custom_components/myrfplayer/rfplayerlib/device.py#L45

HacsMyRfPlayer/custom_components/myrfplayer/rfplayerlib/device.py

Line 58 in 36fe79b

if self.protocol == "CHACON":

With C1327A:24 if 24 is decimal (0 - 255) then X10 pseudo address for 24 should be B9. if I'm right it should mean group B, unit 9. but that's not how it's currently implemented in my code

[Doubledom45]

Slt
Pour ce qui est des Chacon, que tu transformes en switch:

• le switch ne fonctionnera que si celui-ci est avec un appairage correct, car le code est changé en interne par le Rfplayer, le code envoyé ne correspondra pas à celui créé ( chaque Rfplayer à une entête particulière )

TEST SUR UN SWITCH RECONNU COMME 573467521 OFF / ON ( le récepteur fonctionne)

• ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-41", "floorNoise": "-95", "rfQuality": "10", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "0", "id": "573467521", "subTypeMeaning": "OFF"}}}
• ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-41", "floorNoise": "-96", "rfQuality": "10", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "1", "id": "573467521", "subTypeMeaning": "ON"}}}

ON ESSAI D' EMETTRE LE SWITCH 573467521

• ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-52", "floorNoise": "-107", "rfQuality": "10", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "0", "id": "917178369", "subTypeMeaning": "OFF"}}}
• ZIA33{ "frame" :{"header": {"frameType": "0", "cluster": "0", "dataFlag": "0", "rfLevel": "-50", "floorNoise": "-107", "rfQuality": "10", "protocol": "4", "protocolMeaning": "CHACON", "infoType": "1", "frequency": "433920"},"infos": {"subType": "1", "id": "917178369", "subTypeMeaning": "ON"}}}

CELUI-CI n'est pas reconnu comme l'origine

Donc voir à ajouter comme capteur pour le controle.
Tu peux effectivement créé le Switch, mais il faut réappairer le récepteur.
Quand le Rfplayer émet il n'écoute pas en même temps !

[Doubledom45]

Slt..
J'ai repris un peu plus cette histoire d'envoie de code .
Le Rfplayer se sert de son adresse MAC pour modifier le code d'envoie. La réception ne bouge pas.( écris dans l'API)

Set the interface MAC address to unsigned long decimal 32 bits value.
Warning! Changing the MAC address is without effect on incoming RF Frames.
But changing the MAC address will modify the ID contained in outcoming RF Frames on most protocols.
Pairing between the dongle and actuators could be broken.
Each Dongle owns a different MAC address configured at the factory.
Examples :
SETMAC 123456765
SETMAC 0x2AB265C3
Specified MAC value is saved during shutdown

Pour l'instant je n'arrive pas à m'approcher du vrai code (en changeant la MAC), on dirait qu'il n'y a que les 2 octets BAS qui servent pour MAC dans la trame d'envoie corrigée ?

[racletteparty]

AFAIK chacon has 26-bit pairing id. rfplayer has 32-bit MAC address. so internally it's probably using only the 26 lowest bits

For now the automatic add feature picks up the first device profile in the list matching the incoming frame. Since chacon info type is very basic there is no way to detect if it's a switch or anything else. The default is to match a switch. But it's not a good idea since for actuators you need to first pair the device. I would have expected the rfplayer to filter out the frames from devices that are not paired, but seems it's not the case.

In addition to automatic add, it's possible to manually declare devices if the device is a receiver-only. When you click the "configure" button for the integration, there's a check box "Configure RF device manually" and then you can enter the procotol and address you want to add. It's not very user friendly but it should work for your chacon switch.

[racletteparty]

There is probably a better way to add devices manuallly since there is a dedicated button in the UI. I'll check how to simplify how to add switches

[racletteparty]

@Doubledom45 is it better with #15 ?

[racletteparty]

J'ai fais des tests avec des cdes Bp >16 Je ne les décode pas normalement en Hexa ou JSON Une erreur depuis le début ! des Add-on Pour un 24 (18 hexa) il le transforme en 7 ------ > 304C9E87 [87 9E 4C 30] Représentation RFXCOM --> C1327A:24 le BP en base 10 [ en x00 C1327A18 ] Pour un 62 (32 hexa) il le transforme en D ------ > 304C9E8D [8D 9E 4C 30] Représentation RFXCOM --> C1327A:62 le BP en base 10

Pour info j'ai deux Rfplayer et plusieurs RFXCOM pour faire les tests Le transcodage entre RFXCOM et Rfplayer se fait pour l' ID en ID -1 puis rotation circulaire gauche (2 fois)

D'après DIO l'adresse du module (association/pairing) est sur 26-bits. Ensuite il y a 2 bits pour on/off/all_on/all_off. Reste donc 4 bits pour le sous-identifiant de la cible (channel) soit 16 valeurs. Donc en théorie il ne peut pas y avoir de Bp > 16. Le besoin ici est de pouvoir extraire de l'ID info type 1 (qui contient l'adresse du module + le channel), l'ID à utiliser dans la commande rfplayer ON/OFF ID. Je suis parti du principe que ca correspond directement à un masque 0xF sur l'ID info type 1 étant donné que l'ID de la commande rfplayer est 0-255 dans la doc. Dans le cas de chacon, on serait limité à 0-16.

[Doubledom45]

Salut...
Moi je parlais de la façon que le Rfplayer envoie une commande avec un ID >256, il le transforme.
Tu ne peux donc pas, si tu as le sensor reproduire ce même switch ( comme une télécommande )
C'est une interdiction de copie initiée au début de la création par Ziblue , j'avais demander à GCE s'il pouvait lever cette interdiction , mais pas d'avancer ...
Le codage est refait avec l'adresse MAC ( les deux octets bas)

J'ai vu que tu essaye de faire avec la version de GCE @aohzan

[racletteparty]

En fait, le switch va correspondre à une prise chacon, et la télécommande sera vue comme un autre device plutot type sensor.
Si tu veux juste savoir ce qu'il se passe dans HA, il faut laisser l'appairage entre la télécommande et la prise. Le controle de la prise se fait en direct. Si tu veux que HA et la télécommande puissent tous les 2 controler la prise, il faut faire l'appairage de la prise avec le rfplayer et écrire un automatisme pour recopier la valeur de la télécommande (sensor HA) sur la prise (switch HA). Dans ce ca le controle de la prise est indirect car il passe par HA.

En fait, ces protocoles sont assez simplistes et les devices sont en général soit transmitter, soit receiver. La plus part du temps, il n'y a pas d'ack ni de retour/lecture d'état. C'est ce que HA appelle "assumed state". Donc ca n'est pas possible de connaitre l'état d'une prise autrement qu'en connaissant le dernier ordre envoyé.

Le mode "automatic add" ne permet que de détecter des transmitters comme des télécommandes ou des capteurs. Les actuators doivent être appairés et déclarés manuellement. Mais comme j'ai mis un menu spécial pour ca, ca devrait être pas trop compliqué. Une bonne amélioration serait de pouvoir faire l'appairage automatiquement au moment de l'ajout manuel.

[Doubledom45]

Salut.
De toute façon comme on a pas le controle du récepteur cela ne sera jamais une certitude de la commande, que ce soit d'un émetteur ou de HA.
J'avais bidouiller un récepteur pour qu'il renvoie une cde , lors du changement d'état, par un émetteur, mais cela devient une usine si plusieurs récepteurs à contrôler.
Le mode EDISIOFRAME en 868 renvoie une trame d'acquisition , ou on peu interroger l'état du récepteur .
Mais je pense plus facile de contrôler la charge du récepteur autrement .

Il faudrait voir avec @Aohzan ou @Patrick de GCE , si on peut modifier le Firmware pour lever l'interdiction de l'envoie d'un code réel > 256 ( sur les protocoles l'interdisant)

On peut tester la new version en relation avec GCE et @Aohzan , sur quel repos ?

Tu as besoin de frame des EDISIO que je contrôle ?
@Doubledom45

[racletteparty]

Il y a une PR ouverte sur le repo GCE avec mon code.
Dans le readme, j'ai mis un tableau avec la liste des profiles de device pour lesquels j'ai pu valider avec des trames provenant d'un vrai device. Si tu en as en plus de la température edisio, on peut en rajouter.
Pour l'instant, je n'ai pas écrit de test automatisé pour tester les trames de commande associées aux services ha.