search

sinricpro / esp8266-esp32-sdk

Library for https://sinric.pro - simple way to connect your device to Alexa, Google Home, SmartThings and cloud
https://sinric.pro
Other
230 stars 124 forks source link

SinricPro.handle() refresh frequency #98

Closed sgrizzi closed 3 years ago

sgrizzi commented 3 years ago

Hi, I am testing the doorbell functionality with an ESP32 module. In the main loop

void loop() { .... SinricPro.handle(); {...additional activities...} } if I include additional activities that take time -for example, I need to run a BLE scan which can take 5 seconds - the doorbell keeps disconnecting and reconnecting, and the doorbell does not work anymore. In the documentation it is stated that SinricPro.handle() should be run as frequently as possible but is there a definition of the maximum time between two runs??

Best regards, Gabriele

kakopappa commented 3 years ago

  1. Have you tried calling “ yield() ” while scanning ?

  2. Try pinning the scanning logic to a specific core so the other core is able to keep the connection alive

On Tue, 27 Oct 2020 at 10:06 PM sgrizzi notifications@github.com wrote:

Hi, I am testing the doorbell functionality with an ESP32 module. In the main loop

void loop() { .... SinricPro.handle(); {...additional activities...} } if I include additional activities that take time -for example, I need to run a BLE scan which can take 5 seconds - the doorbell keeps disconnecting and reconnecting, and the doorbell does not work anymore. In the documentation it is stated that SinricPro.handle() should be run as frequently as possible but is there a definition of the maximum time between two runs??

Best regards, Gabriele

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sinricpro/esp8266-esp32-sdk/issues/98, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZTFVHTNE34SPJ6V53DSM3OY3ANCNFSM4TA6WMYQ .

sivar2311 commented 3 years ago

If the main loop is blocked too long, no events can be received or sent. However, the connection will not be disconnected within 5 seconds. This could only happen after about 5 minutes (Websocket Timeout). Does the Bluetooth scan have to run permanently? If so, ESP32 offers the option of using the second processor core.

sgrizzi commented 3 years ago

Dear Aruna,

I am using the standard BLE library in Arduino. The BLEScanResults foundDevices = pBLEScan->start(scanTime, false); is a blocking call. Since I may need to scan for 5-10 seconds, worst case I will block the main loop for this amount of time.

BLEscan does yield one result at a time -and I could possibly run SinricPro.handle() every time I get a new result, and even stop the scan if I find the device I am expecting, but, worst case, if no BLE device is within reach then the call will block the main loop for “scanTime”. Or would you see a workaround?

Using the two cores is a possibility – is this possible with Arduino?

Regards, Gabriele

From: Aruna Tennakoon notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 16:22 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

  1. Have you tried calling “ yield() ” while scanning ?

  2. Try pinning the scanning logic to a specific core so the other core is able to keep the connection alive

On Tue, 27 Oct 2020 at 10:06 PM sgrizzi notifications@github.com wrote:

Hi, I am testing the doorbell functionality with an ESP32 module. In the main loop

void loop() { .... SinricPro.handle(); {...additional activities...} } if I include additional activities that take time -for example, I need to run a BLE scan which can take 5 seconds - the doorbell keeps disconnecting and reconnecting, and the doorbell does not work anymore. In the documentation it is stated that SinricPro.handle() should be run as frequently as possible but is there a definition of the maximum time between two runs??

Best regards, Gabriele

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sinricpro/esp8266-esp32-sdk/issues/98, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZTFVHTNE34SPJ6V53DSM3OY3ANCNFSM4TA6WMYQ .

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

sivar2311 commented 3 years ago

Using the two cores is a possibility – is this possible with Arduino?

https://randomnerdtutorials.com/esp32-dual-core-arduino-ide/

sivar2311 commented 3 years ago

I don't know much about ESP32 & BLE scanning, but there is an async way to do the scan. You only have to provide a callback function. See here: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/Arduino/BLE_scan/BLE_scan.ino

sgrizzi commented 3 years ago

Hi Boris,

This is the actual code I am using – very simple, just for testing purposes:

void loop() {

  checkButtonPress();

  SinricPro.handle();

 

  BLEScanResults foundDevices = pBLEScan->start(scanTime, false);

  Serial.print("Devices found: ");

  Serial.println(foundDevices.getCount());

  Serial.println("Scan done!");

  pBLEScan->clearResults();   // delete results fromBLEScan buffer to release memory

}

scanTime is set at 5 seconds.

When I look at the doorbell device on the portal I keep getting a green blob saying that the device is connected and a purple one saying it is disconnected….

See below.

In the meantime I also saw your other messages. Thanks a lot for your suggestions. I will look into them.

Clearly if the device would not disconnect so fast, I would be able to run my scan -5 to 10s max- get advertising package of the BLE device I need to listen to, and then use the data to trigger a “doorbell” event if needed.

So, BLE scan and event transmission to Sinric would run as one event after the other.

Best regards, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 16:23 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

If the main loop is blocked too long, no events can be received or sent. However, the connection will not be disconnected within 5 seconds. This could only happen after about 5 minutes (Websocket Timeout). Does the Bluetooth scan have to run permanently? If so, ESP32 offers the option of using the second processor core.

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

sgrizzi commented 3 years ago

Thanks Boris!

VERY useful.

Best regards, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 16:42 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

Using the two cores is a possibility – is this possible with Arduino?

https://randomnerdtutorials.com/esp32-dual-core-arduino-ide/

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

sgrizzi commented 3 years ago

Unfortunately this is running the scan in the initialization phase -and processing will stay there till scan is finished- then start the main loop, but the no more scanning then takes place afterwards.

I need to run the connection to sinric and the scan continuously – one after the other is fine.

Probably the multi-tasking solution is the best.

I will try and let you know.

Rgds, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 16:48 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

I don't know much about ESP32 & BLE scanning, but there is an async way to do the scan. You only have to provide a callback function. See here: https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/Arduino/BLE_scan/BLE_scan.ino

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

sivar2311 commented 3 years ago

As far as I understand it should work if you use a callback function for scanning. Did you do that?

sgrizzi commented 3 years ago

Yes, I do use the callback function.

According to the BLE library documentation, the BLEscan call is blocking for the time the scan is running – whether this is in the main loop or in the init phase it apparently does not matter.

When the advertising message of a new BLE device, the callback call is activated immediately and the result is made available immediately, then the scan continues till its time is over.

This is from the BLE library documentation (see below)

The BLEScan object, when presented to us, isn't actually yet scanning, to start it scanning we invoke its start() method passing in the duration of how long we would like it to scan for

…. This is a blocking call. It will return after the scan period has elapsed

…. Since we are scanning, we will want to know as soon as possible about the devices that we find and this is where a callback function comes into play. Before calling start() we can register a callback function that will be invoked for each peer device that was found.

https://github.com/nkolban/esp32-snippets/blob/master/Documentation/BLE%20C%2B%2B%20Guide.pdf

It is a bit strange since a BLE client is normally always listening… i.e. scanning, and a blocking scanning is not exactly what you need, but maybe I am overlooking something…

Rgds, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 17:28 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

As far as I understand it should work if you use a callback function for scanning. Did you do that?

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

sivar2311 commented 3 years ago

A Google search for "esp32 ble scan disconnect wifi" lists some hits. Maybe someone else has already found a suitable solution (maybe use another BLE library or something similar).

sgrizzi commented 3 years ago

Thanks!

This could be yet another issue…

Best regards, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Tuesday, 27 October 2020 at 17:57 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

A Google search for "esp32 ble scan disconnect wifi" lists some hits. Maybe someone else has already found a suitable solution (maybe use another BLE library or something similar).

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

kakopappa commented 3 years ago

I just remembered a long a long time ago i had a similar problem. I believe your issue is the wifi antenna being shared by WiFi and BLE. When you are scanning for BLE packets BLE core takes over the antenna and the WebSocket connection drops.

