Froggit WH1080: Mostly no output

[Jochen]

Hi,

I have bought this replacement part from froggit:

http://www.froggit.de/product_info.php/language/en/info/p145_ersatz-ausseneinheit-komplett-wh1080-solar.html

It is sending data on 868.3MHz. Unfortunately rtl_433 does only sometimes (approx. 1 out of 50 tries, mostly when my raspberry is rebooted) output data when using "rtl_433 -f 868300000"

I get output when using "rtl_433 -f 868300000 -a -t". I have attached two samples. 

Can anybody help?

Greetz 

jochen

[Jochen]

Additional info: While capturing the samples I had no sensors connected. There sould be values for temperature and humidity only...

[NiK NIK]

Hi,
this is the output of one of your samples:

[00] {87} ff 59 64 f0 44 00 00 00 01 01 d2


and this is the output of my Froggit station:

[00] {88} ff a0 51 d9 52 01 02 12 65 0e db


As you can see your station output is 87 packets long, while the WH1080 decoder expects 88 (like mine) to work correctly. Furthermore, after the first 'ff' byte there should be a 0a or 0b in the next nibble, but you have 05.
Maybe by not connecting all of your sensors your output is different than expected by the decoder so it's not decoded at all. Try connecting all of your hardware, and also put a '-l 0' to your command line.
Just another thing: do not tune exactly to your tx frequency, stay slightly out of that (let's say 868200000 instead of 868300000), to avoid the center frequency dc spike that usually is present while receiving by using an rtl-sdr system.
I hope it helped, let me know

ovrheat

[Jochen]

Thank you for your answer ovrheat!

I have connected all sensors now, but still 87 packets:

root@srvaws:/home/pi/# rtl_433 -f 868200000 -l 0 -a

Registering protocol "Silvercrest Remote Control"

Registering protocol "Rubicson Temperature Sensor"

Registering protocol "Prologue Temperature Sensor"

Registering protocol "Waveman Switch Transmitter"

Registering protocol "Steffen Switch Transmitter"

Registering protocol "ELV EM 1000"

Registering protocol "ELV WS 2000"

Registering protocol "LaCrosse TX Temperature / Humidity Sensor"

Registering protocol "Acurite 5n1 Weather Station"

Registering protocol "Acurite Temperature and Humidity Sensor"

Registering protocol "Oregon Scientific Weather Sensor"

Registering protocol "Mebus 433"

Registering protocol "Intertechno 433"

Registering protocol "KlikAanKlikUit Wireless Switch"

Registering protocol "AlectoV1 Weather Sensor (Alecto WS3500 WS4500 Ventus W155/W044 Oregon)"

Registering protocol "Cardin S466-TX2"

Registering protocol "Fine Offset Electronics, WH-2 Sensor"

Registering protocol "Nexus Temperature & Humidity Sensor"

Registering protocol "Ambient Weather Temperature Sensor"

Registering protocol "Calibeur RF-104 Sensor"

Registering protocol "X10 RF"

Registering protocol "DSC Security Contact"

Registering protocol "Brennstuhl RCS 2044"

Registering protocol "GT-WT-02 Sensor"

Registering protocol "Danfoss CFR Thermostat"

Registering protocol "Energy Count 3000 (868.3 MHz)"

Registering protocol "Valeo Car Key"

Registering protocol "Chuango Security Technology"

Registering protocol "Generic Remote SC226x EV1527"

Registering protocol "TFA-Twin-Plus-30.3049 and Ea2 BL999"

Registering protocol "Fine Offset WH1080 Weather Station"

Registering protocol "WT450"

Registering protocol "LaCrosse WS-2310 Weather Station"

Registering protocol "Esperanza EWS"

Registering protocol "Efergy e2 classic"

Registering protocol "Inovalley kw9015b rain and Temperature weather station"

Registering protocol "Generic temperature sensor 1"

Registering protocol "Acurite 592TXR Temperature/Humidity Sensor and 5n1 Weather Station"

Registering protocol "Acurite 986 Refrigerator / Freezer Thermometer"

Registering protocol "HIDEKI TS04 Temperature and Humidity Sensor"

Registering protocol "Watchman Sonic / Apollo Ultrasonic / Beckett Rocket oil tank monitor"

Registering protocol "CurrentCost Current Sensor"

Registering protocol "emonTx OpenEnergyMonitor"

Registering protocol "HT680 Remote control"

Registering protocol "S3318P Temperature & Humidity Sensor"

Registering protocol "Akhan 100F14 remote keyless entry"

Registering protocol "Quhwa"

Registering protocol "OSv1 Temperature Sensor"

Registering protocol "Proove"

Registering protocol "Bresser Thermo-/Hygro-Sensor 3CH"

Found 1 device(s):

  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM

Found Rafael Micro R820T tuner

Exact sample rate is: 250000.000414 Hz

[R82XX] PLL not locked!

Sample rate set to 250000.

Bit detection level set to 0.

Tuner gain set to Auto.

Reading samples in async mode...

Tuned to 868200000 Hz.

...
...
...

*** signal_start = 60768, signal_end = 172270

signal_len = 111502,  pulses = 174

Iteration 1. t: 247    min: 125 (90)    max: 369 (84)    delta 13

Iteration 2. t: 247    min: 125 (90)    max: 369 (84)    delta 0

Pulse coding: Short pulse length 125 - Long pulse length 369

Short distance: 240, long distance: 241, packet distance: 7751

p_limit: 247

bitbuffer:: Number of rows: 2

[00] {87} 00 81 0a bb 77 95 d3 77 bb 74 02

[01] {87} 00 81 0a bb 77 95 d3 77 bb 74 02

 

[Jochen]

I have just noticed that the signal is not always the same. It alternates like so:

1.

*** signal_start = 253761734, signal_end = 253881046

signal_len = 119312,  pulses = 174

Iteration 1. t: 246    min: 124 (58)    max: 368 (116)    delta 17

Iteration 2. t: 246    min: 124 (58)    max: 368 (116)    delta 0

Pulse coding: Short pulse length 124 - Long pulse length 368

Short distance: 240, long distance: 241, packet distance: 7748

p_limit: 246

bitbuffer:: Number of rows: 2

[00] {87} 00 a1 1a fd b3 ff ff ff ff e2 4e

[01] {87} 00 a1 1a fd b3 ff ff ff ff e2 4e

2.

*** signal_start = 265762475, signal_end = 265828258

signal_len = 65783,  pulses = 87

Iteration 1. t: 247    min: 125 (29)    max: 369 (58)    delta 10

Iteration 2. t: 247    min: 125 (29)    max: 369 (58)    delta 0

Pulse coding: Short pulse length 125 - Long pulse length 369

Short distance: 240, long distance: 0, packet distance: 241

p_limit: 247

bitbuffer:: Number of rows: 25

[00] {1} 00 : 0

[01] {1} 00 : 0

[02] {1} 00 : 0

[03] {1} 00 : 0

[04] {1} 00 : 0

[05] {1} 00 : 0

[06] {1} 00 : 0

[07] {1} 00 : 0

[08] {1} 80 : 1

[09] {1} 00 : 0

[10] {1} 80 : 1

[11] {1} 00 : 0

[12] {1} 00 : 0

[13] {1} 00 : 0

[14] {1} 00 : 0

[15] {1} 80 : 1

[16] {1} 00 : 0

[17] {1} 00 : 0

[18] {1} 00 : 0

[19] {1} 80 : 1

[20] {1} 80 : 1

[21] {1} 00 : 0

[22] {1} 80 : 1

[23] {1} 00 : 0

[24] {63} fd b3 ff ff ff ff e2 4e

... and so on.

[NiK NIK]

Sorry, here I repost my answer I have already sent to you yesterday somewhere, but I still don't see here...
I'm fighting a war every time against the most counter-intuitive possible interface that Google News could ever have. It seems to me that it may have been designed by an alien....

-----------------------------------------------------

Thank to you Jochen, every new step forward to improve a better decoding is welcome! :)

