how to pull devices from rtl_433 project

[mgx0]

Hi there,

first of all, thanks for great job here.

I have a question, I need EMOS E6016 sensor support but I have trouble getting it decoded using this lib with OpenMQTTGateway.

I ran update_rtl_433_devices.sh, output said to update rtl_433_ESPcpp with contents of rtl_433_ESP.fragment, I did that. However I did not touch the rtl_433_devices files. I noticed there are 3 fragment files

compiling went fine, but EMOS E6016 seems not to be recognized. Other sensors are recognized, for example Nexus-TH

observations:

• E6016 is transmitting for sure and I am able to see and decode signal by my own program. I just wanted it to get it done by OMG
• when I remove Nexus support, nexus sensors stop appearing in the MQTT messages
• when I remove everything and keep only EMOS protocols, no messages get through
• CC1101 is working fine (i can see other protocols)

what is the process of updating protocols from rtl_433 github project? what else needs to be done besides running update_rtl_433_devices.sh ?

thanks a lot!

[NorthernMan54]

If you look at pr #18 you can see what changed with the last rtl_433 update. The script does update almost everything with the manual changes coming out as comments. The other fragments are used by the script to generate another file. But it is not bullet proof yet, as I just started using it for the last refresh.

if you define RTL_DEBUG during initialization it will list which decoders are enabled, so you can see if EMOS E6016 is enabled. If it isn’t enabled then you need to dig further.

even if it can’t decode your emos device, with RAW_SIGNAL_DEBUG enabled you should see something, and if RTL_DEBUG is enabled, you should see debug messages from the device decoders.

[mgx0]

thanks man, I appreciate it. I can move on with this

[mgx0]

by the way, any chances you have a version that sends raw signals (decoded and undecoded) to MQTT? I am too far away from the sensor, it's on the roof 😁

thanks

[NorthernMan54]

Their is RAW_SIGNAL_DEBUG, but it only logs onto the serial port

And PUBLISH_UNPARSED sends a message when something is received that isn't understood.

But I don't have anything to publish to raw signal to MQTT.

[mgx0]

Thanks a lot, I think that’s all I need. I have couple of cc1101 on the way so I will experiment a bit

i have built a decoder based on rtl_433 sources for emos e6016 but i had to put it on arduino mini to decode and send to uart as parsed string. Then an esp8266 with OMG sends uart data to mqtt

i could not fix panics when having the ISR and PubSubClient used on one ESP chip

[NorthernMan54]

Did you get the EMOS E6016 to work ?

I'm curious as I will be doing a refresh in about a month, shortly after the next rtl_433 release.

[mgx0]

I have two exactly same CC1101 but only one decodes the emos. The other one shows various decodings, anything but emos. I will update you in few days, today I’m expecting two additional CC1101’s.

Funny is, that the CC1101 that is 1m from Emos (must have better signal) does not decode anything. Another one that is 15m behind a wall shows ocassional (but correct) readings. Code is the same, I cannot explain this behaviour.

[NorthernMan54]

The one that is 1 meter away my be too close aka signal too strong or have other interference.

[mgx0]

Then I could shorten the antenna or cover it with something else to make the signal weaker. But in the same box on the root i have SRX882 that is able to capture every 6 packets from the emos. Let’s see how it works when I swap the cc1101 i have at home. The second works fine but is too far and I don’t get data every minute

[mgx0]

no success since then. Got another CC1101 for testing but it does not "hear" anything from EMOS E6016

but I've noticed that after devices update I got an error (and I thought I've fixed it):

lib/rtl_433_ESP/src/rtl_433/devices/flex.c: In function 'parse_modulation':
lib/rtl_433_ESP/src/rtl_433/devices/flex.c:390:16: error: 'OOK_PULSE_PCM' undeclared (first use in this function)
         return OOK_PULSE_PCM;
                ^
