BRESSER 8 Channel Thermo-/Hygro-Sensor (variant of efth800?)

[andrewjw]

Hi,

I have some Bresser 8 channel thermo/hydro sensors (link) which I'm struggling to receive. I very occasionally receive them as efth800s, but mostly they are not detected.

I have captured some signals, which when I decode them seem to be four packets in a ABAB format. I'm not sure what A is, but B is a valid efth800 packet.

cu8 files.zip

Here's a link to a decoding of one of them.

Perhaps I'm doing something wrong, but is this a variant of the efth800? Please let me know if there's anything I can do to help get these decoded. I could start hacking at the existing decoder, but I wanted to get a steer that that is the right approach first.

Many thanks, Andrew

[zuckschwerdt]

Yes that looks very much like the EFTH800 signal. The raw data here is

2B 1E A9 90 AB D3 83 2A 80
AB 1F B3 B7 B6 BE 80
2B 1E A9 90 AB D3 83 2A 80
AB 1F B3 B7 B6 BE 8

which the decoder sees as

{1}8, {65}d4e1566f542c7cd50, {49}54e04c4849410, {65}d4e1566f542c7cd50, {49}54e04c4849410

I guess the bitbuffer_find_repeated_row(bitbuffer, 2, 48); and the check if (bitbuffer->bits_per_row[row] > 49) are the problem here. https://github.com/merbanan/rtl_433/blob/dc95819b3d59aa73ebd59d6e38f1df5cec8e3500/src/devices/efth800.c#L48-L54

[andrewjw]

It seems that the problem is the first packet is 65 bits, so it returns that, when we want the second packet. I could add an optional max_bits parameter to bitbuffer_find_repeated_row so it only returns packets that are 48 or 49 bits long, and therefore will pick up the second packet. Does this make sense?

I guess it would be nice to also decode the first packet, but I have no idea how to start with that, so I guess it's a separate problem. All the data I would expect is in the second packet.

Andrew

[merbanan]

if (bitbuffer->bits_per_row[row] > 49) // 48 bits per row?
    return DECODE_ABORT_LENGTH;

That check needs extra logic. As there is a crc in the message I think we are safe to in this case increase the row value by 1 and then just continue. We should check this row is of proper length.

[merbanan]

It seems that the problem is the first packet is 65 bits, so it returns that, when we want the second packet. I could add an optional max_bits parameter to bitbuffer_find_repeated_row so it only returns packets that are 48 or 49 bits long, and therefore will pick up the second packet. Does this make sense?

That wont work. We just need to make sure that we pick the correct row we want.

[andrewjw]

I've opened a couple of pull requests that add support for these messages. The tests pass, but I haven't run it for real yet. I'll give that a try and report back. Happy to get feedback on the change in the meantime though.

[andrewjw]

I've tried running by initial change and unfortunately it's not picking up anything. Strange, when the test data was saved, and the tests pass. I will have to do some further investigation.

[andrewjw]

It turns out that it wasn't picking up the data because I was using 300k as the sample rate, switching to 250k works perfectly. I've now managed to fiddle the frequency I was using to pick up all my devices with a 250k rate. I'm not sure if this is a problem or not, I don't really understand how sample rate and frequency affect things.

I've committed an updated change based on your suggestion. I'll leave it running to make sure it remains stable.

[andrewjw]

@zuckschwerdt Here is a short dump of the full packet data from these sensors. I have four, channels 2, 4, 5 & 6. Can you let me know if this format is ok? If so I'll capture a longer period of time with a bigger temperature range next week.

efth800_data.txt

I realised that these devices have an RCC Button (Initialise the Radio Controlled Clock signal) (device manual. They don't have a screen of any kind, and looking at the long packet I think it may contain this clock data. Do you know of any standards in this area that might help us decode this?

[zuckschwerdt]

Yes, that log looks good. We have some devices with "radio_clock", I would expect much longer packets and maybe BCD encoded data -- usually the signals have around 60 bits (a full encoding per minute).

[andrewjw]

Here are two files. The long one covers several days, and the new year. The shorter one is about a day - soon after that started I pressed the RCC button on all my devices, to see if that caused the data to change.

I have come across a manual for what I'm pretty sure if the same device, just with different branding. I'm pretty convinced this extra packet is the clock data. Link The key section is:

• Press the RCC button (2) once to initiate the search for the DCF time signal manually.
Synchronisation with the DCF time is executed automatically by the
sensor every day at 2 am and 5 pm. This is sufficient to keep the time
accurate to within one second per day.

I don't have the associated base station to check, but I'm in the UK so should be able to receive the DCF77 signal.

efth800_rccreset.txt efth800_long.txt

[andrewjw]

I forgot to mention that I added the number of seconds since the first message was received as the first value, in case that's useful for decoding the clock.

[zuckschwerdt]

Very nice, looks like some counters in there indeed. I'll try to figure out where the date/time bits are and in what order.

[zuckschwerdt]

Starting to give a pattern: ?1b CH:3d ID:12d 2b H?6d 2b M:6d 2b S:6d Y?7d D:5d M:4d CHK?8h 1x (invert the input data) The first two bytes are a the known Channel+ID (ID is +1 to the other packet). Then we have hours, minutes, and seconds clearly visible (not sure what each top 2 bits encode though). Then follows year, day, month (7, 5, 4 bit) Last byte then is a checksum (CRC-8 poly 0x31 init 0x00).

Can you confirm this with a few spot checks? Decode should be easy then ;)

[andrewjw]

I've confirmed that pattern appears to work - hard to check the seconds are correct, but the rest of the values are fine and they're in range, so I presume so. I've created a pull request for the decoder #2331.

[andrewjw]

I realised that I can compare the time the message is received, to the radio clock value, and the seconds are correct. Two devices are spot on, one is one second out and the other two.

[gdt]

@andrewjw What's the status? Some of your PRs have been merged. Does git master work with this, or is more needed? I'd like to get the issue either closed or such that someone reading knows what remains.

[andrewjw]

I've been running my fork for months with no problems. I've just resynced with master, and that works fine too, so this ticket can be closed.