Chameth.com - posts like debugging-beyond-the-debugger, filament-weight-display, modern-css-is-fun but not sense-api, why-you-should-be-using-https

Monthly Meanderings: March 2026

2026-04-01T00:00:00Z

Since last month’s update I’ve been unpleasantly reminded that I’m middle aged, through the medium of a dodgy knee. There’s nothing quite like not being able to stand up without groaning to underscore that you’re not young any more. The ongoing game of “will this seemingly mundane activity make my knee go funny again?” is a delight to play, too. I’m great at it.

Website updates

Two new blog posts this month: the longest way to represent a date is a short thought experiment on absurd date formats, and modern CSS is fun goes through some neat new CSS features I’ve used recently for this site.

I did some design tweaks this month: headers now have a blue background behind them¹, and a lot of components have been redesigned to have a consistent style. You can see that component in action in the new “now playing” widget I’ve added:

VersaEmerge — Redesign Me Fixed at Zero Scrobbled 1h 59m ago

Instead of each component defining its own styles (which were mostly copied and pasted), there’s now a single class that handles the drop shadow, border, background colour, and the optional title. It also applies a consistent format to elements that are clickable: they use the blue accent colour for their borders, and have a glow effect shown on hover.

The now playing widget is part of a larger bit of work I did on importing some music stats. I’m pulling in the data from my Navidrome instance. A new music page shows my most listened albums and artists. Navidrome doesn’t store a complete play history, just the last play and the count, so I can’t do “what I listened to last month” stats until next month.

Other projects

Other than a minor bug-fix update to contempt, my Dockerfile templating/updating tool, I’ve not done much on my other open source projects. I’ve got a bit more work to do finish migrating all my repositories from GitHub to my private Forgejo instance. I’ve also been thinking about mirroring my public repositories to Codeberg so there’s a non-GitHub way to access them.

Entertainment

I apparently only watched a single film in March:

The Substance

2026-03-18

I really didn’t get on with this. It’s too long for what it is, and over-the-top in a way that just didn’t work for me.

Demi Moore and Margaret Qualley were great, but nothing else really was. The cinematography and sound design were too affected, the plot was pretty shallow and obvious, most of the body horror fell into the uncanny CGI valley for me.

It’s not completely without merit: there were around 40 minutes in the middle where I was really into it, but that’s not really enough given it’s closing in on a 2.5 hour runtime.

There’s something to be said for the message it’s presenting about women in Hollywood, too, but it was very heavy handed. Dennis Quaid’s character is even called Harvey; it’s not so much a subtle nod as a sledgehammer to the face.

Instead of films, I’ve been watching a bunch of TV. After devouring The Pitt last month, I struggled to find something to fill the hole it left. I settled on catching up on Chicago Fire and Chicago P.D.. They’re both mostly about getting things done without personal drama becoming the primary focus. They’re not quite as grounded as The Pitt, but at least they’ve not completely gone off the deep end like 9-1-1 where the first responders end up in space somehow?

I’ve also watched the first two episodes of SNL UK. I didn’t have very high expectations, and it gave me a pleasant surprise. Both episodes so far have some hilarious sketches, and are obviously written by British comics with the typical darker, more sardonic humour that separates us from the USA.

Last but not least, board games! I spent a weekend at a tabletop/LAN event with friends, so got to physically play some games for a change. I also kept up with some turn-based games on Board Game Arena, as usual.

6 plays
4 plays
4 plays
4 plays
3 plays
3 plays
3 plays
2 plays
2 plays
2 plays
2 plays
2 plays
1 play

Around the web

Warranty Void if Regenerated

Some really cool speculative fiction about a future where all software is written by LLMs, and the social effects that may have. Unfortunately the story itself is written with an LLM, and that becomes painfully obvious about a third of the way in. By that point I was already hooked, though.

My 2-step process for AI-free blogging

Speaking of LLM-generated text, this short piece by Manuel Moreale made me laugh. I’m by no means anti-LLM, but I really hate people publishing the output like it’s their own work. It breaks the social assumption that the writer put more effort in than the reader, and makes me wonder how much is hallucinated.

25 Years of Eggs

An interesting applied use of coding agents. I’m a sucker for personal statistics. I have no explicit desire to keep my receipts, or generate graphs of my egg consumption, but seeing the graphs makes me question that. The journey to get there is a great read, too.

I made a one-page notebook

The clever paper folding is interesting, but I really like some of the small touches on the page. There’s a nice little “in reply to” callout providing context at the top of the page, you can click to rotate the image further down, and there’s a details element containing a textual version of it. It has that great ‘small web’ vibe of someone who really cares about what they’re doing.

Workers who love ‘synergizing paradigms’ might be bad at their jobs

I haven’t read the full paper, but the summary given by the article is equal parts interesting and amusing. They developed a “Corporate Bullshit Receptivity Scale”, what more is there to say?

It’s meant to resemble painter’s tape, but I’m not sure quite how well it works. ↩︎

Modern CSS is fun

2026-03-17T00:00:00Z

