UPDATE! I discovered the "drake.py" file in my github  was NOT the program I describe here. I re-wrote the drake.py program and have replaced it in the archive.

I enjoy the prospect of SETI, the Search for Extraterrestrial Intelligence. So it's only natural that I'd like to do something with the Drake equation  "... the probabilistic argument used to estimate the number of active, communicative extraterrestrial civilizations in the Milky Way Galaxy." (https://en.wikipedia.org/wiki/Drake_equation)

Happily I found an example of coding this calculation (https://github.com/DeaconDesperado/pydrake) that I could adapt for this project. I've put the code in a repository "Drake"

Files

• drake.py - calculate the Drake equation- based on https://github.com/DeaconDesperado/pydrake
• sagan - Carl Sagan quotes
• wise.py - selects quotes to display
• ncount.py - used for blinking neopixels
• prt.py - allows prt() to print to REPL or HID keyboard input

Copy the files to your NeoTrinkey running (renaming drake.py to "code.py").

Touch pad#1 for the NeoTrinkey to calculate and print out the estimate - since the factors are coded as ranges, you will get different answers every time. After presenting the calculations, the program will also give a random quote from Carl Sagan - he describes the Drake equation in chapter 12 of his book "Cosmos." This is the "Science" part of my project

For fun, touching pad#2 will give a list of the names of the civilized planets - basically generating a random name for as many as the program calculated (plus Earth). Be aware that the number can be large and this will take a while. And yes, this is the "Fiction" part. :)

Change REPL=False to REPL=True to have output go as if typed via the keyboard.

Output looks like this:

How Many Alien Civilations?
Number of stars in the Milky Way 1e+11
Fraction of stars with planetary systems 0.131585
Number of planets suitable for life 4
Fraction of suitable planets that develop life 0.283515
Fraction of life that becomes sentient and eventually intelligent 0.118758
Fraction of intelligent life that advances to the point of communication 0.0128657
Adjustment for incidence of self-destruction 1.10132e-06
possible number of civilizations 25

Who are we? We find that we live on an insignificant planet of a humdrum star lost in a galaxy tucked away in some forgotten corner of a universe in which there are far more galaxies than people. Carl Sagan

1: Earth
2: Gieuas
3: Zoiah
4: Syoei
5: Mieud
6: Zoafas
7: Syan
8: Theuei
9: Kieei
10: Zoghie
11: Syaie
12: Syafnk
13: Zoyah
14: Paeah
15: Miiah
16: Miuof
17: Reaah
18: Ahghd
19: Aheei
20: Giafn
21: Reud
22: Kiyah
23: Kighn
24: Theie
25: Miud
26: Kieuof

Hope you have fun with this - may it give you something to ponder as you look at the night sky.

I'm not talking about an ill-named monster rocket booster, but honest-to-goodness STARSHIPS! As Wikipedia puts it:

A starship, starcraft, or interstellar spacecraft is a theoretical spacecraft designed for traveling between planetary systems.^[1] The term is mostly found in science fiction.

https://en.wikipedia.org/wiki/Starship

I've certainly not got the resources to make such a vehicle... but what if you could build a really small spacecraft? Say, like this?

This was my inspiration to make a "Starship" on my NeoTrinkey - a simple spaceship program. My "ship on a chip" defines the decks of a ship and a set of potential destinations.

I've included it all in a github repo "Ship on a Chip"

• What IS a "starship?" :https://en.wikipedia.org/wiki/Starship
• Inspired by https://en.wikipedia.org/wiki/Breakthrough_Starshot, https://www.scientificamerican.com/article/inside-the-breakthrough-starshot-mission-to-alpha-centauri/
• trekdecks uses Enterprise deck as found at: https://memory-alpha.fandom.com/wiki/Constitution_class_decks
• Galaxy class decks: https://memory-alpha.fandom.com/wiki/Galaxy_class_decks
• Defiant class decks: https://memory-alpha.fandom.com/wiki/Defiant_class_decks
• Intrepid class decks: https://memory-alpha.fandom.com/wiki/Intrepid_class_decks
• trekdests Destinations used: https://exoplanets.nasa.gov/news/1378/top-10-star-trek-destinations-chosen-by-nasa-scientists/
• exodests from https://en.wikipedia.org/wiki/List_of_nearest_terrestrial_exoplanet_candidates
• sspythondecks created for a simple example

1. Copy the files wise.py, prt.py and shipchip.py (as code.py) to neotrinkey.
2. Copy a "dests" file (trekdests or exodests) to neotrinkey as "dests" (or create your own set of destinations)
3. Copy a "decks" file (trekdecks or sspythondecks) to neotrinkey as "decks" (Or create your own list of decks and dests.)

Change REPL=True to REPL=False if you want output to be "typed" via HID interface.

Change showdecks = False to showdecks = True if you want the decks to be listed on start.

Touch pad #1 to go "up" a deck and pad #2 to go down - holding both jumps to a random deck.

Files:

• shipchip.py - ship on a chip - copy to code.py

• prt.py - copy to neotrinkey

• wise.py - copy to neotrinkey

• exodests - rename to dests for use

• sspythondecks - rename to dests for use

• trekdecks - rename to decks for use

• trekdests - rename to dests for use

When run, you'll get a message "Welcome aboard" - and you begin on "deck 1" - usually the bridge. A random destination is chosen and after a random number of steps up and down in the turbolift you "arrive" and a new destination is chosen.

Looks like this:

Welcome aboard!

Ship destination is: Remus

You are on deck: 1 Bridge

You are on deck: 2 Science labs

You are on deck: 15 Deuterium fuel storage

You are on deck: 14 Engineering support, water storage

You are on deck: 13 Observation deck, dorsal interconnects

You are on deck: 14 Engineering support, water storage

You are on deck: 1 Bridge

Arrived at Remus

Ship new destination is: Nbiru

You are on deck: 2 Science labs

Make up your own ship with a list of decks in the "decks" file and destinations in the "dests" and you've got your own starship!

I replaced the electronics (which had died) in this product from Now and Zen.  Original Product 

Here is a link to the video where I talk about it.  Video

Due to severe RSS, I coded all of this with Talon Voice. There are lots of things I would do to clean up this code (remove globals, clean up use of enums), and given how hard it is to code with my voice, I'm going to leave it as is.

I have a confession to make: I don't love playing video games with a keyboard. While the keyboard/mouse combo is the preferred input method for most PC gamers, I find my left hand often gets cramped using WASD-based keyboard input, and wish for a more ergonomic input method sometimes.

I had an idea to make a simple adapter to map Wii Nunchuck input into keyboard events a game would recognize. I figured I could map the Nunchuck's analog stick to keyboard events for movement, and could map the two digital buttons on the Nunchuck to other keys while I was at it.

This setup would allow me to use the Nunchuck to partially or entirely replace input from my keyboard.

Overview

This no-solder adapter is built with either a QT Py RP2040 or a Trinkey QT2040 microcontroller, coupled with a Wii Nunchuck breakout board connected by a Stemma QT cable. The firmware, written in CircuitPython 9, translates Wii Nunchuck analog stick and button events to keyboard events. Thanks to CircuitPython, customization is easy, allowing you to make changes to the generated key events any time. So far, I have used this adapter for games like XCOM-2, FTL: Faster Than Light, and Half-Life 2!

I've included 2 build variants here, one for those with access to a 3D printer, and one for those without. The QT Py build uses a 3D printed case for mounting the QT Py and the Nunchuck breakout board. The Trinkey QT2040 build takes advantage of the identical screw hole placing on the Trinkey and the Nunchuck breakout adapter board, using a handy standoff mounting kit to make a nice tidy little USB-A adapter.

I'm often wanting to list what's on a device in terms of partition table. There's a handy utility included with the ESP-IDF, but it's python only and it only accepts files so you have to first call esptool to save your partition table data. I've had to do it so often that I've saved the two commands in another playground note, but not any longer!

The other thing is I swear that there used to be some online place to download your devices flash for backup using web serial, but try as I might  I cant find such a place, and my google-fu is usually on point - ignoring my switch to duckduckgo...I digress, introducing my latest possibly needless project, esptool-js "partition edition":

How to use it?

Well, the image above shows after I've clicked the Read Partition Table button. The default partition offset of 0x8000 should be fine for most boards, otherwise try 0x9000, although custom partition table offsets are supported. You won't even see those options until you've clicked Connect and selected your boards serial port.

Once your partition table has loaded it shows the expected information, the bit most people are usually interested in is the first app partition, or ota_0 in this case, and the user file system (user_fs), which is a FAT partition in this screenshot. 

The final column in the table has the download button for each partition, clicking it will start reading from the flash memory of the connected device, and once finished will ask the browser to download it. It will be named according to the chip name, partition type, starting offset, and size in bytes, but all the numbers are in hex not decimal.

Adding WIFI the Easy Way

If you start from scratch, the best thing is to buy a board with integrated WIFI. But this is not possible in all cases. Many older boards just don't have a suitable chip. This is especially true for boards that are based on the RP2040.

For example I recently bought the TinyFX from Pimoroni. That is a very small board about the size of a Qt-Py for controlling Lego lighting kits:

Another example is the Tufty2040, a large sized display with a RP2040 on board:

But I have also quite a few other boards lying around that would profit from connectivity e.g. the ItsyBitsy M4 Express. And of course I also own some of the shiny new Pico2 boards.

Airlift

The standard solution for adding WIFI is Airlift. Airlift is a WIFI-coprocessor running a special firmware on an Espressif ESP32-WROOM-32. Besides the "pure" chip on a breakout, there are also addons for specific form-factors like a FeatherWing or a BitsyWing.

But Airlift has two major problems. The first is wiring. Airlift is based on SPI and in addition uses a number of control GPIOs. So if you don't use one of the wings (that block all of your pins) you end up with wiring 7-9 jumper-cables. That is not only cumbersome, but the boards above don't even provide that many pins (the TinyFx e.g. just exposes what you see in the image).

The second problem is software. The Airlift uses a special CircuitPython library that does it's job, but in a slightly different way than the standard WIFI support of CircuitPython does. E.g. instead of connecting with wifi.radio.connect() you use esp.connect_AP() and instead of using wifi.radio.connected you check the connection state with esp.is_connected. There are many other differences in the API. So all the boilerplate code you have or download from the internet has to be adapted for the Airlift. As long as this is your main code.py file, this is no major problem. But once you start using libraries things get complicated. You have to install the source version of the libs and adapt them. Maintaining this is no fun.

ESP-AT

An alternative to Airlift is ESP-AT. This is a firmware maintained and provided by Espressif turning many of their chips into WIFI-coprocessors. ESP-AT is highly customizable but in its standard versions it uses plain UART for the communication with the main MCU. So you basically only need four wires: VCC, GND, RX and TX.

The drawback of ESP-AT is its textual interface: you send so called "AT-commands" to the co-processor and then you have to parse the response to extract the relevant data. Some of these commands are really complicated, e.g. to connect to an AP you would send

AT+CWJAP="myssid","mypasswd",,0,1,3,1,5,1

Wrapping all the complexity in a library really makes sense. For this reason, Adafruit had created the library CircuitPythonESPAT_Control, but it was abandoned in favor of Airlift and is no longer maintained. That library also suffers from the same drawback as the Airlift library, i.e. it uses a different API than standard CircuitPython.

CircuitPython-ESP32AT

For this reason I created a new library called CircuitPython-ESP32AT. This library talks to the ESP-AT on an ESP-coprocessor, but instead of inventing yet another API it uses the standard CircuitPython API for wifi, ssl, socketpool and so on.

At first, this might seem confusing. On boards with native WIFI these modules don't need to be installed, since the CircuitPython firmware already provides them. For other boards, the ESP32AT project now provides drop-in modules with the same names providing (almost) the same set of functionality.

One important function the external modules don't provide is the web-workflow which really needs native WIFI. Otherwise, you need to look hard to spot differences.

You will find installation and setup instructions as well as notes about various hardware alternatives in the repo of the library. Instead of reproducing this information here, I only show some examples I actually use.

Hardware

From hardware side, you need a board with a supported ESP-chip. Any ESP32, ESP32-S2 and ESP32-Cx will do. ESP32-S3 and the ESP32-Hx series are not supported. You can even use very old ESP8266 hardware as long as it has 1MB of flash. But this is not really recommended since the ESP8266 only supports operation in TCP/UDP/SSL client mode. In addition, you have to compile the firmware yourself (which in fact is easy and a matter of a quarter of an hour - see the repo for details).

Wiring is easy: you must connect RX/TX of your host MCU to the AT-UART ports TX/RX of the coprocessor. Besides RX/TX you should also connect GND. Powering the coprocessor directly from the host MCU might or might not work. For example, I had no problems powering the ESP32C3-SuperMini from the 3V3 pin of the Pico/Pico2, but I did not use any other peripherals:

The connection in this image uses a trick: it redefines the I2C-pins of the PiCowbell adapter from I2C to UART. Of course you loose I2C on these pins, so this is not a solution for all problems but it demonstrates how simple wiring can be compared to the Airlift.

I am using the same trick for the TinyFX board from above. The board does not have any dedicated UART-pins, but the pins of the Stemma/Qt can also be repurposed to UART instead of I2C. This allows a very simple connection using a Stemma/Qt-DuPont adapter cable for the connection of the TinyFX to again to an ESP32C3:

Even simpler is the usage together with the Maker Pi Pico Board. This board has a socket designed for the ESP-01S:

Liligo has created a chip with the same form-factor and basically the same pinout, which is called Lilygo T-01 C3. This board works also in the socket and gives full performance and provides all WIFI-functionality.

The Swedish company "iLabs" even has a Feather-sized RP2350 board with an integrated ESP32C6:

Ok, we will see a Pico2-W soon, but until then, this is the best solution for a WIFI-enabled RP2350.

Performance

For most use-cases like updating the time, querying an API (e.g. for weather information) or running an AP with a webserver the performance is just on par with native WIFI. There are some special cases though where native WIFI is better: e.g. I have a high-frequency data-sampling application that sends data using UDP to a reciever. Native WIFI can send with a rate of 0.001s per message, using ESP-AT this is much slower (I measured 0.015s per message).

Also, if you are dealing with large responses the default chunk size of 32 bytes that the adafruit_requests library uses will slow you down, since every chunk is an AT-transaction. Using response.iter_content() directly is a workaround to speed up processing (this also helps native WIFI a bit and Airlift too).

If you grew up with a Nintendo Entertainment System, you probably remember playing games like Duck Hunt that used the Nintendo Zapper "light gun". The Zapper used a clever technique that depended on the game being displayed on a Cathode Ray Tube, or CRT television. These days, CRTs are rare, and are often prized collectors items among retro gaming enthusiasts. Since these Zappers don't work on modern TVs, most people don't have much use for them anymore. So, why not convert it into a toy/prop that lights up and plays sounds?

Overview

This project uses a Prop-Maker Feather RP2040 to repurpose the the Zapper's iconic shell and clicky trigger mechanism into a prop/toy that uses a NeoPixel for a "muzzle flash", a speaker to play sound effects, and 3D printed parts to contain the electronics. The code is written in CircuitPython, and sounds can be changed or added by dragging and dropping files with no code changes required!

Program your device

Installing CircuitPython environment

1. Download .uf2 file here:
   • https://circuitpython.org/board/raspberry_pi_pico/
2. Plug in USB cable from PC to RP2040 board while holding the BOOTSEL button.
   • A new drive should get mounted on your system.
3. Drag/drop downloaded .uf2 file onto newly mounted drive (RPI-RP2).

Installing libraries and project code

From "CircuitPython Library Bundle" (download here):

1. Copy from bundle .zip file to the microcontroller [drive:]\lib\ folder:
   • adafruit_hid

From the PCMediaRemote release page (download here):

1. Download and unzip the "Source code (zip)" file from the "Assets" section.
2. Copy the "unzipped" custom project code to microcontroller [drive:]:
   • [PCMediaRemote folder]\lib_cktpy\* => [drive:]\lib\
   • [PCMediaRemote folder]\pkg_install\MediaRemote_RP2040\*.py => [drive:]\

NOTE: Feel free to check for newer versions of PCMediaRemote on the releases page. Code from the main branch might also be functional, but explicit releases are less likely to have issues.

Customizing your solution

You can directly modify the main.py file on the [drive:]\ folder. Every time you save the file, CircuitPython will restart with the updates applied.

Note that if the file gets corrupted for some reason, your changes will be lost. It is recommended to work from a folder on your PC, and manually upload (ex: drag/drop) the changes to the CircuitPython drive.

Overview

A media remote receiver for your PC/MAC/thing supporting keyboard media keys.

• Also works with many smart TVs and phones.
• Flexible CircuitPython-based solution can easily be adapted to other microcontrollers/IR remotes.
• Built-in IR signal decoder utility on serial monitor output.
• An easy, inexpensive, solderless build! (if desired)

I am a big fan of "being able to code whenever/wherever I am." That's why I bought a wireless keyboard for my iPhone, when I realized I could edit CircuitPython programs using my phone. It's one of my favorite things about the Micro:Bit - the App lets you write and upload code from your phone.

But I didn't think I could do that with makecode.adafruit.com programs for the Circuit Playground. I was wrong, in fact it's pretty easy. I just needed a lightning-to-USB adapter so I could download the code!

First - load your code in your browser (like the picture above).

Next - click the download icon in the lower left.

Then, click the file link above, to "open in a new tab."

I was looking to try out my new Adafruit Feather RP2350 and I remembered I had the Solder Party Keyboard Featherwing.

The Keyboard Featherwing is a handy device: it is about the same size as a BlackBerry phone with the same alphanumeric keyboard and a 2.6" 320x240 color display. Plug in a Feather board as the "brains" and you have a portable system.

Alas, one has to program the Feather, preferably with CircuitPython, to use the keyboard, display, and other features. Solder Party has example code snippets for those features. But what about something more holistic, more like a computer with input and output?

I found two solutions that were perfect: PyDOS and Beryllium OS. Both are built on top of CircuitPython.

PyDOS emulates MS-DOS commands used on PC compatible computers. And Beryllium OS, formerly ljinux, acts as a Linux-like computer. Neither are binary compatible (they cannot run native DOS or Linux binaries) but their commands and interactions emulate those operating systems.

This Playground Note will show you how I built my PyDOS handheld in short order.

There are two videos, one from Adafruit Show and Tell and another for Tom's Hardware The PiCast.

Preparing the Feather

Solder male pin headers onto the Feather RP2350. You could use long pin stacking headers to add a FeatherWing, but that would create quite a stack on the back.

See this guide page for soldering details:

Have you ever wanted to connect a simple button or sensor to Home Assistant using Circuit Python? This script demonstrates registering a device with Home Assistant so that it can be automatically connected to an Automation. The script triggers its event on power-on. The example uses the "trigger" type, which is better than "button" for a simple remote control. Other MQTT integrations could put a sensor reading on the dashboard, or turn your CircuitPython board into a WiFi light or fan.

Ingredients

• ESP32-C3 board running CircuitPython 9.1.4
• Home Assistant with the MQTT integration and broker, accessible to the local network

This script also demonstrates setting a BSSID, a 12-digit hexadecimal string, to connect to a specific access point.

I was not able to connect to my local mosquitto MQTT broker over ssl; something about how the the MQTT client and broker interact prevents CircuitPython from validating the certificate. The comments include an example of loading a custom root certificate for the connection.

How It Works

Home Assistant's MQTT integration listens on the homeassistant/device_automation/# topic for discovery messages. When it sees a properly formatted message, it adds or updates that device under Settings > Devices and Services > MQTT > devices. It also listens on topic, here circuitpy/{unique_id}/action, for commands from the device. For a two-way device, you can also set a topic for Home Assistant to send commands back to CircuitPython.

Now, we can add our device to an automation in Home Assistant without any additional configuration.

Going Further

Can we send our configuration messages with mqtt_client.publish(topic, msg, retain=True) so Home Assistant will remember us, even if it restarts before we do?

Can we configure our CircuitPython board as a Home Assistant temperature sensor?

Can we put the device in low power mode, wake on a pin change, and make a real battery-operated remote control?

Use nginx to proxy SSL instead of mosqitto's idiosyncratic support.

See also

Language tools for NeoTrinkey

Inspired by Star Trek's Nyota Uhura, these programs provide a way to use a NeoTrinkey to review alien (or foreign) language words or phrases. They are all contained in my github archive Project Nyota.

There are two programs, langtutor.py and langtest.py - copy the one you want to use to code.py. The helper files wise.py and prt.py are required.

The file "langs" is a list of the languages to review. Each line in "langs" should be the name of a file containing language information. In this archive the languages are: klingon, vulcan, mandoa, and Swahili (in honor of Uhura - "Nyota" means "star" in Swahili).

Language files should be in the form:

"Word-or-phrase", "target-language-translation"
"Word-or-phrase", "target-language-translation"
"Word-or-phrase", "target-language-translation"
....

When either program runs, you'll see:

number of languages: 4

klingon
vulcan
mandoa
swahili
Current lang: klingon

To toggle between languages, touch pad #1. When you reach the one you want to review (for the langtutor.py program) touch pad #2 and you'll see 5 random review pairs. For example from the Mando'a set:

You're right. : Gar serim.
twenty : ad'eta
seventy : tad'eta
eighty : shehn'eta
Good. : Jate.

With the langtest.py program, when you choose a language and touch pad#2, you'll get four tests where you're given a word or phrase, then a choice of two possible answers in the target language. Touch #1 or #2 to choose. A pixel will light green or red to indicate if you are right or wrong. (If wrong, the correct answer will be given). After four questions, you can touch #2 to get four more, or touch #1 to change languages.

For example:

Current lang: vulcan

advise
1:lahso
2:a'Tha

correct!

walk (action-word)
1:imroy
2:lahso

yes!

'logic', reality-truth, the way things are.
1:c'thia
2:lahso

wrong: c'thia

'immanence' direc experience of the creator
1:kah-hir
2:a'Tha

correct!

touch #2 for another quiz, or #1 to change language.

When running the programs, you can set the variable REPL to "True" or "False" to direct the output. If REPL=True, all output is sent to the REPL. If it is False, output is directed as if typed using the HID interface. There is a delay when that is the case, to give you time to switch to an open editor window to receive the output.

Note:

Copy all these files to the neotrinkey: langtutor.py, langtest.py, wise.py, prt.py, langs, klingon, vulcan, mandoa, swahili. Then copy langtutor.py or langtest.py to code.py to run.

Language sources:

• Swahili vocab from: https://www.fluentin3months.com/swahili-words/
• Mando'a vocab from https://mandoa.org/ Note: the Mando'a language from Star Wars was developed originally by the author Karen Traviss for the Mandalorian people
• Klingon vocab from: https://kli.org and https://hol.kag.org
• Vulcan vocab from: https://tinyurl.com/VulcanArchive - archive.org of Marketa Zvelbil's original Vulcan work (note: In case archive.org is not available, I've copied the Dictionary and Lexicon to vulcdict.txt and vulcanlex.txt)
• To create your own language, you can use a tool like this: https://rollforfantasy.com/tools/language-generator.php

The objective of this project is to replace the existing WeatherMatrix project's MatrixPortal M4 display with a newer version that uses weather data provided by Adafruit IO Plus (AIO+) instead of the openweathermap.org web API. The requirements include:

• Implement with CircuitPython for ease of development and prototyping.
• Duplicate the existing 64x32 LED matrix display layout including label colors and icons.
• Develop an architecture to support multiple autonomous displays and local data feed devices (new).
• Utilize a weather data source that accurately aggregates station information that closely matches local conditions.
• Weather data updated approximately 3 times per hour and is reliably available.
• Service subscription is free or reasonably priced.
• Include data elements for wind gusts and local workshop temperature (new).
• Display a progress bar to indicate data time since last update (new).
• If possible, use the existing MatrixPortal M4 hardware; upgrade to MatrixPortal S3 only if necessary.

Special Acknowledgements

Thank you to John Park for the initial weather display design concept (see Weather Display Matrix) that inspired this project. Also, the work of Trevor Beaton was instrumental in creating the updated display design with a clearer and simpler coding approach (see itsaSNAP Daily Weather Forecast Board).

Choose a Weather Observation Source

Three options for sourcing weather data were considered. Here are some pros and cons of each.

openweathermap.org:

• utilizes the existing or similar web API; minimal code changes will be needed
• weather station aggregation often doesn't always match local conditions
• data retrieval throttling is reasonable with a consistent service level
• free service was phased out; will eventually require paying for the service

weather.gov:

• a moderately well-documented web API; moderate code changes will be needed
• weather station data is not aggregated and closely matches local conditions
• single weather station data is not reliably available, sometime for hours at a stretch
• data retrieval throttling is currently reasonable, but without a guaranteed service level
• a free service

AIO+ Weather (Apple WeatherKit):

• moderately well-documented CircuitPython library approach; major code changes will be needed
• weather station data is aggregated and matches local and iPhone conditions
• data retrieval throttling is reasonable with a consistent service level
• weather data and workshop conditions can be combined and viewed on a web-based IO dashboard
• requires a paid subscription to AIO+ for access to its Weather Service

The choice to use AIO+ Weather was an easy one since my existing weather tracking and corrosion monitoring projects require a subscription to AIO+. We'll need a new system design and a major rewrite of the existing MatrixWeather project code to make this happen, providing ample opportunities to improve performance and reliability. The next step was to redesign the overarching weather system architecture.

See weather.gov: A Truly Free Weather API and AIO+ Weather: A Premium Alternative for Local Observations for a detailed discussion of each alternative.