Chameth.com - posts like debugging-beyond-the-debugger, home-automation-without-megacorps, why-you-should-be-using-https but not modern-css-is-fun

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. ↩︎

How I Get Things Done

2024-09-01T00:00:00Z

I always quite like reading about how other people do things. What software or hardware they use, or how they manage reminders, todo lists, and so on. I’ve never actually written about how I do any of that, though. So here it is!

Productivity

In the past I’ve fallen victim to the idea of there being One True Productivity System that would solve all my problems and make me amazing at getting things done. The title of this post is a nod to Getting Things Done, which I’ve read and tried to religiously follow in the past, but it’s just not for me. One thing that did actually stick from it, though, was the idea of “open loops”:

Anything that does not belong where it is, the way it is, is an “open loop,” which will be pulling on your attention if it’s not appropriately managed.

If I want to do something and it’s not recorded in a way I trust, it weighs on me a little. Those little weights all add up, and just make life uncomfortable. I deal with those in a few ways:

Inbox Zero-ish: if an e-mail needs me to do something, it sits in my inbox until it’s done. When it’s done, it gets archived.
Notes: random things I try to remember I put into my notes, so I can search for them later.
Budget: anything monetary I just adjust in my budget or create a category for.
Todo list: any other kind of task I want/need to do either now or at some point in the future goes into Todoist.

Todoist

In the past I’ve gone through a lot of different todo systems, once again hunting for one that will fix all my problems etc¹. In the end I always ended up coming back to Todoist, and have stuck with it for a decent period now.

In Todoist, I have everything split up into projects. Work projects are one colour and personal projects are another. Anything that needs more than a handful of individual tasks gets a project, which is archived when it’s done. Any one-off things that don’t neatly fall into projects go into “Random junk” project.

As I’m writing this, I have 116 items in 22 projects. A good deal of those are things that I might want to do at some point, not things that I actively need to worry about. If I want to get one of them done, I schedule it so it shows up in the “today” view. I have the Todoist desktop app open automatically when I login to my computer, and it gets positioned on the right hand side of my ultra-wide monitor, so I can see the “today” view and add/remove things immediately at any point.

I’m not precious about tasks becoming overdue, or unscheduling things I’d previously scheduled. Priorities change, ideas that sounded good a week ago might no longer sound good, and so on.

I do a few things to help me manage tasks and keep track of things:

I have a monthly recurring task to look through everything that’s not scheduled, just so I keep a rough idea of what’s there, and can update or get rid of it as needed.
I wrote todoistager and have it running on a server to automatically apply tags to tasks based on their rough age: weeks, months or years. This lets me identify things that are lingering and reconsider them².
I automate adding tasks for things that demand my attention, like incoming GitHub pull requests. The Todoist API is nice and straight forward, and hooking it up to things is trivial.

Other desktop software

For notes I use Logseq, and I just put whatever I need to write under today’s note and rely on search or tags to find it again when I need to. I note basically anything that I might like to use again in the future. One of my most common tags is #blub, a term I came across in the excellent article “In defense of blub studies”. Blub is random ultra-specific knowledge; it might not be eminently useful to know on its own, but over time it can pay dividends.

I’ve previously tried a bunch of note taking apps, and methodologies, but like with todo lists I end up just wanting something that just works and stays out of the way. Logseq stores notes in Markdown, and I have a cronjob to commit and push my changes to a private git repository.

Like Todoist, Logseq launches when I log into my computer, and sits in the same 500px-or-so region on the right of my monitor. This allows me to switch from Todoist to take or refer to notes when needed. To do this positioning, I use devilspie2. I also use this to position Discord and my IRC client side-by-side on a small portable monitor that sits underneath my ultrawide.

More mundane software: I use IntejjiJ IDEA for almost all development and complex text editing³. The only exception is Android development where Android Studio rules the roost. For lighter text editing, Sublime Text is my choice.

I spend a fair bit of the time at the command line. I use kitty as a terminal emulator, with the zsh shell and Oh My Zsh for some nice plugins and enhancements. One thing I couldn’t live without is autojump, which allows quickly jumping to any directory you’ve previously visited using a substring of the name.

Web browsing is all Firefox, with Bitwarden for password management and two pinned Fastmail tabs, one for personal e-mail and one for work. I don’t think there’s much else to note there.

Oh, I use Arch, by the way.

Infrastructure

This is the hodge-podge of things that support my computer usage but sit outside the actual computer. In no particular order…

All my DNS queries go through NextDNS using DNS-over-HTTPS. NextDNS lets you add custom responses, block certain things from resolving, and subscribe to pre-made anti-tracking or anti-advertising lists. It gives you far more control over everything than most other services I’ve looked at.

