Page 9 of 9

Re: X2D decoding attempt

Posted: Sunday 12 April 2020 0:49
by jcdemay
Finally, I can operate my home heater using a RfCat device. I don't know how, but I initially messed up the clock rate computation. It is actually 4870Hz. With the proper clock rate, I no longer have any issues with additional zeroes and every received frame is decoded smoothly. I've updated my draft to reflect this.

Hope it helps,

KR,
Jonathan.

Re: X2D decoding attempt

Posted: Wednesday 29 April 2020 10:19
by sev2000
jcdemay wrote: Sunday 05 April 2020 17:17 Hi guys,

For the same reasons as you, I also ended up reversing the X2D protocol and came up with similar results except that I don't seem to have a CRC in my frames. This is maybe because my remote controller model is quite old, 2008 at least. Anyway, here is a draft of my findings, maybe it will be of help to someone: http://offsec.online.fr/x2d/x2d_reverse.html

KR,
Jonathan.
Hello jcdemay,

I didn't ended reverse engineering. I succeed to go thru and I'm able to build my own frames with new zones up to 9 zones with CRC computation. I would like to have time to create an "how to" for coding/decoding frame.

If you want I can try to apply it to yours.

regards,

Re: X2D decoding attempt

Posted: Thursday 30 April 2020 16:13
by jcdemay
Hi sev2000,
jcdemay wrote:For the same reasons as you, I also ended up reversing the X2D protocol and came up with similar results
sev2000 wrote:I didn't ended reverse engineering
Il y a un "up" après "I ended", ce qui signifie, "j'ai fini par" (dans le sens "je me suis résolu à").

But in fact, you're right, I actually stopped reversing the x2d protocol because now I can successfully operate my home heater with 2 frames (it's a central heating device so I don't have to worry about things like zones) and I don't really need to understand the meaning of each bytes of those frames.
sev2000 wrote:If you want I can try to apply it to yours.
If you want to use my frames in your documentation about the X2D protocol, feel free to do so, they're all at the end of the draft I wrote. If you want me to capture some other frames, don't hesitate to ask me at jcdemay_at_gmail_dot_com.

Re: X2D decoding attempt

Posted: Wednesday 06 May 2020 9:15
by sev2000
Bonjour jedemay,

Ok if it's fine for you don't need to go further, I have already my frames and the one posted in the forum. Just note that both posts are wrong in the sense that the bit sequence is not truncated at the correct place and some bits should shifted. Anyway, even without understanding the content it's possible to reproduce the pattern and satisfy with that, not me.

I'll contact you by mail if needed.

thx

Re: X2D decoding attempt

Posted: Friday 08 May 2020 11:49
by jcdemay
sev2000 wrote:Just note that both posts are wrong in the sense that the bit sequence is not truncated at the correct place and some bits should shifted.
Well, I only have 1 transmitter and 1 receiver, no zone, just basic on/off of the central heating, so it is entirely possible that I got the splitting wrong (not too many frames to work with...).
sev2000 wrote:Anyway, even without understanding the content it's possible to reproduce the pattern and satisfy with that, not me.
Since I make sure my frame-forging code and my frame-dissecting code are the reverse of one another, it is entirely possible that I am forging valid frames from incorrect payloads if those incorrect payloads come from incorrectly-dissected but valid frames.

Well, you got me curious, I'll try to find the time to see if I can find a better way to split frames (I'll take a look a the pairing frames, that's something I've not considered so far)

Re: X2D decoding attempt

Posted: Sunday 10 May 2020 22:39
by jcdemay
@sev2000

The reason I chose to split the frame the way I did was because of the end of frame I got with every frame I captured (the red square in the following image) :
Image

Do you have that too ?

I originally assumed these bits must be part of the end-of-frame delimiter (and therefore, part of the end-of-last-message delimiter) but if I discard them, then the best way to split the frame changes but nonetheless works. I'll try to see if the messages produced by this new way of splitting the frame actually make more sense.

Re: X2D decoding attempt

Posted: Sunday 10 May 2020 23:26
by jcdemay
Forget what I said. I should have read the thread from the beginning, my bad. In the first page of the thread :
  • Poloalexis found the european patent 1160752B1 from Delta Dore where everything is described about the signal :
    • It's actually Biphase-M and not Biphase-S (not that it matters, there're basically the same albeit a bitwise NOT operation) ;
    • Extra 0's are inserted after 5 consecutive 1's (*that* matters, I just don't understand why since with Biphase-M there's no risk to lose clockrate synchronisation with many consecutive 1's) ;
  • Jimmy2cv found a jar file from Delta Dore that contains :
    • The checksum algorithm ((sum([int(x) for x in data[:-2]])^0xffff)+1 in Python) ;
    • The meaning behind the differents values in the frame ;
With that, I can also compute the checksum and verify that the message is valid. So thanks guys for this information :-)

