TFA 30.3233.01 support

[Fietspomp86]

Hi guys,

I have a new rain-sensor, the TFA 30.3233.01.
Website:

Could I please get some guidance how-to add this?
I tried capturing the raw packages but I didn't succeed.
Running a Pi3 with an RTL dongle.
I see plenty of sensors from the neighbours to it's working.
Just need some help with this new sensor.

[zuckschwerdt]

Capturing the signal is indeed the first step.

• Use -S all to capture a few packets, then read them back with -r mode and sort out the known ones (or maybe use -S unknown).
• Verify the samples visually with http://triq.net/iqs
• Use -A mode to get an idea what's in the samples.

Post your findings and upload a zip with some samples known to be from the device.
A good way to only capture that device is to remove the antenna and place the device about 10 cm from the recevier.

[Fietspomp86]

I did as you suggested, placed the device very close to the pi, removed antenna of the dongle.
I believe I caught something, but I'm no expert.
Without the device near the dongle I tried to scan and found nothing, so I guess it's really only the rainmeter which was in range.

RTL-433.zip

[zuckschwerdt]

It is always good to add some length of USB cable between the Raspi and the dongle. Plugged directly into the ports it will get noticable noise.

[Fietspomp86]

Ok, I used an extension USB cable and tried again.
Here's the sample zip:
sample.rain.zip

[mhaas]

Hi @Fietspomp86, I am also looking into this device! I have many samples and some idea how to decode. I will keep you posted.

[mhaas]

Hi all,

I gathered some samples and loaded one into sigrok. It seems that the signal has a period of 750us. At the beginning of a period, a pulse is sent at either 250us or 500us length.

The sensor sends the same message 6 times. At the beginning of each message, two sync pulses are sent: 750us high, 750us low, 750us high, 750us low. Note that the screenshot shows the beginning of the very first message, where only one sync pulse (750us hgh, 750us low) is sent.

@zuckschwerdt Does this analysis make sense to you?

The modulation seems to be PWM. Given this data, the following flex decoder:

rtl_433 \
      -X 'name=tfa_drop,modulation=OOK_PWM,short=255,long=510,reset=2500,gap=1300,sync=750,bits=66'

produces output:

{
  "time": "2019-12-31 12:26:13",
  "model": "tfa_drop",
  "count": 6,
  "num_rows": 7,
  "rows": [
    {
      "len": 1,
      "data": "8"
    },
    {
      "len": 66,
      "data": "c65d54ff09550047c"
    },
    {
      "len": 66,
      "data": "c65d54ff085500dc4"
    },
    {
      "len": 66,
      "data": "c65d54ff085500dc4"
    },
    {
      "len": 66,
      "data": "c65d54ff085500dc4"
    },
    {
      "len": 66,
      "data": "c65d54ff085500dc4"
    },
    {
      "len": 66,
      "data": "c65d54ff085500dc4"
    }
  ],
  "codes": [
    "{1}8",
    "{66}c65d54ff09550047c",
    "{66}c65d54ff085500dc4",
    "{66}c65d54ff085500dc4",
    "{66}c65d54ff085500dc4",
    "{66}c65d54ff085500dc4",
    "{66}c65d54ff085500dc4"
  ]
}

Note that the first row of len 1 is an artifact of the first sync pulse.

I have already gathered many samples, including a nice rain simulation by putting the sensor under a running sink for an hour or so. I find it most intuitive to look at the data at the crumble level (two crumbles are one nibble).

Here is a histogram:

This shows the relative freqencies of each crumble value at a given index in the data. Note that I am adding a padding of a 0 nibble on the right.

What is immediately obvious here is that the first three bytes (crumbles 0 to 11) are always identical. This is the device ID - it changes after a battery reset. The histogram above was generated from just one run, so the ID is the same.

From looking at the data itself, I know that crumbles 16-19 form the LSB of the rain counter. The data is not entirely clean. I assume some sort of transformation has to be applied - but looking at the bits as they change, it is clear that lower bits roll over and higher bits increase.

