sinricpro / non-sdk-issues

Report non sdk related issues here (Alexa, Google Home, SmartThings, IFTTT, API)
2 stars 0 forks source link

SinricPro - Connection unstable? #14

Closed sim404 closed 3 years ago

sim404 commented 3 years ago

SinricPro seems to be a bit unstable today (25th Feb 1800 GMT) and yesterday 24th too. I have a monitor around the Connected/Disconnected callback. It sends me a message over a Telegram Bot when the connection status changes. I also have a monitor on my WiFi connection and that’s currently solid but I suppose it could be my ISP. Ive seen some 16 disconnects starting around 1800 GMT today, most lasting less than a second, some a bit longer. Is there a problem?

sivar2311 commented 3 years ago

Since this is not an SDK related issue, this issue will be moved to the "non-sdk-issues" area.

brentdcarlson commented 3 years ago

I'm seeing the same issue over the same time frame.

sim404 commented 3 years ago

It’s still happening. Approx 10 disconnects/reconnect around 1300 and 1500 GMT today. Also Alexa saying ‘not responding’ even though the switches are switching all being after a few seconds delay.

kakopappa commented 3 years ago

Yes, doing maintenance work. Posted in Facebook page already.

On Fri, Feb 26, 2021 at 10:38 PM sim404 notifications@github.com wrote:

It’s still happening. Approx 10 disconnects/reconnect around 1300 and 1500 GMT today. Also Alexa saying ‘not responding’ even though the switches are switching all being after a few seconds delay.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-786721416, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZVFH4RTVFXSF4B4Q7TTA656PANCNFSM4YHCHLWQ .

sim404 commented 3 years ago

Ok, apologies - I don’t use Facebook.

brentdcarlson commented 3 years ago

We’re not all social (Facebook). Would be nice to post something on GitHub or webpage. Three days of up and down and we’re suppose to go hunt down maintenance on social media.

Sent from my iPhone

On Feb 26, 2021, at 12:23 PM, sim404 notifications@github.com wrote:

 Ok, apologies - I don’t use Facebook.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

peastuti commented 3 years ago

Hi all, this is happening also today at this time

kakopappa commented 3 years ago

I can control devices at home just fine.. how about @sivar2311 ?

sivar2311 commented 3 years ago

I had no issues here on my side - Activity log is clear and does not show any disconnects (Except the daily 24hrs disconnect caused by my ISP)

sim404 commented 3 years ago

I had a disconnect at 0400 GMT and again around 0730 GMT on 27th, both lasting less than a second. It’s been solid since then (UK). Thanks for sorting the initial problem.

brentdcarlson commented 3 years ago

Pleased to say I had no disconnects last night and my device had no reboots (exception 29) caused by the sinric handler.

First time in weeks.

On Sun, Feb 28, 2021 at 11:52 AM Boris Jäger notifications@github.com wrote:

I had no issues here on my side - Activity log is clear and does not show any disconnects (Except the daily 24hrs disconnect caused by my ISP)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-787491316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBRPT3KXHJF7EFY4W7DTBJ7EJANCNFSM4YHCHLWQ .

brentdcarlson commented 3 years ago

Take it back. Multiple reboots and disconnect. Ready to move on. Can't productize this.

On Mon, Mar 1, 2021 at 9:37 AM Brent Carlson brentdcarlson@gmail.com wrote:

Pleased to say I had no disconnects last night and my device had no reboots (exception 29) caused by the sinric handler.

First time in weeks.

On Sun, Feb 28, 2021 at 11:52 AM Boris Jäger notifications@github.com wrote:

I had no issues here on my side - Activity log is clear and does not show any disconnects (Except the daily 24hrs disconnect caused by my ISP)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-787491316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBRPT3KXHJF7EFY4W7DTBJ7EJANCNFSM4YHCHLWQ .

sivar2311 commented 3 years ago

@brentdcarlson Can you tell more about reboots and exception (29) ? The SDK does not cause reboots, and there should be no exceptions! This is the first time i heard about a user having reboots and exception(29) problems.

Can you provide more info about this?

Also please let me know the version of used

And last but not least can you share the sketch (github repositroy / gitbhub gist)?

Edit: I think your ESP is running out of (dynamic) memory. How much devices do you run on the ESP? Does your sketch make excessive use of dynamic memory allocation?

brentdcarlson commented 3 years ago

