Weather Sensor EMOS 6016 equipped with Temp, Hum, Winddirection, Windspeed

[AutomGuy]

Hi @all, :)

may be some body can try to help me. I have got a sensors as above described. With a flex decoder i have got these values. But i can not intepret the values

Detected OOK package 2021-05-05 09:44:01 Analyzing pulses... Total count: 726, width: 773.64 ms (193410 S) Pulse width distribution: [ 0] count: 265, width: 792 us [772;816] ( 198 S) [ 1] count: 455, width: 276 us [256;304] ( 69 S) [ 2] count: 6, width: 1828 us [1824;1848] ( 457 S) Gap width distribution: [ 0] count: 270, width: 260 us [240;284] ( 65 S) [ 1] count: 455, width: 776 us [776;800] ( 194 S) Pulse period distribution: [ 0] count: 720, width: 1056 us [1036;1080] ( 264 S) [ 1] count: 5, width: 2088 us [2088;2092] ( 522 S) Level estimates [high, low]: 15905, 94 RSSI: -0.1 dB SNR: 22.3 dB Noise: -22.4 dB Frequency offsets [F1, F2]: -4812, 0 (-18.4 kHz, +0.0 kHz) Guessing modulation: Pulse Width Modulation with sync/delimiter Attempting demodulation... short_width: 276, long_width: 792, reset_limit: 804, sync_width: 1828 Use a flex decoder with -X 'n=name,m=OOK_PWM,s=276,l=792,r=804,g=0,t=0,y=1828' pulse_demod_pwm(): Analyzer Device bitbuffer:: Number of rows: 7 [00] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 ff [01] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 fe [02] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 fd [03] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 fc [04] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 fb [05] {120} 55 5a 7c 2a f0 ef 37 be 7f 4b e4 ff 5f 41 fa [06] { 0}

what i found is:

Byte 1 to 6 -> should be device ID,Bat, Channel Byte 7 to 13 -> should be (IMHO) Temp, Hum, WindSpeed, WindDir Byte 14 -> should be a kind of checksum Byte 15 -> repeats

Many Thanks in Advance

[zuckschwerdt]

Grab more codes, put them in a list with expected values (Channel, Temp, Hum, Wind) and then post a BitBench like this.

[AutomGuy]

Good Morning,

i have graped more codes. I found that Byte 13 is the Wind direction. that means FF -> N (0 - 360), DF -> NE (45), BF -> E (90), 9F -> SE (135), 7F -> S (180), 5F -> SW (225), 3F -> W (270), 1F -> NW (315) That is the List with a BitBench

I have only grep the (fc) repeat because other repeats are the same i don't know the order of the values ​​except for the wind direction the specified order of the values ​​is only a guess