Interestingly, after 8 tips of the rocker, crumbles 16, 17 and 24-27 flip from 00 to 11. So 24-27 also seem to be related to the rain counter, which would give us 8 crumbles or 2 bytes to encode the rain data.

I will investigate a bit more. It seems that I need to XOR crumbles 18 and 19 with 0111 to get sensible data, but I don't know what to do with the other bits.

[zuckschwerdt]

The analysis on crumbles and the histogram is great. I have an old half-finished tool to detect change frequency, roll-over and similar. But it was a rabbit hole. It seemed I always needed to add too many assumptions. Better to just show a picture and squint your eyes ;)

The unexpected double bit flip might be a parity bit. Some protocols have 7-to-8 encoding.

[mhaas]

@zuckschwerdt Well, I have a script which dumps only the changed crumbles. High-entropy columns are bold, low-entropy columns are light. Sadly, the output does not transport very well except as a screenshot.

The leftmost column here is the number of tips of the rocker which 0000 being the initial state and 0001 the first tip. Note that some values are duplicated.

It is easy to see that crumble 19 changes often, then crumble 18. It also seems obvious that 00 is the highest possible value, after which the next significant bit increases. 11 is then the value after rollover, so likely the smallest possible value. This seems to hold true for both crumble 18 and 19.

I am still confued by what's happening after 0009 - and why the initial state at 0000 does not seem to correspondly nicely to something zero-ish.

I was also looking at BCD, but that does not seem to be case. Perhaps some gray code or hamming code. I will check later.

I also have some more data for 50, 75 and 100:

[zuckschwerdt]

If I read that right and 00 is assumed to be the biggest and 11 the smallest value that might indicate the bits are flipped? Though I guess you already looked into that.
There is one other decoder that does not roll over a counter to zero. IIRC it divides by a large factor and keeps the remainder.

[mhaas]

I think I got it. You were right about flipping the bits. The missing transformation is the addition of 10 (as in, ten). This is somewhat obvious in the bitbench (cool tool, btw!) after inverting: Bitbench

Basically, zero is at 65526 - 9 is at 65535, and thus 10 (ten) must be at 0.

The following python code implement this transformation:

def simple_decoder(input_data) -> int:
    rain_a = input_data.get_byte_at_index(4)
    lower = (rain_a.as_int() ^ 0xff)
    rain_b = input_data.get_byte_at_index(6)
    higher = rain_b.as_int() ^ 0xff

    value = (higher << 8) + lower

    value = value + 10
    value = value & 0xffff

    return value

I will make a PR with this. Now I need to figure out two more things: the bit for low battery and the parity/checksum. Basically, I have 5 bytes out of 8.5 figured out by now.

@zuckschwerdt Given that I have to invert bytes 4 and 6, it is reasonable to assume that I have to invert the entire stream?

edit:

Looks like the "low battery" bit is bit 24, i.e. first bit after the ID: bitbench

[mhaas]

@Fietspomp86 Can you try this code? #1255

[Fietspomp86]

@Fietspomp86 Can you try this code? #1255

Hmm, it seems my rainmeter has died on me.
It won't show any figures, also not on the display....
Guess I'll send it back to the shop. Sorry guys!

[mhaas]

@Fietspomp86 Maybe you can also try to reset the batteries - maybe the devices lost sync.

[mhaas]

I did some work on the checksum today

I noticed some interesting behavior: the sensor will repeatedly submit identical data with increasing transmission counter bits. Once the transmission counter rolls over, byte 7 is identical to previous transmissions with identical rain counter and transmission counter bits.

I assume now that byte 7 is indeed the checksum.

I already tried several approaches: reveng, xor of values, sum of values, two's complement etc. Nothing worked. I also tried leaving out the first nibble, as it is a fixed for all device IDs - no luck.

I should note that the checksum is different for identical rain and transmission counter values across different device IDs (e.g. after battery reset).

One interesting thing: the last bit of byte 7 determines the value of the first bit of byte 8: they will be identical.

I have prepared several bitbenches with different device ids:

• 1
• 2
• 3

@zuckschwerdt Any idea how I can proceed with the checksum?