I assume the server runs on a microcontroller, so it is not easy to live-debug what it is doing (or not doing), by looking at on-device logs. Could you add some code to the server so that it writes program progress to the filing system when you send the stop GET request?
It looks like you have your web server routing in here. It looks like it calls set_plasma_pattern, which is in the same file - it uses print - do you see that in your browser?
Yes, it all works fine (including print statements to console), until I start the first plasma pattern (e.g., fire). As soon the pattern is running, the webesrver becomes unresponsive.
OK, so you need to do some some debugging on the server, to narrow down where it is getting stuck. If you are running it headless then you’ll need to log intermediate debug line to a text file, assuming you have a writeable device on the compute device.
From my earlier post:
Could you add some code to the server so that it writes program progress to the filing system when you send the stop GET request?
Will be watching this closely. I have two Plasma Sticks setup to light up two small artificial Christmas Trees. I was thinking it would be cool to turn them on off over WIFI. Maybe even change the pattern via WIFI. I also have a couple of sets of the LED Snowflakes I’d like to control with a Pico W and control over WIFI. Snowflake Decoration - Lucky Resistor
@alphanumeric - what’s possible with the webserver is to call arbitrary functions that are on the pico. So in theory switching patterns should be no problem. The issue I’m struggling with is to have the pattern running (in one thread) while the pico webserver still listens (in the other thread).
@Bjoern It looks like the advice you’ve received on the bug report is the same advice as mine. I mean this kindly, and for the sake of helping you solve you problem: would you be willing to try modifying the code and running it, so you can see where it is getting stuck?
Feel free to set out in this thread what programming experience you have here, so that any replies you get from readers are tailored to your level. Nevertheless, if you have not done much in the past, diving in is often the best way! Readers may be able to help you debug too.
Does your microprocessor have a writeable file system that you can use to collect logs?
(Please add a link from that report to this one, since some of this conversation provides context.)
I’ve now put the code all into one file, snippet below. To explain, fire, is the function that operates the led strip (not in the original gurgleapps code). I have created a new function called blinker, that breaks out some of the code form the main loop (which was in the gurgleapps code).
The observation is this:
With Option 1 enabled and Option 2 commented out (i.e., not using fire), the code runs fine. That is to say, the server stays responsive, and blinking can be turned on/off.
With Option 1 commented out and Option 2 enabled, the server hangs. Having done the above, I actually figured out the solution - essentialyl following the github advice. The time.sleep(0.5) breaks the code. If replaced with await asyncio.sleep(0.5), the code works!!
async def fire():
while status:
for i in range(NUM_LEDS):
try:
led_strip.set_hsv(i, uniform(0.0, 50 / 360), 1.0, random())
except:
print("led_strip error")
await asyncio.sleep(0.5)
print("done with fire")
async def blinker():
while not shutdown:
if status:
# Option 1:
# led.on()
# await asyncio.sleep(blink_on_time)
# led.off()
# await asyncio.sleep(blink_off_time)
# Option 2:
await fire()
else:
led.off()
await asyncio.sleep(0.2)
return
async def main():
global shutdown
if config.BLINK_IP:
await(server.blink_ip(led_pin = led, last_only = config.BLINK_LAST_ONLY))
while not shutdown:
if status:
print("in")
await blinker()
print("out")
else:
led.off()
await asyncio.sleep(0.2)
I have a reasonable amount of general programming experience, but little experience with embedded python like this. Thanks for asking.