Holger Adams

Guess we need a neutral protocol, as I'm not a that big fan of MQTT. The simpler to data format the better. Guess everybody can add its own glue layer...

I bisect'ed this twice and always ended up here: ``` 1012167c893d5ced7540b59acea8a0bff654bf34 is the first bad commit commit 1012167c893d5ced7540b59acea8a0bff654bf34 Author: Sacha Weatherstone Date: Sun Jul 9 14:14:49 2023 +1000 Second round...

I only tested using the IP. On the forum this issue was confirmed. One person suggested a workaround: Marking the IP-Field then hitting enter. Works for me.

Played around a bit more. Seems like when the ESP32 is running into a power loss during the early phase of the first file system operations it will reset the...

I just tested this rather ugly hack: ``` NodeDB.cpp, loadProto(...): uint32_t retry = 0; while(state == LoadFileResult::OTHER_FAILURE && retry < 5) { if (f) { LOG_INFO("Loading %s\n", filename); pb_istream_t stream...

I'm trying to force the Brownout-detection right now: ``` REG_SET_BIT(RTC_CNTL_BROWN_OUT_REG, RTC_CNTL_BROWN_OUT_ENA); // Enable brownout WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 7); // Set threshold to max (3.0V) ``` But as the device in placed on...

Not Yet. As I'm using pretty big batteries (3000...4000mAh) this doesn't happen that often to me. The patch above (RTC_CNTL_BROWN_OUT_REG) is integrated into my Fork but not properly tested yet....

Looks like the RAK4631 have a similar problem.

Got it. Looks like pretty much all ESP32 example code you can find on Google regarding the ESP32 Brown-Out mode is wrong or awfully out of date. Following code snipped...

After testing a while: the self-reset still occurs. Even with early brown-out detection and self reset. But I was able to narrow the issue down. It happens if the device...