Add support for DeltaDore X3D

[mr-sven]

The Payload is not fully clear due the fact I have only thermostat's and switch actors.

[zuckschwerdt]

Looks really good at a quick glance, thanks! (and I did laugh at the length thing and "data from previous larger messages")

[mr-sven]

At the moment I've no more additional info, I'm working on decoding the messages. I'll continue on this if I have more valid infos.

[mr-sven]

I now added most of the known protocol, for my point of view it's done and can be merged

[mr-sven]

Waiting for merge

[zuckschwerdt]

It seems some output keys are missing from output_fields, e.g. temperature_type, can you check that?
And the doc-comment should start (line 11) with /** @fn int deltadore_x3d_decode(r_device *decoder, bitbuffer_t *bitbuffer) to properly attach to the decoder function.
Otherwise good for merge.

[zuckschwerdt]

Thanks! I just noticed the // NOLINT (why?): there is a recent addition to the data output, you should be able to just use something like
data = data_hex(data, "raw_msg", "Raw Message", NULL, &frame[bytes_read], len - bytes_read - 2, raw_str);
(rename raw_data to raw_str and raw to raw_msg)

[mr-sven]

I don't know where that NOLINT came from, maybe c&p.

[zuckschwerdt]

I've refactored the CCITT data whitening to bit_util.c with 11d2c7a. Can you check it still works, and do we have any test samples?

[mr-sven]

Is working, added a valid sample: #3116

[zuckschwerdt]

Great, thanks!
I should have said: "sample files", i.e. a .cu8 capture for regression tests. But a code sample is useful too.
Using rtl_433 -y aaaaaaaa8169967ede78db58b8f7f836575bd3940e71ed2636425a2bb7b05cf1e79aeb45fd2d53 I get a CRC error though?

[mr-sven]

ah, yes, I removed CRC from that data because I also modified the device id, so this data was only for ccitt tests.
I've a capture file, ahm should I upload it here or put it in any folder?

[mr-sven]

Ah, I've seen the tests repo, I will make an pull request

[zuckschwerdt]

If you are concerned about real device ids leaking then hold off, it's a valid concern.

[mr-sven]

Here merbanan/rtl_433_tests#472 .

[zuckschwerdt]

Thanks! Is that a manual recording (e.g. -w filename.cu8) or an automatic sample capture (e.g.-S all)? It seems like an automatic capture but I've never seen an automatic sample that long, nearly a whole second and full 15 sample buffers long. Interesting!

[mr-sven]

I used rtl_433 -f 868.95M -R 269 -S known and triggered an register read. The protocol is very complex and there is still some guessed data left. If you are interested in you can take a look in my X3D controller repo https://github.com/mr-sven/x3d-rfm-esp32/blob/main/X3D-Protocol.md