Add Alecto WS-1200 support

[untergasser]

Hi,
with having the Alecto WS-1200 data at
https://github.com/merbanan/rtl_433_tests/tree/master/tests/alecto_ws_1200
would it be possible to add to crtl_433?

I would suggest to decode all 3 possible signals:

1. Version 1.0:
   rtl_433 -X 'n=Alecto-WS-1200-v1.0,m=OOK_PWM,s=450,l=1450,r=37000,g=1100,t=400'
   {63} fe 72 25 0a 00 01 fe 20
   PRE: 7b Type: 4b ID: 8h BATTERY: 1b ?:1b T: 10d R:<16d ?: 8h CRC: 8h
   Type must be 0011
   Temp value must be (value - 400) / 10
   Rain must be value * 0.3

Output could be:
Model: Alecto WS-1200 v1.0
ID: hex
Battery: OK
Checksum: OK
Temperature: xx.x C
Rainfall: xxx.x mm

2. Version 2.0 sensor data:
   [00] {95} fe 78 84 da 00 01 ff d5 a8 69 d3 10
   PRE: 7b Type: 4b ID: 8b BATTERY: 1b ?:1b T: 10d R:<16d ?: 8h CRC: 8h MAC: 8h DATEKEY: 24h
   Type must be 0011
   Temp value must be (value - 400) / 10
   Rain must be value * 0.3
   The Date Part I would give as hex string

Output could be:
Model: Alecto WS-1200 v2.0
ID: hex
Battery: OK
Checksum: OK
Temperature: xx.x C
Rainfall: xxx.x mm
Date Key: hex

2. Version 2.0 time data:
   [00] {95} fe a5 88 20 32 02 02 0c 46 8d bb 1a
   PRE: 7b Type: 8b ID: 8b BATT: 1b ?: 1b ?: ??: 6b YY: 4d YY:4d MM: 4d MM: 4d DD: 4d DD: 4d HH: 4d HH: 4d MM: 4d MM: 4d SS: 4d SS: 4d ? 16b
   Type must be 01010010
   The time is assembled from single digits.
   I would also give the last 24 as hex as Date Key, it is sent in the how to install? #2 Signals.

Output could be:
Model: Alecto WS-1200 v2.0
ID: hex
Battery: OK
Checksum: OK
Date: 14.02.2019
Time: 02:45:36
Date Key: hex

There is more information in the readme in the folders:
https://github.com/merbanan/rtl_433_tests/tree/master/tests/alecto_ws_1200

I fail implementing it myself, as it is hard to see were to add the information. I assume that once added, I could do maintenance and enhancements like summer time on my own.

Thank you for considering this enhancement!

Best,

Andreas

[curlyel]

Thanks Andreas for raising this and providing the test data. As I said yet - I'm keen on having them supported too :-)

I fail implementing it myself, as it is hard to see were to add the information

Exactly the same here. I've had a look at the source code too but did not understand enough for providing some useful add :-(

Nevertheless: I do have currently access to two units WS-1200 - one is outdoor and a second one is here on my desk. If some additional tests are required I'm happy doing it and share the outcome.

[zuckschwerdt]

The documentation is good. I'll draft a decoder in the next days.

[curlyel]

Hi Christian,
just noticed, that rtl_433 is already decoding something of my two WS-1200 units. It automatically chooses a decoder for "Fine Offset Electronics WH0530".

First sensor outdoor:
time : 2019-02-04 12:33:53 model : Fine Offset Electronics, WH0530 Temperature/Rain sensor ID : 38 Temperature: 7.3 C Rain : 250.8 mm Battery : OK Integrity : CRC

Second sensor indoor:
time : 2019-02-04 12:34:03 model : Fine Offset Electronics, WH0530 Temperature/Rain sensor ID : 62 Temperature: 21.5 C Rain : 8.1 mm Battery : OK Integrity : CRC

The values are valid. Sure, the DCF stuff is missing...
So probably less work than expected?

btw.: Does the light blue "CRC" output mean, that the CRC is checked and valid or does the blue indicates that it is not evaluated yet?

[zuckschwerdt]

If you see CRC it means checked and valid. The colors don't encode data, just to make things easier to see.

[curlyel]

Good to know ;-)
Thanks a lot!

[untergasser]

Hi,
my Alecto WS-1200 signals are not picked up as "Fine Offset Electronics WH0530". rtl_433 completely ignores them.
So maybe there are even more versions.
Best,
Andreas

[zuckschwerdt]

Looks like the Fine Offset WH0530 protocol matches close enough.
https://github.com/merbanan/rtl_433/blob/master/src/devices/fineoffset.c#L393

If you remove the Validate package check then it should mostly work. The V1.0 test sample are shown as Fine Offset WH3080 though. Either some sanity checks need to be added to remove those false positives or we need to confirm that they are (mostly) the same.

[curlyel]

Mmh. I've checked my units again. It seems, that both are V.1.0, see:

[zuckschwerdt]

Does the V1.0 also have a time packet (maybe only once a night)? It seems to suggest that on the package (or perhaps the DCF receiver is built into the indoor unit for 1.0?).

[curlyel]

I'd expect the latter (DCF in the indoor display unit). I'm going to check it...

[curlyel]

It's hard to block the rf-signal from the outdoor unit. I wanted to avoid climbing to the roof to pull out the batteries just to find out if it is receiving DCF without an outdoor unit powered on.

So I've decided to disassemble the indoor unit. Well ... it's broken now ...
(just kidding ;-))

I can confirm: It's definitely receiving the DCF in the indoor display unit. There are two antennas inside - one simple wire antenna for the 433MHz and a ferrite antenna for the longwave 77kHz DCF receiption.
See:

[untergasser]

I deassembled both, v1.0 and v2.0. Version 1.0 has the ferrite antenna in the display, Version 2.0 in the sensor. The "time" information gets a seperate signal with v2.0 and a stamp is attached to the old signal type.

Is it difficult to add the three signals? It would be great to have them in rtl_433!!!

Best,
Andreas

[zuckschwerdt]

Thanks for all the great info!
It's not difficult, just the issue with overlapping (false positive) Fine Offset devices was confusing me.
I'll add a branch for the decoder in a few days now.

[zuckschwerdt]

Just a quick preview, but there is some test code at #975 now.

[zuckschwerdt]

The PR now has the DCF77 decoding.

[zuckschwerdt]

Did you have a chance to test the code? Closing this, report back in #975 when you have time to test.