Wemos D1 R2 (ESP8266MOD) - only module I'm using for this device. SinricPro SDK V2.9.0 Websockets V2.3.4 ESP8266 boards V2.7.4 Arduino IDE 1.8.13

include "SinricPro.h"

include "SinricProDimSwitch.h"

This device has IR remote control, OLED, time (NTPClient), temperature, OTA and SMTPserver (to send me texts when reboots/startup).

So when I disable Sinric and use only with the remote, the device works fine for days without any reboots.

Perhaps something stands out in the following exception decoder results:

Exception 29: StoreProhibited: A store referenced a page mapped with an attribute that does not permit storesPC: 0x40222ca6: esp8266::MDNSImplementation::MDNSResponder::stcMDNS_RRAnswer::stcMDNS_RRAnswer(esp8266::MDNSImplementation::MDNSResponder::_enuAnswerType, esp8266::MDNSImplementation::MDNSResponder::stcMDNS_RRHeader const&, unsigned int) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Structs.cpp line 999EXCVADDR: 0x00000008 Memory allocation of 544 bytes failed at 0x40223dda: esp8266::MDNSImplementation::MDNSResponder::_readRRAnswer(esp8266::MDNSImplementation::MDNSResponder::stcMDNS_RRAnswer&) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Transfer.cpp line 493 Decoding stack results0x4021b8b4: operator new(unsigned int) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*abi.cpp line 390x40223de4: esp8266::MDNSImplementation::MDNSResponder::_readRRAnswer(esp8266::MDNSImplementation::MDNSResponder::stcMDNS_RRAnswer&) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Transfer.cpp line 4940x40220008: _GLOBAL__sub_D_MDNS() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*ESP8266mDNS.cpp line 90x40220d99: esp8266::MDNSImplementation::MDNSResponder::_parseQuery(esp8266::MDNSImplementation::MDNSResponder::stcMDNS_MsgHeader const&) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Control.cpp line 3210x4022fc19: glue2esp_linkoutput at glue-esp/lwip-esp.c line 3010x4022fea6: new_linkoutput at glue-lwip/lwip-git.c line 2600x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x402238d1: esp8266::MDNSImplementation::MDNSResponder::_udpReadBuffer(unsigned char, unsigned int) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src/include/UdpContext.h line 3610x40223c05: esp8266::MDNSImplementation::MDNSResponder::_udpRead16(unsigned short&) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Transfer.cpp line 10610x40221a8d: esp8266::MDNSImplementation::MDNSResponder::_parseMessage() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Control.cpp line 1410x40233aa6: pbuf_free_LWIP2 at core/pbuf.c line 7860x4020a60a: UdpContext::next() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src/include/UdpContext.h line 3380x40221df5: esp8266::MDNSImplementation::MDNSResponder::_process(bool) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Control.cpp line 810x40221e10: esp8266::MDNSImplementation::MDNSResponder::_callProcess() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Helpers.cpp line 1970x4022619f: std::_Function_handler (esp8266::MDNSImplementation::MDNSResponder)>