I’ve been doing a bunch of CSS tweaking recently, and keep being surprised by how nice modern CSS is to work with. As someone grey-haired enough to remember writing HTML without CSS, it’s amazing to think how far along web technology has come¹. I wanted to demonstrate some of the handy bits and pieces I’ve used recently.

:has

The :has selector allows you to effectively query for child elements. While a span will match a <span> within an <a>, a:has(span) will match an <a> that contains a <span>. This really shines when combined with more complex selectors, for example:

input {
    border-radius: var(--border-radius);

    &:has(+ .results:not(:empty)) {
        border-bottom-left-radius: 0;
        border-bottom-right-radius: 0;
    }
}

This is part of the styling for my film search box. When the search box is presented initially it has fully rounded corners. But when it is followed by a non-empty results element, it removes the rounding on the bottom corners so that the border continues in a straight line down into the results. You can see it in action below; just enter a few characters (like “the”) to get some results:

You could achieve the same effect by having JavaScript add a class to the <input> element, but I’ll take a CSS solution over a JavaScript solution any day.

Nested rules

You probably spotted this in the example above. It’s what finally made me switch from SCSS to plain CSS. If you have a rule for .foo and a rule for .foo .bar you can just nest them. Not only does it save repeating yourself an awful lot, it keeps everything organised nicely. For example, the CSS for my film list embeds looks like this:

a.film-list {
    display: grid;
    grid-template-areas: "header images" "description images" "meta images";
    grid-template-columns: 1fr auto;
    grid-template-rows: auto 1fr auto;
    row-gap: var(--small-space);

    @media (width <= 800px) {
        grid-template-areas: "header" "description" "images" "meta";
        grid-template-columns: 1fr;
        grid-template-rows: auto auto auto auto;
    }

    & + & {
        margin-top: var(--medium-space);
    }

    h3 {
        font-size: var(--font-size-xxlarge);
    }

    .description {
        /* ... */
    }
}

Everything is wrapped up in a single bundle, including the @media rules for changing the layout on smaller screens, the lovely little & + & rule that adds some extra margin if there are two lists in a row, etc. The & syntax refers to the parent selector, so & + & in this case is the same as a.film-list + a.film-list: it’s very handy! The best part about this is that it’s the exact same syntax as SCSS, so converting is easy². The styled element looks like this:

Watched films ranked

Every film I’ve watched since I started logging, ranked.

Obviously super subjective, and subject to change often and arbitrarily.

264 films

Media range syntax

Once again, you might have spotted this in the previous snippet. I’m not deliberately teasing things, I promise! Back in the day, you did media queries like so:

@media (min-width: 1000px) and (max-width: 2000px) {
    /* some rules that work for screens at least 1000px wide and at most 2000px wide */
}

I always hated this syntax. I always got muddled up as to whether I wanted “min” or “max”, and whether they were inclusive or not. It’s easy to reason through, but it never came naturally. Fortunately you can now just use ranges:

@media (1000px <= width <= 2000px) {
    /* some rules that work for screens at least 1000px wide and at most 2000px wide */
}

I find this style so much easier to write and understand.

Anchor positioning

Trying to dynamically position one element next to another used to exclusively fall within the purview of JavaScript. Fortunately anchor positioning fixes all this. I use this in the film search field I showed above:

.film-search {
    input {
        anchor-name: --film-search-box;
    }
    .results {
        position: absolute;
        position-anchor: --film-search-box;
        position-area: bottom center;
        position-visibility: always;
        width: anchor-size();
    }
}

This does lots of fun things. The .results element is anchored to the input field (via the --film-search-box name), and it’s positioned on the bottom, directly under the anchor. The position-area rule describes a 3x3 grid, with the anchor at the center, so top left would put it diagonally adjacent to the anchor. Next, position-visibility keeps the .results element visible when the anchor isn’t; otherwise when you scroll the anchor off the screen the results would immediately vanish. Finally, the special anchor-size() function makes the .results element take up the same exact width as the anchor.

All-in-all, this puts the results exactly where I want them, without having to deal with any JavaScript at all. I can see how it’d also be amazingly useful trying to do tooltips or other forms of ‘floating’ content too. You can even leave the positioning up to the browser, giving it hints about which order to try, or what property to optimise for (e.g. you can say “anchor to the left or right, whichever has more horizontal space”).

attr() function

This one blew my mind a little. In some of the elements on the site, I’ve added a little label to the top. It looks something like this:

It’s meant to just be a visual flourish, not a semantic title or anything, so I initially just added a ::before selector to each element, customising the content to have the right value. I didn’t like the duplication, though. Now, instead, I do this:

&::before {
    content: attr(data-title);
}

Each component defines its title in a data attribute: <div class="raised-box" data-title="an example">, and the attr function plucks it out and puts it in the content rule. It’s worth noting that this is only widely supported for the content rule, you can’t yet use it for colours or dimensions or other things. It still feels a bit magical, though. Like you’re making a reusable, customisable component with just HTML and CSS.

layers

I’d come across layers a few times, but I never found a need for them. It seemed like something you’d only really need with complicated design systems, or something. Then I had a problem and layers were the perfect solution!

