uRequests and Pi PicoW #10229
-
I'm having both success, and an intermittent problem with a code I've written on a Raspberry Pi PicoW utilizing network, and urequests and ujson. I've implemented try and exception blocks in the code, but yet, I seem to keep having a stall in getting data from urequests. Apologies in advance if this isn't the appropriate place to post this issue, I've tried StackOverflow but no responses. I'm pretty sure I've narrowed the issue down to urequests being the problem, as I have exceptions everywhere else, and it seems that the only place that could be causing this issue is after the code calls urequests.get() To summarize, this project is using a Pi Pico W, with a 4 digit, 7 segment display, running MicroPython. The goal of the project is to gather temperature data from an API for an industrial oven, and the multiplex that data to display on the 7 segment display. Using both cores with _thread to acheive both a constant check for temperature, and a constant looping of the temperature data on to the display to multiplex it. This all works great, and works consistently for a long time. However: An issue continues to arise pretty much every time I use this project, but at unpredictable times, where the temperature data received stalls, but doesn't throw an exception. So the temperature value freezes (even though the network, and API are still both alive), but the multiplexing loop continues. Eventually it will begin to work again after a long amount of time passed, or the board is unplugged and restarted. My suspicion is that it for some reason is taking an excessive amount of time to call urequests.get(), or that something happens that causes it to get hung up, but not throw an exception to cause the machine.reset(). Please note this code is still a major work in progress, so likely a lot of unneccesary things hanging around in places still that I haven't came back and tidied up yet. This project took a lot more testing and altering than I expected. Heres the code as it runs currently for reference. The get_temp() function is where I'm 99% certain the issue is coming from. But, mostly asking if anyone has had any issues similar with urequests after running for a long period of time
|
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 4 replies
-
@captaincaden sorry about the delay responding. Could you please confirm that you're using a recent build (i.e. a nightly from at least December). When you say it "stalls" what does that mean exactly? I suspect you could be right about the request timing out. Have you tried passing the i.e. r = requests.get(temp_url, timeout=1) # 1 second |
Beta Was this translation helpful? Give feedback.
-
Hi @jimmo ! No worries. I appreciate your response! I believe I’m using a recent build, but will double check. Stalling implying that the temp variable stops updating, and never starts again until the machine is restarted manually, or until the code forces a restart from an exception of requests.get() (which sometimes happens, and sometimes doesn’t) . The temp variable is updated every second from the requests.get() to the API url. The code itself continues, which is obvious because the 7 segment display loop still continues to run, (it’s multiplexed, so if it stopped, only one digit would display) but the temp variable stays constant, despite the API still being accessible, and the temp value changing. I have not tried the timeout kwarg, but I will add it later and see what happens. That sounds like what will resolve this problem. I’m unfamiliar with the requests library in general, and even more unfamiliar with all of the kwargs for urequests, and I wasn’t able to find documentation easily, so I was unaware that kwarg existed, but will update when I add it! This problem has been very intermittent, so proving that it’s not happening anymore may take some time. Again, thank you for responding, and for the help! |
Beta Was this translation helpful? Give feedback.
-
Adding the timeout kwarg to .get() and then using machine.reset() if it does timeout has seemed to correct the issue. When it freezes, it very quickly resets and displays the temp correctly again. Just have to do some testing. Thank you again! |
Beta Was this translation helpful? Give feedback.
-
Hi, captaincaden, Did you find a solution in the meantime? |
Beta Was this translation helpful? Give feedback.
-
Just an improvement of your code, to reduce the source code size. It does not solve the other problems. ...
# definition of pins and setting
# explicit the state of the pin with value
dig1 = Pin(10, mode=Pin.OUT, value=0)
dig2 = Pin(11, mode=Pin.OUT, value=0)
dig3 = Pin(12, mode=Pin.OUT, value=0)
dig4 = Pin(13, mode=Pin.OUT, value=0)
# put the pins in a list for later use:
dig_pins = [dig1, dig2, dig3, dig4]
# the other pins in a dict, to address them with their p
other_pins = [
Pin(2, mode=Pin.OUT, value=0),
Pin(3, mode=Pin.OUT, value=0),
Pin(4, mode=Pin.OUT, value=0),
Pin(5, mode=Pin.OUT, value=0),
Pin(6, mode=Pin.OUT, value=0),
Pin(7, mode=Pin.OUT, value=0),
Pin(8, mode=Pin.OUT, value=0),
Pin(9, mode=Pin.OUT, value=0),
]
# pay attention, that the ERROR_MASK has the same amount
# of elements as other_pins
ERROR_MASK = (0, 1, 1, 1, 1, 1)
def error():
"""
displays EEEE
"""
clear()
for pin in dig_pins:
pin.value(1)
for pin, value in zip(other_pins, ERROR_MASK):
pin.value(value)
for pin in dig_pins:
pin.value(0) |
Beta Was this translation helpful? Give feedback.
@captaincaden sorry about the delay responding.
Could you please confirm that you're using a recent build (i.e. a nightly from at least December). When you say it "stalls" what does that mean exactly?
I suspect you could be right about the request timing out. Have you tried passing the
timeout
kwarg to therequests.get()
method?i.e.