RF433 unreliable - only captures 1 of 20 Signals

[Dattel]

Hey, i updated my ESP8266 today with the current Development version but it seems, that the current version only captures only 1 of aprox 20 RF Signals. With earlier versions it was working fine... So i was a bit afraid, that my ESP8266 had some hardware failures and therefore i also tested it with a ESP32 module - same behaviour

I've testes with RXB8 V2 and MX-RM-5V

[env:TEST-esp32dev-rf]
platform = ${com.esp32_platform}
board = esp32dev
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.rc-switch}
build_flags =
  ${com-esp.build_flags}
  ${platformio.build_flags}
  '-DZgatewayRF="RF"'
  '-DGateway_Name="OpenMQTTGateway_ESP32_RF"'

Remark: ${platformio.build_flags} just contains WIFI&MQTT-Config

Did i overlook something? Is there anything i can provide for help?

[1technophile]

Strange there was not so much changes on this part, could you try to revert back to esp32_platform = espressif32@3.1.1

[Dattel]

hi, thanks for your quick reply... I cannot point out since what version it stops working..

I reflashed the device some month weeks ago (not sure to what version since i didn't updated my old local github-copy, since i hardcoded the MQTT server to config and needed to change it) today i realized, that RF signals leads to a reboot, so i decided to completely reflash the device with the latest dev-version. I recently migrated from FHEM to HomeAssistant and the RF-Devices are the last part i would like to bring into Homeassistant.

Here are my current used libs:

Processing TEST-esp32dev-rf (platform: espressif32@3.1.1; board: esp32dev; framework: arduino)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.1.1) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 3.10005.210308 (1.0.5)
 - tool-esptoolpy 1.30000.201119 (3.0.0)
 - toolchain-xtensa32 2.50200.97 (5.2.0)
Converting main.ino
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 34 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <PubSubClient> 2.8.0
|-- <ArduinoJson> 6.18.3
|-- <ArduinoLog> 1.0.3+sha.d13cd80
|-- <WifiManager> 1.0.0+sha.c3ff582
|   |-- <DNSServer> 1.1.0
|   |   |-- <WiFi> 1.0
|   |-- <ESPmDNS> 1.0
|   |   |-- <WiFi> 1.0
|   |-- <WebServer> 1.0
|   |   |-- <WiFi> 1.0
|   |   |-- <FS> 1.0
|   |-- <WiFi> 1.0
|-- <rc-switch> 2.6.2+sha.36dfb45
|-- <EEPROM> 1.0.3
|-- <ESP32 BLE Arduino> 1.0.1
|-- <Wire> 1.0.1
|-- <ArduinoOTA> 1.0
|   |-- <Update> 1.0
|   |-- <WiFi> 1.0
|   |-- <ESPmDNS> 1.0
|   |   |-- <WiFi> 1.0
|-- <DNSServer> 1.1.0
|   |-- <WiFi> 1.0
|-- <ESPmDNS> 1.0
|   |-- <WiFi> 1.0
|-- <WiFi> 1.0
|-- <FS> 1.0
|-- <Preferences> 1.0
|-- <SPI> 1.0
|-- <SPIFFS> 1.0
|   |-- <FS> 1.0
|-- <WiFiClientSecure> 1.0
|   |-- <WiFi> 1.0
|-- <HTTPClient> 1.2
|   |-- <WiFi> 1.0
|   |-- <WiFiClientSecure> 1.0
|   |   |-- <WiFi> 1.0
|-- <Update> 1.0

I also found out that i takes a very long time after reboot, till the very first signal can be received. Sometimes i can receive multiple signals in a row - i pressed each key with a delay of aprox a second.. Sometimes i can press different key's for 30 seconds without any signal beeing captured. I have 3 different Remotes to try (Silvercrest for powerplugs)

Here are some samples from the serial-console with LOG_LEVEL=LOG_LEVEL_TRACE.

