X2D decoding attempt

[SixK]

@mikelelere,

Yes forgot about this MSB coding.

Converting my data from LSB to MSB give me the beginning of my data near to thoses of ervplecter (but probably far from those of poloalexis ?)

Several pattern are common with ervplecter datas, comparison is interesting.

All my data are available here :

analyse_log1.zip

(46.82 KiB) Downloaded 97 times

SixK

[ervplecter]

It's been a while since I've visited the forums and I'm *so* glad other people are tackling this decoding project. On my end it's been pushed to the backburner due to the house work and job, I've never totally had the time to play with the USB dongle from Mydomokit.

RE. my original logs, I have no idea if they've been properly decoded (manchester etc). I think that the modem (USB serial => 868 MHz) indeed adds some of the data or at least does the job for the manchester splitting.

The first step (and initial inquiry from SixK when he contacted me recently) is to have a stable packet receiver with proper byte outputs. I've love to see that set in stone, great work from all of you guys. I hope I can start again working on this, 2015 was to the roof (thank you SW ep 7 ).

[SixK]

Well, data i've got doesn't come from my CC1101 device, but from my dvb key.
Actually I only get noise with my RFbee (CC1101) device.
I doubt i'll be able to get anything with the rfbee since Texas Instrument added a note about cc1101 and OOK (dn022 if i have a good memory) saying that cc1101 is quite unstable and difficult to exploit with this modulation.

There are some particular parameters to set to have better stabilité, but it actually give nothing.

Sad because finally we only have to duplicate data we get to be able to command heaters without the official device.

SixK

[ervplecter]

I can't recall fully as it's been a while, but I *think* I was able to get those data from both my CC1101 (with arduino) and with the tap in my delta dore unit, that's how I've compared the logs. It's been further confirmed with the few test I've made with the USB dongle.

my issue was handling properly the data as a packet from the CC. I stopped there. For my first tests, I don't remember what I was doing, possibly decoding straight out of the demo of the CC1101, then I tried to move to packet handling and that never worked, the byte don't accumulate properly to form a packet, possibly because the packet is too long.
It's possible "ok", i might need to build up a packet forge using an arduino instead of using the onboard packet handler of the CC, I don't know. I have to catch up first with what has been tested in that thread and test more with the mydomokit dongle.

[poloalexis]

Hi,


At the transimitter side I plugged a pin of an oscilloscope on the rfPI12F675HC of the Deltadore device (door contact):
1- A message always start with 5 x (LowLongPulse + HighLongPulse): __==__==__==__==__==
2 -Then you have 6 x (LowShortPulse + HighShortPulse) + 1 LowLongPulse: _=_=_=_=_=_=__
3- A frame
4- At the end of this frame you have 14 x (LowShortPulse + HighShortPulse) + 1 LowLongPulse, but I am not 100% sure
5- then rules 2-3-4 are repeated a cuple of times
6- End of Message ? I use RF timeout for now.


From the receiver side do not expect to receive exactly the number of pulses defined by rule 1 but only some of those pulses. Rule 1 is used by the receiver to lock the RF.

From Rule 2, I have deducted the clock (4800Hz): [ short pulse low + short pulse high = 210us ] and [ long pulse low+long pulse high = 420us ]

I have validated the biphase mark code by decoding the device ID: it matches the device ID given by the Deltadore panel I use to control my alarm.
This decoding also validate that LSB are transmitted first.

Here is a Raw sample I receive from my system (biphase mark code on door contact open, deltadore given id is 0x16414):

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 0,
lsb - - msb
0, 0, 1, 0, = 4
1, 0, 0, 0, = 1 => 0x14

0, 0, 1, 0, = 4
0, 1, 1, 0, = 6 => 0x64

1, 0, 0, 1, = 9 => from my experience with all of my sensors, only keep the first 3 bits => 0x1
0, 1, 1, 0, = 6 | type = arrby2[4] & 63; = 0x69 and 0x3F = 41d => Perimetric Contact

1, 0, 0, 0, = 1
0, 0, 0, 0, = 0 => 0x01

1, 0, 0, 0, = 1
0, 0, 1, 0, = 4 => 0x41 | open if arrby2[6] & 64 == 64. Here 0x41 and 0x40 = 0x40 => open

0, 0, 0, 0, = 0
0, 0, 0, 1, = 8 => 0x80

0, 1, 1, 1, = e
1, 1, 0, 1 ,1 = f (remove the extra 0 thanks to Deltadore magic rule, without this rule I was not able to get the crc)

1, 0, 1, 1, = d
1, 0, 1, 0, = 5 | crc = 0xfe5d = not(0x14+0x64+0x69+0x01+0x41+0x80)+1