::_M_invoke(std::_Any_data const&) at c:\users\brent\appdata\local\arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-4-b40a506\xtensa-lx106-elf\include\c++\4.8.2/functional line 20730x4020a044: UdpContext::_s_recv(void, udp_pcb, pbuf, ip4_addr const, unsigned short) at c:\users\brent\appdata\local\arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-4-b40a506\xtensa-lx106-elf\include\c++\4.8.2/functional line 24640x40234420: udp_input at core/udp.c line 4040x40239348: ip4_input at core/ipv4/ip4.c line 14610x401010e3: free(void) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc*umm_malloc.cpp line 3980x40230239: ethernet_input_LWIP2 at netif/ethernet.c line 1880x40230058: esp2glue_ethernet_input at glue-lwip/lwip-git.c line 4690x4026443e: ethernet_input at glue-esp/lwip-esp.c line 3650x4026444f: ethernet_input at glue-esp/lwip-esp.c line 3730x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x4022fc19: glue2esp_linkoutput at glue-esp/lwip-esp.c line 3010x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x4020a075: WiFiUDP::available() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiUdp.cpp line 1210x4020691c: udpListener::handle() at C:\Users\brent\Documents\Arduino\libraries\SinricPro\src/SinricProUDP.h line 430x402355fe: tcp_output at core/tcp_out.c line 13610x40100e5f: umm_free_core(void) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc*umm_malloc.cpp line 3510x401010e3: free(void) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266\umm_malloc*umm_malloc.cpp line 3980x40100758: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1880x4020a07b: WiFiUDP::available() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiUdp.cpp line 1210x4020691c: udpListener::handle() at C:\Users\brent\Documents\Arduino\libraries\SinricPro\src/SinricProUDP.h line 430x4021ba7c: esp_yield() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1190x4021c6d2: __delay(unsigned long) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 540x4020961e: ClientContext::wait_until_sent(int) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src/include/ClientContext.h line 3530x40100758: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1880x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x4021f952: BearSSL::WiFiClientSecure::flush(unsigned int) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiClientSecureBearSSL.cpp line 2120x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x4021c6d2: __delay(unsigned long) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 540x40100719: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1820x401006fd: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1760x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x40100758: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1880x4021baec: optimistic_yield(uint32_t) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1510x4023f426: br_ssl_engine_flush at src/ssl/ssl_engine.c line 13040x4021f8e7: BearSSL::WiFiClientSecure::_run_until(unsigned int, bool) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiClientSecureBearSSL.cpp line 5540x4021ba70: *esp_yield() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266/core_esp8266_features.h line 920x4021c6d2: __delay(unsigned long) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 540x4020e818: WebSocketsClient::handleClientData() at C:\Users\brent\Documents\Arduino\libraries\WebSockets\src*WebSocketsClient.cpp line 5830x40225734: WebSocketsClient::clientIsConnected(WSclient_t) at C:\Users\brent\Documents\Arduino\libraries\WebSockets\src*WebSocketsClient.cpp line 5240x40221dfa: esp8266::MDNSImplementation::MDNSResponder::_process(bool) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Control.cpp line 930x40221ded: esp8266::MDNSImplementation::MDNSResponder::_process(bool) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266mDNS\src*LEAmDNS_Control.cpp line 900x40100758: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1880x4023f426: br_ssl_engine_flush at src/ssl/ssl_engine.c line 13040x4021f8e7: BearSSL::WiFiClientSecure::_run_until(unsigned int, bool) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiClientSecureBearSSL.cpp line 5540x40100700: millis() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_wiring.cpp line 1750x4021fa89: BearSSL::WiFiClientSecure::available() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiClientSecureBearSSL.cpp line 3860x4021efc1: BearSSL::WiFiClientSecure::connected() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\libraries\ESP8266WiFi\src*WiFiClientSecureBearSSL.cpp line 2600x4020e9e6: WebSocketsClient::loop() at C:\Users\brent\Documents\Arduino\libraries\WebSockets\src*WebSocketsClient.cpp line 2730x40206b12: SinricProClass::handle() at C:\Users\brent\Documents\Arduino\libraries\SinricPro\src/SinricPro.h line 2640x40206bcf: loop() at P:\Arduino\Sketches\WifiServerAlexa/WifiServerAlexa.ino line 6270x402077e8: sendEmail() at P:\Arduino\Sketches\WifiServerAlexa/WifiServerAlexa.ino line 12620x40201700: std::_Function_handler::_M_invoke(const std::_Any_data &, unsigned int, unsigned int) at c:\users\brent\appdata\local\arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-4-b40a506\xtensa-lx106-elf\include\c++\4.8.2/functional line 20730x401003d4: ets_post(uint8, ETSSignal, ETSParam) at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 1770x4021bb94: loop_wrapper() at C:\Users\brent\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.7.4\cores\esp8266*core_esp8266_main.cpp line 197*

On Mon, Mar 1, 2021 at 10:34 PM Boris Jäger notifications@github.com wrote:

@brentdcarlson https://github.com/brentdcarlson Can you tell more about reboots and exception (29) ? The SDK does not cause reboots, and there should be no exceptions! This is the first time i heard about a user having reboots and exception(29) problems.

Can you provide more info about this?

  • Which type of ESP do you use
  • Does it happen on different ESP or is this only on one module?

Also please let me know the version of used

  • Arduino ESP Core
  • WebSockets Library
  • SinricPro SDK

And last but not least can you share the sketch (github repositroy / gitbhub gist)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-788576773, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBWV27XFEMCIOU2KXG3TBRTFPANCNFSM4YHCHLWQ .

sivar2311 commented 3 years ago

Memory allocation of 544 bytes failed

