OpenMQTTGateway
OpenMQTTGateway copied to clipboard
1technophile
Upgraded Lilygo Lora T3 v1.6.1 to OMG 1.7 from 1.6 and it is repeatedly rebooting
Before submitting a problem please check the troubleshooting section https://docs.openmqttgateway.com/upload/troubleshoot.html
Describe the bug I have several Lilygo LORA t3 v1.6.1 boards that are listening on the 433 mhz frequency. Each of these boards had v1.6 of OMG installed on them and was working fine.
Today I saw there was an update available for OMG to 1.7 so I used the built in WebUI to initiate an upgrade to v1.7. Immediately after the upgrade I noticed the boards were repeatedly rebooting.
The screen reports:
- OMG Logo
- Wifi connected
- URL...
- MQTT connected
- SYS MQTT
- Then it receives & forwards a few messages, and suddenly reboots back to the OpenMQTTGateway logo and repeats the process.
I took one of the malfunctioning devices, unplugged it, let it sit for a few minutes and plugged it back in and it exhibited the same behavior.
I then connected it via USB to my laptop and reflashed it with 1.7 via Chrome (checking the checkbox to erase the flash). I was able to connect to the self hosted wifi connection & setup my Wifi & MQTT settings, but once I saved the settings the device started the same boot loop again.
During one of the boot cycles I was able to grab the console log via the web interface:
N: OpenMQTTGateway URL: http://192.168.1.215/
N: ZwebUI setup done
N: RF Config not found using default
N: Enable RTL_433 Receiver: 433.92Mhz
N: ZgatewayRTL_433 setup done
N: OpenMQTTGateway modules: ["LilyGo_SSD1306","WebUI","rtl_433"]
N: ************** Setup OpenMQTTGateway end **************
W: MQTT connection...
N: Connected to broker
N: Send on /RFtoMQTT msg {"active":3,"frequency":433.92,"rssithreshold":-82,"rssi":-86,"avgrssi":0,"count":10,"ookthreshold":15}
N: Update check, free heap: 104572N: Update check done, free heap: 64828N: Send on /SYStoMQTT msg {"uptime":18,"version":"v1.7.0","disc":true,"ohdisc":false,"env":"lilygo-rtl_433","freemem":107044,"mqttp":"1883","mqtts":false,"msgprc":0,"msgblck":0,"maxq":0,"minmem":102248,"tempc":53.89,"freestck":5980,"eth":false,"rssi":-62,"SSID":"1qw0pou","BSSID":"80:2A:A8:47:79:98","ip":"192.168.1.215","mac":"64:B7:08:89:FE:08","modules":["LilyGo_SSD1306","WebUI","rtl_433"]}
N: Send on /SSD1306toMQTT msg {"onstate":true,"brightness":50,"display-flip":true,"idlelogo":true,"log-oled":false,"json-oled":true}
N: Send on /WebUItoMQTT msg {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: Send on /RLStoMQTT msg {"latest_version":"v1.7.0","title":"OpenMQTTGateway","release_url":"https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.7.0","installed_version":"v1.7.0","entity_picture":"https://github.com/1technophile/OpenMQTTGateway/raw/development/docs/img/Openmqttgateway_logo_mini_margins.png","release_summary":""}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/7575 msg {"model":"Acurite-Tower","id":7575,"channel":"A","battery_ok":1,"temperature_C":19.4,"humidity":38,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-76,"duration":250000}
N: Send on /RTL_433toMQTT/Acurite-Tower/C/15652 msg {"model":"Acurite-Tower","id":15652,"channel":"C","battery_ok":0,"temperature_C":19.6,"humidity":44,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-48,"duration":127000}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/6190 msg {"model":"Acurite-Tower","id":6190,"channel":"A","battery_ok":1,"temperature_C":18.6,"humidity":48,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-80,"duration":211000}
I am not sure if it is related, but my MQTT base topic is set to 433_direct/raw/, which I know is non-standard.
To Reproduce Steps to reproduce the behavior:
- Install OMG 1.7 on a Lilygo LORA T3 v1.6.1
- Configure Wifi & MQTT server settings
- Once the device restarts from the settings change, it will reboot after receiving messages.
Expected behavior I expect the device to not repeatedly reboot.
Screenshots If applicable, add screenshots to help explain your problem. Video link showing the issue - https://photos.app.goo.gl/hJ7EdvSELMk9ZLGU7
Environment (please complete the following information):
- OpenMQTTGateway version used v1.7.0
- Lilygo LORA T3 v1.6.1
Additional context Add any other context about the problem here.
- You should not have a compilation error if you use the versions of the libraries linked into the libraries folder, this badges show you the state of the compilation
- If you are not sure this is a bug or an enhancement post your question to the forum below
Thanks for such a detailled description. Could you share the message from the serial console just before the reboot please?
Accidentally used my work account above, same person here. Took me a little bit to figure out the baud rate (I think it is 115200 ? )
I used PuTTY and the line wrapping seems a bit funky in places, but this is what is spit out right before the reboot:
N: Send on /RTL_433toMQTT/Acurite-Tower/A/7575 msg {"model":"Acurite-Tower","id":7575,"channel":"A","battery_ok":1,"temperature _C":19,"humidity":38,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-55,"duration":122000}
N: Sen d on /RTL_433toMQTT/Acurite-Tower/A/8623 msg {"model":"Acurite-Tower","id":8623,"channel":"A","battery_ok":1,"temperature_C":7.5,"humidity":41,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-64,"duration":122000}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/5812 msg {"model":"Acurite-T ower","id":5812,"channel":"A","battery_ok":1,"temperature_C":8.400001,"humidity":66,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Light ning, 899 Rain, 3N1, Atlas","rssi":-51,"duration":278000}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/6190 msg {"model":"Acurite-Tower","id":6190,"channel":"A","battery_ok":1,"temperature_C ":18.3,"humidity":48,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-62,"duration":126000}
N: Sen d on /RTL_433toMQTT/Acurite-Tower/A/6248 msg {"model":"Acurite-Tower","id":6248,"channel":"A","battery_ok":0,"temperature_C":16.9,"humidity":42,"mic":"CHECKSUM","protocol":"Acurite 592TX R Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-73,"duration":134000}
N: Send on /RTL_433toMQTT/Acurite-Tower/C/2056 msg {"model":"Acurite- Tower","id":2056,"channel":"C","battery_ok":1,"temperature_C":18.3,"humidity":47,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightnin g, 899 Rain, 3N1, Atlas","rssi":-80,"duration":379000}
N: Send on /RTL_433toMQTT/Acurite-Tower/C/15652 msg {"model":"Acurite-Tower","id":15652,"channel":"C","battery_ok":0,"temperature_C" :18.8,"humidity":45,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-50,"duration":117996}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/13612 msg {"model":"Acurite-Tower","id":13612,"channel":"A","battery_ok":0,"temperature_C":17.5,"humidity":45,"mic":"CHECKSUM","protocol":"Acurite 592T XR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-81,"duration":173000}
N: Send on /RTL_433toMQTT/Acurite-Tower/A/7575 msg {"model":"Acurite -Tower","id":7575,"channel":"A","battery_ok":1,"temperature_C":19,"humidity":38,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning , 899 Rain, 3N1, Atlas","rssi":-56,"duration":228000}
Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (rtl_433_Decoder)
Core 1 register dump:
PC : 0x400d7910 PS : 0x00060836 A0 : 0x800d7cd6 A1 : 0x3ffe0bc0
A2 : 0x3ffe0bf8 A3 : 0x3ffe1380 A4 : 0x00060820 A5 : 0x00060823
A6 : 0x00060823 A7 : 0x00000001 A8 : 0x800d7910 A9 : 0x3ffe0b90
A10 : 0x3ffe0c10 A11 : 0x3ffe0bf8 A12 : 0x00000300 A13 : 0x3ffe1380
A14 : 0x007bfb48 A15 : 0x003fffff SAR : 0x0000001b EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000 LBEG : 0x40089de0 LEND : 0x40089df6 LCOUNT : 0x00000000
Backtrace: 0x400d790d:0x3ffe0bc0 0x400d7cd3:0x3ffe0bf0 0x400d7e72:0x3ffe1270 0x400d7ea2:0x3ffe1290 0x400d7ed9:0x3ffe12b0 0x400de58d:0x3ffe12d0 0x40127dd5:0x3ffe16d0 0x401d7662:0x3ffe1710 0x4011abdb:0x3ffe1730 0x401293a7:0x3ffe3190 0x4012a205:0x3ffe31b0 0x40128130:0x3ffe31f0 0x400fd80f:0x3ffe3220
ELF file SHA256: e59a68d516c7b5a8
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4
N:
************* WELCOME TO OpenMQTTGateway **************
[ 169][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: SYS config not found
N: SSD1306 config initialised
[ 171][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No SSD1306 config to load
N: Setup SSD1306 Display end
N: OpenMQTTGateway Version: v1.7.0
...
Still crashed, it seems to happen at kinda random intervals. The first crash happened very shortly after the settings got saved & it rebooted, the second crash took ~1 minute before it crashed:
N: Send on /RTL_433toMQTT/Acurite-Tower/C/7425 msg {"model":"Acurite-Tower","id":7425,"channel":"C","battery_ok":0,"temperature_C":20.6,"humidity":55,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-72,"duration":124001}
E: [ WebUI ] webUIQueue full, discarding signal RTL_433toMQTT
N: Send on /RTL_433toMQTT/Acurite-Tower/A/5476 msg {"model":"Acurite-Tower","id":5476,"channel":"A","battery_ok":1,"temperature_C":17.6,"humidity":43,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-65,"duration":118000}
E: [ WebUI ] webUIQueue full, discarding signal RTL_433toMQTT
Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (rtl_433_Decoder)
Core 1 register dump:
PC : 0x400d7910 PS : 0x00060836 A0 : 0x800d7cd6 A1 : 0x3ffe0940
A2 : 0x3ffe0978 A3 : 0x3ffe1100 A4 : 0x00060820 A5 : 0x00060823
A6 : 0x00060823 A7 : 0x00000001 A8 : 0x800d7910 A9 : 0x3ffe0910
A10 : 0x3ffe0990 A11 : 0x3ffe0978 A12 : 0x00000300 A13 : 0x3ffe1100
A14 : 0x007bfb48 A15 : 0x003fffff SAR : 0x00000018 EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000 LBEG : 0x40089de0 LEND : 0x40089df6 LCOUNT : 0x00000000
Backtrace: 0x400d790d:0x3ffe0940 0x400d7cd3:0x3ffe0970 0x400d7e72:0x3ffe0ff0 0x400d7ea2:0x3ffe1010 0x400d7ed9:0x3ffe1030 0x400de58d:0x3ffe1050 0x40127dd5:0x3ffe1450 0x401d7662:0x3ffe1490 0x4011abdb:0x3ffe14b0 0x401293a7:0x3ffe2f10 0x4012a205:0x3ffe2f30 0x40128130:0x3ffe2f70 0x400fd80f:0x3ffe2fa0
ELF file SHA256: e59a68d516c7b5a8
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4
N:
************* WELCOME TO OpenMQTTGateway **************
[ 172][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: SYS config not found
N: SSD1306 config initialised
[ 174][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No SSD1306 config to load
N: Setup SSD1306 Display end
N: OpenMQTTGateway Version: v1.7.0
{
"mqtt_server": "192.168.1.127",
"mqtt_port": "1883",
"mqtt_user": "mqtt_hass",
"mqtt_pass": "REDACTED",
"mqtt_topic": "home/",
"gateway_name": "OMG_lilygo_rtl_433_ESP_2",
"mqtt_broker_secure": false,
"mqtt_broker_cert": "",
"mqtt_ss_index": 0,
"ota_server_cert": "",
"ota_pass": "REDACTED"
}N: Config loaded from flash
*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:[2] Added Parameter: cert
*wm:[2] Added Parameter: name
*wm:[2] Added Parameter: topic
*wm:[2] Added Parameter: ota
N: Attempting Wifi connection with saved AP: 0
[ 4450][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No WebUI config to load
N: OpenMQTTGateway URL: http://192.168.1.215/
N: ZwebUI setup done
[
Other background, not sure how relevant any of it is. I have ~25 Acurite temperature // humidity sensors. Each sensor sends out a reading roughly once every 15 seconds. Also I am in a somewhat dense suburban area that picks up a lot of stray noise from neighbors devices.
Could you try this firmware please? lilygo-rtl433-firmware.zip
Erase the credentials of the board with the WebUI Connect to the WiFi Manager portal Click Update Select the file above unzipped Update
And share if you have the same behavior.
Updated:
Still crashed:
N: Send on /RTL_433toMQTT/Acurite-Tower/A/15411 msg {"model":"Acurite-Tower","id":15411,"channel":"A","battery_ok":1,"temperature_C":4.4,"humidity":40,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-70,"duration":117996}
E: [ WebUI ] webUIQueue full, discarding signal RTL_433toMQTT
N: Send on /RTL_433toMQTT/Acurite-Tower/A/7575 msg {"model":"Acurite-Tower","id":7575,"channel":"A","battery_ok":1,"temperature_C":19.1,"humidity":38,"mic":"CHECKSUM","protocol":"Acurite 592TXR Temp/Humidity, 592TX Temp, 5n1 Weather Station, 6045 Lightning, 899 Rain, 3N1, Atlas","rssi":-49,"duration":180000}
Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception).
Debug exception reason: Stack canary watchpoint triggered (rtl_433_Decoder)
Core 1 register dump:
PC : 0x400d7914 PS : 0x00060836 A0 : 0x800d7cda A1 : 0x3ffe0a80
A2 : 0x3ffe0ab8 A3 : 0x3ffe1240 A4 : 0x00060820 A5 : 0x00060823
A6 : 0x00060823 A7 : 0x00000001 A8 : 0x800d7914 A9 : 0x3ffe0a50
A10 : 0x3ffe0ad0 A11 : 0x3ffe0ab8 A12 : 0x00000300 A13 : 0x3ffe1240
A14 : 0x007bfb48 A15 : 0x003fffff SAR : 0x0000001a EXCCAUSE: 0x00000001
EXCVADDR: 0x00000000 LBEG : 0x40089de0 LEND : 0x40089df6 LCOUNT : 0x00000000
Backtrace: 0x400d7911:0x3ffe0a80 0x400d7cd7:0x3ffe0ab0 0x400d7e76:0x3ffe1130 0x400d7ea6:0x3ffe1150 0x400d7edd:0x3ffe1170 0x400de591:0x3ffe1190 0x40127dd9:0x3ffe1590 0x401d7666:0x3ffe15d0 0x4011abdf:0x3ffe15f0 0x401293ab:0x3ffe3050 0x4012a209:0x3ffe3070 0x40128134:0x3ffe30b0 0x400fd813:0x3ffe30e0
ELF file SHA256: fcb3515c7d3ccedf
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4
N:
************* WELCOME TO OpenMQTTGateway **************
[ 172][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: SYS config not found
N: SSD1306 config initialised
[ 174][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No SSD1306 config to load
N: Setup SSD1306 Display end
N: OpenMQTTGateway Version: version_tag
{
"mqtt_server": "192.168.1.127",
"mqtt_port": "1883",
"mqtt_user": "mqtt_hass",
"mqtt_pass": "REDACTED",
"mqtt_topic": "home/",
"gateway_name": "OMG_lilygo_rtl_433_ESP_2",
"mqtt_broker_secure": false,
"mqtt_broker_cert": "",
"mqtt_ss_index": 0,
"ota_server_cert": "",
"ota_pass": "REDACTED"
}N: Config loaded from flash
*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:[2] Added Parameter: cert
*wm:[2] Added Parameter: name
*wm:[2] Added Parameter: topic
*wm:[2] Added Parameter: ota
N: Attempting Wifi connection with saved AP: 0
N: Attempting Wifi connection with saved AP: 1
E (5224) wifi:sta is connecting, return error
[ 2428][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
N: Attempting Wifi connection with saved AP: 2
E (6233) wifi:sta is connecting, return error
[ 3437][E][WiFiSTA.cpp:317] begin(): connect failed! 0x3007
[ 6471][E][Preferences.cpp:50] begin(): nvs_open failed: NOT_FOUND
N: No WebUI config to load
N: OpenMQTTGateway URL: http://192.168.1.215/
N: ZwebUI setup done
One more small update here, I reverted to 1.6.0 and it seems to be running fine again. (At least, it has run for ~5 minutes without any crashes, which is longer than it ever ran on 1.7.0)
I am still completely willing to help out w/ testing any other firmware you have, just wanted to add another data point that downgrading via the captive portal got me running again.
Humm Debug exception reason: Stack canary watchpoint triggered (rtl_433_Decoder)
The rtl_433_Decoder stack size is set here
https://github.com/NorthernMan54/rtl_433_ESP/blob/3fea1cf678212ea5ef70e38f625bc8505f73bb28/src/signalDecoder.cpp#L38
Will need to do some regression testing with 1.7 to see what happened to trigger the stack overflow
Would it help if I provided a log of almost all MQTT messages sent from my various OMG 433 receivers?
Short background:
I have 4x Lilygo devices flashed with the OMG 433 firmware. I have a service that is logging all OMG 433 MQTT messages for the past week to a database, and I can probably create a CSV of topic, message
Long background: I also have ~25 acurite temperature // humidity sensors all over the house & outside. Each sensor sends a message about ~15 seconds. Each message is picked up by typically at least 2-3 of the receivers, if not all of them.
This created a massive torrent of MQTT messages, so I wrote a small service ( https://github.com/pvince/omg-acurite-filter ) that filters out bad readings, throttles the messages, and forwards them to Home Assistant.
In debugging that service I have found it useful to have a log of all messages the service received so I could replay problem scenarios, I should be able to go back to before I upgraded and dump out an hour or so of typical data.
Could you share the logs with TRACE log level please? You can change it in the WebUI.
Not sure what I would do with that data, as the library does not have the ability to inject those message. But thank you for the offer.
Between OMG 1.6 and 1.7 the only differences within the rtl_433_ESP library are - https://github.com/NorthernMan54/rtl_433_ESP/compare/v0.3.0...v0.3.1
Looking back those changes, there is nothing obvious that would trigger the canary as no changes were made to the rtl_433_Decoder function.
If you request a status message from rtl_433_ESP, it should respond with the stack HWM.
OMG 1.6 rtl_433 status request
home/OMG_4C7525A8D5DC/commands/MQTTtoRTL_433 {"status":1}
OMG 1.7 Status Request https://docs.openmqttgateway.com/use/rf.html#rtl-433-device-decoders
With 1.6 response is on the topic - home/OMG_4C7525A8D5DC/RTL_433toMQTT/status
{"model":"status","protocol":"rtl_433_ESP status message","modulation":"OOK","RTLRssi":-99,"RTLAVGRssi":-101,"RTLRssiThresh":-92,"signalRssi":-89,"RTLOOKThresh":15,"train":1,"RTLCnt":958117,"totalSignals":12,"signalRatio":0,"ignoredSignals":11,"unparsedSignals":0,"StackHWM":3132,"RTL_HWM":244,"DCD_HWM":1224,"freeMem":117492,"_enabledReceiver":1,"receiveMode":0}
In that status message, DCD_HWM is the stack that had the canary issue. Watching that over time with 1.7 versus 1.6 would be very interesting.
PS - That is from my test Lilygo board, uptime is 2471102 ( last power flicker here )
{"uptime":2471102,"version":"North-LilyGo-v1.5.0-70-g8624836b[localDev]","discovery":false,"ohdiscovery":false,"env":"North-LilyGo","freemem":117524,"mqttport":"1883","mqttsecure":false,"minfreemem":25520,"tempc":51.11111,"freestack":3132,"rssi":-20,"SSID":"The_Beach","BSSID":"20:C9:D0:1A:CA:85","ip":"192.168.1.69","mac":"4C:75:25:A8:D5:DC","actRec":3,"mhz":433.92,"RTLRssiThresh":-92,"RTLRssi":-95,"RTLAVGRssi":-101,"RTLCnt":958220,"RTLOOKThresh":15,"modules":["LILYGO_OLED","WebUI","BME280","rtl_433"]}
Attached the logs from the latest session after enabling 'TRACE' level logging.
Note: This is using the firmware provided by @1technophile last night. I can redo this w/ the official 1.7.0 firmware if desired.
Thanks, no need to redo it, the difference was only to decrease the minimum memory trigger for reboot.
Could you try to deactivate discovery please ?
Turned off discovery, still crashing. I think the log level reset itself back to whatever the default is for a period of time, but I think I managed to re-enable the logging back to TRACE for at least some of this log.
I have the same problem. How do you revert to v1.6 when it constantly crashes and reboots? I tried to supply the URL: https://github.com/1technophile/OpenMQTTGateway/releases/download/v1.6.0/lilygo-rtl_433-firmware.bin in WebUI and hit "Start Upgrade", but my liligo crashes and reboots before upgrade is finished (or even starts). Tried clearing all credentials and only re-add needed WiFi config. Also tried turning of RF. Same result, constant reboots. USB? It shows up as a "USB-Enhanced-SERIAL CH9102" device in Windows. How to up/down-grade in that case?
I have the same problem. How do you revert to v1.6 when it constantly crashes and reboots?
After erasing the credentials, from the config portal access point you can update the firmware by tapping "Update". You can download the v1.6.0 binary from https://github.com/1technophile/OpenMQTTGateway/releases/tag/v1.6.0
I have the same problem. How do you revert to v1.6 when it constantly crashes and reboots? I tried to supply the URL: https://github.com/1technophile/OpenMQTTGateway/releases/download/v1.6.0/lilygo-rtl_433-firmware.bin in WebUI and hit "Start Upgrade", but my liligo crashes and reboots before upgrade is finished (or even starts). Tried clearing all credentials and only re-add needed WiFi config. Also tried turning of RF. Same result, constant reboots. USB? It shows up as a "USB-Enhanced-SERIAL CH9102" device in Windows. How to up/down-grade in that case?
This is probably not the most efficient method, but this is how I did it:
- Use the OMG Website Upload (with the clear memory checked) to install the 1.7.0 firmware again. This reset my device back to the unconfigured state.
- Download the 1.6.0 firmware to my phone
- Use my phone to connect to the OMG device
- Disable my phone's data to force it to try and use the captive portal's wifi rather than bypassing it.
- Open up a browser on my phone to http://192.168.4.1
- Click the 'upgrade firmware button'
- Browse for the downloaded firmware (should be a bin file, if it was a zip, extract the zip)
- Upload the firmware and after the device restarts, you are back to 1.6.0
Currently working away from my desk, I will need to try out the latest firmware later this evening.
@1technophile Uploaded the latest test firmware, still crashing. Logs below (Turned on trace logging & disabled discovery) esp-web-tools-logs.txt
Not sure how familiar you are with PlatformIO ? It would be interesting to have the decoding of the exception thanks to it.
This could be done by adding monitor_filters = esp32_exception_decoder to the environment, for your board it would be:
[env:lilygo-rtl_433]
platform = ${com.esp32_platform}
board = ttgo-lora32-v21
; ~/.platformio/packages/framework-arduinoespressif32/variants/.../pins_arduino.h
board_build.partitions = min_spiffs.csv
monitor_filters = esp32_exception_decoder
lib_deps =
${com-esp32.lib_deps}
${libraries.ssd1306}
${libraries.rtl_433_ESP}
build_flags =
${com-esp32.build_flags}
; *** OpenMQTTGateway Config ***
;'-UZmqttDiscovery' ; disables MQTT Discovery
'-Drtl_433_Decoder_Stack=30000'
'-DvalueAsATopic=true' ; MQTT topic includes model and device
'-DGateway_Name="OMG_lilygo_rtl_433_ESP"'
; *** OpenMQTTGateway Modules ***
'-DZgatewayRTL_433="rtl_433"'
'-DZradioSX127x="SX127x"'
; *** ssd1306 Display Options ***
'-DZdisplaySSD1306="LilyGo_SSD1306"'
You can upload this environment, activate the serial monitor, and the exception should be decoded automatically.
I found maybe something, could you try these three firmware and let me know if one or several works for you firmware-lilygo-test.zip
Thanks for your help. I don't have the issue with my RTL_433 boards, so I rely on your tests here.
Thanks guys, my Lilygo RTL 433 are now back on 1.6 and working. Funny thing is that it still prompts for the 1.7 update in Home Assistant, should that version not be withdrawn asap?
Trying out a different serial console with these logs (hterm)
- jsondoc
- Still crashed, maybe less frequently?
- jsondoc_output_2023-12-16_09-21-06.log
- staticjsondoc
- Still crashed, maybe more frequently?
- staticjsondoc_output_2023-12-16_09-44-16.log
- pub
- No crash!
- Discovery left on, trace level 5
- Uptime > 500, which is longer than any of the previous firmwares
- pub_output_2023-12-16_10-01-29.log
Just saw the comment about platform.io, I am familiar with it, but only on a very light level. I will check that out later tonight
Thanks for these tests, I will propose other tests later on. No need to setup platformio unless you want to try it.
I think I have a related issue. I updated my DollaTek LoRa32 V2.1 433Mhz ESP32 to 1.7.0 from 1.6.0 yesterday using the update functionality provided via MQTT to Home Assistant. Updating itself went fine.
However, after updating I've noticed that pressing buttons on my 433 MHz remotes now makes my LilyGO restart. My 433 MHz temperature sensors work fine, but my NEXA remotes and motion sensors seems to restart the LilyGO.
I updated the log level but no relevant message makes it to the console in the WebUI or on the hardware display before it restarts itself.
Not sure if it helps but the remotes have this information:
NEXA Model: PET-910 Frequency: 433.92MHz Date code: 1709
While these devices wouldn't automatically translate into useful entities in Home Assistant, I could still make use of the MQTT events from OMG to create automations.
Is there anything I can do to help troubleshoot this further...? I have only flashed the ESP32 using the OMG website before, how would I go about flashing the firmwares you uploaded here...?
Is there anything I can do to help troubleshoot this further...? I have only flashed the ESP32 using the OMG website before, how would I go about flashing the firmwares you uploaded here...?
You need to erase the credentials with the WebUI, and from the onboarding portal, click update and upload the file firmware to test.
Here are 2 other firmware for testing: firmware_dynamic-tests.zip
Firmware tests:
- std-copy
- Crashes nearly instantly & repeatedly
- std-copy_output_2023-12-17_10-11-15.log
- dynamic-outside-cb
- Also crashed nearly instantly & repeatedly
- dynamic-outside-cb_output_2023-12-17_10-20-18.log
Thanks, I see that the stack memory is decreasing before each crash, could you try this one, it has DEBUG activated for RTL_433 and more stack memory firmware-rtl-debug.zip
- rtl-debug
- Crashes hard, doesn't even dump out on the serial console half the time it is crashing. Just goes to a black OpenMQTTGateway logo and starts back up without dumping anything to the serial console about the crash.
- rtl-debug_output_2023-12-18_09-38-39.log