12.14.25

Pixl.js – Nomiibo

My two Allmiibos

Sooo I’ve been kinda obsessed with these Pixl.js Allmiibo NFC tag emulator devices. They are tiny, but are quite powerful, containing an NRF52832 SoC with BLE, NFC tag emulation, a display (there are LCD and OLED variants!), controls, a battery, and often a USB port that supports charging an internal LiPo battery! And most importantly, they are completely open-source, both hardware and software! (for me, this means I could get the cheap mass-produced made in china variants for relatively cheap while still fully compatible with the original open-source firmware)

While I literally could not care less about Amiibos—I do not own or plan to own any Nintendo consoles—I have ended up buying two of these Allmiibo devices! Purely just because they are such unique devices that are really useful for emulating NFC tags.

Card Emulator app on the LCD allmiibo

It has been a convenient little thing for storing a bunch of NFC access cards. Other than that, it’s also just a fun little thing to have. Also, depending on the firmware you have, you can play some mini-games on it. And recently, I also discovered pixlAnalyzer by ATC1441, a 2.4GHz spectrum analyzer that is surprisingly fun to walk around with.

Like I said, I own two of these things. I actually just recently bought an LCD variant because I wanted one I could mess around with, like modifying the firmware on. Previously, I just had the OLED variant, which has a really nice, solid body and a crisp OLED display. But it looked like it was going to be impossible to access the board inside non-destructively, which I would need to do if I wanted to reprogram it with a programmer. (There is an OTA DFU, but if I mess something up, I would be kinda screwed, also it’s extremely slow)

Or so I thought… After checking out the schematics for the OLED variant, it turns out they exposed the SWD pins directly on the USB-C port, which explains why every time I try to charge my OLED Allmiibo, it always causes Windows to complain… But this means the OLED variant is actually much more hacker-friendly than the LCD variant, which doesn’t expose the SWD pins via USB-C like this.

That’s not USB!

So, which one should you get? Well, I think it’s actually kinda interesting. If you just want an NFC/Amiibo emulator, you should get the LCD variant; they are usually a little bit cheaper, and I feel like the LCD display fits the vibe better than the very sharp, crisp, and high contrast of the OLED screen, they are also a bit bigger but I think that is actually better since the smaller size of the OLED variant makes it less comfortable to handle.

OLED allmiibo
LCD allmibo

But as I mentioned before, if you wanna mess around with the firmware, the OLED variant makes it super easy to hook up a programmer just via the USB-C port. Which is definitely something you might also find really fun to do, since this is basically just an NRF52832 devkit with all the important input and outputs, enclosed in a really nice casing, too. (That is, of course, if you don’t need to hook up extra peripherals to it. In which case, you might be interested in the Original Espruino Pixl.js, which these Allmibo Pixl.js are based on)

My own fork: Nomiibo

Okay, so I just made that name up while writing this. But I think that describes it well.

As I said previously, despite the branding and the main use case of these Allmiibo devices, I actually do not need those features at all. I just use the Card Emulator app, and that’s it. The Amiibo features are just wasting space on the already limited 512KB flash space of the NRF52832. So that’s why I was interested in making my own fork. (This is also when that whole thing with buying a second Allmiibo and realizing the OLED variant had the SWD pins in the USB-C happened)

My main goal was to modify the original firmware (by Solosky) in order to disable the Amiibo features and to re-enable the “Game” feature, which was disabled in version 2.13.0 of the original firmware because of size limitations. The plan was to also implement little apps/games that might be cool to have. This was also around the time when pixlAnalyzer (by ATC1441) came out, so the secondary mission was to somehow integrate that into the main firmware.

And that is exactly what I’ve done. You can access my fork of the pixl.js firmware on my GitHub: misaalanshori/pixl.js. I didn’t actually change much in the code; the most important change was just adding a flag to disable all the Amiibo-related apps. The bigger change technically was porting pixlAnalyzer into the Game app of the firmware. And since I’m planning to add more, I want to document the features of my fork here:

Disable Amiibo Features and Re-enable Games

New cut-down firmware running on both variants

Okay, this one is very simple since the solosky/pixl.js project is already very modular, so all I had to do was add a flag to enable/disable all Amiibo-related apps (for some reason, this didn’t already exist), and then disable the flag. Then I also re-enabled a flag for the Game mini app.

When built with the Amiibo features (current default in the original repo), the application size was 363460 bytes, and when built without the Amiibo features, the entire firmware was 234500 bytes. Re-enabling Games increased that to 258692 bytes. So all the Amiibo stuff takes up quite a lot of space!

This was also the first time I used VSCode Dev Containers. It is actually pretty cool and solves the one issue I have with developing with C/C++: The Tooling. I feel like often it could get really confusing very quickly, and having everything contained in a container you can easily take down and rebuild is awesome!

pixlAnalyzer, a 2.4GHz Spectrum Analyzer (Originally by ATC1441)