Re: X2D decoding attempt

Posted: Wednesday 14 October 2020 15:03
by sev2000
jcdemay wrote: Sunday 10 May 2020 23:26 Forget what I said. I should have read the thread from the beginning, my bad. In the first page of the thread :
  • Poloalexis found the european patent 1160752B1 from Delta Dore where everything is described about the signal :
    • It's actually Biphase-M and not Biphase-S (not that it matters, there're basically the same albeit a bitwise NOT operation) ;
    • Extra 0's are inserted after 5 consecutive 1's (*that* matters, I just don't understand why since with Biphase-M there's no risk to lose clockrate synchronisation with many consecutive 1's) ;
  • Jimmy2cv found a jar file from Delta Dore that contains :
    • The checksum algorithm ((sum([int(x) for x in data[:-2]])^0xffff)+1 in Python) ;
    • The meaning behind the differents values in the frame ;
With that, I can also compute the checksum and verify that the message is valid. So thanks guys for this information :-)
Sorry I didn't see your messages. But if you finally succed to decode, it's fine. Everything is written in that thread, even false info.

Re: X2D decoding attempt

Posted: Wednesday 14 October 2020 15:07
by sev2000
I have posted a screeshot of an X2D_CPL/Internet gateway I did last year after having decoded the protocol :

https://community.jeedom.com/t/centrali ... que/6552/2

Re: X2D decoding attempt

Posted: Sunday 16 May 2021 3:42
by arturo
how are you.
Do you know if this protocol is similar to the RADIAL protocol? It is used in various measuring devices for water, gas, etc.
I need to decode it but I can't find much information, it's a French protocol.
Thanks!

Re: X2D decoding attempt

Posted: Wednesday 20 April 2022 16:41
by sev2000
arturo wrote: Sunday 16 May 2021 3:42 how are you.
Do you know if this protocol is similar to the RADIAL protocol? It is used in various measuring devices for water, gas, etc.
I need to decode it but I can't find much information, it's a French protocol.
Thanks!
Hello I can't find any clue on that. Do you have a link or a brand page to share?

Re: X2D decoding attempt

Posted: Monday 16 January 2023 19:36
by poloalexis
Hello all,

I am able to fully decode all x2d frames and map them to devices IDs
see my python script (attached) and focus on "class X2DDecoder" to understand the bit frame

the input of this script is "def Decode (self,width)" where width is a pulse (or gap) length in micro sec unit

I will port it to rtl_433 project (https://github.com/merbanan/rtl_433) by creating a BMC decoder and x2d protocol decoder

Re: X2D decoding attempt

Posted: Sunday 22 January 2023 14:10
by sev2000
Hi,

Interesting. I can recognise in your code the same Header description I took from a french documentation in internet. We may have used the same source.

Also I did the decoding mainly for heating system (not RF but CPL) and I don't see here the heaters command in your mapping, if you want I can share some info on these types.

Before playing with X2D I also did some decoding on Oregon, it's a good point to bring it in rtl_433.

Re: X2D decoding attempt

Posted: Thursday 16 February 2023 12:29
by blackhorn
Many thanks to everyone for this reversing. I'm currently trying to correctly implement/clean all the protocol decoding/encoding. I have now a really simple python code (inspired by @poloalexis one). But I still don't understand the association part. I have only one X2D device (Calybox) and I want to command it using CC1101 and ESP8266. I saw the captured frames from @SixK about association (I took me 2 hours to understand that i have do reencode the bytes in manchester in order to have the "raw signal"), but this is only one part of the association. Is there a way that somebody with multiple X2D devices to do a capture of the all association part, even better, of multiple assocations/devices?

Here the WIP code: diorcety/X2D on github

Re: X2D decoding attempt

Posted: Sunday 12 March 2023 19:07
by blackhorn
I finally manage to work a kind of API in order to encode/decode x2d frame on c and on python. I will create the esphome application and provide all the code on the repository.
I updated the repository with the code, I can now monitor status and set order on my 3 zones.
The missing part is the way to do request on metering and temperature for example, all the structure/api can allow that but I didn't sucessfully manage to request them.

Re: X2D decoding attempt

Posted: Sunday 03 September 2023 10:39
by mikelelere
Do any of you guys still have the software CD that came with the mydomokit USB dongle? I've bought one secondhand without the CD, and it cannot be found anywhere online. Thanks in advance