Every device I control runs Tailscale to enable remote access. I also use Tailscale’s SSH authentication feature for my servers, allowing quick and easy access from my phone where I don’t have or want normal SSH keys.

One exciting service that combines these two is golink. It was created by Tailscale, presumably based on the go service used extensively inside Google. I run a version on my tailnet, and have NextDNS configured to resolve go to the tailscale IP of the service. That lets me type “go/whatever” on any machine I set up with NextDNS and Tailscale, including mobile devices. I use go links for all sorts of things:

Shortcuts to tools I use commonly: go/board gets updated to my current client’s kanban board or similar tracker, whether it’s in Jira, GitHub, Asana or whatever; go/meet goes to Google Meet with the user parameter set so I’m logged in with my work account not my personal account.
In place of bookmarks: go/flex goes to the CSS-Tricks flexbox guide⁴, go/cad goes to the OnShape login page, go/hmrc goes to the HMRC online services page, and so on
A few dynamic things: go/github/chameth.com will go to the csmith/chameth.com project on GitHub; go/ref/pipico will go to the Pi Pico page on my electronics reference wiki.

For my servers I have a minimal Ansible setup that does some basic configuration and deploys SSH keys to the right places. Almost everything runs inside Docker, and I use my own software for HTTP proxying: Dotege uses tags I apply to containers to build a config for Centauri which handles reverse proxying, using Let’s Encrypt for TLS certs. At the minute I have two servers: a dedicated server that runs basically all my services (including this website), and a little VPS for monitoring and backups. Both are from Hetzner.

I wrote my own basic monitoring software called Goplum to make sure things that should be running on my servers actually are. If it fails checks it sends a notification to my phone using Pushover, and a message to a channel on my private IRC server (running Ergo).

Hardware

For the last two years I’ve used a laptop as my main computer⁵. It’s a Dell G15 Special Edition. After some upgrades its specs are:

Intel i7-12700H processor
NVIDIA GeForce RTX 3060 graphics card
2x32GB DDR5 RAM
2TB Gen4 SSD

At home it sits behind my Alienware AW3423DWF monitor. This is a Quantum Dot OLED monitor, and I bought it almost immediately upon seeing someone else use it at a LAN event. As did three other people that were sat near us. It just looks so good. I wasn’t sure I’d get on with a widescreen monitor, and made sure it supported picture-by-picture before buying it, but have never actually used that. I generally run whatever I’m working on at nearly-fullscreen, then have Todoist or Logseq on the far right. Games go fullscreen over everything, of course.

Above the widescreen I have a curved lightbar that I find helps reduce eyestrain and makes it easier to focus on the monitor. And on top of that I have a Logitech Brio webcam which gives a great picture with lots of control over pan/zoom/etc for meetings. I have a little set of systemd scripts that detect when the external webcam is connected and disable the laptop’s built-in webcam, and vice-versa when it’s disconnected; that means whenever I jump into a video call in any app there’s only one input and it’s always the right one, which is nice.

Below the main monitor and its friends, I have a generic 1080p portable monitor connected to the laptop via USB-C. This comes with me when I travel, and serves as a Discord/IRC monitor when at home. It’s handy for throwing other things on as well, like if I need to reference a design while writing code, and don’t want to keep alt+tabbing.

I have two Durgod K320 keyboards: one with Cherry MX Silent Red switches for when I’m at home and don’t want to annoy people with the sounds, and one with Cherry MX Blues for when I’m travelling and can make a bit more noise in exchange for a much nicer typing experience. They’re both tenkeyless so they can handily fit in a backpack.

I use a Zowie EC1-C wired mouse, which does the job well. I got fed up with mice from more mainstream manufacturers failing: my previous mouse was a Razer Viper that lasted 7 months before it started losing clicks. All my audio goes through a HyperX Cloud Alpha Wireless, which has the most insanely good battery life of any wireless headset I’ve ever owned or seen. Their claim of 300 hours is not just marketing!

In non-computer hardware, I have a Bambu P1S 3D printer that I’ve mentioned in my blog before. For printing in fewer dimensions I have an Epson EcoTank ET-1810, which is surprisingly reasonable for an inkjet printer, and the ink costs aren’t as astronomical as normal cartridges. Plus, you can’t decide to DRM ink when it’s loaded raw into the printer…

I have a small Zigbee network set up mainly to control the lights and the old 3D printer I no longer use (the P1S has a sensible standby mode so you don’t have to yank its power away to make the fans stop spinning!). That’s run through a Raspberry Pi running Zigbee2Mqtt and a custom app I wrote to monitor events on MQTT and generate the appropriate responses (or just log the data).