1, 1, 1, 1,
1, 1, 1, 1, 0 | end of frame (? still to be defined)

I still I have to do some test on my alarm controler device (2 buttons and 4 buttons remotes): this one should use the rolling code as defined by DeltaDore

[SixK]

@poloalexis,

OK, we don't study exactly the same device type. (We are looking Heaters device, while you are looking Alarm device)

At least we have the same start : 5 Long pulse + 6 short pulse.

I'm not sure that frames are starting right after Preamble+Sync (5 Long pulse + 6 short pulse --> Words 1 and 2).
With Heaters, from Words 3 to 9, values are exactly the same between Eco and Comfort state, so I would say, we have the following structure :
#Champ Adresse Maison 2 octets 0 à FFFFh => House adress => Words 3 + 4 (same value for my 3 areas)
#Champ Adresse Source 1 octet 0 à FFh => Source adress => Word 5 (same value for my 3 Area)
#Champ Adresse Destinataire 1 octet 0 à FFh => Receiver adress =>Word 6 (1 value for each area)
#Champ Adresse Transmetteur 1 octet 0 à FFh => Sender adress => Word 7 (same value for 2 areas and 1 area different ?) ?
Words 8 and 9 I have no idea, but I have 1 value for each areas

Then I would say we have 5 sub frames of 12 Words long, I'm not sure about the right start, but I would say Word 10. (no idea why X2D need 5 frames to command a heater, but why not ?

Then From Words 70 to 73 probably something like CRC (dunno exactly how many Words are used for CRC ? 4, 2 or 1 ?)

Word 74 is always 0 here, so I would say the End Tag.

I should try to decode as bi-phase mark and see if we have interesting values.

For Heaters, we have 2 different messages at about 2ms interval, repeated only once about 1 second later.

SixK

[SixK]

An information I just found here :
https://tel.archives-ouvertes.fr/tel-00738342/document