The headings on this site have a whole bunch of CSS attached to them. Currently they look a bit like blue painter’s tape with handwriting on them. This style is applied to all headers, and then the various places that don’t want it had to manually reset everything. I got fed up with that, so decided to add a plain-header class which would “disable” the extra styling:

h2,
h3,
h4,
h5,
h6 {
    /* common styles for all headers, regardless */
    font-family: "Chris Hand", sans-serif;
    font-size: var(--font-size-xxlarge);
    color: var(--text-highlight-colour);
    margin: var(--medium-space) 0;
    line-height: 1;

    &:not(.plain-header) {
        /* do fancy stuff if it _doesn't_ have the .plain-header class */
        transform: rotate(-0.15deg);
        padding: var(--smedium-space);
        font-weight: 800;
        filter: drop-shadow(3px 3px 5px rgb(0, 0, 0));

        a {
            background: none;
            text-decoration-skip-ink: auto;
        }
    }
}

This might seem a bit backwards but I want the default to be styled, as those are far more common. I added this change, sprinkled around some “plain-header” classes, tidied up a lot of duplicate CSS, and things mostly worked. Mostly. Some things stopped working. In a few places the headers had slight tweaks, and they stopped working entirely.

It turns out in moving the rules from a plain h2 selector to a h2:not(.plain-header), I’d made them more specific. Previously a selector like h2.special would have been more specific, so its properties would override those from the less specific h2 selector. My first reaction was to try and hack around it. Changing all the overrides to body h2.special would make them more specific again, but I didn’t want to have to remember to do that forever more.

Instead, I defined some custom layers, and put the header definitions in one:

@layer reset, links, headings

@layer headings {
    h2,
    h3 {
        /* etc */
    }
}

The first @layer rule defines some layers that will be handled in a specific order: first the “reset” layer, then the “links” layer, then the “headings” layer, and then anything not in a layer after that. Rules in one layer don’t have to worry about beating the specificity of rules in another layer, because they’re handled separately.

Note that I couldn’t just put the headings in a layer and call it a day: their rules have to come after the CSS reset, and after the normal link styles, as headers have a bit of extra styling for nested links. If the CSS reset weren’t in a layer, then the * { margin: 0; padding: 0; } type reset would apply over the rules from the headings layer.

Using layers is definitely a bit fiddly, and is not necessary for a lot of sites, but it’s a much cleaner alternative to ugly specificity hacking.

Things I’m looking forward to

There are a few things that aren’t (widely) available yet, that particularly interest me:

sibling-index() and sibling-count()

These new functions are available in WebKit and Blink based browsers, but not Firefox. They give you the index of the element within its siblings, or the count of siblings. For the film list component above, I currently have this abomination for the overlapping posters:

&:nth-child(1) {
    z-index: 5;
    left: 0;
}
&:nth-child(2) {
    z-index: 4;
    left: calc(133px * var(--overlap) * 1);
}
&:nth-child(3) {
    z-index: 3;
    left: calc(133px * var(--overlap) * 2);
}
&:nth-child(4) {
    z-index: 2;
    left: calc(133px * var(--overlap) * 3);
}
&:nth-child(5) {
    z-index: 1;
    left: calc(133px * var(--overlap) * 4);
}

These could be replaced with something like:

z-index: calc(1 + sibling-count() - sibling-index());
left: calc(133px * var(--overlap) * (sibling-index() - 1));

As an added bonus, it would scale to any number of posters. index being 1-based not 0-based is a bit unfortunate as it makes using it in calculations awkward (see 1 offset in both of those rules!), but it’s leagues better than writing 5 separate rules.

random()

Currently only available in Safari. There are a few places where I’d like to have slight random variations of the style. Things like elements that are rotated slightly for aesthetics; they look a bit silly if they’re all identically positioned. I also randomise the icons and positions of my rating stars to break up the visual monotony. Here are a few examples:

Currently I do the stars by hardcoding a bunch of classes and having the backend randomly apply one when it generates the markup for stars. Being able to do it in CSS would be great, though.

Mixins

This one’s so far off it’s not even listed on caniuse.com yet. Mixins are another handy feature of SCSS, that allow you to define reusable blocks of rules, then import them when needed:

@mixin fancy-background {
    background: /*...*/;
}

.some-element {
    @include fancy-background;
}

#other-element {
    @include fancy-background;
}

This would be particularly useful if you can’t easily control the markup to add classes to everything. For example, my footnotes are rendered by a markdown plugin, and don’t easily have a way to add extra classes to them. To style it the same as another element, I currently duplicate a bunch of rules between them both. Mixins would allow me to define those rules once, and then import them in both places.

Aside from JavaScript, which seems to just endlessly reinvent new frameworks and ways to make the most sprawling dependency tree possible. ↩︎
It also means that if your website’s syntax highlighting library doesn’t seem to understand nested rules, you can just pretend your perfectly valid CSS is actually SCSS and it’ll magically work. Grumble, grumble. ↩︎

Home Automation Without the Megacorps

2025-05-21T00:00:00Z