To fix this problem:

  1. You have to set the correct scan time/interval in order to keep the web socket connection alive. If you do this you may lose some BLE packets https://esp32.com/viewtopic.php?t=2291 https://esp32.com/viewtopic.php?f=12&t=12379&p=49594&hilit=antenna#p49594

  2. Use a cheap ESP8266 board for Sinric Pro + Websocket and use another ESP32 board for BLE scanning. You can communicate between two boards using UART

sgrizzi commented 3 years ago

I think I managed to get this to work.

This example

https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleAsyncScan.cpp

shows the use of this call

bool BLEScan::start(uint32_t duration, void (*scanCompleteCB)(BLEScanResults), bool is_continue)

which returns immediately after starting the BLE scan process, and will then use the callback scanCompleteCB when the scan has finished.

In my case I set duration = 0 so that the scan process will never end and start the BLE scan process in the initialization phase.

The main loop is then running continuously and fast

void loop() {

  checkButtonPress();

  SinricPro.handle();

}

and I get a call back whenever a BLE advertising message is received.

Unfortunately I have a new problem: when I press the button on the ESP32 board I can see the green “ding dong” pop up on the portal, but the Alexa routine triggered by the doorbell is not responding anymore.

Tried to delete and restore the device in Alexa, also tried disable and re-enable sinric pro but I cannot get the doorbell to work again!

Nothing to do with BLE as I also tried with another ESP32 sample, with the initial doorbell code on it and also this one is not working.

Any suggestion? Shall I open a separate issue?

Gabriele

From: Aruna Tennakoon notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 03:55 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

I just remembered a long a long time ago i had a similar problem. I believe your issue is the wifi antenna being shared by WiFi and BLE. When you are scanning for BLE packets BLE core takes over the antenna and the WebSocket connection drops.

To fix this problem: You have to set the correct scan time/interval in order to keep the web socket connection alive. If you do this you may lose some BLE packets https://esp32.com/viewtopic.php?t=2291 Use a cheap ESP8266 board for Sinric Pro + Websocket and use another ESP32 board for BLE scanning. You can communicate between two boards using UART — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

sivar2311 commented 3 years ago

Thats what i meant yesterday (using async callback for ble scan)!

About your new problem: Did you enable the Doorbell device in alexa app?

sgrizzi commented 3 years ago

You did point me in the right direction but the library call I am referring to is using two callbacks: one is to get the scan results, as it would be with the standard “blocking” call while the second is triggered by the end of the scan – and this call returns immediately, which is what we need!

Also the idea of using the two cores is very interesting – for sure useful for future device enhancements.

Second unexpected problem.

Yes, the doorbell is enabled in Alexa.

What is strange is that somehow Alexa can communicate with the device.

If I say “Alexa, turn on bell1”, I get the following message on the ESP32

[SinricPro:Websocket]: receiving data

[SinricPro.handleReceiveQueue()]: 1 message(s) in receiveQueue

[SinricPro.handleReceiveQueue()]: Signature is valid. Processing message...