X2D protocol have a different frame per device class.
For a Door opener sensor (don't know the exact name in english for "detecteur d'ouveture de porte"), it only has 2 variables :
Door state and Energy source status.

You already found the door state variable, but you probably have the Energy source status somewhere.
If it works with battery, you should try with fully charged battery and discharged battery to see what change in frame.

SixK

[SixK]

I'm trying another approach, I'll try to send data with my RFbee and compare to Deltia device.

I'll use the following tools :
- SDRSharp and the waterfall graph to set the right frequency and verify Baudrate
- Baudline - to analyse frequency, timings, signal
- RTL_433 - to analyse data seen by my DVB Key

Actually using SDRSharp, I can say that my RFbee is at the same frequency as my Deltia device when using the following parameters :
#define CC1101_DEFVAL_FREQ2_868 0x21 // Frequency Control Word, High Byte
#define CC1101_DEFVAL_FREQ1_868 0x65 // Frequency Control Word, Middle Byte
#define CC1101_DEFVAL_FREQ0_868 0xC4 // Frequency Control Word, Low Byte
--> 868.335571 Mhz

When sending data, I have problem with the FIFO 64 bits limit, I have to find an example showing how to exceed this limit.

SixK

[SixK]

Hey guys,

Incredible, I can switch my Heater from Moon to Sun with a piece of code that should not work !
I send two 37 bytes packets with LSB values I catched with RTL_433.
I only send 1rst 74 bytes message, not the second one that is usually sent by Deltia.

I can't verify right now, but I should have packet size before payload for each packets I send, and data should be seen as 2 packets, not a single one, but my heater switch

I tried to switch back from Sun to Moon, but it doesn't work with the same method.

I freeze the code right now, to make it available. Then I'll try to go further.

cc1101-ook-master.zip

(48.22 KiB) Downloaded 143 times

Here is my actual source. As already said, it should not work I'm sending as variable packet length and data size is added before payload, but it works with my heater to go from Moon to Sun state.
To use it, first compile rtl_433 (address provided in an earlier post by someone else).
Catch data sent by your deltia or any heater command device with a DVB TV key.
You can use the following command :
./rtl_433 -A -D -f 868340000

Then replace my binary values by your binary values in .ino file(hexa should work too if 0x is added before value).
Only 1rst message sent by Deltia is necessary, the second one seem's necessary.

-- Update --
As I was suspecting, sending only 37 first bytes of the message seem's to be enought !
I will try to reduce message size to the maximum, this should give good indications on message structure.
Still working with 25 first bytes
Still Ok with 20 first bytes.
KO with 13 bytes.
OK with 16.
OK with 15.
And OK with 14 bytes !!

So possible conclusion, we only need 14 bytes to go from Moon to Sun.
It's probably not as simple as this, since going from Sun to Moon doesn't work.

I will now try to verify this assumption with my others area.

Switching from Sun to Moon is working too ! I only had to move 2 bits.

Last time I was Switching from Moon to Sun and 10 seconds later from Sun to Moon, but it was not working.
Dunno if I made a mistake or if I have to wait a certain amount of time before switching back ? Will do more tests later.

Area2 switched from Moon to Sun ! About 6 meters from emitter.
And switched back from Sun to Moon.


Area1 don't switch.

SixK

[ervplecter]

awesome work ! I'm going to port this to my own setup (arduino + CC1101), it's interesting to see if at least we can get it to work and not be stuck with rolling codes.

Regarding the other part of the packet, 2 things I've observed :
- the repeated packet is safety, and though their standard mentions it, the repeat / duplicate can probably be avoided.
- when I change manually one area, it seems it updates also the other area (sets them in same state as they are but I can see the receivers are updated). So your full message could actually get the states for other heaters or areas in it and that explains why you can shorten the message to update only one heater.

To confirm, do your have the same kind of area unit as I have ?

thanks again for sharing !

[SixK]

@ervplecter,

Here are my units :
Deltia 8.33 as emitter
Deltia 1.03 as receiver. (7 devices ==> 4 on Area 1, 2 on Area 2, 1 on Area 3)

Don't forget, you need to send LSB data, not MSB as you actually already catched.

The easiest way is probably to catch data with RTL_433 + a DVB Key.
I could try to compile it for Windows if someone need it.

Note that I only succeed with Area 2 and 3, but It still don't work for Area 1.
I will need to do a proper code to send the entire message. (I tried with 59 first bytes but it didn't worked)

SixK

[SixK]

Damn me ! Area 1 was working too with only 14 first messsage bytes !
I was doing this :
data.data[0] =01010101;
instead of :
data.data[0] = 0b01010101;

Ok corrected now...

Next step, I'll try to command heaters using Serial messages like "Sun 1" for area 1.
I'll remove unused files too.

SixK

[SixK]

Played few minutes with Heater Area Assocation.
Associate a new Heater with an Area is probably not difficult.

It seem's we only have to send 13 first bytes of Association message. (not tested yet)

I'll try to add this functionnality.


I had a look at Deltia 8.33 documentation, it seem's it can send data to Alarm device and handle opened window status.
This may explain why Messages are 74 bytes long.

I'll try to publish my source code on github this week.

SixK

[Lucas]

Hi,

I must say that I don't understand much of what you are doing, but being the owner of a X2D-based installation, I'm really looking forward to being able to control it using a raspberry pi!

Awesome work, really!

[SixK]

Added my sources to github :
https://github.com/SixK/CC1101-X2D-Heaters

@Lucas,
You will need at least a RFBee + UartSBee + a DVB key (RTL-SDR compatible) to be able to control your heaters with a Raspberry pi. (maybe DFRobot Leonardo&Xbee arduino will be necessary too but it should not)

Then a small python script should be able to send serial commands I have added in my Arduino Sketch like
Sun1 --> to switch from Moon to Sun on Area 1

I'll try to do this python script later.

To avoid data capture step with the DVB Key + RTL_433 software, I'll have to see if we can create our own messages and associate Heaters with what could be called a virtual Deltia Emitter Device

SixK

[jimmy2cv]

Hi,

I continue my search about the protocol x2D and I find a little box with a web server integrated and managing the protocol x2D and x3D.
The update contains all library about these protocoles but compiled.
The archive is in this link : https://www.well-box.fr/telechargements ... _05.00.zip
I extract the x2D library in the attach file.

Who can do a retro-engenering of this library ?

Regards

Jimmy

[SixK]

Hi jimmy2cv,

I decompiled binaries quickly, but I'm not an Assembler expert.
I would have been glad to see a function name talking about Manchester or Bi-phase mark, but there is none, only something like MESSAGE_RECEIVER and MESSAGE_TRANSMITTER.

Binary (.so) size is quite small, this lead me to this thought, interesting functions are probably not here, but probably in transmitter device itself or in a uC (Atmel or something else) controlling the transmitter.

I found nothing that could be exploited, But I might be wrong since I'm not really ASM friendly.

SixK

[SixK]

Did few modifications in github sources :
- Removed uneeded delays
- Added Area Association support (untested yet)
- Added a simple python script to send commands to RFbee. (can be used like this : python pyX2DCmd.py Sun3)

SixK

[SixK]

Tested Area Association.
It works

OK, now it would be interesting to see if we can create our own messages.
This would avoid the message capture step with DVB-T Stick.

SixK

[marcelr]

Who can do a retro-engenering of this library ?

Attached (I don't have X2D equipment, but I like what you do ... )

grtz,

marcelr