Update v0.1.8 breaks reading for Silvercrest RollingCode-RemoteControl

[Dattel]

Update between v0.1.7 and v0.1.8 breaks readout from Silvercrest RollingCode-RemoteControl (was formerly recognized as Smoke-GS558)

i fiddled down the problem to a change in pulse_demod.c

https://github.com/NorthernMan54/rtl_433_ESP/compare/v0.1.7...v0.1.8#diff-c3b9cfffc39510a8fed4b5781925ff518ec37a5876f5d50cca1dc1d971d5c45cR313-R314

V0.1.8

  if (s_tolerance <= 0)
    s_tolerance = s_long / 4; // default tolerance is +-25% of a bit period

V0.1.7

  //   if (s_tolerance <= 0)
  //       s_tolerance = s_long / 2.2; // default tolerance is +-45% of a bit

also see here for initial issue report at libary usage: https://github.com/1technophile/OpenMQTTGateway/issues/1609

[Dattel]

it also seems, that the CC1101 goes back into a deaf-state after a couple of hours.... not sure, but i'm trying to evaluate these guess.

[NorthernMan54]

@Dattel Tks for finding this, we have identified this change and one other recent change that has reduced the ability of sx127x and CC1101 devices to receive signals. I'm going to include this in an update to 0.2.0 in the next few days.

[Dattel]

Thanks for quick Feedback...let me know, what i can contribute and If there ist anything i can Test If you are ready :-)

[Dattel]

does that also includes my guessed deaf-state?

-yesterday i flashed OpenMqttGateway1.5.1 in combination with rtl_433 v0.1.7
-last night my receiver got a deaf-state. i repowered it to solve that this morning. -currently i'm testing OpenMqttGateway1.5.1 with rtl_0.1.6 to enclose the responsible codechange for that problem. -I will leave it for the night and if it works fine, i will reflash tomorrow to rtl_0.1.7 an see if i can resproduce the deaf-state

[NorthernMan54]

I presume your using a CC1101 ?

The deaf workaround for a CC1101 has not changed in a long while - https://github.com/NorthernMan54/rtl_433_ESP/blob/353b500092da349638620558c06fff0f9f0a7894/src/rtl_433_ESP.cpp#L434

Also my CC1101 devices are not showing this behaviour ( I had cleared the RTL_433toMQTT topic a few minutes before this

I'm wondering if there are things going on that may be giving similar symptoms.

[Dattel]

yeah, it's a cc1101... i'm still breeding on that... maybe these current deaf-state is a more OpenMqtt-Related-problem... it looks like there is something like a queue getting slower and slower over the time. some signals are comming out to mqtt with a very long delay .... some signals got dropped and MQTT stays is empty.. not quite sure, how to fiddle the reason

[NorthernMan54]

If you watch the SYStoMQTT messages, and freemem etc, they may show a resource leak

Also the serial console may show something

[Dattel]

some update... OpenMqttGateway 1.5.1 with RTL_433 v.0.1.6 works for about 24h without dropouts. i just switched to v.0.1.7 and CC1101 goes deaf after about 2h... :-/

[NorthernMan54]

Anything in SYStoMQTT? What was in the last message ?

[Dattel]

Deaf again over night.... SystoMQTT is comming in

{
  "uptime": 37207,
  "version": "v1.5.1-development",
  "env": "esp32dev-OpenMediaGateway_rtl_433",
  "freemem": 137200,
  "mqttport": "1883",
  "mqttsecure": false,
  "tempc": 51.11111,
  "freestack": 1644,
  "rssi": -59,
  "SSID": "Fratzenbox",
  "BSSID": "xx:xx:xx:xx:xx:xx",
  "ip": "192.168.xx.xx",
  "mac": "4C:11:AE:xx:xx:xx",
  "actRec": 3,
  "mhz": 433.92,
  "RTLRssiThresh": -82,
  "RTLRssi": -80,
  "RTLAVGRssi": -80,
  "RTLCnt": 1290,
  "modules": [
    "RF",
    "rtl_433"
  ]
}

freemem looks also good - so no leak there.

[Dattel]

Deaf again after aprox 1h of runtime.

[NorthernMan54]

Just to start again with the issue

Need to determine if the issue is rtl_433_ESP or OMG, you had mentioned that the OMG device went deaf. So leads me to believe it is an OMG issue

1 - Version of rtf_433_ESP / OMG your running 2 - What board / receiver module 3 - Does the OMG device go silent or is it just rtl_433_ESP that stops receiving ? 4 - What is the LED on the board doing ( in your setup does the LED blink for each received message ? )

[Dattel]

okay, lets sort my mind :-D

Hardware: -Espressive ESP32-wroom-32D Developer Board -Attached CC1101 on 433Mhz

i'm compiling OMG v1.5.1 and tested different RTL-Versions... As the original issue points out, starting between v0.1.7 and v0.1.8 my rolling-code-remote didnt work anymore. I assume, that these probleme should be fixed in the meantime with the latest release of RTL?

So v0.1.7 was the last version for me to work with my remote control, i stayed at OMG1.5.1 with RTLv0.1.7 to wait for a official "go" for the latest RTL release to test.

But after a while i realized, that v0.1.7 stoppes randomly receiving signals. The receiver stays silent, as there are no signals parsed- LED stops blinking, so no signal parsed. i call it the deaf state at these point. The omg itself stays online and still pushing correct SysToMQTT to MQTT. I remember, that the deaf-bugfix resets the receiver after a certain amount of signals? - but it dosnt work anymore. the receiver stays silent for hours till i reboot the device.

I stepped down to RTLv0.1.6, because that was the last working version before i started my update session a few days ago.. So currently i have flashed OMG1.5.1 with RTL0.1.6 and it works fine without deaf-states... if i just switch to RTL0.1.7, the device goes deaf after a random time.

Hope that you understand, what i tried to describe :-D

[NorthernMan54]

Are you able to build with the OMG Development branch ? It has the latest RTL_433_ESP and all the known problems with 1.7+ are resolved

[Dattel]

sure... just switched to development with RTL0.2.1 and will give feedback..

[Dattel]

seems to work... it's still receiving :-D i think we can close the issue at this point Thanks again