My daily-driver phone is an iPhone 15 Pro, but I have a bunch of Android devices kicking around for work purposes. I read nearly every day on a Kindle Paperwhite Signature Edition.

Money and work

I use You Need A Budget for figuring out how much money I can spend on what, and making sure I have enough put aside for bills and taxes and so on. I use it for both business and personal accounts together, but I mark all the business categories and accounts with a 💼 emoji, and have some scripts that use the API to make sure the money split makes sense⁶.

Every recurring monthly and annual payment has a category, as do all upcoming events I plan to attend, and all the wonderful taxes I have to pay. I also have categories for hobbies and other expenditure. I think all of that is pretty typical for a normal YNAB setup.

I also use YNAB for tracking anything I might like to buy at some point: it gets a category in a “Wishlist” group, and I’ll occasionally budget to buy things from there. I try (and often fail) to use that as a way to put off impulse purchasing. As my income is often very inconsistent, I try to set aside money so that I can “spend” a bit every week on things in the wishlist group. That feels a lot nicer to me than just budgeting everything in one go as soon as I get paid, and gives me more time to consider whether I really want those things⁷.

For work, I do all the more technical accountancy and tax filing and so on through FreeAgent. For my fairly straight-forward tax situation, I can basically manage everything myself using FreeAgent without paying for an accountant. That does mean occasionally spending a bunch of time reading tax manuals, but I’d rather fully understand the rules than just follow advice anyway.

The problem with implementing productivity systems or switching todo apps or anything of that ilk is that it can feel like you’re being productive by doing so. It takes a while to realise that you’re not, and actually getting on with things is better. ↩︎
Or just accept that I’ll maybe do them at some point. I kept the labels vague to try and not make it feel judgmental. ↩︎
Including writing this blog post right now. ↩︎
One day I will get all the justify- and align- options right without looking them up, but until then… ↩︎
This is very normal for developers, but much less common for computer gamers. I’ll probably go back to a desktop next time I upgrade, as I’m travelling a lot less. ↩︎
I can’t just arbitrarily move money from the business to myself, it has to be given as salary or a divided etc, which has tax implications. If I budget “business money” for personal things, then it actually has to be properly transferred and accounted for before being spent (as I’m in effect budgeting a future paycheck). It would be cleaner to keep the accounts completely separate, but I find this way works well for me as I can be a bit more flexible. ↩︎
It feels a little like I’m giving myself pocket money, which is a bit weird, but it’s a lot better than having no “income” for several months when client invoices fall weirdly or I’m between contracts. ↩︎

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. ↩︎

Adventures in 3D printing

2023-09-17T00:00:00Z

The Sovol SV06.

I’d been idly considering getting a 3D printer for a while, but have only recently taken the plunge. I picked up a Sovol SV06 from Amazon for £199.99¹, which is a model commonly recommended for beginners. About three weeks later, I think I’ve finally finished fixing all the problems the printer has, and thought I’d document them.

Setup and out of the box performance

The setup of the printer itself was straight forward. Most parts are assembled, you just have to bolt the frame together, bolt the various parts to the frame, and connect some wires. The hex bits in the iFixit Mako Bit Set were a godsend for this, as the included hex keys were a bit flimsy.

Once everything is bolted and connected, you turn it on and immediately start looking around for the jet engine you can hear. The fans are loud. The instructions walk you through the initial calibration, which consists of:

Levelling the X-Axis gantry (where the print head moves). The printer does this by (gently) ramming the gantry up as far as it will go.
Adjusting the Z-offset of the print head. The printer has an inductive proximity sensor attached to the extruder, but it doesn’t know how high it is relative to the nozzle. The calibration process involves manually dialing in this offset while moving a piece of paper back and forth under the nozzle.
Levelling the bed. This is entirely automatic: the printer just probes a bunch of points on the bed with the proximity sensor and builds up a mesh it can use to compensate for the bed not being level.

After that’s done, the included SD card has the standard “Benchy” model on it, pre-sliced and ready to print. It came out looking good:

A nice, problem free Benchy. No dramatic irony here.

The noise. Oh god, the noise.

I set about printing a few more things, but the noise of the machine quickly got to me. It sits approximately 80cm from my ear, and between the fans and the noises it makes when moving it was driving me mad. The fan in the PSU seems to sit at 100% power regardless of temperature or load, and sounds about three times louder than my laptop’s fans do when they’re running at full tilt. Fortunately, someone had designed a printable PSU fan silencer that redirects the airflow (and most of the noise) from the fan. It doesn’t feel like it should help that much, but it does significantly reduce the noise as it claims. This was the first of many times I’d use the 3D printer to print parts for itself.

