I just moved into a new neighborhood. On my morning walk I discovered the best "neighborhood score" of my whole life: a brand-new electric fireplace, still in the box, with a "free" sign on it, sitting at my neighbor's curb. I snagged it immediately. I've been eyeing these since I saw one at the State Fair a while back. They produce a really cool flame-like effect, and also include a heater module. 

Apparently my neighbors were getting rid of it because it "beeps from time to time". Well, being the DIY hacker that I am, I decided to crack it open and see if I could disable the beep, and also upgrade the LED strips inside while I was in there. 

Teardown / How it Works

This fireplace has two 12v analog RGB strips -- one at the bottom and one at the top -- plus a custom PCB with super-bright LEDs that control the flames. It comes with an IR remote control and a capacitive touch panel, both of which trigger a VERY LOUD annoying beep whenever a button is pressed. The LED light strips are both programmed to cycle through 14 different color modes, but the lights just change from one solid color to the next with no brightness controls or animations available. 

I was really interested to learn how the flame effect was created. Turns out it's a very clever spin on the popular "Pepper's Ghost" illusion. This is the same illusion used at the Haunted Mansion in Disneyland to make ghosts seem to appear in mirrors all around. 

We all love the subtle, intermittent glow produced by fireflies in the summertime. Each firefly produces its own unique visual pattern in response to the signals given off by its neighbors. Running through the yard trying to catch them is a quintessential Summer activity for young (and not-so-young) children. Kids will often collect them and put them in a jar to bring in the house to enjoy the light show that the fireflies produce before releasing them to go on their merry, little ways.

This project attempts to replicate the beauty and ambience created by a Mason jar of fireflies. But unlike the "real thing", this virtual jar of fireflies can be enjoyed year-round without having to capture and maintain the little buggers.