{120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a ff {120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a fe {120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a fd {120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a fc {120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a fb {120} 55 5a 7c 2a f0 ee bc be 7f 2e e6 ff ff 4a fa

{120} 55 5a 7c 2a f0 ee f1 93 ff 2c e5 ff ff d1 fc [expected CH:1 T:21.4C H:37% Bat:1 WindSpeed 0 WindDir: N] {120} 55 5a 7c 2a f0 ee ee b6 ff 30 e5 ff ff f5 fc [expected CH:1 T:21.0C H:35% Bat:1 WindSpeed 0 WindDir: N] {120} 55 5a 7c 2a f0 ee cb 17 ff 34 e6 ff ff 38 fc [expected CH:1 T:20.5C H:29% Bat:1 WindSpeed 0 WindDir: N] {120} 55 5a 7c 2a f0 ee c5 06 ff 3a e6 ff ff 27 fc [expected CH:1 T:19.9C H:30% Bat:1 WindSpeed 0 WindDir: N] {120} 55 5a 7c 2a f0 ee c1 64 7f 3b e6 ff ff 02 fc [expected CH:1 T:19.8*C H:30% Bat:1 WindSpeed 0 WindDir: N]

{120} 55 5a 7c 2a f0 ee ba e4 ff 28 e7 ff bf a9 fc [expected CH:1 T:20.8C H:30% Bat:1 WindSpeed 0 WindDir: E] {120} 55 5a 7c 2a f0 ee ba d5 7f 28 e7 ff bf 1a fc [expected CH:1 T:21.4C H:29% Bat:1 WindSpeed 0 WindDir: E] {120} 55 5a 7c 2a f0 ee ba b7 7f 28 e7 ff bf fc fc [expected CH:1 T:21.5C H:29% Bat:1 WindSpeed 0 WindDir: E] {120} 55 5a 7c 2a f0 ee ba 6a ff 27 e7 ff bf 2e fc [expected CH:1 T:21.6C H:29% Bat:1 WindSpeed 0 WindDir: E]

{120} 55 5a 7c 2a f0 ee b7 e9 ff 20 e7 ff bf a3 fc [expected CH:1 T:22.1C H:29% Bat:1 WindSpeed > 0 WindDir: E] {120} 55 5a 7c 2a f0 ee b7 da 7f 21 e7 fa bf 10 fc [expected CH:1 T:22.1C H:29% Bat:1 WindSpeed > 0 WindDir: E] {120} 55 5a 7c 2a f0 ee b7 ca ff 1f e7 f9 bf 7d fc [expected CH:1 T:22.1C H:29% Bat:1 WindSpeed > 0 WindDir: E] {120} 55 5a 7c 2a f0 ee b6 f6 ff 1e e7 f7 bf a5 fc [expected CH:1 T:22.3C H:29% Bat:1 WindSpeed > 0 WindDir: E] {120} 55 5a 7c 2a f0 ee b6 d7 ff 1c e7 f2 bf 7f fc [expected CH:1 T:22.5*C H:30% Bat:1 WindSpeed > 0 WindDir: E]

Many Thanks

[zuckschwerdt]

The code is likely inverted then! Press "Invert" to get

0x00 (  0) -> N (0 - 360),
0x20 ( 32) -> NE (45),
0x40 ( 64) -> E (90),
0x60 ( 96) -> SE (135),
0x80 (128) -> S (180),
0xa0 (160) -> SW (225),
0xc0 (192) -> W (270),
0xe0 (224) -> NW (315)

For probably temp, hum, wind see this BitBench.

[AutomGuy]

Hi, Many thanks to Mr. Zuckerschwerdt. It was very helpfull. (Danke Herr Zuckschwerdt:) i guess we have the same mothertongue) first question: So if i would like write a decoder i would catch one of the existing decoders modify them. wich one can i send the code to verify that code and put it into that repsitory?

second question: How can i use the flex decoder with the decoded values?

Thanks in Advance

[zuckschwerdt]

For a first few tries you can just use a flex conf file (see examples in the conf dir) with the get keyword to extract fields. (There are some improvements planned to use calculations on the get but for now you only get raw values or mapping.) You can then try different channels and a variable power supply or a near dead battery to find the battery_low flag.

Also the checksum is important and not supported with flex (for now). I'll try to recover the algo -- if you can record more codes (about 30-50 should do) that'll help with the checksum. The checksum can be a hint if this device is similar to one we already have. Then copy that decoder and change it.

[zuckschwerdt]

Checksum is just an addition. I.e. add_bytes(b, 13) == b[13]

[AutomGuy]

OK at the weekend is planed to mount the Sensor outside.(at the moment the sensor is mounted at my desk. :) ) And then i can automatically record the values over a day this sensor sends all 61s a record. is it enough to extract one repeat like "fc" at the end? Technical Data Temperature: -30 °C - +60 °C, resolution 0,1 ° Accuracy ±1 °C for Range 20 °C - +24 °C, ±2 °C for range 0 °C - +20 °C and 24 °C - +40 °C, ±3 °C for range -20 °C - 0 °C and 40 °C - +50 °C, ±4 °C for other ranges Humi: 1–99 % relative , deviation 1 % Accuracy: 5% Windsensors: 0 - 127,5 km/h Winddirection: 8 cardinal N NE E SE S SW W NW

[zuckschwerdt]

Yes, the repeats are not interesting, one code (...fc) is enough. The wind dir field is likely only 4 bits, 16 directions (or 8). Wind should have a max and average value. We only spotted one of those so far.

If you can reset the sensor we can maybe see a different ID (is it 83d50f11?). The first 2,5 bytes (before temp) should show some relevance also. Perhaps the max wind speed? If you can put the sensor in the freezer to see how negative temperature is encoded (a sign bit? 2s complement?)

[AutomGuy]

Morning :) Have put the sensor into a freezer. in that BitBench 12 Top Rows are the values from plus to minus. the expected values are from a other device in the same freezer. it is slightly different. In plus deg we could have max 0600 i guess. In minus deg we have 4xxx, 3xxx and so on. How can i calculate that? Thank you

[zuckschwerdt]

That's 2's complement (the usual signed numbers). Subtract 4096 to get the negative values. In code it look like this:

int temp_raw  = (int16_t)(((b[8] & 0x0f) << 12) | (b[9] << 4)); // use sign extend
float temp_c = (temp_raw >> 4) * 0.1f;

[AutomGuy]

That is what i have tested but under PHP it will not work. i was a litle bit surprised. With this code i get exactly what the BitchBench get. :) PHP has no dtatatypes like c.

$temp_r = ((($b[8] & 0x0f) << 8) | ($b[9])); if($temp_r < 1000) { //negative Values $temp_c = (4096 - $temp_r - 4096) 0.1; } else { //positve Values $temp_c = (4096 - $temp_r) 0.1; }

$hum_r = $b[10]; $hum_c = (255 - $hum_r);

$windsp_r = $b[11]; $windsp_c = (255 - $windsp_r);

$winddi_r = ((($b[12] & 0xf0 ) >> 4)) ; $winddi_c = (15 - $winddi_r);

[zuckschwerdt]

You should first bitwise-not every byte, e.g. $b[i] ^ 0xff, then e.g. $temp_c = $temp_r >= 2048 ? ($temp_r - 4096) * 0.1 : $temp_r * 0.1;

[AutomGuy]

Thank you i will tried. :) i believe i found out what the UKN in this BitBench are. The weather sensor has a pb called "wave" with these you can dcf77 switch on/off, but i have no idea how is the byte order i can not find a pattern like 080852021111258. May be you have an idea. further more the sensor has a channel switch 1-3 and a pb "tx" have a nice weekend :)