PixlAnalyzer is an awesome 2.4GHz spectrum analyzer made by ATC1441 for the Pixl.js hardware. I loved it so much, but the fact that it’s completely separate from the main firmware means I would have to keep reflashing the firmware if I want to switch functionalities. So I wanted to integrate or port it over to the main firmware, and after looking at the source code, the Game feature seems perfect for integrating external projects like this.

With a lot of help from Copilot to figure out how everything worked—No, I’m not proud of this, but C dev is currently still very much outside of my skillset—I got the pixlAnalyzer to run as part of the main Pixl.js firmware! It works surprisingly well. I originally ran into some issues, but now it seems to be running fine on both the OLED and LCD variants. It seems to be running a bit slower, though. Running standalone, it would run at 67Hz, but integrated like this, it only runs at 47Hz. Still plenty smooth, but I think the one thing that stood out to me with the original pixlAnalyzer was how smooth it was running at 67Hz. So maybe I’ll try figuring out why it’s slower and if possible, make it run faster.


There are still a lot of things I wanna do with this. The Espruino Pixl.js page has a collection of projects that could run on this. But they are, of course, written for JavaScript (Espruino is an embedded JS platform). So I think an interesting next step is to port those projects into this fork. I’ll try refraining from using AI coders like Copilot and also minimize using AI Chatbots when implementing these. I can already feel my brain rotting from just using them for a few weeks…

06.13.25

Letting a Computer Assist My Home

My Main Home Assistant Dashboard

Smart homes are all the rage nowadays. But I’ve really only stayed with the basics, some smart light bulbs, a smart clock with environmental sensors, and an internet connected air purifier. One issue though, is the fact that these things has their own separate apps. And that is where Home Assistant comes into play.

Despite it being released 11 years ago and watching a bunch of Youtube videos talking about home automation using Home Assistant. I’ve just never gotten around to setting it up and actually trying it out. But that changed just a few weeks ago when I decided to look into ESPHome, a really cool tool/framework that allows you to build custom firmware for building your own IoT device on espressif MCUs. But first, I of course needed to install Home Assistant.

Setting Things Up

Home Assistant is not just an application you can run, you have two options: Home Assistant Container and Home Assistant OS. Home Assistant Container would be simpler to deploy, but it lacks support for one important feature: Add-ons, which are based on containers itself. So of course, I went for Home Assistant OS.

My Home “Server” setup is just my PC that I leave running 24/7, it has all kinds of services running mostly in Docker. So to run Home Assistant I just setup a VirtualBox VM with the provided Home Assistant OS VDI Image. This turned out to be a huge mistake, using Hyper-V might’ve been the better option, I’ll talk about this later.

Setting up Home Assistant itself was very simple, I created a VM with it and set its networking to bridge with my physical network. After starting it, the VM just boots straight into Home Assistant OS and shows up on port 8123 for you to setup a new account. After I logged into my Home Assistant instance, I immediately went looking for the ESPHome addon.

Getting started with ESPHome is surprisingly extremely easy. I just had a random ESP32-S2 board laying around that I soldered some pins to connect my Neopixel strip onto. Now here is where I ran into my first issue. Normally you should be able to flash your ESP using WebSerial in the browser directly. But because I’m still connected by insecure HTTP, it seems that WebSerial isn’t available and caused weird issues. So I had to download the firmware image and flash it myself, luckily there are web versions of the ESPTool online, so I just used esptool-js to flash the image. As soon as I reset the board, it connects to my network and showed up as online in the ESPHome dashboard.

ESPHome is a low code platform, you can do most basic things without writing a single line of code. Even more complex features can be written with minimal code. In order to get started with my Neopixels, I just created a light component and configured it to my Neopixel pin.

Example ESPHome configuration

And just like that, we can wirelessly flash the code to the ESP board and after adding the new ESPHome device to Home Assistant I have a smart controllable Neopixel strip.

Now understand why people loves Home Assistant so much.

The simplicity of everything was amazing, it was so quick to get this smart light setup. But now things start to become a bit of a mess. Using Home Assistant on a VM was starting to backfire and using a very old esp8266 on a DIY board was making this a huge mess.

After this I noticed more and more instability. Like Home Assistant not booting up properly after a host restart (Thanks Windows Update!) and also Home Assistant randomly failing to connect to my physical network. That combined with my unstable DIY boards makes my lights randomly turn off or disconnect.

In the end I decided move the Home Assistant instance to a random mini PC that I just have running doing nothing. This was easier said than done, because Home Assistant does not have a bootable installer, they only provide images of a preinstalled Home Assistant instance. So what I had to do was boot up a Live Ubuntu installer, this was a huge pain because this mini PC is so old that it struggles to run the desktop (I probably should have used something lighter). But anyways I downloaded the Home Assistant OS x86 disk image and wrote it to the main disk of the mini PC and it booted up Home Assistant.

In order to move the instance, I had to create a backup in my Home Assistant VM and then upload it to the new instance which will restore the backup. This was surprisingly easy and *it just worked*.