lib/rtl_433_ESP/src/rtl_433/devices/flex.c:390:16: note: each undeclared identifier is reported only once for each function it appears in
lib/rtl_433_ESP/src/rtl_433/devices/flex.c:392:16: error: 'OOK_PULSE_RZ' undeclared (first use in this function)
         return OOK_PULSE_RZ;
                ^
*** [.pio/build/esp32dev-rtl_433/lib5a5/rtl_433_ESP/rtl_433/devices/flex.c.o] Error 1

those OOK_PULSE_PCM and OOK_PULSE_RZ are not declared.

enum declaration is as follows:

/** Supported modulation types. */
enum modulation_types {
    OOK_PULSE_MANCHESTER_ZEROBIT = 3,  ///< Manchester encoding. Hardcoded zerobit. Rising Edge = 0, Falling edge = 1.
    OOK_PULSE_PCM_RZ             = 4,  ///< Pulse Code Modulation with Return-to-Zero encoding, Pulse = 0, No pulse = 1.
    OOK_PULSE_PPM                = 5,  ///< Pulse Position Modulation. Short gap = 0, Long = 1.
    OOK_PULSE_PWM                = 6,  ///< Pulse Width Modulation with precise timing parameters.
    OOK_PULSE_PIWM_RAW           = 8,  ///< Level shift for each bit. Short interval = 1, Long = 0.
    OOK_PULSE_PIWM_DC            = 11, ///< Level shift for each bit. Short interval = 1, Long = 0.
    OOK_PULSE_DMC                = 9,  ///< Level shift within the clock cycle.
    OOK_PULSE_PWM_OSV1           = 10, ///< Pulse Width Modulation. Oregon Scientific v1.
    OOK_PULSE_NRZS               = 12, ///< NRZS modulation
    FSK_DEMOD_MIN_VAL            = 16, ///< Dummy. FSK demodulation must start at this value.
    FSK_PULSE_PCM                = 16, ///< FSK, Pulse Code Modulation.
    FSK_PULSE_PWM                = 17, ///< FSK, Pulse Width Modulation. Short pulses = 1, Long = 0.
    FSK_PULSE_MANCHESTER_ZEROBIT = 18, ///< FSK, Manchester encoding.
};

I did a workaround of defining OOK_PULSE_PCM and OOK_PULSE_RZ to 4, but not sure if that's correct. Could you point me please?

[NorthernMan54]

That is the flex decoder, which won't work due to stack overflow issues. You should remove it

[mgx0]

Okay so I’m investigating further then. I didn’t catch how to remove it, do you have any suggestion on how to? It did appear there after scripted update

[NorthernMan54]

Try brute forcing it, by removing flex.c

[mgx0]

Yep done, uploaded and testing again. But I doubt this will affect the main problem (emos not decoded). I will most probably go to the roof and demount the sensor

[mgx0]

Didn’t change anything, i have left MY_DEVICES enabled and put only 5 sensors there, one of them is emos6016.

All of them except emos6016 are decoded. Emos6016 is decoded by my own decoder. Tomorrow I’ll try to decode with usb sdr and come back to report

[NorthernMan54]

Humm, the CC1101 is receiving signals, and the decoders are working which is positive.

If you enable RTL_DEBUG, does the emos6016 have any debug output ?

[mgx0]

just this when some data comes: emos_e6016_decode: Repeated row fail <<this repeats quite a lot of times. This data is actually Nexus data as you can see below. I'll capture it with SDR today and see