[zuckschwerdt]

Oh DCF77, yes that seems to fit. The encoding is not obvious but the bits count up roughly with the time. Can you record more codes with timestamps? Interesting points would be at rollover (59-0 for seconds and minutes, 23-0 for hour and day changes). Something like UNK?:3b D?5d H?6d M?6d S?6d ?2b seems to count roughly D:H:M:S but there are strange offsets.

[AutomGuy]

Good morning, i have made some more test and have figured out the Channel, likely ID, DateTime Format from DCF 77 ? please see BitBench Thanks

[zuckschwerdt]

Channel and ID looks good. To figure out the DCF77 we need a very long list of codes. If you can, log to a txt file and upload a zip here. Strange thing is between 09/05/2021 10:41:09 and 09/05/2021 17:17:35 the value gets smaller?

[AutomGuy]

Yes i can clarify this. 10:41 is befor i have made a reset (Bats out) and 17:17 is a sequence after but back the bats. I can do a long term recording over 24Hours. Is that sufficient? your are fan of the packers or is it a other christian? :)

[zuckschwerdt]

Yes that would be great. Just a long txt with codes and timestamp, like you have for the BitBench. Whatever you can easily get automatically.

[AutomGuy]

New Day the recording is done. :) And here we have the result file. Emos6016_G_form.zip

[zuckschwerdt]

If you look at it like this STATIC?:8h8h8h ID?:8h BAT?8h DT?10b SEC:16d CH:2d TEMP:12d HUM?8d WSPEED:8d WINDIR:4d ?4h CHK:8h REPEAT:8h the SEC field is counting seconds (the difference in timestamp seconds matches). Not sure why it wraps to 0 after 15 bits are full, between 10/05/2021 17:09:13 and 10/05/2021 17:12:34 though.

[AutomGuy]

Thank You, But could it be that the values are BCD and the year only last 2 digits? means xx01 :)

[zuckschwerdt]

No, that would be easy to spot.

[AutomGuy]

Now i have created an other BitBench (to long for a Link) Emos6016_G.zip with a 26d decoding and here i can see that the number constantly increase. I thought it was a timestamp in seconds; but nothing. STATIC?:8h8h8h ID?:8h BAT?8h SEC:26d CH:2d TEMP:12d HUM?8d WSPEED:8d WINDIR:4d ?4h CHK:8h REPEAT:8h

[zuckschwerdt]

But there is the one point I mentioned where it "skips a bit":

[zuckschwerdt]

At which value does it start with batteries out/in? Is it always a low value? Is not affected by the battery change? If it is DCF77 it should be a "bad" value for at least a minute, but then always a value as if there was no power interruption. Worth a test ;)

[zuckschwerdt]