************* WELCOME TO OpenMQTTGateway **************
N: OpenMQTTGateway Version: v0.9.8-development
T: Connecting to Fratzenbox
N: WiFi ok with manual config credentials
T: OpenMQTTGateway mac: XXXXXXXXXXXXX
T: OpenMQTTGateway ip: 192.168.178.76    
T: Port: 1883
T: Mqtt server: mqtt.fritz.box
N: RF_EMITTER_GPIO: 12
N: RF_RECEIVER_GPIO: 27
T: ZgatewayRF command topic: home/OpenMQTTGateway_ESP32_RF/commands/MQTTto433
T: ZgatewayRF setup done
T: enableActiveReceiver: 2
N: Switching to RF Receiver
T: mqtt_max_packet_size: 2048
N: OpenMQTTGateway modules: ["RF"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
N: Connected to broker

[...]

T: Rcv. RF
T: RF Task running on core :1
T: isAdupl?
T: RF Entity Discovered, create HA Discovery CFG
T: CreateDiscoverySwitch: RF
T: Announce Device Trigger  homeassistant/device_automation/FCF5C43D2470-8377-RF/config
T: [ OMG->MQTT ] topic: homeassistant/device_automation/FCF5C43D2470-8377-RF/config msg: {"automation_type":"trigger","type":"button_short_press","subtype":"turn_on","topic":"home/OpenMQTTGateway_ESP32_RF/433toMQTT","device":{"identifiers":["FCF5C43D2470"],"via_device":"OpenMQTTGateway_ESP32_RF"}} 
N: Send on /433toMQTT msg {"value":8377,"protocol":3,"length":14,"delay":102,"tre_state":"-","binary":"10000010111001","raw":"4431,940,612,418,1138,407,1122,422,1130,411,1127,420,1126,934,614,415,1125,936,629,915,615,934,626,406,1126,418,1127,932,619,"}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: home/OpenMQTTGateway_ESP32_RF/433toMQTT msg: {"value":8377,"protocol":3,"length":14,"delay":102,"tre_state":"-","binary":"10000010111001","raw":"4431,940,612,418,1138,407,1122,422,1130,411,1127,420,1126,934,614,415,1125,936,629,915,615,934,626,406,1126,418,1127,932,619,"} 
T: Store val: 8377
T: Min ind: 0
T: store code : 8377 / 96840
T: Col: val/timestamp
T: mem code : 8377 / 96840
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: Hey I got a callback home/OpenMQTTGateway_ESP32_RF/433toMQTT
T: isAdupl?
N: no pub. dupl
N: [ MQTT->OMG ]: {"value":8377,"protocol":3,"length":14,"delay":102,"tre_state":"-","binary":"10000010111001","raw":"4431,940,612,418,1138,407,1122,422,1130,411,1127,420,1126,934,614,415,1125,936,629,915,615,934,626,406,1126,418,1127,932,619,"}

[...]

T: Rcv. RF
T: RF Task running on core :1
T: isAdupl?
T: RF Entity Discovered, create HA Discovery CFG
T: CreateDiscoverySwitch: RF
T: Announce Device Trigger  homeassistant/device_automation/FCF5C43D2470-8999-RF/config
T: [ OMG->MQTT ] topic: homeassistant/device_automation/FCF5C43D2470-8999-RF/config msg: {"automation_type":"trigger","type":"button_short_press","subtype":"turn_on","topic":"home/OpenMQTTGateway_ESP32_RF/433toMQTT","device":{"identifiers":["FCF5C43D2470"],"via_device":"OpenMQTTGateway_ESP32_RF"}}
N: Send on /433toMQTT msg {"value":8999,"protocol":3,"length":14,"delay":103,"tre_state":"-","binary":"10001100100111","raw":"5804,925,651,386,1151,398,1152,399,1143,921,650,903,663,375,1152,396,1151,915,648,389,1144,405,1159,907,662,888,668,880,658,"}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: home/OpenMQTTGateway_ESP32_RF/433toMQTT msg: {"value":8999,"protocol":3,"length":14,"delay":103,"tre_state":"-","binary":"10001100100111","raw":"5804,925,651,386,1151,398,1152,399,1143,921,650,903,663,375,1152,396,1151,915,648,389,1144,405,1159,907,662,888,668,880,658,"}
T: Store val: 8999
T: Min ind: 2
T: store code : 8999 / 218083
T: Col: val/timestamp
T: mem code : 8377 / 96840
T: mem code : 4289209 / 212407
T: mem code : 8999 / 218083
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: mem code : 0 / 0
T: Hey I got a callback home/OpenMQTTGateway_ESP32_RF/433toMQTT
T: isAdupl?
N: no pub. dupl
N: [ MQTT->OMG ]: {"value":8999,"protocol":3,"length":14,"delay":103,"tre_state":"-","binary":"10001100100111","raw":"5804,925,651,386,1151,398,1152,399,1143,921,650,903,663,375,1152,396,1151,915,648,389,1144,405,1159,907,662,888,668,880,658,"}

Hope that helps... I you need any more informations, let me know.

Best D

[1technophile]

I tried to reproduce today with a press button and I'm not reproducing the issue, of course the gateway doesn't publish all the signal due to their identification as "duplicates" but I suppose that you already know this. One change that could impact the detection capabilities is this one also. Could you try to set RCSwitch::nSeparationLimit = 4300; into RCSwitch.cpp and see if you have a better behavior?

Also, you may check that you don't have other RF devices "spamming" the band but I suppose this is not the case as previous versions are working fine.

[Dattel]

Brilliant!..... changing nSeparationLimit immediately fixes the problem for me.. committed on 19 Jul 2020 ... uh - oh thats a long time ago

Duplicates is not a problem for me - i use 3 Silvercrest remotes for socket-switches with a 4-rolling-code system. So even if i press the same key again, only every 5th keypress will result in a duplicate message.. I have 2 newer versions of the remote and one very old. The dialect is very similar but the length of the transmission changed a bit between the different versions. (but OMG catches them all 👍 )

I validated that the remotes are working properly, because the CC1101 always catches the transmissions correct. Nevertheless, i would like to stay on MX-RM-5V and FS1000A for these remotes because it was a reliable system here in the past and i'm not yet ready to send through the CC1101 replacement. :-)

So what now.... do i need to change nSeparationLimit manually for the next releases? There must be a reason, why you changed that.

[1technophile]

Thanks for the feedback, this change enables to support self-powered button that bursts the signal in a short time frame but I was not aware that it could cause regressions. I can add a macro to specify it when you build the firmware if you want, I may also revert back to the default and propose the macro only for those who want to use the DIGOO SD10.

[Dattel]

whatever you think is the best solution for that :-D

i just saw me having a list of all things in lib's i have to change, if i update OMG since CC1101 also having a issue for me...

[Dattel]

BTW: same version of OMG but changed from the board from ESP32 to ESP8266 NodeMCU causes exception on receiving RF-Codes immediately:

N: WiFi ok with manual config credentials
N: RF_EMITTER_GPIO: 12 
N: RF_RECEIVER_GPIO: 14
N: Switching to RF Receiver
N: OpenMQTTGateway modules: ["RF"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
N: Connected to broker
N: Send on /SYStoMQTT msg {"uptime":5,"version":"v0.9.8-development","freemem":39456,"mqttport":"1883","mqttsecure":false,"rssi":-72,"SSID":"XXX","ip":"192.168.178.10","mac":"XXXXXX","actRec":2,"modules":["RF"]}
N: Send on /433toMQTT msg {"value":4597520,"protocol":5,"length":24,"delay":504,"tre_state":"-","binary":"010001100010011100010000","raw":"7074,480,1033,989,538,490,1036,488,1034,490,1035,986,540,986,540,488,1050,485,1036,488,1037,984,544,485,1039,485,1041,981,543,981,545,981,557,482,1043,481,1043,481,1042,979,546,483,1041,483,1041,483,1042,482,1048,"}
N: no pub. dupl
N: [ MQTT->OMG ]: {"value":4597520,"protocol":5,"length":24,"delay":504,"tre_state":"-","binary":"010001100010011100010000","raw":"7074,480,1033,989,538,490,1036,488,1034,490,1035,986,540,986,540,488,1050,485,1036,488,1037,984,544,485,1039,485,1041,981,543,981,545,981,557,482,1043,481,1043,481,1042,979,546,483,1041,483,1041,483,1042,482,1048,"}
N: no pub. dupl
N: no pub. dupl
N: no pub. dupl

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Exception (28):
epc1=0x402010d5 epc2=0x00000000 epc3=0x00000000 excvaddr=0x0046271c depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3ffffa90 end: 3fffffc0 offset: 0190
3ffffc20:  3ffffeb8 00000020 00000007 00000000
3ffffc30:  00ff0000 3fff182f 3ffffe50 40202a00
3ffffc40:  3fff0e44 3fff182f 3ffffe50 40206b7e  
3ffffc50:  3ffffc78 3ffffc78 3ffffe78 3ffffe78
3ffffc60:  00000000 00000218 00462710 00000000
3ffffc70:  3ffe9008 00000000 3ffffd30 401003b0
3ffffc80:  00000800 ffffffff ffffffff 00000000  
3ffffc90:  00000003 00000003 00302075 401003b0
3ffffca0:  00000000 4bc6a7f0 628f5c28 ffffffff
3ffffcb0:  401008bc 00000001 00000000 401003b0  
3ffffcc0:  e003203d 00000020 c9fbe76c ffffffff
3ffffcd0:  401008bc 00000001 00000000 401008a8
3ffffce0:  e003203d 00000020 401006a1 ffffffff
3ffffcf0:  401008bc 00000001 00000000 401008a8  
3ffffd00:  00000005 00000000 00000020 4010058c
3ffffd10:  4021f035 00000009 00000005 401003b0
3ffffd20:  3ffea0d5 4010595f 3ffedb10 00000022  
3ffffd30:  40103253 3ffedb10 3fffc258 4000050c
3ffffd40:  00007fff 00eff307 3ffee418 ffffffff
3ffffd50:  401008bc 00000001 00000000 401008a8
3ffffd60:  e003603d 00000020 401038ea 00000100  
3ffffd70:  3ffea980 7fffffff 00002200 00000001
3ffffd80:  00000001 00004288 00000020 00000022
3ffffd90:  3fffc200 401007dc 3fffc258 4000050c  
3ffffda0:  40209f99 00000030 00000010 ffffffff
3ffffdb0:  4020a0ae 3fff0e0c 00000001 00000000
3ffffdc0:  00004bc6 00000000 00000000 fffffffe
3ffffdd0:  00000000 3fffc6fc 00000000 3fff0e0c  
3ffffde0:  3fff1804 00003d6e 00000029 00000030
3ffffdf0:  000000be 3fffc6fc 82607052 00000000
3ffffe00:  00eff33e 3fff15dc 00470676 00000030  
3ffffe10:  00000000 4a168160 00000000 fffffffe
3ffffe20:  000047ec 3fffc6fc 9e0a8160 00000000
3ffffe30:  00eff0ea 3fff15dc 00000001 00000030
3ffffe40:  00000173 00000173 3ffe87c4 40100e17  
3ffffe50:  402071e8 3fff1804 40209ab0 00000001
3ffffe60:  3fff14b4 00000020 3fff14b4 40100ff6
3ffffe70:  00000000 00000000 3fff0e44 00000000  
3ffffe80:  00000001 3fff0e4c a9fb0100 3ffffc50
3ffffe90:  37393534 00303235 4bc6a7f0 40225d2e
3ffffea0:  00003d6e 00000000 3fff0e0c 40209fe4  
3ffffeb0:  00003d6e 3fff1804 0000001e 00000001
3ffffec0:  00003d6e 3fff1804 00000030 4020a0ae
3ffffed0:  00000000 3ffffc68 3ffffc50 40206db4
3ffffee0:  00000027 3fffff00 00000003 3fff184e  
3ffffef0:  00000001 00000007 00000020 3fff184e
3fffff00:  3fff0e44 3fff0e4b 3fff182f 40206cbe  
3fffff10:  0000001e 00000026 00000028 00000001
3fffff20:  00000001 00003d6e 3ffef7c0 40219ae8
3fffff30:  00000001 00003d6e 3ffef7c0 40207361
3fffff40:  00000007 3fff184e 3fff182f 00000000
3fffff50:  3fffdad0 3fff0854 3ffefc01 402147d8  
3fffff60:  00000003 0000001e 00000029 00000004
3fffff70:  3fff0a54 3ffef7c0 00003d6e 00000000
3fffff80:  3ffef850 3ffef7c0 00003d6e 402063e0  
3fffff90:  3fffdad0 00000000 3ffeff88 3ffeff9c
3fffffa0:  3fffdad0 00000000 3ffeff88 40210ce4
3fffffb0:  feefeffe feefeffe 3ffe87c0 40101465  
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v000767e0
~ld

i extracted the exception for you :-D

Exception 28: LoadProhibited: A load referenced a page mapped with an attribute that does not permit loads
PC: 0x402010d5
EXCVADDR: 0x004ea39c

Decoding stack results
0x40228d4a: pbuf_free_LWIP2 at core/pbuf.c line 786

[Dattel]

-> Exception Source identified:

'-DsimplePublishing=true' causes that reboot for me

[env:nodemcuv2-OpenMediaGatewayTEST]
platform = ${com.esp8266_platform}
board = nodemcuv2
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.rc-switch}
  ${libraries.esp8266_mdns}
build_flags =
  ${com-esp.build_flags}
  ${platformio.build_flags}
  '-DZgatewayRF="RF"'
  '-DGateway_Name="OpenMediaGatewayTEST"'
  '-DRF_RECEIVER_GPIO=14' #D5
  '-DRF_EMITTER_GPIO=12' #D6
  '-DsimplePublishing=true'
board_build.flash_mode = dout

i think that was something i newly enabled - but i think i can dispense on that

[Dattel]

HI again.. any idea, what causes this issue??

during initialization, there is an error line: E: ERROR: unsupported receiver 4 Looking on the code, that should be no real issue because these message always pops out, ifndef ARDUINO_AVR_UNO

There seems to be something wrong, during switching between receiving and sending.. I figured out, that if i send some RF-Message through OMG, the receiver will not come back online property. It no longer receives RF-Signals.

WiFi ok with manual config credentials
N: Setup BME280 on adress: 0x76
N: Bosch BME280 successfully initialized: 0x60
N: RF_EMITTER_GPIO: 12
N: RF_RECEIVER_GPIO: 14
E: ERROR: unsupported receiver 4
N: OpenMQTTGateway modules: ["BME280","RF"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
N: Connected to broker
N: Send on /SYStoMQTT msg {"uptime":5,"version":"v0.9.8-development","freemem":38232,"mqttport":"1883","mqttsecure":false,"rssi":-82,"SSID":"XXXX","ip":"192.168.178.10","mac":"XXXXXX","actRec":4,"modules":["BME280","RF"]}
N: Send on /433toMQTT msg {"value":4372912,"protocol":5,"length":24,"delay":498,"tre_state":"-","binary":"010000101011100110110000","raw":"7007,636,886,1097,429,619,903,595,930,596,916,591,933,1073,475,561,968,1086,446,599,925,1065,452,1068,456,1065,459,575,949,560,960,1058,499,1021,504,530,995,1071,455,1057,469,522,992,536,993,566,953,551,991,"}
N: no pub. dupl
N: [ MQTT->OMG ]: {"value":4372912,"protocol":5,"length":24,"delay":498,"tre_state":"-","binary":"010000101011100110110000","raw":"7007,636,886,1097,429,619,903,595,930,596,916,591,933,1073,475,561,968,1086,446,599,925,1065,452,1068,456,1065,459,575,949,560,960,1058,499,1021,504,530,995,1071,455,1057,469,522,992,536,993,566,953,551,991,"}
N: no pub. dupl
N: [ MQTT->OMG ]: {"value":4557892,"protocol":5,"length":24,"delay":520,"repeat":5}
N: RF Protocol:5
N: RF Pulse Lgth: 520
N: Bits nb: 24
N: MQTTtoRF OK
N: Send on /433toMQTT msg {"value":4557892,"protocol":5,"length":24,"delay":520,"repeat":5}
E: ERROR: unsupported receiver 4
N: [ MQTT->OMG ]: {"value":4557892,"protocol":5,"length":24,"delay":520,"repeat":5}

[Dattel]

Update: on boottime, the correct receiver is enabled..

once i send data through the transmitter, i need to reenable the correct receiver with the MQTT-Message... mosquitto_pub -t "home/OpenMQTTGateway/commands/MQTTto433" -m '{"active":true}'

these setting will to be stored on EEPROM so these step only need to be done once for the device.. (now i know, it can be predefined using activeReceiver=2).

Would be fine to have a build-flag for that. Thanks

[NorthernMan54]

@Dattel - going to need to dig further into this, but when I wrote the original receiver switching code it should default to that module when you have a single receiver defined. And when you have multiple their is some logic around which one is default. And when you transmit, it should return to the same module.

My first thought is that this pull request that enables using the eprom to store the results causes the issue. #1091

And it is being triggered by changing the defined/included receivers between builds. Did you previously have a build that enabled gatewayRF2 ? That is receiver 4

Am thinking this is what happened

1) Build with RF2 enabled, and 4 was stored on the flash as the active receiver

2) Build with only RF enabled, and during boot it finds the stored active receiver (4) in the flash, and the attempt is made to enable receiver 4, but as it wasn't included in the build you get the error message.