The other noise was a lot less straightforward. The linear rods that all three axes run on pass through several bearings. Sovol apparently don’t bother to apply any lubrication to these, so it sounds like an elephant is moving through a gravel pit when the printer is running. Some people online suggest rubbing lube on the rods and pushing the movable parts back and forth, but this just results in a load of lube caught on the dust filters of the bearings².

The solution to this, then, was to dismantle most of the printer to gain access to each of the ten bearings, and manually lubricate them. This was tedious and messy, but not actually that difficult. It doesn’t seem like the kind of thing you should have to do on a brand-new machine, but I guess you get what you pay for.

Speeeeeeed

3D printers are slow. The SV06 is not one of the faster ones. One simple way to increase the print speed is to change out the nozzle. The SV06 comes with a 0.4mm nozzle, which is pretty standard, but if you upgrade to a 0.6mm nozzle you can extrude more than twice the volume of plastic in the same amount of time³. The consensus among anonymous internet people is that if you’re using a modern slicer there isn’t much difference in print quality when doing this.

I dutifully ordered a new nozzle, and after it turned up set about installing it. This is mostly straight forward, aside from the complication that you’re meant to do it when the hot-end is hot. That makes sense: you want it be under the same thermal expansion it will be under during use, but the tool they provide to change the nozzle is all metal. So you have a relatively delicate operation that you have to do in a bit of a rush before the heat creeps all the way up to your hand.

With the new nozzle in place, the printer was noticeably faster. I didn’t notice any difference in print quality, either.

SD cards are not fun

Up until this point, my process for printing anything was to slice it on the computer, export the gcode file to an SD card, turn around and walk over to the printer, insert the SD card, and start the print from the LCD. I don’t particularly mind those steps, but the SD card slot on the Sovol is terrible. It doesn’t line up well to the hole in the case, doesn’t guide the card in well, and is all round a pain to use.⁴

To remove the sneaker-net element of this process, I ordered a Raspberry Pi and installed OctoPrint on it. OctoPrint provides a web interface to the printer (which it controls over USB), and most slicers can automatically export the gcode to an OctoPrint instance.

While OctoPrint itself is great, there was one small problem: if you connect anything to the USB port on the printer, it tries to draw 5V from it and “backpower” itself. It’s not meant to draw power from the USB port, it’s just not designed well. A lot of the cheaper 3D printers share this flaw, it seems. The fix here is to get a power blocker such as the one made by PortaPow that simply leaves the +5V line unconnected between the two ends. Presumably Sovol could fix this by adding a diode to the USB power line, but maybe that would push their costs too high?

After getting OctoPrint working, I printed a nice case for it to mount on the side of the printer. I slotted the Pi in, and when I powered it on again it didn’t boot. When I went to pick it up to debug the problem, I burnt my finger on the SD card⁵. Apparently if you break SD cards in a certain way, they can short out and get very hot. Fun! Maybe I shouldn’t have been using the no-brand card that came with the printer…

What do we do with a drunken bed?

I continued printing bits and bobs, but was starting to notice a new issue: if I was printing multiple copies of the same object, those on the right hand side of the bed often failed. OctoPrint has a nifty plugin that lets you cancel certain regions from the build, which saves it ruining everything, but only being able to print in certain places was annoying.

I ran through all the troubleshooting steps I could think of, including a foray into custom firmware with different bed levelling abilities, but nothing seemed to help. Another OctoPrint plugin later and I could see the problem:

This should probably be straight.

The orientation of the graphic is a bit confusing, but you can see how the right hand side of the bed is significantly higher than the left. There’s a total variance of just over 0.5mm, which is apparently enough to cause problems even with the auto bed levelling. I spoke to Sovol support, and eventually they suggested disassembling the print bed and measuring the aluminium spacers that hold the bed. Sure enough, they were all different heights:

You had one job…

There’s a 0.13mm variance in their heights, which doesn’t account for the 0.5mm seen in the bed mesh, but it’s a good starting point. Rather than go back and forth with Sovol support over the course of many days, I just ordered some nylock nuts and reinstalled the bed without spacers. The nuts hold the bed in place, while still allowing you to tighten or loosen the screws to adjust the height.

After five or six rounds of totally and utterly uneventful adjusting and re-leveling, I got to this point:

This is much more straight.

There’s only so much you can do when you only have five screws to adjust, but I’m pretty happy the variance is now under 0.15mm. That’s definitely in the “good enough” range that the bed leveling algorithm can compensate for.

Whoops

