I realise this is quite an old thread, at least in parts. I have a
luaradio decoder for extracting x2d frames from the transmissions of a Delta Dore Tybox 33 (boiler thermostat), though I've really only got as far as making the checksum work and haven't yet discovered what the data bytes mean
It's at
https://github.com/telent/luaradio/ and accepts IQ data, which I have captured with rtl_433
Refer in particular to
https://github.com/telent/luaradio/blob ... g-dore.lua for the overall structure, and to
https://github.com/telent/luaradio/blob ... ecoder.lua for the frame decoding.
Some observations for this particular hardware, most of which are consistent with the findings of at least one previous poster
- it's biphase mark coding, not manchester
- after biphase mark decoding , the packet preamble is 0,0,0,0 (may be longer, I only look for four)
- frames start with 111110
- frames end with 1,1,1,1,1,1,1,1,0
- in the body of a frame, 111110 needs to be replaced with 11111
- in the body of a frame, bits are transmitted in lsb order (e.g. 48 appears as 000011, not 110000)
- the final two bytes of a frame are the checksum, which is given by bitwise xor of (sum(payload) - 1) with 0xffff. Yes, this is exactly what poloalexis
said it would be ,
Some captured decoded data for you:
Code: Select all
[nix-shell:~/src/luaradio]$ cat /tmp/*json |grep payload |sort |uniq
{"payload":[136,66,0,1,5,144,12,0],"checksumValid":true}
{"payload":[136,66,0,1,5,144,2,0],"checksumValid":true}
{"payload":[136,66,0,1,5,144,2,3],"checksumValid":true}
{"payload":[136,66,0,1,5,144,2,5],"checksumValid":true}
{"payload":[188,187,72,1,5,144,1,0],"checksumValid":true}
{"payload":[188,187,72,1,5,144,1,3],"checksumValid":true}
{"payload":[188,187,72,1,5,144,1,5],"checksumValid":true}
{"payload":[188,187,72,1,5,144,2,0],"checksumValid":true}
{"payload":[188,187,72,1,5,144,2,3],"checksumValid":true}
{"payload":[188,187,72,1,5,144,2,5],"checksumValid":true}
I can't make a whole lot of sense of this yet, but:
- 1,5,144 are consistent in every single message - maybe that's sender/receiver/transmitter IDs? as far as I know, I have only one transmitter and one receiver
- if two of these bytes are supposed to be for the "house" id, apparently I'm controlling two houses? I didn't configure this initially, I left that to the engineer who fitted the boiler. I suppose it's not impossible he did the association twice and it's remembered both?
- all of these messages were received at times when I switched between comfort/reduced/anti-frost settings on the thermostat, but sadly I have now lost my notes which told me which messages were which scenario. I'll do some more captures later tonight and then update the thread again