• Hypothesis: the counter works similar to unixtime but with some offset.
• Take unixtime at the first timestamp: "11.5.2021 13:55:57" -> 1620741357 (note timezone +02:00)
• Calculate offset: 1620741357 - 4541232 = 1616200125
• Add "1616200125" to every "26d" number and convert from unixtime to datetime

This seems to work somewhat, but there is drift and also the wrap at 11.05.21 17:10. My guess it's not one big (26d) number but smaller numbers. Not sure.

[AutomGuy]

yes will try it. today i grep a Variable Powersup. and check where the bat bit is. May be we get more clarity. :)

[AutomGuy]

stumble arround at google and found that smallest-number-of-bytes-that-can-store-a-timestamp maybe the year is not included.?

[zuckschwerdt]

If we plot the number against the actual seconds (from the unixtime) we get a slope of 0,883... So the counter is not actually counting seconds. It just somewhat close.

[AutomGuy]

Morning, more tests mor in the wild shows -> the sensors delivers 16 cardinal wind directions. from 00,01 ... 0e,0f . i was wondering that i have after deconding no value for "WD". and the raw show me the secret. :)

[AutomGuy]

Good morning, i 'll be back after few days. something is happend at the BAT bit. please see the BitBench . Can you see a pattern at DCF77?

[AutomGuy]

Hi Mindavi, Hi at All, the decoder is under construction. unfortunately i can not integrate all what the sensor supplies. at first i will integrate the device identification, id, temperatur, humidity, windspeed, winddir, checksum, ch. I'm still struggling with the battery bit and DCF77

[AutomGuy]

Hi Christian, now i have written the decoder for the EMOS6016. Is it possible that i send the file to you? Or what is the next step? Many Thanks in advance

[merbanan]

We prefer a Github PR but if you are unable to use that just upload the code here.

[AutomGuy]

Hi Benjamin, i am not yet familar with PR at the moment. That is the reason why i upload the code here as zip. Thx in advance emos6016.zip

[AutomGuy]

Hi, maybe some body can help me to create a pull request. i have forked that repo. I would like upload the tested decoder file for the EMOS6016 sensor. but it seems to be i am to stupid to create a pull request. Thx in advance

[zuckschwerdt]

The steps should be

• fork in GitHub
• clone your fork
• in your fork git checkout -b my-emos
• add your files, check that it compiles
• git push, follow the suggestion
• open https://github.com/merbanan/rtl_433/ and click to add PR

[AutomGuy]

Thx, but how can i do it in the web browser window?

[zuckschwerdt]

Is the zip still the latest code? If so I'll put it on a branch tomorrow.

[AutomGuy]

Unfortunately not. Tommorow morning i will put in here the latest zip. Thx

[AutomGuy]

Good morning, that is the latest zip of the decoder. emos6016.zip Thx in advance for put it in a branch.

[AutomGuy]

Thx for adding support. I have question. what is the reason that you remove the wind direction (N up to NNW)? because that is language specific?

[AutomGuy]

Christian have one question more: [00] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 ff [01] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 fe [02] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 fd [03] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 fc [04] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 fb [05] {120} 55 5a 7c 00 6a a5 60 e7 3f 36 da ff 5d 38 fa Means the -8 in that line int r = bitbuffer_find_repeated_row(bitbuffer, 3, 120 - 8) that the last byte fa - ff will be ignored? Thx

[zuckschwerdt]

reason that you remove the wind direction (N up to NNW)?

rtl_433 is not meant to transform values for display purposes. There should only be the direct output of a value.

It's always assumed that every kind of "nice" display has different needs for calculations and should do those by itself. E.g. you might reasonably want to display wind speed as Beaufort scale, but that is not a task for rtl_433.

[zuckschwerdt]

Means the -8 in that line int r = bitbuffer_find_repeated_row the last byte fa - ff will be ignored?

Yes, we could have written 112 or 14 * 8, it's just to show that we don't want to compare the last byte for repeats.

[AutomGuy]

what the the recomended github client for linux debian?

[zuckschwerdt]

My preference is just Git on the terminal. Or Visual Studio Code with GitLens. Fork is also very nice, but Windows or Mac only.

[AutomGuy]

Thx for that

[zuckschwerdt]

Do you know what the "SEC" field of 30 bit is? edit: ignore that, I see we already talked about that ;)

[AutomGuy]

We try to find out how the DCF is coded but we could not. As Attachement here the manual from the entire weather station. EMOS E6016 Weather Station.pdf The operating instructions do not allow the conclusion that there is more in the sensor