************* WELCOME TO OpenMQTTGateway **************
[E][Preferences.cpp:49] begin(): nvs_open failed: KEY_TOO_LONG
N: OpenMQTTGateway Version: omgrfcc1101-test
*WM: [1] Free heap:        136528
*WM: [1] ESP-IDF version:  v3.3.5-1-g85c43024c
*WM: [3] allocating params bytes: 20
*WM: [2] Added Parameter: server
*WM: [2] Added Parameter: port
*WM: [2] Added Parameter: user
*WM: [2] Added Parameter: pass
*WM: [2] Added Parameter: secure
*WM: [3] Updated _max_params: 10
*WM: [3] re-allocating params bytes: 40
*WM: [2] Added Parameter: cert
*WM: [2] Added Parameter: name
*WM: [2] Added Parameter: topic
N: Attempting Wifi connection with saved AP: 0
N: Attempting Wifi connection with saved AP: 1
E (826) wifi:sta is connecting, return error
[E][WiFiSTA.cpp:221] begin(): connect failed!
N: Attempting Wifi connection with saved AP: 2
E (1328) wifi:sta is connecting, return error
[E][WiFiSTA.cpp:221] begin(): connect failed!
N: Attempting Wifi connection with saved AP: 3
E (1830) wifi:sta is connecting, return error
[E][WiFiSTA.cpp:221] begin(): connect failed!
N: Attempting Wifi connection with saved AP: 4
E (2332) wifi:sta is connecting, return error
[E][WiFiSTA.cpp:221] begin(): connect failed!
N: Connect your phone to WIFI AP: omgrdcc1101-test with PWD: xxxxxxxxxxx
*WM: [1] AutoConnect 
*WM: [2] ESP32 event handler enabled 
*WM: [1] AutoConnect: ESP Already Connected 
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set 
*WM: [1] AutoConnect: SUCCESS 
*WM: [1] STA IP Address: 10.0.0.245
Registering protocol [1] "Akhan 100F14 remote keyless entry"
Registering protocol [2] "EMOS E6016 weatherstation with DCF77"
Registering protocol [3] "Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor"
Registering protocol [4] "Generic Remote SC226x EV1527"
Registering protocol [5] "Wireless Smoke and Heat Detector GS 558"
N: ZgatewayRTL_433 setup done 
N: Switching to RTL_433 Receiver: 433.92Mhz
N: OpenMQTTGateway modules: ["rtl_433"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
N: Connected to broker
N: Send on /SYStoMQTT msg {"uptime":4,"version":"omgrfcc1101-test","freemem":181984,"mqttport":"1883","mqttsecure":false,"freestack":4792,"rssi":-56,"SSID":"e","BSSID":"94:83:C4:06:81:CB","ip":"10.0.0.245","mac":"0C:DC:7E:61:CB:2C","actRec":3,"mhz":433.92,"RTLminRssi":-80,"RTLRssi":0,"RTLCnt":0,"modules":["rtl_433"]}
rtl_433_ESP(7): demod(6) - Akhan 100F14 remote keyless entry
rtl_433_ESP(7): demod(6) - EMOS E6016 weatherstation with DCF77
emos_e6016_decode: Repeated row fail
emos_e6016_decode: Repeated row fail
…
…
…
…
…
…
emos_e6016_decode: Repeated row fail
emos_e6016_decode: Repeated row fail
emos_e6016_decode: Repeated row fail
rtl_433_ESP(7): demod(5) - Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor
N: Send on /RTL_433toMQTT msg {"model":"Nexus-TH","id":14,"channel":1,"battery_ok":1,"temperature_C":7.5,"humidity":77,"protocol":"Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor","rssi":-63,"duration":930634}
pulse_demod_ppm(): Nexus, FreeTec NC-7345, NX-3980, Solight TE82S, TFA 30.3209 temperature/humidity sensor
bitbuffer:: Number of rows: 12 
[00] {35} 1d 00 97 e9 a0 : 00011101 00000000 10010111 11101001 101
[01] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[02] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[03] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[04] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[05] {37} 09 40 25 fa 68 : 00001001 01000000 00100101 11111010 01101
[06] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[07] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[08] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[09] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[10] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
[11] {36} 0e 80 4b f4 d0 : 00001110 10000000 01001011 11110100 1101
rtl_433_ESP(7): demod(6) - Generic Remote SC226x EV1527
rtl_433_ESP(7): demod(6) - Wireless Smoke and Heat Detector GS 558

[mgx0]

nope, totally nothing. The CC1101 seems to be deaf to E6016 signals .. and I swear it worked few weeks ago with my first attempt (then I rebuilt whole project, rtl_433 got pulled from github and it stopped working)

having RTLSDR dongle AND CC1101 few meters away from the sensor, watching output from both: dongle+rtl_433 decodes E6016 fine while CC1101 with OMG does not. Not a single line of output from OMG on serial console.

note that CC1101 decodes Nexus, Acurite and other stuff fine. I just added the EMOS sensor, which is registered properly. But the emos decoder does not show anything on the console. Not even the "repeated row fail".

and note that rtl_433 has been built from source today, same source as the rtl_433_ESP uses for importing new devices.

I doubt it helps but here is the cu8 capture from RTLSDR g013_433.92M_250k.cu8.zip

Now I'm gonna try to find older versions of rtl_433 and import them

[mgx0]

and I'm 100% sure the sensitivity of CC1101 is miserable comparing to RTLSDR or SRX882. but you mentioned that in readme :)

[mgx0]

here's the output from sdr_433. I tried to tune it according what GQRX app shows me as the main frequency. I cannot get to the core, must be some stupid thing that breaks it

$ rtl_433 -A -R 214 -f 433990000 -vvv -M level

Tuned to 433.990MHz.
Detected OOK package    2022-04-29 11:04:03
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2022-04-29 11:04:03
model     : EMOS-E6016   House Code: 245
Channel   : 1            Battery_OK: 1             Temperature_C: 17.9       Humidity  : 37            WindSpeed m_s: 4.0        Wind direction: 45.0
Radio Clock: 2022-04-29T11:04:02                   Integrity : CHECKSUM
Modulation: ASK          Freq      : 434.0 MHz
RSSI      : -0.1 dB      SNR       : 17.3 dB       Noise     : -17.4 dB
Pulse data: 726 pulses

Analyzing pulses...
Total count:  726,  width: 791.14 ms        (197785 S)
Pulse width distribution:
 [ 0] count:  277,  width:  820 us [808;864]    ( 205 S)
 [ 1] count:  443,  width:  292 us [284;320]    (  73 S)
 [ 2] count:    6,  width: 1876 us [1876;1880]  ( 469 S)
Gap width distribution:
 [ 0] count:  282,  width:  256 us [252;280]    (  64 S)
 [ 1] count:  443,  width:  784 us [780;800]    ( 196 S)
Pulse period distribution:
 [ 0] count:  720,  width: 1080 us [1064;1144]  ( 270 S)
 [ 1] count:    5,  width: 2140 us [2136;2144]  ( 535 S)
Pulse timing distribution:
 [ 0] count:  720,  width:  800 us [780;864]    ( 200 S)
 [ 1] count:  725,  width:  280 us [252;320]    (  70 S)
 [ 2] count:    6,  width: 1876 us [1876;1880]  ( 469 S)
 [ 3] count:    1,  width: 18804 us [18804;18804]   (4701 S)
Level estimates [high, low]:  15932,    295
RSSI: -0.1 dB SNR: 17.3 dB Noise: -17.4 dB
Frequency offsets [F1, F2]:   14914,      0 (+56.9 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
view at https://triq.org/pdv/#AAB1040320011807544974819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090909090A1819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090909081A1819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090908190A1819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090908181A1819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090819090A1819081908190819081908190908190818190909090908181818181819081908181909081908181909081909081818190819081908181909090819090909090908190909090909090819081819090818190908190908190819090909090819090909081909090819090909081908190819090909090819081A355
Attempting demodulation... short_width: 292, long_width: 820, reset_limit: 804, sync_width: 1876
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=292,l=820,r=804,g=0,t=0,y=1876'
pulse_slicer_pwm(): Analyzer Device
bitbuffer:: Number of rows: 7 
[00] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea ff 
[01] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea fe 
[02] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea fd 
[03] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea fc 
[04] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea fb 
[05] {120} 55 5a 7c 0a 69 b1 53 bf 7f 4c da fb dd ea fa 

[mgx0]

and one interesting observation: with every other signal I have at home (Nexus, generic etc) I get RAW data on UART (RAW_SIGNAL_DEBUG enabled).

but when EMOS transmits, it produces nothing. That's weird, looks like freq tuning to me, but I need to study more, how it should work

[NorthernMan54]

The raw signal detection logic I use is to constantly watch the RSSI level reported by the CC1101 and if is above MINRSSI start the signal receiver, and once it drops below MINRSSI stop receiving and send the raw signal to the rtl_433 decoders. It also performs a basic sanity check ( signal length ) for noise https://github.com/NorthernMan54/rtl_433_ESP/blob/77707f473414e05c0af26d1c61d1a2b0fa7735a7/src/rtl_433_ESP.cpp#L425.

Sounds like your EMOS device may not be passing the sanity check or ???, does the LED blink when the EMOS transmits ?

[mgx0]

good idea, thanks. No, the LED does not shine during EMOS transmitting (my other device does so I'm able to see when it is + considering 61s transmit interval).

is there something I can comment? for example start with more comments to exclude checks and find the culprit.

Are you willing to do this? I am able to work on my own, I just need to turn my head in correct dimension

[NorthernMan54]

If the LED is not flashing when EMOS is transmitting, then the signal is likely below MINRSSI, you could try tuning it to a lower value but keep it above the noise level in your environment. If you watch the SYStoMQTT topic, the message includes the current RSSI level RTLRssi being seen by the CC1101, so you could lower MINRSSI in an attempt to receive the signal.

This is from one of my devices, you can see RTLminRssi and RTLRssi

{"uptime":22930,
"version":"esp32dev_rtl_433-v0.9.9beta-6-g02e96f2[patch-1]",
"freemem":87472,
"mqttport":"1883",
"mqttsecure":false,
"freestack":29916,
"rssi":-56,
"SSID":"The_Beach",
"ip":"192.168.1.60",
"mac":"9C:9C:1F:C6:F5:6C",
"actRec":3,
"mhz":433.92,
"RTLminRssi":-82,
"RTLRssi":-94,
"RTLCnt":6115,
"modules":["BME280","RF","RF2","Pilight","rtl_433"]}

[mgx0]

the led blinks in 1 second interval (short blink every second), not sure if that's an incoming signal or what, on uart there is no output when blinking ...

but anyway, lowering the MINRSSI to -95 did not help, led only blinks in intervals (and during Nexus transmission, but not EMOS)

this is my SYStoMQTT output. what is RTLCnt? it is zero on mine

{
    "uptime": 244,
    "version": "strecha",
    "freemem": 189124,
    "mqttport": "1883",
    "mqttsecure": false,
    "freestack": 4584,
    "rssi": -45,
    "SSID": "e",
    "BSSID": "DC:2C:6E:1B:4C:9D",
    "ip": "10.0.0.188",
    "mac": "E8:31:CD:D6:D3:A8",
    "actRec": 3,
    "mhz": 433.92,
    "RTLminRssi": -95,
    "RTLRssi": -87,
    "RTLCnt": 0,
    "modules": ["RTL_433"]
}

anyway I'm starting thinking this could be too much work for you (and me) to get this working. When I realise the weak reception and range on CC1101, it's frustrating and maybe not the best thing I can do here.

I have my own EMOS decoder (based on rtl_433 source) working and I have only one sensor, so I might live with this. If there's anything I can try, please shoot, but this is really a low priority.

thanks a lot

[NorthernMan54]

Looking at your output, the noise level in your environment is higher ie 87 so a MINRSSI of 95 will never stop receiving and pass something for decoding.

rtlCnt is a count of received and decoded messages, so you can see if it stops working. Had an earlier issue with the boards going deaf over time.

Sounds like you are in a similar place as me on this. When I did the original port I was expecting a similar signal reception ability as a rtl-sdr, but found after completing the effort found that the range was pitiful. I did try other things like tuning the CC1101 receiver settings, and using carrier sense ( an option in the cc1101 ), but it didn’t change things.

I built a couple of devices and even found that sitting side by side they weren’t consistent, so in the back of mind I keep thinking counterfeit chipsets or ???

personally, I had started this effort to stop using rtl-sdr’s on my RPI’s and have a small device I can deploy, but never achieved that goal due to the issues you found. So for now I consider this a proof of concept, but not production ready yet.

[mgx0]

Ah crap negative numbers … okay I’ll try with filter at -75 or even -70. Having the transmitter that close to the receiver should result in even higher filter.

Well, it’s worth the shot. Does not look like I will have this in production but at least i’ll learn something. And that’s important 😊

it is no fun anymore, i wanted to crush the cc1101 board 3 times already 😊

thanks man!

[mgx0]

Can I use this issue ro ask somerhing?

I see you use rf, rf2 and pilight at the same time. How does multi-decoding work? Is the received packet passed to multiple decoders?

I have PIR sensors that cannot be decoded by pilight but RC-switch output is sufficient. I am thinking about having one esp32 with srx882 to listen for these signals and decode either by pilight or rc-switch.

How does it work, if I may?

[NorthernMan54]

Unfortunately it isn’t that sophisticated to allow multiple signal decoders to process a signal, what it does is allow one binary to contain all the decoders, and you can switch which one is active via a MQTT message. I use it for transmitting signals to control devices, while receiving messages via a different decoder. When you transmit it switches to the appropriate decoder, transmits, then switches back to your original decoder.

[mgx0]

Ah so. Okay then, I have to find some other solution for me 😊 anyway thanks, it gave me a lot. I’ll post here when I know something new

[mgx0]

today one OMG with RTL_433_ESP started decoding. I haven't touched that since friday. This is the OMG with CC1101 that is farther from the sensor. The OMG that's 50cm from the sensor seems to be either deaf or overwhelmed :D

here is the data:

{ "model": "EMOS-E6016", "id": 245, "channel": 1, "battery_ok": 1, "temperature_C": 14.9, "humidity": 60, "wind_avg_m_s": 5, "wind_dir_deg": 315, "radio_clock": "2022-05-02T20:40:27", "mic": "CHECKSUM", "protocol": "EMOS E6016 weatherstation with DCF77", "rssi": -78, "duration": 805463 }

[NorthernMan54]

If you look at the reported RSSI value -78, that is pretty low and close to the MINRSSI cutoff of -82

[mgx0]

now I'm confused ... should I try MINRSSI cutoff of -90 or -70 in this case? I'm sorry for stupid question

[Cezar8421]

Hello @mgx0 I'm not a programmer but an electronics enthusiast. I can see you have your first sensor readings and I am impressed with your work. Could you, at my hot request, compile the bin file for OMG esp32dev-rtl_433 with device support: "EMOS-E6016". I have the necessary components and I have purchased a set of sensors. However, I cannot compile the file for ESP32. Thank you in advance.

[mgx0]

hi @Cezar8421 , thanks 😁 attached is the file and settings (note the password)

I noticed today the CC1101 stopped decoding data when sun has rised and started after sunset. Magic stuff, gentlemen!

[env:esp32dev-rtl433-cezar] platform = ${com.esp32_platform} board = esp32dev lib_deps = ${com-esp.lib_deps} ${libraries.wifimanager32} ${libraries.smartrc-cc1101-driver-lib} ${libraries.bme280} build_flags = ${com-esp.build_flags} '-DZgatewayRTL_433="RTL_433"' '-DZradioCC1101="CC1101"' '-DGateway_Name="omgrfcc1101-predok"' '-DOMG_VERSION="omgrfcc1101-predok"' '-DMINRSSI=-90' '-DOMG_VERSION="predok"' '-DMY_DEVICES="YES"' '-DCC1101_FREQUENCY=433.92' '-Dota_password="YOURPASSWORD"' '-DWifiManager_password="YOURPASSWORD"' '-DBase_Topic="/home/omg/"'

firmware.bin.zip

7 protocols are included in this binary:

akhan_100F14 smoke_gs558 emos_e6016 nexus generic_temperature_sensor generic_remote generic_motion

[NorthernMan54]

Lol, I've heard of vampire ethernet taps, but not vampire radios.

[Cezar8421]

Thank you @mgx0 very much for help. Soon I will try to revive my set and describe the results. Maybe they will be as successful as the implementation of RFLink32.

EDIT:

{"uptime":484,"version":"predok","freemem":226724,"mqttport":"1883","mqttsecure":false,"freestack":4680,"rssi":-79,"SSID":"xxxxxx","ip":"192.168.2.254","mac":"AC:67:B2:36:04:4C","actRec":3,"mhz":433.92,"RTLminRssi":-90,"RTLRssi":-106,"RTLCnt":5,"modules":["RTL_433"]}

@mgx0 Do sensors need to be connected to the DCF77 weather station for the decoding to work? I only have a set of sensors. @mgx0 ; @NorthernMan54 Will RTL_433_ESP send separate messages to the MQTT broker after decoding the sensor readings to OMG (humidity, wind_avg_m_s, ...)? Will it all be in one load? Will autodiscovery work in HA and sensor entities will be created automatically, on their own?

[drejkus]

Hello, would you possibly mind sharing the source code that works with Emos E6106? I'm having troubles making it work myself. Thanks in advance...

[mgx0]

Thank you @mgx0 very much for help. Soon I will try to revive my set and describe the results. Maybe they will be as successful as the implementation of RFLink32.

EDIT:

{"uptime":484,"version":"predok","freemem":226724,"mqttport":"1883","mqttsecure":false,"freestack":4680,"rssi":-79,"SSID":"xxxxxx","ip":"192.168.2.254","mac":"AC:67:B2:36:04:4C","actRec":3,"mhz":433.92,"RTLminRssi":-90,"RTLRssi":-106,"RTLCnt":5,"modules":["RTL_433"]}

@mgx0 Do sensors need to be connected to the DCF77 weather station for the decoding to work? I only have a set of sensors. @mgx0 ; @NorthernMan54 Will RTL_433_ESP send separate messages to the MQTT broker after decoding the sensor readings to OMG (humidity, wind_avg_m_s, ...)? Will it all be in one load? Will autodiscovery work in HA and sensor entities will be created automatically, on their own?

Hi, very sorry for late reply, forgot.

Yes there is a single json message containing all values. Sensor itself including DCF77 works wihtout being connected to the display (emos receiver)

[mgx0]

Hello, would you possibly mind sharing the source code that works with Emos E6106? I'm having troubles making it work myself. Thanks in advance...

Yes, but I don’t want to be off topic here. I have a dirty decoder for mega328 and srx882. If you are interested, ping me at s3030150@gmail and I will send the projec to you

[mgx0]

Lol, I've heard of vampire ethernet taps, but not vampire radios.

Yeah because what you buy on aliexpress under the name cc1101 is a pure vampire crap 😊

[NorthernMan54]

Try the Heltec esp 32 433 MHz board, the next release will support that as wellOn Sep 9, 2022, at 3:16 PM, mgx0 @.***> wrote:

Lol, I've heard of vampire ethernet taps, but not vampire radios.

Yeah because what you buy on aliexpress under the name cc1101 is a pure vampire crap 😊

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>