I mean; this is the normal mode of operation for GitHub at this point.

0 nines.

9 nines found somewhere after the decimal point if you measure with enough precision

It would probably be a good idea to verify some of the ideas you're posting; some of them are oversimplified (or wrong) :)

Which ones jumped out as erroneous to you?

Sure, that means the idea of using unprotected cells was already there when the holders were selected :)

Yeah, I'm just saying, you can't even buy regular protected cells and put them in, because they won't fucking fit. I do think "actual" 18650 protected cells exist, but they would be rare and expensive because you can't build them out of mass manufactured bare 18650 cells (for obvious reasons of where do you put the damn protection circuit.)

The nomenclature, as commonly used isn't precise enough.

18650 means 18x65mm, but "protected 18650" usually means that cell with electronics stuck on the end, which ends up at 68-70mm long. Nobody calls the result "18680" even though that describes it more precisely.

There isn't a common cell slightly shorter than 18650 to produce protected cells that fit in every holder designed for 18650. The AA-size (but not AA-voltage!) 14500 often does come in protected versions that are exactly 50mm long, based on 14430 cells.

Ah yea then I misunderstood. That's right you can't easily switch out the cells for protected cells yourself :(

Thanks, fixed!

Thanks, I've written that one down in my notes as well it definitely fits the superstitions because it sounds like it should work well.

Yea, it's not super clear but that's indeed what I meant to say :)

Then change your code.

Every AP has a bssid (MAC address) that you can use to connect to specific AP.

It’s up to the code to figure out which one to connect to. The libraries have all the options.

When you do a scan you get bssid of the AP and strength of each signal. You can make a determination of when to rescan and reconnect.

The activation of the virtualenv is unnecessary (one can execute pip/python directly from it), and the configuring of your local pyenv interpreter is also unnecessary, it can create a virtual environment with one directly:

  pyenv virtualenv python3.12 .venv
  .venv/bin/python -m pip install pandas
  .venv/bin/python

Not quite one command, but a bit more streamlined; I guess.

Note that in general calling the venv python directly vs activating the venv are not equivalent.

E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.

Surely if you want to invoke python you call sys.executable otherwise if your subprocess doesn’t inherit PATH nothing will work with uv or without uv

I don't think that's "sure" at all. For one thing, only Python code directly calling Python has that option in the first place, often there is another layer of indirection, e.g., Python code which executes a shell script, which itself invokes Python, etc.

IME it is common to see a process tree with multiple invocations of Python in a ancestor relationship with other processes in between.

In rare cases, programs might also care about the VIRTUAL_ENV environment variable set by the activate script, and activation may also temporarily clear out any existing PYTHONHOME (a rarely used override for the location of the standard library). But yes, in general you can just run the executable directly.

Indeed, you're right ;).

Betteridge's law applies:

> Any headline that ends in a question mark can be answered by the word no."

No, it looks different from this.

Cool idea. I would be interested in knowing the concentration you achieve and flow rates (LPM/CFH). This wouldn't work in my workshop as we don't treat our equipment nicely enough and we don't have sparkies to tend to it.