Closed melyux closed 7 months ago
Actually, I see that OMG's env:esp32dev-rtl_433
build has '-DNO_DEAF_WORKAROUND=true'
. I guess I didn't see the "NO_" there and couldn't conceive why they would turn that workaround off by default in the main RTL_433_ESP build. I'll test with that unset as '-UNO_DEAF_WORKAROUND'
and see how it goes.
Never mind, still happens with that unset too.
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":26896,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":450,"msgblck":0,"maxq":2,"minmem":52820,"tempc":52.78,"freestck":1900,"eth":false,"rssi":-53,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":27016,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":452,"msgblck":0,"maxq":2,"minmem":52820,"tempc":52.78,"freestck":1900,"eth":false,"rssi":-55,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":27136,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":454,"msgblck":0,"maxq":2,"minmem":52820,"tempc":52.78,"freestck":1900,"eth":false,"rssi":-54,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":27256,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":456,"msgblck":0,"maxq":2,"minmem":52820,"tempc":52.78,"freestck":1900,"eth":false,"rssi":-53,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":27376,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":458,"msgblck":0,"maxq":2,"minmem":52820,"tempc":52.78,"freestck":1900,"eth":false,"rssi":-55,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-92,"rssi":-101,"avgrssi":-101,"count":8985}
N: Send on /SYStoMQTT msg {"uptime":27496,"version":"version_tag","env":"xxx-xxxxx-xxx","freemem":135272,"mqttp":"1883","mqtts":false,"msgprc":460,"msgblck":0,"maxq":2,"minmem":52820,"tempc":53.33,"freestck":1900,"eth":false,"rssi":-54,"SSID":"xxxxxx","BSSID":"xx:xx:xx:xx:xx:xx","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","modules":["WebUI","RF","RF2","RTL_433"]}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
To see if the deaf workaround is truly the issue, what about adding a logprint around here ?
Just my luck, been running it for 2 days with the logging line added and it hasn't gone deaf yet. It was doing it like 5 times a day when I filed this
Still going... I did erase the flash on the ESP, so no idea what happened. So far so good. Will close unless it happens again
Analysis
I'm using OpenMQTTGateway to utilize this library and I got it working perfectly with my two FSK sensors on 433MHz. But every few hours, for exactly an hour, the ESP32 running OMG will stop getting data from both sensors for exactly one hour. The intervals between the deafness vary, but the deafness length is always 1 hour.
I'm assuming this caused by an internal check in this library to reset the CC1101 when it goes deaf? But yeah that's happening.
Any suggestions? I'm open to ditching the CC1101 if it's hopeless and switching to an equivalent radio, but not sure which one.
Expected Behavior
The library decodes data from the devices without any intervals of no data.
Steps To Reproduce
env:esp32dev-rtl_433
but with these changed options:Logs
Configuration
Environment
Process Supervisor
not applicable
Additional Context
No response