There you have it! Your ESP is running out of memory! Can you share your sketch please? upload to gist.github.com and share the link or send via e-mail please

brentdcarlson commented 3 years ago

Sketch uses 542332 bytes (51%) of program storage space. Maximum is 1044464 bytes. Global variables use 33680 bytes (41%) of dynamic memory, leaving 48240 bytes for local variables. Maximum is 81920 bytes.

On Tue, Mar 2, 2021 at 2:31 PM Boris Jäger notifications@github.com wrote:

Memory allocation of 544 bytes failed

There you have it! Your ESP is running out of memory! Can you share your sketch please? upload to gist.github.com and share the link or send via e-mail please

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-789193491, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBXEM6VIV7OGANDG433TBVDI7ANCNFSM4YHCHLWQ .

sivar2311 commented 3 years ago

Yes, but the issue is about DYNAMIC MEMORY allocation. Forget about the numbers you see while compiling!

brentdcarlson commented 3 years ago

So adding Sinric is just putting me over the top. Makes sense. Any tools to analyze this?

I assume porting to an ESP32 would solve my problem?

Thanks

On Tue, Mar 2, 2021 at 2:31 PM Boris Jäger notifications@github.com wrote:

Memory allocation of 544 bytes failed

There you have it! Your ESP is running out of memory! Can you share your sketch please? upload to gist.github.com and share the link or send via e-mail please

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-789193491, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBXEM6VIV7OGANDG433TBVDI7ANCNFSM4YHCHLWQ .

sivar2311 commented 3 years ago

The following sketch uses 262284 bytes (25.1%) of program storage space. Maximum is 1044464 bytes Global variables use 27084 (33.1%) of dynamic memory, leaving 54.836 bytes for local variables. Maximum is 81920 bytes.

#include <Arduino.h>

#define SIZE 0x1000 // 4kb

void setup() {
  Serial.begin(115200); Serial.println();
}

void loop() {
  Serial.printf("Available memory: %d. Going to allocate %d bytes\r\n", ESP.getFreeHeap(), SIZE);
  delay(250);

  // allocate 4kb dynamic memory
  char *array = new char[SIZE];
  if (!array) {
    Serial.printf("Last memory allocation failed (not enough memory). array is pointing to \"nowhere\"! now i am writing to \"nowhere\" and let the ESP Crash ;)\r\n");
    delay(5000); // 5 seconds to read serial output before crash ;)
  }

  // fill up with zeros
  for (int i=0; i<SIZE; i++) array[i] = 0;

  // dynamic memory is not released! it will remain allocated which reduces the available memory in next round
}
sivar2311 commented 3 years ago

Let the sketch above run and it will crash after a few seconds (out of memory / writing to invalid memory space -> Exception 29)

sivar2311 commented 3 years ago

I didn't find an memory issues in SinricPro library and no other one complained about memory issues.

You said you use an OLED -> usually displays needs a lot of ram to store the pixel informations. Somewhere must be a memory leak in your sketch or one of the used library (this does not exclude SinricPro SDK).

brentdcarlson commented 3 years ago

Thanks, I get it. Wasn’t clear what the decoder was telling me. I was tracing the stack dump and ignoring the bigger picture.

Thanks again

Sent from my iPhone

On Mar 2, 2021, at 3:04 PM, Boris Jäger notifications@github.com wrote:

 Let the sketch above run and it will crash after a few seconds (out of memory / writing to invalid memory space -> Exception 29)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

sivar2311 commented 3 years ago

I assume porting to an ESP32 would solve my problem?

No. The problem is while your sketch is running something allocates dynamic memory without releasing it! (Memory leak!) This will reduce the available memory over time. The more ram you have the longer it will take until the crash happens.

Please share your sketch. Maybe the issue is inside the sketch and i am able to find it (maybe not)... but i can give it a try.

sivar2311 commented 3 years ago

Btw: This is reason and the answer for your comment in esp8266-esp32-sdk issues #140

brentdcarlson commented 3 years ago

Yes, agreed

On Tue, Mar 2, 2021 at 3:24 PM Boris Jäger notifications@github.com wrote:

Btw: This is reason and the answer for your comment in esp8266-esp32-sdk issues #140 https://github.com/sinricpro/esp8266-esp32-sdk/issues/140#issuecomment-782611645

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-789226846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBUHK4M4CGWN34ULUR3TBVJSNANCNFSM4YHCHLWQ .