Back to our trouble, I was asking myself if after you have connected all of your sensors you did some kind of reset (i.e. pull over the battery from the tx) or not. If you don't, please do it then retry to read values and let's see.

If you did it already, then we have something I've never seen yet, so the best thing would be if you could upload some data files in the test repository , also adding a little txt file containing what you were reading in the console while recording each data file, so to have some references. But try the reset first... :)

In addition to this: are there some other similar devices near to you? Are we sure that both of your samples comes from this same device?
(what If you pull off the batteries from your weather station? No more messages of this kind are still in the air?)

Il giorno venerdì 22 aprile 2016 19:55:33 UTC+2, Jochen ha scritto:

[Jochen]

Yes I am sure that this signals are coming from my device because I get no signals until I put in the batteries.

Every time I have recorded a sample I have done a complete reset (removed the batteries). 

When I have plugged in the battieries the device sends first some 0's.

[00] {1} 80 : 1

[01] {88} 00 00 00 00 00 00 00 00 00 00 00

then something like that:

[00] {87} 00 ae fb 15 ad ff ff ff ff e3 b6

[01] {87} 00 ae fb 15 ad ff ff ff ff e3 b6

then this

[00] {1} 00 : 0

[01] {1} 00 : 0

[02] {1} 00 : 0

[03] {1} 00 : 0