Note: This is a cross-post of the project I posted on hackaday.io at: ( https://hackaday.io/project/193890-virtual-jar-of-fireflies ). The majority of the components in the project are from Adafruit, so I thought I'd include it here as well.

The Jar

When I originally designed this project in 2020, I chose to house the virtual fireflies in a plastic Mason jar with a plastic lid. Although it looks more attractive in a glass Mason jar (see pics and vids), I was making it for my son and wanted it to be able to survive being dropped without causing a safety hazard. I built all of the circuitry on a protoboard small enough to fit in the lid of the jar along with the rechargeable LiIon battery. A capacitive touch sensor placed under the center of the lid detects a hand "press" to control turning the jar on and off. A built-in LiIon charger allows the battery to be recharged by connecting a USB charger via a micro-B connector when the lid is off of the jar. Once the jar is powered on, it is configured to operate for 1 hour before automatically powering off (if not manually powered off sooner). This is long enough to allow it to be used as a calming nightlight while children (or adults) are drifting off to sleep.

The Weather Chimes project fills that need. It connects to the Adafruit NTP service for network time and to OpenWeatherMap.org for wind speed data. The wind speed data is retrieved every twenty minutes and is used to adjust wind chime playback in a pseudo random pattern. The chime voice synthesizer is provided by the CircuitPython_Chimes class and for this project, is sent to an Adafruit MAX98357A I2S amplifier driving an Adafruit 40mm 4-ohm 3-watt speaker. Although an Unexpected Maker Feather S2 was used for this project, the code should work on just about any ESP32 device that's capable of running CircuitPython.

The Weather Chimes project consists of two primary code files, weather_chimes_code.py and weather_chimes_wifi.py. The weather_chimes_code.py code is imported via the default code.py file contained in the Feather S2's root directory. This code contains the primary non-wifi device definitions and the master while... loop that plays the chimes. It also imports the WeatherChimesWiFi class from weather_chimes_wifi.py.

The WeatherChimesWiFi class takes care of all the networking details for connecting and retrieving data from the internet. It also provide helpers for updating and retrieving time and weather as well as properties for including the local time and wind speed. The WiFi class uses the settings.toml file for connecting to a home WiFi router as well as parameters needed for Adafruit NTP and the OpenWeatherMap.org API.

A fictional settings.toml file:

A CircuitPython project for indoor "windless" garden chimes that play along with the outdoor wind speed.

Weather_Chimes GitHub repository

A sign for all times

The neopixels are controlled by the WLED app, to use this you need a WIFI connection. This is a sturdy construction, I have it lashed on my front balcony and it all works fine, it’s winter ready.

Parts and skills needed:

• 1 hula hoop, mine came from the dollar store and is 30 inches in diameter.
• 1 esp32 huzzah / 3405
• 2 1 meter neopixel strip (30 led) / 4801
• 1 5 volt power supply at least 2 amps / 4298
• nylon ties and electricians tape

The tools and skills needed are a glue gun and soldering iron.

The first thing I did was to strengthen the hoop by gluing the insert that was linking the ends with contact cement. Then I attached the vertical strip and huzzah to the hoop as so:

Mad With Power, or just keeping it on the down-low... There's a few good reasons to want to create or use a custom bundle of libraries for circuitpython!

Perhaps you write educational guides and lesson plans and want to have all your custom requirements in once easy to use place. Maybe you've got enough private, rudely-named, or trademark-infringing libraries / drivers / helpers for CircuitPython that you won't add to the community bundle, but still want the convenience of circup (the package manager for CircuitPython).

I love having a package manager for circuitpython (currently supports USB mass storage based devices, but theres a pull-request for web-workflow suppport).
circup install --auto --py and I get all my dependencies in readable form, modifiable even if I so wish!

So a recent pull request caught my attention, for circup-depenencies that weren't in the pypi repository (python package hosting used by `pip`) yet or at all. That's the exact state of my libraries!

I also was aware of seeing a bundle-add option for circup, used to add custom library bundles, so this weekend was time to bring it all together.

Minor Yak Shaving - Get Library Ready

I've cleaned up the library enough to have a releasable thing, but never sorted the docs. The project is a fork of a Sensirion python library, for which I actually have permission to use their name, but to avoid any issues I wanted to have a way without friction, like a custom library bundle. Anyway the docs use Sphinx, and the read-the-docs theme, but are an old form of config etc, so I cleaned up that to the point of publishing to github pages.

Then I could setup a pyproject.toml file with a [circup] section, and inside a field called circup_dependencies with an array of strings. Similar to this:

After looking at the current community bundle (which has a build script, and publishes json+zips with each release) I noticed the dependencies were only setup for a requirements.txt and not the new pyproject.toml circup_dependencies section. The build script did however include the requirements.txt and pyproject.toml for each included library in the built release assets (a zip for each mpy/circuitpython version plus a python file version).

As a result of this I've included fake requirements in my requirements.txt (they will actually pass and install with python on a pc as the names match the official libraries. Then the two circuitpython dependencies are included in pyproject.toml as described above.

The last thing was that there were two libraries for release, the Sensirion SEN5x device driver, and a base Sensirion I2C python driver. Both of these need to be submoduled into my bundle repo, in a similar fashion to the official community bundle repo.

Create the bundle

Simplest for me was to fork the community bundle, then clone it locally and git submodule deinit --all -f and delete all the submodules, then add the two of my own, and tweak the readme. I also stopped the CI script from attempting to publish to AWS S3. It's worth noting it will error if the submodules commit reference doesn't match latest tag.

The usual git submodule add, for each library to be included, and if you update things in the driver repos then craft a new release for them and then come back to the bundle repo and enter the library submodule folder and git pull then commit and push those changes, then create a new release of the bundle. Probably equally wise to use the update script or tweak the CI script to update and release (could be scheduled).

Use the Bundle

circup bundle-add <github_owner>/<github_repository_name>

e.g. for https://github.com/good-enough-technology/CircuitPython_GoodEnough_Bundle

circup bundle-add good-enough-technology/circuitpython_goodenough_bundle

then install newly available package:

circup install sensirion_i2c_sen5x

(I prefer to add the --py option to get readable python instead of .mpy module files)

 

Maybe It's Just Me

As I work on different projects I find myself implementing similar things across projects. This has led to a lot of copy/paste work. Which in turn leads to having to update multiple projects when I find an issue or improvement.

So I decided to start a helpers project. It is essentially a set of wrapper classes that I can use across projects.

What's In The Big Pink Box?

I've just started to build this project and have started with the ones that were in use with my current projects. I plan to add more as I move to other projects.

• time_lord.py
  • Provides a time singleton that supports RTC if desired
  • Currently does not support using SPI and Network to get the time (maybe in a later release)
• local_logger.py
  • Provides a logging singleton that supports adding/removing different handlers and accessing files on your SD card
  • rotating log files is currently incomplete
• local_mqtt.py
  • Provides an MQTT singleton that uses SSL by default
  • Supports publishing independently or via the MQTTHandler in adafruit_logging 

Any Gotchas?

I have done my best to keep all the helpers independent. I didn't want to force anyone to use local_logger just to use the time_lord wrapper.

The responsibility use the helpers together falls to the program.

How Does it Work?

I clone this project into the project in which I want to use the wrappers. From there I just copy the wrappers I'm using to my microcontroller.

Example code - implementing time_lord.py without using a real-time clock:

...
import socketpool
import wifi
import time_lord

...
pool = socketpool.SocketPool(wifi.radio)

my_time = time_lord.configure_time(pool)

...

Example code - implementing local_logger with time_lord and a real-time clock:

...
import rtc
import socketpool
import wifi
import time_lord
import local_logger

...

pool = socketpool.SocketPool(wifi.radio)
rtc = RTC()  # using a QTPY ESP32 Pico

my_time = time_lord.configure_time(pool, rtc)
my_log = local_logger.getLocalLogger(use_time=True)

...

Example code - implementing local_mqtt with local_logger without time_lord:

...
import local_mqtt
import local_logger

...

my_log = local_logger.getLocalLogger()
my_mqtt = local_mqtt.getMQTT(use_logger=True)

Where To Get the Project

You can find the project on Github

Please feel free to contribute!

Circuit Diagram

The diagram below provides a general visual reference for wiring of the components once you get to the Assembly page. This diagram was created using the software package Fritzing. Note that we will be using all available GPIO pads on the QT Py, so there will be a good bit of soldering involved.

Overview

Modern electronics are capable of incredible things. Even the simplest gadgets now have clocks, gyroscopes, radios, GPS, touch screens, literally anything you can imagine, built right in. Sometimes though, the devices that are capable of doing several things don't do all of them particularly well. Touch screens are often bolted onto things that really don't benefit from them, or even worse, detract from the experience. Anyone who has accidentally grazed the touch panel on an Apple TV remote while grasping for it in the dark knows exactly what I'm talking about. Sometimes I just want to have a remote with a few simple buttons I can press to make things happen, and that's it!

Most of the lights in my apartment are WiFi-connected, and offer MQTT capability. I took advantage of this and set up a local MQTT broker (https://mosquitto.org/) on a Raspberry Pi 4 wired to an old Apple Airport router/hub I had lying around (my internet provider makes me use their router for my internet). Now, it's easier than ever to control my lights...from a browser. Or some phone interface. Or an app. Wait a second...each of those still requires multiple steps just to get me to the point where I can actually control anything. And I probably still have to use a touch screen. Leading me back to my original point, and thus the motivation for the imaginatively named:

WiFi Matrix Keypad Remote

I've been a DIY remote control enthusiast for almost as long as I've been hacking around with microcontrollers (at least a few years now). One thing that I've found really hard to source as a hobbyist is good, pre-made button panels intended to be mounted into a small space, such as a remote control. So far, one of my favorite sources for a dense panel of decent quality, inexpensive buttons are these old-school 3x4 matrix keypads:

Part one : Where's the mic? 

"Breaker breaker , any takers? This is the the one and only Delchi hunting for bear on I-95 South , keeping that double nickel and keeping the sunny side up & the greasy side down! We gone!" ¹

I was looking for some new gaming frontiers when I came across truck simulators! All the skill & thrill of a big rig from your PC. As with all simulators there are button boxes and realistic cockpits to buy, but one thing I didn't see was a CB radio mic! They expect us to use desktop mics, headsets or some other hoo-haw instead of the ol jabberjaw microphone! A little deeper digging showed that you can buy adapters, but they ranged from $180 to $300! ( Granted the $300 one is an awesome button box and has a lot of realistic controls along with the mCB mic.) 

Well the first thing I did was say "Belgium" to that, and pulled Rolling Thunder across the room to my workbench and got to work. This was going to be a project that would work with Truck simulators, sub simulators and more! Grab that soldering iron, the wire clippers and that drill over there! It's time to start making! 

 

Notes : 

1. CB radio jargon was around long before IRC , and was its own language designed to obfuscate communication and have a grand ol time. "Handles" were common, and yes CB radio handles are where the hacking community got the term handles for hacker aliases! 

Translation? Why not ? 

• "Breaker breaker , any takers?"
  • In cb radio ( less formal than ham radio ) it was common to ask permission before talking on an open channel. Calling for a "break" was like requesting permission to chime in , and was normally answered with "Go ahead breaker"
• "This is the the one and only Delchi"
  • Handles were a point of pride and very often unique, but when they did collide they politely adjusted to be like "The New Orleans Joker " vs "The Chicago Joker" and so on.
• "hunting for bear on I-95 South"
  • Truckers took great lengths to avoid being caught by the police in speed traps. "Smokey Bear" referred to the Smokey The Bear hat most often worn by police patrolling the interstates. If you were hunting for bear that meant you were on the lookout for police, and sometimes were asking for a "Smokey report" if anyone had seen any police.  You usually followed this with the interstate you were on and the direction you were traveling and sometimes the mile marker you had passed most recently.
• "keeping that double nickel"
  • This referred to the speed limit of 55 miles per hour that was enforced back then. Sadly there is no clever phrase for the 65 mph speed limit.
• "keeping the sunny side up & the greasy side down!"
  • Multiple meanings here, but for the most part this meant keeping your truck upright ( sunny side was the cabin, greasy side was the road ). It was like wishing someone safe travels and no accidents. 
• "We gone!"
  • When a conversation ended people would signal this with a number of phrases like "we gone" , or "On the side". Sometimes it also included the "10-code" messages such as "10-10 Till I see you again"

Related Links : 

• Truck Simulator
  • https://americantrucksimulator.com/
• Button Box
  • https://www.simpanel.com/ats
• 10- Code & other jargon
  • https://www.rightchannelradios.com/blogs/newsletters/cb-radio-slang-and-10-codes

 

Part Two : Requirements

So then at the workbench with graph paper and pencil in hand ( or Lucidchart if you will ) let's determine what we need to make this CB mic project roll down the road : 

• Utilizing a CB Microphone
  • Be able to attach the microphone to the computer
  • Be able to use the button on the microphone to activate the  PTT ( Push to talk ) feature on the computer / in game
  • Make it look realistic! 
  • Make it as clean as possible ( minimum number of wires / software / configuration )

 

I recently released another retrocomputer miniature that incorporates a handful of Adafruit boards so I thought that I'd share the details here.

The original Connection Machines were built in the late 80s and early 90s to provide a few thousand hyper-connected processors which at the time was rather unique. If you're interested, here's a wikipedia page about them.

My Patreon supporters vote for which miniatures I make and I was pretty happy when the Connection Machine was chosen. I was also happy to find that Adafruit sells pretty much exactly what I needed to make the blinking light panels:

• QT Py ESP32-S3 x1
• Red LED matrix x4
• Matrix driver board x4
• Stemma QT cable x4

Assembly requires me to solder the four matrix driver boards to the four LED matrix boards and then plugging in the Stemma QT cables between the QT Py and a chain of the driver boards.

Then I assemble these printed parts. The little C shaped parts on the lower left of this photo are what hold the two-board sandwich of the LED maxtrix board and the driver board.

Then I install CircuitPython on the QT Py and then load it with my code from Codeberg. There you'll find the default blinkenlights script but also a script that uses the network to fetch the time and then turn the Connection Machine into a clock. It took a bit of work to figure it all out so hopefully the code will be a handy starting point for similar projects.

Once everything is assembled I box it up and put it on my gumroad store.

I post pretty much every day about what I'm working on over on Mastodon at @[email protected] and for maker-y types of conversations I like that place much more than the other social media sites. Maybe I'll see you there!

• Logs onto network if present, showing QRcode for the Wifi Access point for easy joining and remote configuration, also displays SSID. 
  
  Next to that is the Web Workflow QRcode, built from the IP address of the device and web workflow port if specified.

 

• If the user hasn't configured SSID or fails to get an IP in 5seconds, then the help page QRcode is displayed along with a touch sensitive Circuitpython logo.

 

• There is code to adapt the returned touch events to be rotated (the BAR 320x820 display is vertically orientated so coordinates of touch events need adjusting).
  
  The touch code cycles through the tilegrid and group objects looking for a callback on a tilegrid to trigger if the x + y (plus tile_width and tile_height) match the touch point.
  
  It works for the bitmap, but not the qrcode tilegrids, nor labels.

Feature List:

The Problem:

A frequent problem I have when creating a new Raspberry Pi-based project is determining the IP address of the device.  I am often working with Pi projects in a "headless" (no monitor) configuration using SSH to log in from a PC on the same LAN network.  But to log in this way, I need the Pi's IP address, which sets up a chicken-and-egg problem that goes like this:

I want to connect (SSH) to a headless Raspberry Pi, but before I can do so, I first need to attach a monitor and keyboard to it to login locally and get its IP address (with 'ifconfig'). 

This is the very thing I would like to avoid since the system will ultimately be "headless".  In truth, while it is only a minor inconvenience, it is one I'd like to do without.  The more new RPi systems that you set up, the more tedious it is to pull out a monitor and keyboard to find the IP address of each one before you can begin remotely connecting to it over the LAN using SSH.

My Solution:

I would like to be able to find the IP address of a headless RPi without having to connect a monitor and keyboard to it.  Ideally, I would be able to connect my new RPi to my network, and know the IP address that is it assigned.  Then, I could simply connect directly to it using SSH from my PC on the same network.

As is the case for many others, my minor annoyance at "the problem" turned into a full-blown project to solve it.  I created a program I called Hello Pi that can be run on a Linux or Windows computer to identify the IP address of a Pi (or other device) connected to the same network segment.