Mark Smith

Resolving due to lack of response from OP @zsoltmar. Several folks have added support for new hardware platforms, not sure if your platform is in there. Might be worth pulling...

But! But! But! I opened it! </sarcasm> Yeah, you're probably right. This was firmware from ages ago, and the WiFi code has changed dramatically since then. Resolving.

@ExplodingLemur just reported this problem happening to him. Reopening. Its probably a good idea to put some retry logic around wifi connection failures. That seems reasonable.

https://github.com/SmittyHalibut/EleksTubeHAX/blob/main/EleksTubeHAX/EleksTubeHAX.ino#L60

https://github.com/SmittyHalibut/EleksTubeHAX/pull/30 implements this. Resolving.

First off, let me say that I love we were able to use technology to help us communicate across language barriers. :-) I wish you luck in your project, @Yevgeniy135....

Wow. WAY behind on issues. Awesome, @frankcohen Glad to see more projects. :-) Resolving this issue.

I think what you're seeing is https://github.com/NorthernMan54/rtl_433_ESP/issues/61 with associated pull request https://github.com/NorthernMan54/rtl_433_ESP/pull/62 tl,dr: rtl_433_ESP is inspecific which type of memory to `calloc()` and it appears the ESP core is pulling...

Thanks to @NorthernMan54 it looks like https://github.com/NorthernMan54/rtl_433_ESP/pull/62 has been accepted and will be released soon. 🥳

Honestly, I'd probably just use an EEPROM field to store the received time zone, and default to that if one isn't obtainable anymore for whatever reason. Having said that, I'm...