I first experimented with home automation in 2016, by picking up a Samsung “SmartThings” hub. It was terrible. The UI to configure things was slow and clunky, firmware updates were applied whether you wanted them or not, and everything stopped working if their cloud services stopped. You were also locked into whatever integrations they deigned to support, of course. After that broke for the umpteenth time I scaled back and for years the closest I got to home automation was a couple of Hue bulbs.

Recently I’ve been building it out again, though. This time using off-the-shelf components that interop using Zigbee, open-source software, and some code I wrote myself. It’s great; it runs entirely locally and has had basically zero downtime. The Zigbee ecosystem lets me integrate all sorts of things without having to spend lots of money on “smart” alternatives. I think I’ve spent less on this incarnation than I did on the original SmartThings hub all those years ago (even without adjusting for inflation!).

My current setup

I run everything on a Raspberry Pi 4, with a Sonoff USB Zigbee adapter based on the CC2652P chipset¹. Interfacing with the Zigbee stack is handled by zigbee2mqtt (z2m for short), an open-source project that basically bridges your devices to an MQTT broker². When a device reports some data, it will send a new message over MQTT; when you want to make a device do something you just post a message back. It’s incredibly lightweight, but supports a huge array of devices out of the box. And as it’s just using MQTT, it’s trivial to integrate with other software or build on top of.

I know a lot of people building out this kind of home automation use Home Assistant, but I don’t get on with it terribly well. It felt incredibly sluggish, and the entire project is just a bit… much. I want a binary or package or docker image I can just run, not an entire operating system. That’s not how computers are meant to work! In contrast, z2m is simple to set up, super light weight and responsive.

Anyway. z2m exposes Zigbee devices over MQTT, so I wrote some code in Go to connect to the MQTT broker, and listen to the messages. It’s grown a bit beyond this now, and I’m skipping some boring bits like error handling and JSON parsing, but at first I had something like:

for {
    message, topic, err := c.ReadSlices()
    
    if string(topic) == "zigbee2mqtt/desk-button" {
        if strings.Contains(message, "single") {
            c.Publish(nil, []byte("{\"state\": \"TOGGLE\"}"), "zigbee2mqtt/room-lights/set")
        }
    }
}

I think I actually made this harder to read by trying to simplify it here, but hopefully you can follow that it was relatively straight forward to listen for a particular action to happen (in this case me “single”-pressing on the device called “desk-button”) and then make another device do something in response (toggling the state of the “room-lights” device).

So what actually are these devices? At present in z2m I have the following:

Some generic buttons
An air quality sensor (USB powered), and a separate temperature sensor (battery powered)
A light switch
Some 240V relay modules, that I use to turn non-smart devices on and off
Some USB relay modules, for the same purpose
Some “smart” plugs that I mostly use to monitor power usage
A motorised blind roller

I think all of these are either Tuya or Moes branded, and were all sourced from AliExpress. You can get the same things from Amazon or elsewhere, but they tend to be 3-4x more expensive for the same product.

One of the cool things about Zigbee devices is that the powered ones work together to create a mesh network, so you don’t have to worry about network repeaters or signal strength like you do with Wi-Fi networks. z2m even makes a map showing the connections:

The network map produced by z2m. You can see how all the powered devices form a mesh that the lower power ones can connect to.

Some interesting automations

A Zigbee relay spliced into the power cable for the fan

So what do I actually do with all of this? Some of it is just what I’ll call “laziness automation”: I want to be able to turn on the lights without getting up and walking to the light switch. So there’s a Zigbee button on my desk that does it. Then there are some less manual automations: my blinds are automatically closed at sunset³, for example. It feels a bit trivial, but it’s surprisingly nice just not to have to think about that at all.

Another nice quality of life automation is the light I have above my monitor. It’s USB powered, and I now have it going through a Zigbee USB relay that lets it be toggled on and off. Then I have a small agent running on my desktop that turns the light on when the computer is unlocked, and off when it locks or shuts down. I keep meaning to make a “film mode” that detects when I’m watching a film, and turning all the lights and blinds down, but I haven’t got around to it yet.

The most complex automation is probably for a window fan. It’s not smart in any way, so I cut the power cable and inserted a Zigbee relay. The whole thing is housed in a little project box to keep it secure. The relay basically acts as a switch: the live wire leading to the fan runs to the “normally open”⁴ contact, while the upstream power goes to “common”. When the relay is told to turn the fan on, the two get connected and the fan gets power. Oh, it’s also not actually a window fan, but I designed and 3D printed some adapters so that it sits right in the window.

So now we have a window fan that can be turned off and on automatically. But I don’t want to have to press a button to do that. I’m lazy, remember? Instead, I made it so that the Go code constantly monitors the temperature reported by the air quality sensor, and queries the free OpenWeatherMap API to get the rough temperature outside. It can then turn the fan on if the room is too hot, and outside is cool enough to make a difference (there’s no point in blowing hotter air in!).

A graph of room temperature, showing the effect of the fan being turned on and off