brentdcarlson commented 3 years ago

Pulled the oled and it ran all night without crashing. Not sure if it is responsible for a memory leak or just provided sufficient headroom. I did see 20 Sinric connect/disconnects on the monitor.

For grins, I ported the device to an ESP32 protoboard design (yes, I understand your point if it is a memory leak). I have everything working except it won’t connect to Sinric. Anything special for ESP32 vs ESP8266? Same handler and routines, same DNS, etc

Brent

Sent from my iPhone

On Mar 2, 2021, at 3:12 PM, Boris Jäger notifications@github.com wrote:

 I assume porting to an ESP32 would solve my problem?

No. The problem is while your sketch is running something allocates dynamic memory without releasing it! (Memory leak!) This will reduce the available memory over time. The more ram you have the longer it will take until the crash happens.

Please share your sketch. Maybe the issue is inside the sketch and i am able to find it (maybe not)... but i can give it a try.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

sivar2311 commented 3 years ago

I did see 20 Sinric connect/disconnects on the monitor.

Woh, 20 connect/disconnects "without reason". That's a lot. I suggest to log ESP.getFreeHeap() to serial monitor or to a file on FS periodically.

Difference for ESP32: No there aren't except ESP8266WiFi.h vs. WiFi.h What's your ESP32 Core version?

Edit: At the moment you are the only one who has problems connecting an ESP32 - As far as I know -. If this was a general problem, there would be a lot of git issues

Edit2: I was able to reproduce the ESP32 connecting issue. It seems that Espressif32 platform 3.1.0 arduino-esp32 v1.05 is causing SSL issues (this didn't happen in 2.1.0 and 3.0.0) There are 2 workarounds:

  1. #define SINRICPRO_NOSSL before including SinricPro.h (this will disable SSL connection)
  2. Downgrade to Espressif32 platform version 3.0.0 the arduino-esp32 core
kakopappa commented 3 years ago

Few disconnections are be related to the new version update yesterday

brentdcarlson commented 3 years ago

It is a ESP-WROOM-32. Not sure how to get the core version.

Sinric debug shows:

platform:ESP32 version:2.9.0

My status dump:

Chip Revision: 1 Cores: 2 Features: 88 SDK Version: v3.3.4-432-g7a85334d8 CPU Freq: 240 MHz Sketch size: 1095120 bytes Flash Chip Size: 4194304 bytes Free Heap: 244676 bytes

Sinric debug status:

SinricPro:Websocket: Connecting to WebSocket Server using SSL ( ws.sinric.pro)

appkey:removed deviceids: removed restoredevicestates:false

I added the free heap dump to the ESP32 module (without connecting successfully to Sinric) and heap remains relatively constant at:

Free Heap: 233296 bytes

On Wed, Mar 3, 2021 at 10:10 PM Boris Jäger notifications@github.com wrote:

I did see 20 Sinric connect/disconnects on the monitor.

Woh, 20 connect/disconnects "without reason". That's a lot. I suggest to log ESP.getFreeHeap() to serial monitor or to a file on FS periodically.

Difference for ESP32: No there aren't except ESP8266WiFi.h vs. WiFi.h What's your ESP32 Core version?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sinricpro/non-sdk-issues/issues/14#issuecomment-790274817, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASZZWBXWTWY5P2UOAMTRQD3TB4B3NANCNFSM4YHCHLWQ .

sivar2311 commented 3 years ago

version:2.9.0

That's the SinricPro library version not esp-arduino core ;)

The issue have beein identified and a fix is in progress.

The esp-arduino core has changed - so the WebSockets library needs to be changed too For this i opened an issue in websockets repository, as well as a pull request

We have to wait until websockets library gets updated. Until then you can use the #define SINRICPRO_NOSSL option.

Edit: Another option is to use the forked and fixed websockets library from my repository

brentdcarlson commented 3 years ago

Did the trick

Sent from my iPhone

On Mar 5, 2021, at 4:00 PM, Boris Jäger notifications@github.com wrote:

 version:2.9.0

That's the SinricPro library version not esp-arduino core ;)

The issue have beein identified and a fix is in progress.

The esp-arduino core has changed - so the WebSockets library needs to be changed too For this i opened an issue in websockets repository, as well as a pull request

We have to wait until websockets library gets updated. Until then you can use the #define SINRICPRO_NOSSL option.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.