[04] {1} 00 : 0

[05] {1} 00 : 0

[06] {1} 00 : 0

[07] {1} 00 : 0

[08] {1} 80 : 1

[09] {1} 00 : 0

[10] {1} 00 : 0

[11] {1} 00 : 0

[12] {1} 80 : 1

[13] {1} 80 : 1

[14] {1} 80 : 1

[15] {1} 00 : 0

[16] {1} 80 : 1

[17] {1} 80 : 1

[18] {1} 80 : 1

[19] {1} 00 : 0

[20] {1} 80 : 1

[21] {1} 00 : 0

[22] {1} 80 : 1

[23] {1} 00 : 0

[24] {63} f1 af f3 d3 77 b9 75 f2

after that it starts blinking and it sends for about 2 Minutes nothing. After the 2 Minutes I get the upper both alternating.

I will upload the data files and output to the test repository now.

[NiK NIK]

That's right, I've seen your files under Froggit in the repository. Now I'll take a look.

Il giorno venerdì 22 aprile 2016 19:55:33 UTC+2, Jochen ha scritto:

[NiK NIK]

Hmm it's very hard to try to figure out something without the correct reading taken from the original console... If we could know that when you were recording (for example) gfile002.data the console was reading (for example) 22°C and also the wind speed and direction, it would be very helpful for decoding purpose. Is it possible for you to do that?

Il giorno venerdì 22 aprile 2016 19:55:33 UTC+2, Jochen ha scritto:

[Jochen]

Unfortuately I have only the sender and not the display. Would it be helpful if I record samples with different temps and wind speed? I could give you the temperature approx. if a use a second sensor...

[NiK NIK]

Well, sadly I see it as a desperate try... Not knowing the *exact* value that we are looking for in the encoded signal would probably lead us in a 'search-forever' path.
A different temperature and wind sensor placed near to the Froggit mast could give us some idea of the values, but because of the natural discrepancies between sensors it would not be the *exact* values that we need.
To complicate things, I guess that the two alternated signals you posted could be some alternate reading of different sensors (i.e first signal could be temperature data, second signal could be wind data), but it's just a guess... To have some confirm we (again) should know those exact values.
If you feel, you could still try and post on a new folder on the test repository some new record with readings you take in the same time from the second sensor, but I doubt that we could have some success this way, at least from my point of view.

Il giorno venerdì 22 aprile 2016 19:55:33 UTC+2, Jochen ha scritto:

[Jochen]

I think you are right. I will send the sensors back and will try to buy some which are supported.