 Hello everyone. This is the Circuit Python Weekly for April 1st, 2024. It's the time of week where we get together to talk about all things Circuit Python. I'm Jebler and I'm sponsored by Adafruit to work on Circuit Python, which is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is a community effort, but it's sponsored primarily by Adafruit. So if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it slash discord. There is pretty much constant talk about electronics topics in the Discord, but this meeting is held in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel, usually on Mondays at 2 p.m. US Eastern, 11 a.m. US Pacific, except when it coincides with the US holiday. In the notes document, you can find a link to a calendar. You can view online or add to your favorite calendar app, which eases checking time zones and things, especially if you're outside of the US. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications or you'd like to participate in the voice meeting, ask us to add you to the Circuit Python East's Discord role. There is a notes document to accompany the meeting and recording. You can contribute to this document beforehand. The final notes document includes timestamps, so you can skip around to the part of the video that interests you the most if you're watching it after the fact. The meeting tends to run 30 to 60 minutes, depending how many folks have updates to share. And after each meeting, we post the link to the next meeting's notes in the Circuit Python Dev Channel of the Aideford Discord. Just hit that pinned messages button at the top to find the link so you can add your notes for the following meeting. And if you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. When you do that, it's super helpful if it's, you know, something that somebody can just read cold that they don't have to make a lot of interpretation of that. But anyway, the structure of this meeting, we're going to have five parts after this introduction. We're going to take a look at the community news, which is a set of items from the Python on Microcontroller's e-newsletter. Next up after that is the state of Circuit Python, the libraries, and Blinka, a quantitative overview of the whole project, a chance to look at the numbers separate from our individual updates. And then come the participatory parts. The third part is hug reports, an opportunity to highlight the good things folks are doing, taking time to recognize the awesome folks in our community that can be on Discord, on GitHub, on the Aideford forums, or just on the internet at large. The fourth part is status updates. It's the opportunity for anyone to report on what they've been up to, moving the status of Circuit Python forward, take a couple of minutes and talk about what you've been doing in the last week or since you had a chance to catch up with us, and what you hope to get up to over the next week or in the near future. And then the final part, if we need it, is called in the weeds. If we need a more long form discussion about things, whether this emerges from status updates or something that you have identified ahead of time, this is the place for it. And that covers how the meeting will go. And so next up we will start with community news. I've picked just a couple of Python related news stories or stories from the newsletter. And number one is a little project called EcoEDA, recycling e-waste during electronics design in KeyCAD. And this is a Python-based tool that integrates with KeyCAD and is designed to provide suggestions of recycled components whenever you add a new symbol to your schematic. Next up, Python tops yet another rankings list. And this is a link to a real news article published in ABC Australia. Python snake meat could become a super protein on dinner plates in years to come, research suggests. A study published in The Nature Journal has found the meat to be highly efficient environmentally friendly source of nutrition that can be raised on waste proteins. And then back to serious stuff for a moment, the Adafruit IO in 2024 survey last chance is coming up. Inspired by Scott's blog post circuit Python 2024, the Adafruit IO developers and designers are requesting feedback from you to help guide development of Adafruit IO in 2024. It's wrapping up soon, so please respond. There's a link to the Adafruit blog, which says if you're a current Adafruit free IO user or an Adafruit plus paid user or have previously used IO in the last year, we want to hear from you. And there's a lot more in the newsletter. The Python and Microcontrollers weekly newsletter is a circuit Python community run newsletter emailed every Monday. The complete archives are at adafruitdaily.com slash category slash circuit Python. It highlights the latest Python on hardware related news from around the web, including circuit Python, Python and MicroPython developments. You are invited to contribute your own edits, whether it's news that you ran across or a project of your own. And you can do that on GitHub. There's a link in the notes document and submit a pull request with the changes. You can also email CPnews at adafruit.com or tag a post with hashtag circuit Python on mastodon, blue sky or X. And next up, we have the state of circuit Python, the libraries and Blanka. We have our lovely Adabot run a report covering seven days of contribution information and that runs in the early hours of the morning US Eastern time. So changes that occurred today are not included in this report. And I will do the overall section and then ask some other Adafruit folks to take up some individual sections below. So overall, we saw 33 pull requests merged by 18 authors and eight reviewers. So thanks to all of those people. Among the authors, there are some names that are less familiar to me. We have URE, Yuri, Kyle Moore. Anonymous Cowhead is back. Thanks for sticking with us. Fabian Chouteau is a newer name for me. SAK917 and XS5871, I also don't recognize. And issues-wise, we saw 29 closed issues by 13 people and 16 opened by 12 people. So it's really nice to see those large numbers of people involved. And it's always nice when the net number of issues edges down a little bit. And with that, I'll ask Scott to go over the numbers for the core. Sure, thanks, Jeff. Okay, for the core, we had 24 requests merged from 12 different authors, which is awesome. Seed Areas, Fabian Chouteau, URE, SAK917, Kyle Moore, Sean the IT guy, XS5871, and Bablock B are all infrequent authors. So thanks to those folks. For reviewers, we had six reviewers. BlitzCityDIY, Retired Wizard, and Anecdater are all infrequent reviewers. So thanks to them. We had 24 open poll requests. So we're just under the 25 single-page goal that I have for us. Issues-wise, we had 14 closed issues by eight people and 14 opened by 11 people. So we're net zero, which is great. And we also have nearly signal digits on both opening and closing, which is awesome. We have a total of 672 open issues. We have nine active milestones. These are used to prioritize work by Adafruit-funded folks. If you have other issues that you'd like to work on, don't be afraid if they're long-term. We're happy to help shepherd changes that people want to see. But these are the priorities for Adafruit-funded folks. So we have four open issues for 9.0.x. These are like small fixes to the latest stable release, 9.0. We have zero open issues for 8.2x, which we could probably close at this point. I think we're feeling good about 9.0 well enough to close 8.2x. We have one open issue for 9.1.0, which will be the next feature release. And then we have 29 open issues for 9.xx, which are other things that we've had to do between before 10. And we have two issues, not assigned to milestones. So we do have some triage to do, although that may have been done between when these tasks were grabbed and when I'm reading them off there. All right, thank you, Scott. Next up, I'd like to invite Tim to tell us about the libraries. All right, thanks, Jeff. This section covers the circupython libraries, all of which can be found on GitHub under names like Adafruit underscore, circupython underscore, and then the name of whatever library it is. Across all of those libraries this week, we had eight pull requests merged by six authors. The name that was there that stuck out to me as newer or less familiar was VIN 1953. The other names there are folks that I see more frequently on this list. So thanks to them as well and VIN 1953 this week. We had four reviewers, also relatively usual suspects on reviewers, thanks to Melissa, Scott, Tektrick, and Dan. All the pull requests this week were just one day old, relatively light week, all brand new ones. That leaves us after the week with 72 open pull requests. The oldest one I believe is a draft one at 592 days and the newest one is actually two days old, which is interesting. Usually that shows one day. We had over the past seven days, 13 issues that were closed by six people with two new issues opened up by two people. That leaves us with 730 open issues across all these libraries and of those, we're down to five of them that are labeled as good first issues. You can find those five as well as all the other open issues in PRs over at circuitpython.org slash contributing, which is where you should head if you are interested in getting involved in the project. If you wanna start out with reviewing, that's usually a pretty good spot. Over on that contributing page, you'll find a list of all the open PRs. You can take a look through those. If you've got hardware for any of them, you can test it out. Otherwise you can just have a look at the code and the syntax spelling, et cetera. Leave a comment letting us know that you took a look and what you found. Once you get comfortable with that, we can get you leveled up to leave official reviews over on GitHub. If you like to get more involved on the coding side of things than reviewing, you can also view a list of open issues over on that contributing page. The open issues are issues that have been created on GitHub. So if you would like to try to tackle one of those, you can identify one that you've got hardware for or a particular interest in and go try to code up whatever change is mentioned in the issue and submit a PR with that change. The page does have a dropdown near the top that allows you to filter those, which is how you can pull out those good first issues if you'd like or search by one of a few other filters that are there. We do have guides for contributing to get in GitHub. If you need help, we also have folks available on the Discord. So just let us know if you're trying to contribute and having trouble, just let us know on the Discord. We're always gonna be happy to help folks get spun up with contributing, whether it's reviewing or contributing code or whatever. We want everyone to be able to contribute in whatever ways they can. In library PyPI weekly download stats this week, we had 151,767 downloads across the 325 libraries on PyPI. The top tens list is here in the note stock if you'd like to check those out. And then for new and updated libraries in the last seven days, there is a new EHTTP server, which is a different variation of HTTP server that was added to the community bundle, which looks really interesting. And then the RSA library was updated with some new examples. That's what we've got for libraries this week. Thanks. Thank you. And to round out this section, Melissa, would you like to give us the stats on Blinka? Yes, Blinka is our circuit Python compatibility layer for MicroPython Raspberry Pi and their single port computers. And let's see, I lost my place on here. Oh, here it is. The text is like smaller than the other ones. So this week we have five pull request merge by two authors and two reviewers leaving a net of four open pull requests amongst all the repositories, which is definitely less than I normally am reading off. There were two closed issues by one person and zero open by zero people leaving a net of 84 open issues. There were 15,121 PyPI downloads in the last week, 12,031 PyWheels downloads in the last month and we are at 132 supported ports. And that is it. All right, thank you to all three of you for going through that information for us. And now we're ready to move on to hug reports. Hug reports is a chance to highlight folks in the circuit Python community and beyond for doing awesome things. I'll start, then we'll go down the notes document in the order that folks are there. If your text only are missing the meeting, I'll read your notes when I get to them in the list. So I want to start with a group hug, but then thank Melissa for her patience as I worked on a PR about absolute image links on circuitpython.org. And shortly before the meeting, Todd Bot dropped a cool demo on Mastodon. There is a video and I think that Tim or somebody is going to put the link in the channel if you want to check that out, but otherwise you can find that link in the notes document. All right, next up is Anikdata, hello. Or I can just read it out. Happy to. Anikdata has a hug for me for ongoing work on SSL and server-side stuff like SOReuseAdder. Next we have Dan and then I have notes to read from Devin. Okay, thanks to Bill88T, who was trying the main branch and noticed that the tags, there was something odd when setting up the ESPIDF environment that it got the version wrong and that turned out to be due to tagging problems with our fork of their repo. So that was noticed and easily fixed. And then thanks to Anikdata and McCall-Fukusa and DJ Jevin and Retard Wizardence and other people, there have been many who are doing a lot of testing on network issues. There's a lot of discussion in Discord and also in a few different issues on GitHub and that's really helpful for people to kind of pin down what's really going wrong. Okay. All right, next I have the notes from DJ Devin 3. Coming up after that, though, is Tim, foamy guy. So DJ Devin 3 writes a hug for StudioStuff, Anikdata, Dan H, and Jebler for working together to fix a bug that prevented the RP2040 from starting HTTP server. The fix by Jebler was rolled into 9.1.0. A hug for Justin for his continued work on connection manager and rough linting. Also a thank you for the quick PR involving connection manager with HTTP server. A hug for Snakey Makercat for starting a port for the ElectroSmith Daisy Seed. After looking into it more, they figured out it has eight megabytes of flash so it could be a pretty nice circuit python port. A hug to Kmatch for the excellent learn guide on memory saving tips. It was a nice quick reference for using Memfree to track resource usage. Hugs for Toddbot, Anikdata, Deshipoo, Alpakenon, foamy guy, Tyeth, and many others for answering questions in the Help with Circuit Python Discord channel. A hug to Sean who is a relative newcomer to our Discord. They're doing a custom ESP32 board port, parallel display project and helping others with display related questions from the experience they've gained. A hug for Michael Pocusa for starting to port HTTP server examples to connection manager. A couple of hugs to foamy guy, the first for recommending Windows task scheduler to keep circuit python stubs updated as well as for the new outlined label for display text. It works very well. And that brings us to foamy guy and then to Kenny. All right, thank you. Hug reports for me this week. Thanks to DJ Devon 3 for diving into typing in some of the libraries as well as submitting a new feature for the IS31FL, something, something, something that I don't remember library. That's a matrix LED display driver. Thanks to Dan H for sharing a PDF copy and the idea of checking on Archive Orc to find a learn guide page that got deleted when I tried to use a rollback to the earlier state functionality while I was slightly panicking, trying to figure out how to get it back. Very much appreciated. Thank you to Jeff and that maker Melissa for improvements to the way that the images are included in the RSS feed on circuitpython.org and a group hug. Thanks. All right. And after Catni is maker Melissa, but go ahead, Catni. Hello. So first my hug is for Tyath for talking girl light setups with me and for answering an ate a fruit IO question. It's been so long since I've actually used the dashboard to track data that I couldn't remember whether I needed a single feed for individual things or so on and so forth. And that got answered really quickly. To follow me guy for working on interactive software for my conference badge and a group hug to my PioHio organizers team for being an amazing group of folks. That's what I got. All right. Thanks. Melissa, you're up next. And then I got some notes to read. Okay. I have to Jeff and Dan for a quick responsiveness with the circuitpython.org updates and group hug to my notes. All right. I have notes from snaky maker cat and then we'll go to Scott. First snaky maker cat says hug to DJ Devon three for being patient while I dig through the daisy seed guts. I know he is dying to test circuitpython on the new board and a group hug. And for one, Scott, you're not rounding out the section, but you are next. Yeah. Thanks, Todd, but for rounding out just in just a minute. First, I have a hug to Dan for figuring out Bill 88 T's issue that I hadn't pushed tags to the Adafruit USB IDF. I hadn't thought about that. And then thanks to TAC for working on D&Net for tiny USB for me. I know there's a lot going on in tiny USB land and it's really helpful when he's lets me interrupt him and kind of co-opt his time for a little bit. So I really appreciate that. All right. And the notes from Todd bot say group hug. Thanks for all the circuitpython work. It's so fun to hack on. A hug specifically for me for bitmap filter. I'm starting to play with it now for non photo uses to Kreer, Tanute, Dan H et al for getting parallel bus working and enabled for ESP32. These fast displays on fast processors are super nice. And that concludes hug reports. So we will move on to status updates. It's time to tell folks what we're up to individually. I'll start and then we'll go through the notes document once again. When I call on you, take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. And this is a great time to provide a quick tip or trick but if a discussion is gonna become long then we want to move it to in the weeds. So with that general reminder, I will get started. Last week I wrote a learn guide the first that I had written in a while. I used an RP2040 with the Feather RP2040 DVI to create a DVI converter for a particular vintage computer. And I use circuit Python to do it. So that guide is live on learn.aderfruit.com and was the 3,000th guide published on learn which is an amazing number. What I'm doing other than that is working on updates to the floppy IO module and the Adafruit floppy circuit Python package. That is mostly done. There's just one problem with PIO capture of flux that I need to get back to. And I'm hoping that with the fresh eyes of taking like five days off from it to do other stuff that I will just see that and fix it, but you never know. And that's what I am gonna be up to. Next up is Dan. Then I'll have some notes to read from DJ Devon 3. Okay. So last week was three circuit Python releases, 9.01 with some fixes, 9.02, which was a single point released to make to fix a missing pin on a single board which was just being introduced and also 9.10 beta zero, which includes a bunch of development changes working toward 9.10. So there'll probably be a 9.03. And related to that, there was a problem with analog in on NRF boards. So I fixed that in the 9.0 X branch. As mentioned, I updated tags to fix a problem, a build problem when you're using the main branch. That was really simple. I'm kind of watching over some testing of wifi stuff that's going on and to see at what point I need to start doing some deeper debugging in the core of what's going wrong with some wifi stuff, but I appreciate everybody who's working on that. And otherwise I just have a long list of 9.0 X and 9.0 XX issues to work on. Also over the weekend, I did a bunch of editing, fixed them really simple typos and stuff and a bunch of learned guides. And I will continue to do that when I get bored. Okay. Thanks, Dan. Next up, I have notes from DJ Devin 3. Submitted a PR for HTTP server that uses Connection Manager for the socket pool. The idea was well received and it was decided all examples with socket pool will use Connection Manager going forward. So that's a thing now we're full steam ahead with Connection Manager. I reported my multiplexed seven segment display project to 9.0 didn't run into any HT 16K33 library issues. It pulls six different API sequentially. So it's a pretty good torture test for socket reuse. It works great on an S3, but on the S2 it throws an ESP IDF memory error. I tracked the memory error as far back as 8.0 beta then handed my findings over to the devs. The mastodon API example I submitted two weeks ago is already broken as mastodon revamped their API this week and deprecated a lot of endpoints. It only required minor changes in the URL and endpoints to get it working again. Seems like they're moving towards OAuth 2.0. So it's probably just a matter of time before they completely deprecate their publicly open version one API and wrote a playground note on automating PIP and circuit Python stubs updates for Windows by creating a task scheduler bash script. So check out the eight of fruit playground for that. The next up we have foamy guy again. All right, thanks Jeff. Last week I updated some learn guide, both code in the repo and some pages that reference different bits of code but aren't checked into the repo for some of the updates to display IO in 9.0. But we decided to change the way that those warnings work and the timing of the deprecation and how that rollout will go. So those will sit as draft for now until we're ready. And then I did go back through the guide pages to change them back to how they were originally and also saved off a list of URLs this time. So when it is time to make that switch, we can actually just click through that list instead of searching through them again, which will save a fair amount of time when the time does come. I started up a Grove feather wing in a feather S3 TFT reverse with the intention, they've got some pins that are kind of backwards compared to how most normal feathers are, but I started them up that way so that they could be used back to back with the Grove plugs on one side and the display on the other side inside of a Simon type game that I would like to make inside of a cardboard box. My feather does have a dead TFT, so I've got to get a new one, but everything else did fit together how I'd imagined and the buttons work how I was imagining. So once I get the new device, I think I will be good to go on that, at least as far as what I have planned. I updated the display text learn guide to include some new sections for the two new types of labels, outline label and scrolling label. Both of those I created at some point after that guide was written and it was never updated to include them. So now they're there. I updated the pie charm page specifically that's in, I think it's in the Welcome to Circuit Python guide. There's like an advanced page and then pie charm is one of the sub pages there. I updated that to include information about the new device specific board stuff, so how you can enable that onto that page. And then lastly, I've been working on a Tic Tac Toe game that runs on the Eink display for a Badger 2040W. Most recently, the bits that I added were checking for the winners at the end of the game or really checking for the winner after every turn and then drawing a line through the winning pieces if there was a winner found. Currently it draws correctly, but it does need some help still because it refreshes the display a bunch of extra times and it also doesn't remove the line when it's time to start the next game. So it's close, but still needs some tinkering and that's what I have got. Thanks. Thank you. And next up is Catney, followed by maker Melissa. All right, so I finished up the software for my Girlite setups. There are currently three different versions because I ended up needing to mount the controller in an opposite orientation on one terrarium and there's another one running a, there's only one running a sensor, so three different versions of the software. I eventually figured out where to mount the other three, but it required rewiring the level shifter so the connector was coming out the opposite side of the Feather sandwich. The difference in the code on the other three is that one's currently running the temperature and humidity sensor out inside the terrarium. I'm only running one at the moment to compare to one that I have outside the terrarium to see if there's any point in adding it into the other setups or whether the climate inside is identical to ambient. So far it seems that LEDs increase the temperature in the terrarium during the day, but it's basically identical at night. That said, watching the humidity spike after watering and seeing how long it remains high is at least interesting. So that may be enough reason to add sensors to the others. The one with the sensor displays the date, sensor data and what the manual LED status is which is to say whether or not I turned the LEDs on or off using a button on the controller and the ones without sensors display the date and LED status only. My wife designed a 3D printed case for the controllers that mounts to the terrariums using magnets. It's a really slick design and it worked incredibly well for my needs. We're finishing up a case for the sensor to allow airflow, but avoid directly misting the sensor board when watering the plants. It looks really neat so far, but we need to test it to make sure the airflow is enough. After that, we're designing a case for the Badger 2040W with that is gonna be running the code that Tim was talking about. For me, the case, I added Neopixels to mine by soldering three wires of a STEMQT cable to it and using the quick port on the Badger to connect them. The Neopixels are about the same height as the Badger so I'm going to add them into the case along the left side of the board. And then completely unrelated, I'm not sure I shared this here, but I agreed to be conference chair for Pi Ohio 2024 which is where my hug report to my organizing team came from. It is an incredible amount of work, but I have an amazing team of people helping me. So hopefully I can get everything going in time and within budget. But it's been an incredible learning experience and I'm very excited to be doing that. So if you are in the area and or want to come out, it's July 27th and 28th, I think, in Cleveland, Ohio. Anyway, that's what I've got. Thank you. And next up is maker Melissa. Hello. So I added the new boards to circuitpython.org that were added to circuitpython 9.1 beta and fixed compiler warnings in some Arduino libraries to fix some small issues in a couple of circuitpython libraries. I updated the magic storybook guide with, or this magic storybook with chatGBT guide for Bookworm and the latest open AI API. And I'll probably update the chatGBT bear project to Bookworm next. And that's for a minute. Thank you. Next I have notes from Snakey Maker Cat who writes, I started working a few weeks ago on the circuitpython port to the Daisy Seed, a really cool STM32 board, but ran into the 128KB internal flash issue early on. Luckily, there is an eight megabyte chip external flash and 65 megabytes of RAM that makes the project totally work the effort. Unfortunately, the documentation from ElectroSmith is not great, especially since they went closed source recently, and the only available config file for the flash chip contains plenty of mistakes. So at the moment, I'm working on an STM cube IDE project and digging through data sheets to figure out the right configurations for the MCU and how to use the Q-Spy flash in XIP mode. It's easier to test all that in the ST work environment. I'm sure I will get to the actual circuitpython part soon. And this time, Scott, you do get to finish the section. So what's up? So I'm giving a podcast gates talk next weekend. It's mostly done. They actually wanted slides yesterday, which I didn't realize until Wednesday evening last week. So I was doing a lot of work on my podcast gates talk on Thursday and Friday. So thanks to DeepDivers for working through them with me and giving feedback. I do have some bugs to file for the mobile apps. I'm gonna try to do that today as well. And then after that, I'm back to the USB host featherwing work. I tried to show it on, show and tell on Wednesday and saw that there was a bug and I figured out soon after that that I had the console UART set up for circuitpython debugging and but the like input serial stream was just floating pin, which meant that like any sort of noise that I generated was causing random inputs to circuitpython, which it caused my demo to not work. So remember that if you're ever in a world where you're getting using the UART input into circuitpython, make sure that your RX pin or like the data going into circuitpython is pulled down or up whatever it should be for UART. So you don't get just a bunch of random stuff in. All right, pro tip tips from Scott. But next we have the section in the weeds. In the weeds is an opportunity for long form discussions. If you have any in the weeds topics, please make sure they get added while we're discussing other things. So we're not waiting around to see if anybody has topics and we do have a topic from Dan. So I will let you take it away. Okay, this topic came up in issue 9112 that's linked in the notes. Circuitpython issue 9112. So the question is right now, well it used to be that we would give Wi-Fi credentials in two variables in secrets.py and then we switched that to settings.toml. And then very much because of the web workflow, we decided that if two variables were used, circuitpy Wi-Fi SSID and circuitpy Wi-Fi password that we would auto connect to that access point when circuitpython started up. And if I'm correct, Scott, you can tell me yes or no. That always happens, but the web workflow isn't started unless the circuitpy web API password is set. Right, it used to be that if you had the auto connect stuff, then the MDNS server and the HTTP server for the web workflow would start. And then you would just, it would tell you that you needed to set the password but people wanted to separate that out. So we've tied the web workflow to the presence of the password now. And does the MDNS server start on auto connect or only when the password is present? I believe it's gated by the password too. Okay, all right. So the fact that auto connect occurs at all is it's not clear from the names, but they are kind of official sounding names. There was some discussion in examples of whether we wanted to give examples that use some other names to distinguish whether or not. You wanted auto connect or not, or you could add a flag and use the same names but suppress auto connect by saying set circuit pi Wi-Fi auto connect to zero or if we implemented Booleans, which we don't have yet, in settings.toml to set it to false. So I think we have some kind of varying ideas on this. And I think the question is what's clear and should we document this somewhere? Should we think about changing the names in the long run to make it more obvious that auto connect happens from the names? Like you could think of names could be circuit pi Wi-Fi password auto connect or something like that. But that's mouthful and we'll have to change a whole lot of examples. My intention was that the circuit pi prefix meant that it was something that circuit pi would do something based on. Yeah, yeah. And I understand that, but it's not, it's still you have to look up what it is or you have to know. It's like it's not manifest from the name. So it's not sort of, so- Yeah, the auto connect is. Yeah, the auto connect, the word auto connect isn't there or something. It is. You could put a comment in. It is documented. In settings.toml that says what, you know, like a tiny bit of documentation or something like that. And I was just wondering whether people have ideas about this and whether when auto connect happens, it screws them up where they like it. I mean, I don't think it makes a lot of difference. It makes it go a little faster if you haven't enabled the web blur flow. But I'm not sure what other, whether there are disadvantages for the auto connect and whether people are even aware that auto connect is happening. Also, I guess when you do a deep sleep, I don't know, does it be auto connect when you wake up from deep sleep? I don't even know if you answered that question. And that takes a while. So you don't really want to do that if you're just doing something simple. So all those things make it a little complicated about. It looks like it does. It will auto connect again for you. Right. It will not start the workflow again. Okay. So that first link I posted is into this logic. So it does, it gets the SSID, it gets the password. If it can't get those, it returns. And if it can't get those, it calls connect. If connect doesn't work, then it just disables the radio returns. And then it gets the reset reason. And, oh, I guess deep sleep alarm, reset reason doesn't equal deep sleep alarm, then return false. So I guess it will start, it will start the web workflow again after deep sleep alarm. Okay. So that means it's kind of expensive to wake up from deep sleep if these things are set. So, and then the question is like, I know this foamy guy says in the comments that he likes auto connect because it's nice not to have to actually put a Wi-Fi.radio.connect in the user code and have to look up the environment variables. And I guess the question is like, well, what should be the standard boiler plate or not? And, we could say like, okay, you can do a connect or if you do this, it will connect automatically. And it's sort of like, there are definitely two use cases and they're both kind of equally valid. So, I don't know if, so David glowed the pet, it's the password. This is not the Wi-Fi password. This is a password that you have to type into the browser when you're using the web workflow. Well, we won't connect if there's no password. Right. It's a separate issue. It's not related to this discussion. Yeah, yeah. Like, yeah. If, if circuit by what Wi-Fi password is not found. Oh, actually, no, if, if it's not set at all, then it assumes there's that it's an open network. Web API, web API password or Wi-Fi password? Wi-Fi password. So you, you, you can auto connect if you have an open number. Yeah, that makes sense. It's the web API password that I'm talking about that. It's really a different password completely. So. Well, yeah, for Wi-Fi password. So my, my response on the issue was if people want to store Wi-Fi credentials but not have circuit Python do anything with them, they should just use a different key. So I can be the question is then in the examples, like we have examples all over the Wazoo that say like, here's a sample test program to get you started with Wi-Fi and what, what should be the standard? Should the standard example use the auto connect behavior or not? I think it should because I think web workflow is good. Okay. I think by default people should have web workflow on. Okay. I have one quick observation about that. When I hung out with JP a couple of weeks ago, he had brought his Memento camera and he wanted to take it out and make a quick snapshot of something. And this, this could be down to his configuration and in this case, you'd want to change it. But anytime he wanted to turn the camera on, he had to wait out the auto connect timeout of his Wi-Fi that he had previously configured. And that was not great. And, but I don't know what the solution is to that because you do want to then connect to it on web workflow and download a SD card image or whatever it is. So in summary, I'm not sure what the solution is, but this is a pain point that I noticed someone having with Memento specifically and web workflow or Wi-Fi, automatically Wi-Fi connecting at boot time. That's all. Right. Well, maybe for the Memento, that's an example of something that's used in a portable environment a lot. So maybe that needs to be discussed in the appropriate guide or guide. I think there's, I think there's optimizations that we can do. That could make all of this faster. Like if there's a timeout that we have to wait for, then we could try to set the timeout lower. We could also like, we could add a key that allows you to specify what channel the Wi-Fi's on or we could automatically save it ourselves so that like we know what channel to start searching for. Cause like, yeah, and even I have a to do in here. It says do our own scan so that we can find the channel we want before calling connect. Otherwise connect will do a full slow scan to pick the best AP. Yeah. I think there are other possibilities like asynchronously doing the Wi-Fi connect. I mean, I know some of the APIs allow you to initiate the connection and then get a call back. And that would be something we'd have to kind of take care of in the core, but it seems like. We would need to add that internally. It could happen asynchronously compared to starting your code.py potentially. It's probably tricky to do, but it's not impossible. Anybody else have something to say or Dan, do you want to say any wrap up to that? I don't know, I can reach a conclusion, but this is helpful that I got other input that everyone contributed to this discussion and I see where anybody is coming from. If we assume web workflows enabled there's simple examples that even need connect logic. I mean, maybe not. Maybe when we write those examples, we say explicitly because you set these things, circuit pipe them will auto connect for you. Right. I think it should be, it needs to be better documented for sure. Right now it's documented in the reedid docs, but not in the guides so much. That's not so great. And we could also use up bytes in the firmware, but we could, the default settings.toml could have information in it. Yeah. And the sample settings.toml could also have that same, like if you set these things, it will auto connect. And so whenever anybody copies a sample one and edits it, they'll know right away. So I'll kind of look at the guides and see if we can do something. Some nice asked, will Wi-Fi radio enabled equals false prevent auto connect? It will not. It's too late. It's too late because the auto connect happens before user code runs. Yeah. And then anecdote it says, when connect logic is desired, do we want some pseudo standard settings that toml credentials to user recommend? Yeah, I would do what you suggested I think anecdote, which is Wi-Fi SSID and Wi-Fi password. That's what I do in my own programs for what that's worth. Right. And there is, I think we do have some work on the web workflow side to work, like to do the reverse of like manually connect a Wi-Fi that then turn on web workflow automatically. If like, maybe we don't want auto Wi-Fi connect, but we do want auto web workflow. So like, if your user code does some more fancy logic for like multiple SSIDs if you're roaming, but you've set in your settings.toml, like the API password, then maybe we should auto start web workflow after a manual connect. I don't think that works either. Yeah, that's not even an issue that says that. So maybe we need to open that issue. Right. So I can file an issue for that. Okay. All right. Well, this is good. This is just what I wanted. Yeah, it was a little bit of brainstorming on this. Okay. All right. Well, thank you everybody for that discussion and for everything else. I'm going to wrap up this meeting. This has been the Circuit Python Weekly Meeting for April 1st, 2024. Thanks to everybody who participated. And just a reminder, we'd love it if you could support Adafruit and Circuit Python and folks like me who work on Circuit Python. And you can do that by purchasing from the Adafruit shop at adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. You can visit adafruitdaily.com to subscribe. The next meeting will be held Monday, April 8th, 2024 at the usual time of 2 p.m. Eastern, 11 a.m. Pacific. And that meeting is held on the Adafruit Discord, which you can join by going to adafruit.it slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Pythonistas role on Discord. We hope to see you all next week. Thanks again, everybody.