[SinricPro:extractTimestamp(): Got Timestamp 1603891704

[SinricPro.handleRequest()]: handling request

{

  "header": {

    "payloadVersion": 2,

    "signatureVersion": 1

  },

  "payload": {

    "action": "setPowerState",

    "clientId": "alexa-skill",

    "createdAt": 1603891704,

    "deviceAttributes": [],

    "deviceId": "5f91f28c0a046d3259896863",

    "replyToken": "f97e9dda-c1e1-4d55-839e-840f65b7582b",

    "type": "request",

    "value": {

      "state": "On"

    }

  },

  "signature": {

    "HMAC": "zeukh4/s3/YjWQalwA1r2ln3hh6dJbIUUxiXEfEZrZc="

  }

}SinricProDevice::handleRequest()

[SinricPro:handleSendQueue()]: 1 message(s) in sendQueue

[SinricPro:handleSendQueue()]: Sending message...

{

  "header": {

    "payloadVersion": 2,

    "signatureVersion": 1

  },

  "payload": {

    "action": "setPowerState",

    "clientId": "alexa-skill",

    "createdAt": 1603891704,

    "deviceId": "5f91f28c0a046d3259896863",

    "message": "Device returned an error while processing the request!",

    "replyToken": "f97e9dda-c1e1-4d55-839e-840f65b7582b",

    "success": false,

    "type": "response",

    "value": {}

  },

  "signature": {

    "HMAC": "eVcxBMbTnnlDxdLHkEUTDRqdjKkhElBN1/GyndfyT2I="

  }

}

[SinricPro:handleSendQueue]: Sending to websocket

[SinricPro:handleSendQueue()]: message sent.

Since no “power on” is implemented I get an error response from the ESP32 and Alexa tells me so.

When I press the doorbell button on the ESP32 I get the following message out:

Ding dong...

[SinricPro:sendMessage()]: pushing message into sendQueue

[SinricPro:handleSendQueue()]: 1 message(s) in sendQueue

[SinricPro:handleSendQueue()]: Sending message...

{

  "header": {

    "payloadVersion": 2,

    "signatureVersion": 1

  },

  "payload": {

    "action": "DoorbellPress",

    "cause": {

      "type": "PHYSICAL_INTERACTION"

    },

    "createdAt": 1603891897,

    "deviceId": "5f91f28c0a046d3259896863",

    "replyToken": "782fae5e-af78-42d5-a86f-c4de56a29120",

    "type": "event",

    "value": {

      "state": "pressed"

    }

  },

  "signature": {

    "HMAC": "Xeci1H6J9jTmyRcHsPOFBoJy/s0qGWK1BX+EwbIoxIA="

  }

}

[SinricPro:handleSendQueue]: Sending to websocket

[SinricPro:handleSendQueue()]: message sent.

Apparently the message is sent successfully. I see “ding dong” on the portal but nothing happens with Alexa (with the same setup everything was working fine till yesterday…)

Rgds, Gabriele

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 12:56 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

Thats what i meant yesterday (using async callback for ble scan)!

About your new problem: Did you enable the Doorbell device in alexa app?

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

sivar2311 commented 3 years ago

Please check if notifications are enabled for your device in the alexa app.

kakopappa commented 3 years ago

There was a problem and I have fixed it

Please check now On Wed, 28 Oct 2020 at 8:49 PM Boris Jäger notifications@github.com wrote:

Please check if notifications are enabled for your device in the alexa app.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/sinricpro/esp8266-esp32-sdk/issues/98#issuecomment-717945434, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZV5QEWLBDS74HLFBSTSNAONFANCNFSM4TA6WMYQ .

sgrizzi commented 3 years ago

This is the configuration of bell1 I see in my alexa app.

  

In the meantime, I did do/touch/modify nothing at all…. and Alexa routine is now triggered correctly! This is scary – what is going on?

FYI, this is the setup of the routine triggered by bell1 pressed.

And this is the message I get from the ESP32 (createdAT, replyToken and HMAC signatures are different, if this is of any use…)

Ding dong...

[SinricPro:sendMessage()]: pushing message into sendQueue

[SinricPro:handleSendQueue()]: 1 message(s) in sendQueue

[SinricPro:handleSendQueue()]: Sending message...

{

  "header": {

    "payloadVersion": 2,

    "signatureVersion": 1

  },

  "payload": {

    "action": "DoorbellPress",

    "cause": {

      "type": "PHYSICAL_INTERACTION"

    },

    "createdAt": 1603895525,

    "deviceId": "5f91f28c0a046d3259896863",

    "replyToken": "154294f6-dbfa-452d-bae7-a30b74e7af81",

    "type": "event",

    "value": {

      "state": "pressed"

    }

  },

  "signature": {

    "HMAC": "AkrboyGEMiiksMTD8ZxW+4MJnE/5Ub9TWZFSRWTJbFg="

  }

}

[SinricPro:handleSendQueue]: Sending to websocket

[SinricPro:handleSendQueue()]: message sent.

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 14:49 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

Please check if notifications are enabled for your device in the alexa app.

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

kakopappa commented 3 years ago

There was a problem with one of the outgoing message queues (To Alexa cloud) and I have fixed the problem now. Services are operating as usual

On Wed, 28 Oct 2020 at 9:39 PM sgrizzi notifications@github.com wrote:

This is the configuration of bell1 I see in my alexa app.

In the meantime, I did do/touch/modify nothing at all…. and Alexa routine is now triggered correctly! This is scary – what is going on?

FYI, this is the setup of the routine triggered by bell1 pressed.

And this is the message I get from the ESP32 (createdAT, replyToken and HMAC signatures are different, if this is of any use…)

Ding dong...

[SinricPro:sendMessage()]: pushing message into sendQueue

[SinricPro:handleSendQueue()]: 1 message(s) in sendQueue

[SinricPro:handleSendQueue()]: Sending message...

{

"header": {

"payloadVersion": 2,

"signatureVersion": 1

},

"payload": {

"action": "DoorbellPress",

"cause": {

  "type": "PHYSICAL_INTERACTION"

},

"createdAt": 1603895525,

"deviceId": "5f91f28c0a046d3259896863",

"replyToken": "154294f6-dbfa-452d-bae7-a30b74e7af81",

"type": "event",

"value": {

  "state": "pressed"

}

},

"signature": {

"HMAC": "AkrboyGEMiiksMTD8ZxW+4MJnE/5Ub9TWZFSRWTJbFg="

}

}

[SinricPro:handleSendQueue]: Sending to websocket

[SinricPro:handleSendQueue()]: message sent.

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 14:49 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author < author@noreply.github.com> Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

Please check if notifications are enabled for your device in the alexa app.

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sinricpro/esp8266-esp32-sdk/issues/98#issuecomment-717977846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZTGMJTBKMIMNO2MINTSNAUK3ANCNFSM4TA6WMYQ .

sgrizzi commented 3 years ago

Perfect! Now everything is working fine, also the new version of my ESP32 with background BLE scanning!

Thanks for the support of both of you!

Best regards, Gabriele

From: Aruna Tennakoon notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 15:44 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author author@noreply.github.com Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

There was a problem with one of the outgoing message queues (To Alexa cloud) and I have fixed the problem now. Services are operating as usual

On Wed, 28 Oct 2020 at 9:39 PM sgrizzi notifications@github.com wrote:

This is the configuration of bell1 I see in my alexa app.

In the meantime, I did do/touch/modify nothing at all…. and Alexa routine is now triggered correctly! This is scary – what is going on?

FYI, this is the setup of the routine triggered by bell1 pressed.

And this is the message I get from the ESP32 (createdAT, replyToken and HMAC signatures are different, if this is of any use…)

Ding dong...

[SinricPro:sendMessage()]: pushing message into sendQueue

[SinricPro:handleSendQueue()]: 1 message(s) in sendQueue

[SinricPro:handleSendQueue()]: Sending message...

{

"header": {

"payloadVersion": 2,

"signatureVersion": 1

},

"payload": {

"action": "DoorbellPress",

"cause": {

"type": "PHYSICAL_INTERACTION"

},

"createdAt": 1603895525,

"deviceId": "5f91f28c0a046d3259896863",

"replyToken": "154294f6-dbfa-452d-bae7-a30b74e7af81",

"type": "event",

"value": {

"state": "pressed"

}

},

"signature": {

"HMAC": "AkrboyGEMiiksMTD8ZxW+4MJnE/5Ub9TWZFSRWTJbFg="

}

}

[SinricPro:handleSendQueue]: Sending to websocket

[SinricPro:handleSendQueue()]: message sent.

From: Boris Jäger notifications@github.com Reply to: sinricpro/esp8266-esp32-sdk reply@reply.github.com Date: Wednesday, 28 October 2020 at 14:49 To: sinricpro/esp8266-esp32-sdk esp8266-esp32-sdk@noreply.github.com Cc: Gabriele Rizzi gabriele.rizzi@smartsol.it, Author < author@noreply.github.com> Subject: Re: [sinricpro/esp8266-esp32-sdk] SinricPro.handle() refresh frequency (#98)

Please check if notifications are enabled for your device in the alexa app.

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sinricpro/esp8266-esp32-sdk/issues/98#issuecomment-717977846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZAZZTGMJTBKMIMNO2MINTSNAUK3ANCNFSM4TA6WMYQ .

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