So, about that “totally and utterly uneventful adjusting” I did. To get at the screws that hold the bed in place, you have to remove the thin sheet that acts as the build surface. This attaches magnetically to the bed, so it’s easy to do, but I am lazy and decided to leave it off while I fiddled with the bed.

There’s a slight problem here, though: when it’s working out the bed mesh the printer uses the inductive proximity sensor. The inductive proximity sensor detects metal. The metal is in the removable sheet. The first time I tried to run the bed mesh, the printer rammed the extruder assembly into the bed at a decent speed and ended up at a rather nasty angle.

I checked over the extruder and found the heat break had bent:

This should also probably be straight.

I tried printing with it as-is, but the filament came out too thin and at an angle, which made the print go about as well as you’d expect. I ordered a replacement, installed it, and… nothing worked still.

At this point I was getting thoroughly fed up. There seemed to be one problem after another, and no good way to diagnose problems with the print not sticking (because there are a dozen or so different potential causes). After a lot of frustrated googling, I found a post on the Prusa forums that suggested cleaning the build sheet with dish soap. I’d cleaned it with IPA, but several people were saying that dish soap magically fixed issues that IPA couldn’t. I took the plate to the kitchen, gave it a wash, and the next print went down perfectly.

Growing a backbone

For a blissful period of about four days the printer was chugging along perfectly with no issues. Then it started making a weird noise. In a display of amazing restraint, I didn’t immediately throw the whole thing out the window. Looking at the printer, I could see that the cable running from the extruder assembly to the main board was sagging and rubbing on top of the print as the print head was moving around. I’m not sure what property of the cable was keeping it aloft before, but it apparently ran out after about three weeks.

Like most of the other problems with the SV06, this design flaw has been noted by others and worked around. I printed a cable chain and installed it⁶. Amusingly, while I was printing the chain, the cable dragged on the print and dislodged one of the pieces entirely before it was finished. Fortunately, it didn’t affect the neighbouring pieces, so I just had to run off a replacement for that one.

The difference is rather pronounced:

It feels like I own a 3D printer to print parts for my 3D printer…

If you can’t see it: in the first image the cable is sagging and actually ends up below the print bed. The individual links of the cable chain limit its freedom of movement, stopping it sagging.

The end?

Once again the printer is printing properly again. 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…

I think, if I had to do this all again, but with the knowledge I have now, I’d have stumped up the extra cash to get a Prusa MK3S+⁷. This is the original machine on which the SV06 (and a lot of other cheap imitations) is based. Some obvious benefits it has over the SV06:

The extruder cable runs on the outside of the machine, so won’t droop onto prints
The heated bed has copper embedded in it for use in the induction sensor, so it won’t crash into the bed if the build sheet is removed
They actually put lubricant in the bearings instead of shipping them bone dry
The bed is held in place with screws instead of poorly sized aluminium spacers, so you can adjust the height without having to take the whole thing apart
They don’t use the cheapest possible power supply and main board, so it doesn’t backpower off of USB devices or have the loudest fans known to mankind

Prusa also have a much better attitude towards 3D printing: they open source the hardware designs (which is why there are so many cheap clones), and they actually use the printers themselves. The plastic parts of an SV06 are injection moulded, but those on a Prusa printer are actually printed on a Prusa printer. Not only is it cool that they use their own products, it means they have to run them en-masse so they’re obviously invested in making them reliable. They also have a reputation for exceptional support.

Despite all the problems, I do enjoy having the printer. I’ll probably talk more about the prints I’ve done that weren’t for the 3D printer itself in the future.

The RRP is £279.99, Amazon discounted it down to £269.99 then offered a £70 voucher. The voucher says it expires at midnight, but it’s said that every day for the past three weeks… ↩︎
Which is exactly what another set of people said would happen. It was worth a try, though. ↩︎
This feels strange, but if you work out the areas of the nozzles it makes sense: a 0.4mm diameter nozzle has an area of 0.04πmm² (the radius is half the diameter, and the area of a circle is πr²), and a 0.6mm diameter nozzle has an area of 0.09πmm². Maths! ↩︎
At least it doesn’t eject the SD card across the room like this Ender 3 V2! ↩︎
My only 3D printer related injury so far. It’s impressive I can be around a 200 degree hot-end and somehow burn myself on a storage device. ↩︎
Well actually I printed 5 copies of their calibration piece until it was perfect, then printed the actual cable chain, then had to sand each of the individual links because they still weren’t good enough. God, I hate sanding. ↩︎
Or maybe I’d cave and get the newer, shinier, much more expensive MK4. That wouldn’t be out of character. No, I didn’t just check my bank balance. You’re imagining things. ↩︎