I don’t want it to do that all the time though. The room doesn’t need to be cooled if I’m not around. There are various Zigbee presence sensors you can get, but the cheaper ones seem to be of dubious quality. Instead, I wrote some code to guess whether I’m present. It uses the state of the monitor light as a proxy for “is the computer in use”, and then makes some guesses based on the last time the computer was used and the current time (if I turn the computer off at midnight it probably means I’m going to sleep; if I turn it off at 2pm it probably means I’m going out somewhere).

You can see in the graph that the fan has a decent impact on temperature. I coded it to cool the room to 19 degrees, but then not turn on again until it was above 20. This prevents it flip-flopping on and off constantly. You can clearly see the pattern in the graph, as it actively cools and then slowly the room warms back up. This arrangement is much better than being woken up at 5am because it’s painfully cold. Trust me.

Bonuses: metrics and 3D printer

One of the things my custom Go code does is collate all the various stats reported by the Zigbee devices, and inserts them into a VictoriaMetrics database. I originally hosted this on the Pi itself, and it performed fine, but I’ve since moved it onto a server so that I can use it for some other things as well.

I set up Grafana to point to VM, and can create dashboards showing power usage, what devices are turned on when, and a bunch of environmental conditions. This also makes it easy to spot how good the data coming from the devices are. For example, the air quality sensor reports a figure for the amount of Carbon Dioxide in the air, as well as the amount of Volatile Organic Compounds (VOCs). The graphs are basically identical, but on a different scale. It turns out this particular device has no actual way of detecting CO₂, so it just “calculates” it from the VOCs figure. Useful to know if you want to actually use that data.

Recently I came across a go library for interacting with Bambu Lab printers, so I’ve also hooked that into my automation. It exports metrics about the printer, so I now have a way of seeing what’s going on when I’m not physically present⁵. I even added a HTTP endpoint (exposed over Tailscale) that shows pictures from the built-in camera.

On the automation front, I’ve made it automatically turn off the printer’s light when it finishes a print, and also added push notifications via PushOver whenever the state changes. No longer will I be sat in another room blissfully unaware it ran out of filament seconds after I walked out the door!

Was it worth it?

These days you could probably just buy some kind of ‘smart home’ hub that works well enough, and do most of what I’ve done with a lot less effort and no coding. I’m still of the opinion that for something so essentially local, it should itself be managed entirely locally. I don’t trust companies like Google or Amazon not to kill their products, or change or remove an API I rely on.

Obviously the “Not Invented Here” approach of coding everything yourself doesn’t suit everyone, but as someone who enjoys coding and enjoys having things work just so it works very well for me.

It turns out the chipset is important. I initially used a similar Sonoff dongle that used a CC2531 chipset, and its performance wasn’t great. It often failed to pair with new devices, and dropped links to existing ones. The zigbee2mqtt docs do explicitly advise against the CC2531 chips for that reason. At the time they recommended CC2652Ps, so that’s what I went with. If you’re starting new I’d go with whatever their latest recommendation was. ↩︎
MQTT is basically a network protocol for publishing and subscribing to arbitrary messages. A broker is the thing that sits in the middle and routes the messages. I use Mosquitto but any will do. ↩︎
They originally also re-opened at sunrise but that was a terrible mistake. Who knew the sun rose so early?! ↩︎
“open” meaning “there’s a gap so it doesn’t work” not “open for business”. This confusion in terminology also extends to drawbridges. ↩︎
I use the printer in LAN mode, which means there’s no way to monitor it from a phone, even if you’re connected to the same network still. ↩︎

Further adventures in 3D printing

2024-08-04T00:00:00Z

The Bambu Labs P1S.

Not quite a year ago, I bought a Sovol SV06 3D printer and wrote about my initial experiences. At the end I joked:

I’m sure there will be more problems, but hopefully I get at least a week or so before anything else goes wrong. Maybe I’ll print an “X days since the last SV06 problem” counter…

That turned out to be more prophetic than I expected. It became a running joke that I’d flip the imaginary “days since” sign back to 0 almost every time I printed. I still really enjoyed having a printer, though: it’s so useful to be able to be able to go from an idea to a CAD drawing to a physical object in the space of minutes or hours. So when Bambu Labs reduced the price of the P1S — a printer generally regarded as about as trouble free as you can get — to £522 including shipping, I splurged on one.

Concerns

I make it sound like that was an easy decision, but I actually ummed and ahed a lot before pulling the trigger. I had a lot of objections to a Bambu Labs printer, and wasn’t quite sure if the price made up for them.

The Bambu Labs printers are designed to be more consumer friendly than most previous 3D printers. You can start a model printing directly from their website or mobile app, which employs a cloud-based slicer that then sends the model down to your printer. This is one of those things that sounds amazing for consumers, but should terrify anyone who works with computers. There are so many ways for a “cloud-connected” printer to go wrong, and with such potentially disastrous results it gives me anxiety just thinking about it.

This is not just theoretical, either. In a blog post with the rather under-stated title of “Initial Investigation in the Bambu Cloud Temporary Outage”, Bambu describe how a server-side error caused printers to start printing unprompted. Users on Reddit reported printers starting in the middle of the night, trying to print on top of other objects that were left on the build plate, and so on. 3D printers can easily start fires; having them cloud controlled is frankly insane.

As a result of that “temporary outage”, Bambu further improved the “LAN mode” for their printers, which allows you to sever its connection from their servers and control it over the network. That’s basically how my old printer worked anyway, so I was happy enough that I could enable LAN mode and ignore all the cloud nonsense.

My other objection to Bambu was more nebulous. Almost all 3D printers are built upon open source software, and some companies like Prusa go out of their way to make their products more open to give back to the community. Bambu don’t really do any of that: I’d be very surprised if they hadn’t incorporated a bunch of open source software into their printers and just ignored the licences¹. I’d much rather give my money to a company doing good, but the only equivalent printer was the Prusa MK4 which was double the price and didn’t come with an enclosure. To add an enclosure kit would have made it £800 more expensive than the P1S, and I just can’t justify that.

Experience

The initial setup of the P1S was a breeze. While the SV06 shipped in parts, the P1S came fully assembled and just needed some packaging and retaining screws removed. These were all clearly marked with large coloured arrows. It’s very much designed so anyone can do it.

I ran through the initial calibration, firmware update, and then put it in LAN mode. Then I just started printing and it went fine. No messing around levelling a bed, or using a sheet of paper to try and set the Z-offset properly; it just worked. It was really loud though. After talking a bit with a friend who’d also bought a P1S, I realised that most of his noise was from the fans, while most of mine was from the servos. A bit of research later and I found out they added servo noise compensation in a firmware update, but I hadn’t run the calibration for it because the initial calibration happened before the update. After doing that, the printer went from sounding like it was impersonating a continental police siren to just being a bit fan-y.

The biggest difference over the SV06 is the speed. I’d swapped the nozzle on the SV06 to a 0.6mm one, and generally printed at a layer height of 0.4mm. The P1S still has its 0.4mm nozzle, and I mostly print at a layer height of 0.2mm. So it’s laying down twice the number of layers, with a nozzle that can extrude half the amount of plastic… And it’s at least twice as fast! Prints that I previously wouldn’t have even attempted on the SV06 are now 8-10 hours on the P1S, without even adjusting the speed or lowering the quality. Here’s a side-by-side comparison:

P1S vs SV06.

The P1S can print eight objects because of its slightly larger bed, while the SV06 can only manage three. The P1S is also printing at a much higher quality. Yet somehow it still ends up being faster. It’s mind blowing.

The other big difference I’ve not mentioned yet is that the P1S is a “core XY” printer rather than a “bed slinger”. That means in order to move along the Y-axis (from the front of the bed to the back), the P1S moves the extruder while the SV06 moves the bed. This makes a big difference when printing tall objects, as they’re far more likely to wobble and come loose when the bed is moving back and forth. It also presumably makes the kinematics a lot easier as the mass of the moving parts is constant, instead of gradually becoming heavier as more and more plastic gets added.

The only failures

I’ve only had a handful of failures since getting the P1S. I had one weird issue where the slicer decided to print some parts extremely slowly, and the print just didn’t work out in those parts; that’s more of a slicer issue, though: after tweaking the model to stop the weird behaviour it printed fine.

The only failure I can directly attribute to the printer was when I tried ironing. This is a process where after printing the top layer, the printer slowly goes back over it at the same height while extruding a small amount of plastic. This is meant to fill in the small gaps between extrusions and give a smooth finish. In my case, though, it just clogged the nozzle and extruder.

At first I thought it was because I was printing too hot: the profile I was using was designed for fast printing, so had to melt the filament rapidly, but there was no way to turn that temperature down just for the ironing pass. I tried another run at a lower temperature and everything clogged again. I then swore off ironing, did a normal print, and everything clogged once more.

At this point I was getting exceedingly good at disassembling the hot end, but also fairly annoyed. It felt like I was using an SV06 again²! I’d previously read some recommendations that you should leave the door or top of the enclosure open when printing PLA, but had never really had any issues so hadn’t bothered. I tried a print with the top propped open and everything worked smoothly again. In hindsight all these clogging issues happened when it was particularly hot and humid outside, which was probably a factor.

Summary

Upgrading to the P1S has made the 3D printer feel more like a tool and less like an additional ongoing project. The speed increase continues to amaze me, as does the increase in quality.

I still think it was valuable to have the SV06 to learn how printers work — you definitely don’t get as much of that from using something so consumer-focused as the P1S — and figure out if I was actually going to use it long-term or whether it was just a fad for me. So it served its purpose, but I’m rather glad to see the back of it in favour of something better in pretty much every way.

And if they did there’s nothing anyone can do about it because copyright doesn’t exist in the same way in China. ↩︎
Although taking apart the P1S (which is a proprietary machine you might not expect to be very user-servicable) was orders of magnitude easier than taking apart the SV06 (which was an open source design). Everything is just much nicer: the connectors are easier to attach and detach, the screws are all a consistent size instead of needing a whole suite of allen keys, and so on. ↩︎

Project log: Filament weight display

2023-12-03T00:00:00Z

The finished project

One problem¹ I have when 3D printing is that it’s hard to gauge whether there’s enough filament left on a roll to complete a print. Sometimes it’s obvious when the print is small or the roll is full, but often it’s not. If I’m unsure about it, I end up obsessing over the printer instead of just leaving it to do its thing.

The typical approach to this problem is to use a run-out sensor, which stops the printer when it detects that the filament is no longer running through it. I’d rather know in advance though: it’s no good stopping the print if I’m making something that has to look nice and now half of it is one colour and the remainder will be something else.

While browsing around for ideas, I came across a project that used a load cell to measure the weight of the filament roll². I didn’t really know what a load cell was, but decided to do some research and see if I could build my own. I didn’t actually read the article I found, intending to figure things out on my own if I could.

Load Cells 101

A load cell, its amplifier, and some random headers

At the heart of the project is a load cell. It turns out these are the things that do the lifting in most electronic scales. They’re basically a carefully machined metal bar with a strain gauge attached to it. The strain gauge is a long trace of conductive material that runs back and forth across the middle of the bar. When the bar bends very slightly (due to load), the conductor flexes with it and gets longer or shorter; that flex changes its resistance by a tiny amount, which can be measured using a Wheatstone bridge.

The Wheatstone bridge is a diamond of resistors, and requires an ’excitation’ voltage to be applied across it in one direction, and the resistance is then read from the perpendicular pair. As the resistance is tiny, and the changes even more tiny, you generally need an amplifier to read it and output something more useful. The HX711 is such an amplifier, and is so ubiquitous that most places that sell load cells will just bundle one with it.

The HX711 connects to the load cell using four wires: two for the excitation voltage, and two for the output. On the other end it takes a 5V input, ground, and then has two pins to deal with the onward communication: one for a clock signal, and one for data. We’ll get back to that later!

Early prototyping

The prototype, mid-debugging

I decided early on to base the project around an RP2040-based board, as I had previous experience with them and they’re cheap and easy to get hold of. I started off with a Raspberry Pi Pico, slotted it into a breadboard, and connected it to the HX711. A short search produced three or so different python libraries, but I couldn’t get any of them to work reliably.

If you look at the picture of the prototype, you’ll notice a large bundle of wires to the left. These are connected to a logic analyser I bought to try and understand what on earth was happening, because it seemed like the code should work, and there was definitely some communication with the HX711 happening, but none of the readings made any sense.

At one point I noticed that moving my head near to the Pico caused the readings to change, but I didn’t understand the implication of that³. I went to bed unable to figure out what was going on, and just before I dozed off realised that I must have the pins configured wrong. The next day I checked the spec sheet and discovered that the pin with the number “1” silk-screened next to it is in fact GPIO 0, not GPIO 1⁴. The pin the Pico was trying to read data from wasn’t actually connected to anything, which is why waving my hand near it was enough to induce a signal.

Updating the code to use the correct pins made everything work much better and I started to get sensible readings. At this point I came across the RP2040-Zero by Waveshare, which is not only a smaller, cuter, cheaper Pico, but has silk-screened numbers that actually match the GPIO pin numbers (plus an actual a reset button!). I immediately bought several, and switched the prototype over as soon as they arrived.

The rest of the prototyping was reasonably uneventful. I used a little OLED screen I had sitting around from a past Ali Express order, and once again there were several python libraries to handle it. Soon enough I had raw weight readings from the load cell (which was stuck to my desk with painters’ tape) being displayed on the screen.

The load cells don’t measure absolute weight, so you have to “calibrate” them by remembering the reading when there is no load, and then applying a scaling factor to turn the raw reading into a weight. I worked these out by putting a known weight on the business end of the load cell, and then hard-coding the numbers.

An interruption to deal with interrupts

One thing I noticed with the MicroPython libraries for the HX711 is that they relied on polling the data pin to see if there was any data to read. The way the HX711 communicates is by pulling the data line low when it has data; you then have to pulse the clock line to get it to shift a bit of the reading out over the data line. The HX711 I have operates at 10Hz by default⁵, and reading the data takes almost no time at all, so the most “efficient” thing to do is to sleep for 100ms between readings.

This is fine if you’re not doing anything else, but gets awkward if you also want to refresh a screen at certain points, or check for button inputs, etc. It also upset me to see the data line being low for so long when viewing the logic analyser traces. The RP2040 supports setting interrupts on the GPIO pins, but I couldn’t find anyone who was actually using them for the HX711.

I therefore did the only sensible thing: wrote my own library, using interrupts to monitor for data availability. It was pretty straightforward, but didn’t actually work consistently. Looking more closely at the other libraries, they all do something to try to increase the speed at which the clock signals are written⁶: some were disabling interrupts, others were using assembly. I, again, did the only sensible thing: I threw all the python away and wrote a new driver in TinyGo.

My new code is event driven: it adds interrupts for button presses, and one for the HX711 data line. When the data line is pulled low, it removes that interrupt (so it doesn’t fire for every bit of data we receive), does the reading logic, then re-adds the interrupt. Theoretically if you spam buttons at an inopportune time you could mess up a reading, but the reading 100ms after would be fine. So my code spends most of the time idle, which translates to very little power draw.

User experience

While prototyping I was using some standard small push buttons to navigate the user interface I was creating. I soon realised that if I needed to enter weights on the real device I wasn’t going to be happy poking an annoying little button hundreds of times, and I didn’t feel like coding anything more elaborate to make input easier. Instead, I switched to using a rotary encoder. This is a bit like a variable resistor, but it can rotate completely freely, and sends a signal when it’s turned. It also has a button built in, so you can press it down to select things.

It took me a while to get the hang of the rotary encoder: it has two data pins for turning, and you have to wait for a falling edge on one pin and then immediately read the other to figure out which way it’s turning. My initial attempts at doing this weren’t quite immediate enough⁷, so I ended up with somewhat random data. Trying to select a number when going right sometimes increases it and sometimes decreases it is an exercise in frustration.

The correctly functioning rotary encoder makes it much easier to input numbers and change settings. I ended up with a very simple menu system at the bottom of the screen which lets you cycle between three options: setting the spool weight, zeroing the scale, and calibrating it. Zeroing is the most straightforward option: it simply reads the current value, and saves it as the zero offset in the flash memory. Selecting spool weight enters a mode where turning the rotary encoder increases or decreases the spool weight by a gram at a time; pressing the encoder in saves the value to flash and exits the mode⁸.

Calibration is a bit more confusing. Changing the spool weight changes the value you see on the screen directly and predictably. Calibration instead affects the “scale” value you can’t actually see; you just see the effect of the scaling on the weight reading. Still, if you have a known weight on the scale you simply rotate the encoder until the right weight is displayed on the screen. Pressing the encoder saves the value to flash as with the other modes.

Putting it together

The final assembly

The final step was to assemble everything in a way where it would be usable, and wires wouldn’t keep falling out whenever you looked at it. I found some cute little prototype boards that would just about fit all the components on – I left the OLED screen and rotary encoder off so they could be mounted to the front of the box.

I obviously 3D printed the enclosure, because I own a 3D printer and therefore spend a lot of my time 3D printing parts for my 3D printer. In my first prototype I put raised areas on the back panel and put some heat-press inserts in them, intending to screw down the protoboard. The screw holes I was going to use, however, were underneath the soldered-down RP2040-Zero and HX711. I instead uninserted the inserts and simply put some screws through the back panel with the intention of slotting nuts under the components. This turned out to be both incredibly annoying and entirely unnecessary; the board sits at the back of the box on its own, and there’s no real danger from it having a bit of freedom.

While I was prototyping I was powering the circuit from the USB port on the microcontroller, but for the actual unit I added a buck converter and ran a cable from the 3D printer’s power supply (which outputs 24V). This has the handy side effect of turning the scale on and off with the printer. I’ve recently bought a bench power supply, which made testing this part a lot easier: being able to dial in a voltage and current limit and then just plug things in is great.

The other thing that needed to change between my prototype and the final version was the load cell. It needed to be attached to the printer in such a way that one end bore all the weight of the spool (and, you know, not stuck to my desk with painters’ tape). I was originally going to do something fancy with bearings, but settled on the easier option of a spool holder which uses the same threading as the original, so it slots straight in:

The load cell mounted as part of a spool holder on the printer.

With all of this done, I invented a complicated mounting system to keep it attached to the printer. Any resemblance to blue painters’ tape is entirely coincidental.

Bill of materials and sources

Here are the major components that I ended up using:

Part	Source	Cost
RP2040-Zero microcontroller	WaveShare	£3.15
5KG load cell + HX711	AliExpress	£1.89
Buck converter	AliExpress	£0.51
SH1106 OLED module	AliExpress	£1.70
Rotary encoder	AliExpress	£0.80
Mini PCB prototype board	Amazon	£1.49

Where things come in packs of more than one, I’ve listed the cost of one unit. I’ve not included things like wires, connectors, or the filament used in printing the enclosure as you can use whatever you have to hand.

The source code I wrote is available on GitHub, and the designs for the 3D printed parts are shared in OnShape.

Among many, many others, of course. ↩︎
I can’t actually find where I saw this original project now, but there are quite a few kicking around if you search. ↩︎
This happened at about 1am and I was tired and frustrated. That’s my excuse, anyway. ↩︎
At this point I realised I’d made the exact same mistake the last time I used a Pico. Fool me once, etc. ↩︎
You can change this to 80Hz by resoldering a resistor on the board, but 10Hz is already several orders of magnitude faster than I actually need. ↩︎
If the clock signal stays high for longer than 60ms it’s treated as a shutdown signal by the HX711. This is somewhat unideal when you’re trying to read data from it. ↩︎
Because of my very clever interrupt system. I wanted to do as little work in the interrupt handler as possible, so I was just enqueuing an event to be processed in the main loop. This introduced enough delay that I wasn’t reading the second pin at the right time. The solution was to read the pin in the interrupt handler and then just enqueue a “left” or “right” event instead of my original “turning somehow, you figure it out” event. ↩︎
I was initially planning on hard-coding the weights for all the spools I’m likely to use, and just having a way to switch between them. But the thought of having to re-flash the device every time I bought a new type of filament made me reconsider. Plus, it was way easier to not do that. ↩︎