3) When you transmit, it switches back to the active receiver, which is still 4 hence the issue.

@nerk does this make sense ?

[nerk]

@NorthernMan54 @Dattel Definitely, this is a problem. Flash must be completely erased before flashing in such a case. This is unfortunate. Is there a quick way to enumerate available receivers? A simple solution would be to ignore stored receivers which are not available anymore and fallback to the default receiver.

[NorthernMan54]

@nerk - Good thought, am thinking some logic similar to this section put into the flash reading code would enumerate the available receivers. https://github.com/1technophile/OpenMQTTGateway/blob/00709675bc42e09f303bb4784032ac17f248c4c5/main/config_RF.h#L210

[Dattel]

@NorthernMan54, you are right... since i was not sure, which receiving-module is the best for my usecase, i tried them all... one by one (RF,RF2,Pilight) - mostly compiled OMG with only one active receiver in the past. nevertheless I played around with the switching commands, because my signals from remote were ignored - or the OMG capture was very unreliable. As you can read above, the reason for the unreliable capture was another bug :-D

If the problem is already known, i'm able to circumvent that now :-D ...

[nerk]

@NorthernMan54 Pull request #1115 only restores an active receiver if it is really available. If it is not available, it falls back to the default behavior.

[NorthernMan54]

I just looked at the change, and it looks good.