Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMG doesn't like... #1989

Open
kroman666 opened this issue Jul 10, 2024 · 9 comments
Open

OMG doesn't like... #1989

kroman666 opened this issue Jul 10, 2024 · 9 comments
Labels

Comments

@kroman666
Copy link
Contributor

A story.

I am using OMG for bluetooth detection since years. Two ESP32 are doing their job 24/7 without issues, upgraded to 1.7.0 quite soon after it arrived if I remember correctly.

Suddenly OMG1 was offline, not pingable. After reset, it work for a couple of hours, but then offline again. The TRACE log didn't give a hint and I missed to change to VERBOSE via web.

So I thought, okay, hardware can fail and I flashed another ESP32 with the same configuration.
It seemed to work at the beginning, but then it went offline again and OMG2 did the same.

At this point it was hard, I didn't know what's going on.
Hardware - already replaced; was the new hardware faulty too?
Software - not changed, can be excluded

So 3 hareware faults at a time?
As I couldn't believe that, but didn't have other ideas either, I did nothing for a while as I didn't know what to do at all.

What would be your ideas at this step? :)

@kroman666 kroman666 changed the title OMG doesn't like Shelly BLU Button Tough 1 OMG doesn't like... Jul 10, 2024
@kroman666
Copy link
Contributor Author

Okay, I f.. it up, submitted the title unwanted.
However, let me proceed.

Then I remembered that I bought a Shelly BLU Button Tough 1 for playing which was somewhere aroung.
I changed the log to VERBOSE and saw this at the end:

N: Scan begin
T: Creating BLE buffer
N: Device detected: 7C:C6:B6:61:FE:F4
T: getDeviceByMac 7C:C6:B6:61:FE:F4
T: Get services data number: 1
T: Converted service data (7) to 44003501643a00
T: Service data: 44003501643a00
T: Service data UUID: 0xfcd2
T: Processing BLE data 7C:C6:B6:61:FE:F4
T: Decoder found device: SBBT-002C
T: getDeviceByMac 7C:C6:B6:61:FE:F4
T: add 7C:C6:B6:61:FE:F4
N: Active and continuous scanning required, paramaters adapted
T: Enqueue JSON
ERROR A stack overflow in task procBLETask has been detected.

Backtrace: 0x40083bad:0x3ffe55e0 0x40095b15:0x3ffe5600 0x4009977d:0x3ffe5620 0x4009773f:0x3ffe56a0 0x40095c24:0x3ffe56d0 0x40095bd4:0xbaad5678 |<-CORRUPTED

Since I removed the shelly, both OMG work fine again.

@1technophile
Copy link
Owner

Could you try the development version and let us know if it fixes your issue please
https://docs.openmqttgateway.com/dev/

@kroman666
Copy link
Contributor Author

Sure, I installed one OMG with the dev binary via web.
No crash so far, since ~2 hours, but I'll wait longer and report again.
Btw. is there any reason why the code from the dev version cannot be downloaded from github?
Usually I used PlatformIO and my own _env.ini file to program the ESP.
So now the difference is that default parameters are used in case this is important.

@1technophile
Copy link
Owner

Btw. is there any reason why the code from the dev version cannot be downloaded from github?

You should be able to clone the repository, what is preventing you from doing this?

@kroman666
Copy link
Contributor Author

Sorry, I was just searching on the releases page and didn't consider this.
So now 2 OMGs were running 1 day, one with 1.7.0 and the other with the development version.
The one with 1.7.0 went offline an hour ago while the other is still running.
So looks like the dev version doesn't have this problem, even I'm not sure if the crash would have to happen on both at the same time.
However, if something new happens, I will let you know.

@kroman666
Copy link
Contributor Author

Unfortunately the problem is not solved with the development version. Seems I didn't recognize immediately because it's rebooting now instead of hanging up.

T: Creating BLE buffer
N: Device detected: 7C:C6:B6:61:FE:F4
T: getDeviceByMac 7C:C6:B6:61:FE:F4
T: Get services data number: 1
T: Converted service data (7) to 4400a101643a00
T: Service data: 4400a101643a00
T: Service data UUID: 0xfcd2
T: Processing BLE data 7C:C6:B6:61:FE:F4
T: Decoder found device: SBBT-002C
T: getDeviceByMac 7C:C6:B6:61:FE:F4
T: add 7C:C6:B6:61:FE:F4
N: Active and continuous scanning required, paramaters adapted
T: Enqueue JSON
T: Qu
ERROR A stack overflow in task procBLETask has been detected.

Backtrace: 0x4009d6ac:0x3ffe6490 0x40095d57:0x3ffe6570 0x4009977d:0x3ffe6590 0x40097781:0x3ffe6610 0x40095c24:0x3ffe6640 0x40095bd4:0xa5a5a5a5 |<-CORRUPTED

ELF file SHA256: 77957ce7d00999b0

ERROR A stack overflow in task procBLETask has been detected.

Backtrace: 0x40123e99:0x3ffe62f0 0x401241cb:0x3ffe6360 0x40083c3d:0x3ffe63b0 0x4008d479:0x3ffe63d0 0x00040021:0x3ffe6490 |<-CORRUPTED

ELF file SHA256: 77957ce7d00999b0

Re-entered core dump! Exception happened during core dump!
Rebooting...

@1technophile
Copy link
Owner

Could you try the development version of esp32dev-ble-idf. It has more memory for procBLETask.

@kroman666
Copy link
Contributor Author

Thank you for the hint, indeed this seems to work better, i.e. I see less disconnects on HA.
I traced some disconnects and at least not all of them are caused due to resets.
For now I will go back to 1.7.0 without the shelly, which is stable setup for the holiday season (I never had disconnects in 1.7.0 before).

Thank you.

Copy link

github-actions bot commented Nov 1, 2024

This issue is stale because it has been open for 90 days with no activity.

@github-actions github-actions bot added the stale label Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants