Time to move website to server / Discord webhook issue #27

New Issue

sickprodigy · 2025-11-14T21:54:24-05:00

sickprodigy commented

2025-11-14 21:54:24 -05:00

Discord webhooks not wanting to work. enoem and chatgpt says it's a ram issue basically. Been trying to clean it up but may just need to make an api on pico, and host the server elsewhere. May just do 2 different versions idk.

sickprodigy changed title from ~~Time to move it to a website / Discord webhook issue~~ to Time to move website to server / Discord webhook issue

2025-11-14 21:57:08 -05:00

sickprodigy commented

2025-11-14 22:00:04 -05:00

it would be nice to just have everything self-contained though. I mean how many people are running a server. May divulge this project down 2 lines if I have to. Give a try at forking and keeping most of it mostly the same but just porting out the website part. Tried to keep it mostly to it's on file anyways. The file would still have to be converted to talk to server and have an api. (web_server.py file) removed and possibly api.py file imported.

sickprodigy commented

2025-11-15 14:58:57 -05:00

Did a lot of bs to get the webhooks working in its current state. need 100kb of memory just to hit a webhook. Would an api be any different. Trying to send shit through an api that will update. Or should I have the api on the pi, and have the website ping the api every so often. Can't think about it right right now.

sickprodigy commented

2025-11-15 15:04:04 -05:00

Also would note i had to set a threshold of around 95000 bytes in order to get webhooks rolling. The pico in it's current state uses about 80-90kb of memory actively. Even with doing a lot of gc cleanup. in order to get the saving of schedules notification sent I have to del params, prev_schedules, prev call gc.collect() then try to pass webhook. Then i 'del schedules' to clear up some more room. Something about ssl and webhooks is the issue. So local hosting would be better. Or just run everything on regular pi. Because it would be a lot easier than this for real

The below is before anything is loaded and right after wifi connects. So not much is loaded yet technically.
DEBUG: Free RAM before Discord send: 165 KB

After schedules and everything is loaded here is example:

==================================================
Startup Memory Check:
==================================================
Total:      187.4 KB
Used:       86.3 KB (46.0%)
Free:       101.2 KB (54.0%)
==================================================

Also would note i had to set a threshold of around 95000 bytes in order to get webhooks rolling. The pico in it's current state uses about 80-90kb of memory actively. Even with doing a lot of gc cleanup. in order to get the saving of schedules notification sent I have to del params, prev_schedules, prev call gc.collect() then try to pass webhook. Then i 'del schedules' to clear up some more room. Something about ssl and webhooks is the issue. So local hosting would be better. Or just run everything on regular pi. Because it would be a lot easier than this for real The below is before anything is loaded and right after wifi connects. So not much is loaded yet technically. `DEBUG: Free RAM before Discord send: 165 KB ` After schedules and everything is loaded here is example: ``` ================================================== Startup Memory Check: ================================================== Total: 187.4 KB Used: 86.3 KB (46.0%) Free: 101.2 KB (54.0%) ================================================== ```

sickprodigy commented

2025-11-15 15:12:53 -05:00

So in order to run webhooks i need above 95kb of memory free at all times. Even though in my testing it took about 30-40kb of memory just for a single script to run a webhook.

Even though a simple webhook script may only use 30–40KB, you need much more free memory for reliable Discord webhook sends on MicroPython. Here’s why:

TLS/HTTPS Overhead
- Discord webhooks use HTTPS, which requires TLS encryption.
- The TLS stack (certificates, buffers, handshake, encryption) is very memory-intensive on microcontrollers.
- MicroPython’s TLS implementation often needs a large, contiguous block of RAM—much more than the script itself.
Memory Fragmentation
- MicroPython’s memory can be fragmented, so even if you have 40KB free, it may not be in one contiguous block.
- TLS libraries (and sometimes urequests) need a big, contiguous chunk for buffers.
Temporary Objects
- During a webhook send, many temporary objects are created: HTTP headers, buffers, sockets, encryption contexts, etc.
- These objects are created and destroyed rapidly, but peak memory usage can be much higher than the average.
Garbage Collection Timing
- If you run gc.collect() right before sending, you maximize available memory.
- But if other objects are still referenced, they can’t be freed, so you need a higher threshold to be safe.
MicroPython’s Conservative Memory Checks
- Your script checks for >95KB free before sending to avoid ENOMEM errors.
- This is a safe margin to ensure the TLS stack and all temporary objects can be allocated.

Summary:

TLS/HTTPS needs much more RAM than the webhook script itself.
Fragmentation and temporary allocations mean you need a bigger margin.
95KB is a practical threshold for reliable Discord webhook sends on Pico W.

If you want to experiment, you can lower the threshold, but you’ll see more ENOMEM errors and failed sends.

So in order to run webhooks i need above 95kb of memory free at all times. Even though in my testing it took about 30-40kb of memory just for a single script to run a webhook. Even though a simple webhook script may only use 30–40KB, you need much more free memory for reliable Discord webhook sends on MicroPython. Here’s why: 1. **TLS/HTTPS Overhead** - Discord webhooks use HTTPS, which requires TLS encryption. - The TLS stack (certificates, buffers, handshake, encryption) is **very memory-intensive** on microcontrollers. - MicroPython’s TLS implementation often needs a large, contiguous block of RAM—much more than the script itself. 2. **Memory Fragmentation** - MicroPython’s memory can be fragmented, so even if you have 40KB free, it may not be in one contiguous block. - TLS libraries (and sometimes `urequests`) need a big, contiguous chunk for buffers. 3. **Temporary Objects** - During a webhook send, many temporary objects are created: HTTP headers, buffers, sockets, encryption contexts, etc. - These objects are created and destroyed rapidly, but peak memory usage can be much higher than the average. 4. **Garbage Collection Timing** - If you run `gc.collect()` right before sending, you maximize available memory. - But if other objects are still referenced, they can’t be freed, so you need a higher threshold to be safe. 5. **MicroPython’s Conservative Memory Checks** - Your script checks for >95KB free before sending to avoid ENOMEM errors. - This is a **safe margin** to ensure the TLS stack and all temporary objects can be allocated. --- **Summary:** - **TLS/HTTPS needs much more RAM than the webhook script itself.** - Fragmentation and temporary allocations mean you need a bigger margin. - 95KB is a practical threshold for reliable Discord webhook sends on Pico W. If you want to experiment, you can lower the threshold, but you’ll see more ENOMEM errors and failed sends.

sickprodigy added the bug label 2025-11-15 15:18:22 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sickprodigy/Auto-Garden#27