DEV Community: Emir Mrkaljević

"Make the hole 2 mm bigger" is now one command for an STL you converted to CAD

Emir Mrkaljević — Sun, 01 Nov 2026 19:10:41 +0000

When I started mesh2cad, the sentence I kept in my head was "make the hole 2 mm bigger". You have an STL of a bracket, the hole is a little too tight for your bolt, and the original CAD file is gone. Editing triangles is miserable, so mesh2cad fits the mesh and writes a CadQuery, OpenSCAD or FreeCAD script with named numbers at the top.

That got you a file where hole_1_d = 10.0 was sitting right there. You still had to open it, find the line, change it, run the script and hope the result was sane. 0.17.0 closes that loop with two commands: params and edit.

pip install -U "mesh2cad[cadquery]"
mesh2cad convert bracket.stl --cadquery bracket.py
mesh2cad params bracket.py
mesh2cad edit bracket.py --set hole_1_d=+2 --output-script bracket_12.py -o bracket_12.step

What you can change

The demo part is a 50 x 30 x 6 mm plate with rounded corners, a 10 mm hole in the middle and two 5.5 mm holes for M5 bolts. After convert, params prints this (real output):

name      value  kind      unit  note
base_x    50.0   length    mm    base length (X)
base_y    30.0   length    mm    base width (Y)
base_t    6.0    length    mm    base thickness (Z)
base_cx   0.0    position  mm
base_cy   0.0    position  mm
base_z0   -3.0   position  mm    bottom face height
fillet_r  3.0    radius    mm    vertical corner radius
hole_1_d  10.0   diameter  mm    diameter
hole_1_x  0.0    position  mm
hole_1_y  0.0    position  mm
hole_2_d  5.5    diameter  mm    diameter
hole_2_x  -15.0  position  mm
hole_2_y  0.0    position  mm
hole_3_d  5.5    diameter  mm    diameter
hole_3_x  15.0   position  mm
hole_3_y  0.0    position  mm

It works the same on .py, .scad and .FCMacro files, because all three backends use the same names.

Making the hole 2 mm bigger

A value with a leading + or - is a delta, a plain number is an absolute value:

$ mesh2cad edit bracket.py --set hole_1_d=+2 --output-script bracket_12.py -o bracket_12.step
hole_1_d: 10.0 -> 12.0 (diameter, mm)
volume: 8197.31 -> 7989.96 mm^3 (delta -207.35)
bbox min: [-25.000, -15.000, -3.000] -> [-25.000, -15.000, -3.000]
bbox max: [25.000, 15.000, 3.000] -> [25.000, 15.000, 3.000]
valid solid: yes
wrote script bracket_12.py
wrote bracket_12.step

The volume delta is a quick sanity check you can do by hand: a ring between 10 mm and 12 mm through 6 mm of plate is pi x (36 - 25) x 6 = 207.35 mm^3. The bounding box did not move, which is what you expect when only a hole changes.

The script diff is exactly one line:

< hole_1_d = 10.0  # diameter
---
> hole_1_d = 12.0  # diameter

edit replaces the number and leaves every other byte alone, so the file stays readable and you can keep editing it by hand. You can pass several --set flags at once, for example opening both bolt holes for M8 clearance:

$ mesh2cad edit bracket.py --set hole_2_d=+4 --set hole_3_d=+4 -o b2.step
hole_2_d: 5.5 -> 9.5 (diameter, mm)
hole_3_d: 5.5 -> 9.5 (diameter, mm)
volume: 8197.31 -> 7631.82 mm^3 (delta -565.49)
...
valid solid: yes
script unchanged on disk
wrote b2.step

Without --in-place or --output-script, the script on disk is not touched and you only get the new solid.

Edits that cannot work are refused

I cared more about this part than about the happy path. A 40 mm hole in a 30 mm wide plate is not a part:

$ mesh2cad edit bracket.py --set hole_1_d=40 -o bad.step
hole_1_d=40.0 does not fit: the hole is larger than the wall it sits in (30.0 mm on the shorter side)
$ echo $?
2

Nothing is written. The same goes for a counterbore that no longer clears its through-hole, a fillet that eats the short side of the base, a draft that closes a boss, an unknown parameter name (the error lists the names that exist), or a render that is empty or not one valid solid.

For agents: list_params and edit_params

The MCP server got the same two tools. list_params(script_path) returns the table above as data, and edit_params(script_path, changes, output_path?) takes something like {"hole_1_d": "+2"} and returns old and new values, validity, the volume and bounding-box delta, and warnings. So in Claude Desktop or Cursor you can literally say "make the hole 2 mm bigger" about an STL and the agent has a safe, checked way to do it instead of rewriting the script itself.

{ "mcpServers": { "mesh2cad": { "command": "mesh2cad", "args": ["mcp"] } } }

Limits, plainly

It only edits scripts mesh2cad generated. A hand-written CadQuery file is refused.
The fit-checks are the obvious ones (does the hole fit in that face), not a constraint solver.
Outline and cutout point lists are listed but not edited as one number. Moving a corner of an outline is still a text edit.
Simple parts give short, readable parameter lists. Complex ones do not: the Prusa MK3S Y belt holder converts to a valid script, but with 282 parameters, most of them small cut positions and lengths. You can edit them, but nobody would call that list friendly yet.
OpenSCAD and FreeCAD need the openscad and freecadcmd programs on PATH to render. Without them the script is still rewritten and the command says the solid was not rendered.
It is not a PartDesign body or a constrained sketch. The number changes, and the same script runs again.

If you want to try it without installing anything, the gallery on Hugging Face has precomputed Prusa parts with STEP, CadQuery and OpenSCAD downloads. Issues with STLs that do not convert are the most useful thing you can send me: github.com/emirmrkaljevic/mesh2cad.

What a real user's USB capture found that my synthetic tests didn't: two bugs in usb-rea

Emir Mrkaljević — Sun, 01 Nov 2026 13:06:46 +0000

For weeks every test of usb-rea ran on captures I generated myself, on protocols documented by liquidctl and rivalcfg, and on a few public Wireshark samples. All of that passed. Then a real user shared a real capture, and within a day it had found two bugs that none of my tests could have found.

This is the fifth post about usb-rea, an open-source tool I built that diffs USB captures per labelled click in a vendor app and writes a pyusb driver. The first one covered commands, the second one naming what the device reports back, the third one handshakes and session tokens, the fourth one video streams to case LCDs. This one is about what happened when the tool met hardware I don't own.

The capture

On liquidctl issue 936 the owner of an ASUS TUF Gaming LC III AIO (the one with an LCD on the pump) shared a USBPcap capture from Windows while changing the screen brightness in the vendor app. The full capture is big: about 76,000 packets, nearly all of them a 320x320 JPEG video the app streams to the screen at around 70 frames per second, plus four tiny brightness writes hidden in between.

That capture is what pushed me to add image stream detection in v0.7.4 (the fourth post). After that, the full capture gave the right answer: brightness is byte 4 of a 440-byte message on interrupt EP 0x01, the video goes to EP 0x03 with a 08 nn 00 80 header, and the device acks each frame with 08 81 on EP 0x84. That matched what the owner had worked out by hand.

Then I asked if I could keep a trimmed copy as a regression test. They said yes, and turning it into a test is where the two bugs showed up.

Making a fixture you can publish

A raw capture is not something to commit to a public repo. It has other devices on the same bus, and the video frames are literally whatever was on the screen. So the stored copy:

keeps only this device's packets: the setup, the first 8 frames and two frames on each side of each brightness change (589 packets, 6.5 KB gzipped)
zeroes the image data in every frame, keeping only the JPEG headers and the end marker, so nothing that was on the screen is in the file
shifts the timestamps to a fixed date and replaces the IRP ids with counters

The test in tests/test_user_capture_lc3.py then checks the VID:PID, the brightness command and the stream end to end. The first run failed twice.

Bug 1: USBPcap puts the control reply in the "complete" record

usb-rea finds the vendor and product id from the GET_DESCRIPTOR reply at the start of a capture. On this file it said there wasn't one. Here is what v0.7.5 printed at the top of the report:

Device: `unknown (no GET_DESCRIPTOR in capture)`

But the reply is right there. This is the real output of usb-rea transfers on the fixture (first two lines):

     1 dev   2 ep 0x80 control   IN  8006000100001200 |
     2 dev   2 ep 0x80 control   IN  12 01 10 01 00 00 00 40 05 0b 7b 1c 51 00 01 02 03 01

USBPcap logs a control transfer in stages. Frame 1 is the setup stage (80 06 00 01 ..., GET_DESCRIPTOR for the device descriptor). The descriptor itself (12 01 ..., with 05 0b 7b 1c being 0B05:1C7B little-endian) arrives in a separate record for the "complete" stage, stage 3. My parser only took control IN data from the stage it expected, so on captures where the data comes in stage 3 the descriptor was simply dropped. My own synthetic USBPcap files never did that, which is exactly why the tests never caught it.

v0.7.6 reads control IN data from the complete record too. Same file, new report:

Device: `0b05:1c7b`

Bug 2: counting the ack over the whole capture

The second failure was quieter. v0.7.5 found the video stream and the brightness command, but no frame ack. Worse, the 08 81 acks didn't just disappear: they ended up in the report as a "reply to brightness", because a couple of them happened to arrive a few milliseconds after a brightness write.

The old rule was: a fixed device-to-host message is the ack if it shows up about once per frame over the whole capture (between 0.5x and 1.2x the number of frames). On the full capture that held. On the trimmed one it didn't: the fixture keeps the acks for frames I cut out, so it has 66 acks for 24 frames. That's an artefact of trimming, but the same thing happens on a real capture whenever the app keeps polling while it pauses the video, and a global ratio can't tell the difference.

v0.7.6 counts the ack per frame instead: a fixed device-to-host message between one frame's start and the next (and no more than 1 s after the frame's last packet). It's the ack when at least half of the frames have one and most of those have exactly one. The new frames_acked field says how many frames it was seen for. The report now has this line in the stream section (real output on the fixture):

- Ack: `08 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00` on EP 0x84, 66x (frames 30, 52, 94, 116, 138)

And because the acks are set aside with the stream, the bogus "Reply to brightness" section is gone. Summarised from the usb-rea infer JSON of both versions on the fixture, same labels:

0.7.5  vid/pid None None   ack None                     responses 1
0.7.6  vid/pid 2821 7291   ack EP 0x84, frames_acked 18 responses 0

(2821 and 7291 are 0x0B05 and 0x1C7B.)

What the trimmed copy can't tell you

Some numbers in the fixture report are about the trimming, not the device, and I'd rather say so:

The frame rate shows as about 0.2 frames per second, because most frames were cut out. The full capture is around 70.
The brightness command comes out at 60% confidence from two clean samples (brightness 0 and brightness 50); the third action is ignored because it sent a differently shaped transaction. On the full capture it's 100%.
The image content is zeros, so the fixture can't test anything that depends on the pixels.

What it does test is everything the bugs were about: the device descriptor in a USBPcap complete record, the stream headers, the per-frame ack, and the brightness byte on its own endpoint.

Try it

pip install -U usb-rea          # 0.7.6
usb-rea demo --device lcd

To run it on the same fixture from a clone of the repo:

gunzip -c tests/data/asus-tuf-lc3-lcd.pcap.gz > lc3.pcap
usb-rea report lc3.pcap -l "brightness 0;brightness 50;brightness 100" -o lc3.md

The lesson for me: synthetic captures test the inference, real captures test the assumptions about how capture tools write files. If you have a USB device whose app only runs on Windows, one USBPcap capture while you change one setting is the most useful thing you can send. Device requests are open: https://github.com/emirmrkaljevic/usb-rea

Thanks to the owner of the LC III who shared the capture and agreed to the trimmed copy being kept as a test.

I built usb-rea with help from AI coding tools; the inference itself is deterministic and every claim in its reports points at captured frames.

From STL to an editable FreeCAD macro: change one number, run it again

Emir Mrkaljević — Sat, 31 Oct 2026 19:10:47 +0000

mesh2cad turns an STL into CAD. Every part gets a STEP file with real planes, cylinders and cones. When the part is simple enough it also gets a script with named parameters, so "make the hole 2 mm bigger" is one edited number instead of an afternoon of mesh surgery.

Until now that script was CadQuery or OpenSCAD. A lot of people who print parts use FreeCAD, though, and asking them to install CadQuery just to change a hole felt wrong. So 0.16.0 adds a third output: a FreeCAD macro.

pip install -U mesh2cad
mesh2cad convert plate.stl --freecad plate.FCMacro
freecadcmd plate.FCMacro

What the macro looks like

For a 40 x 30 x 6 plate with a 10 mm hole, the part that matters is this:

# --- parameters ---
base_x   = 40.0  # base length (X)
base_y   = 30.0  # base width (Y)
base_t   = 6.0  # base thickness (Z)
base_cx  = 0.0
base_cy  = 0.0
base_z0  = -3.0  # bottom face height
hole_1_d = 10.0  # diameter
hole_1_x = 0.0
hole_1_y = 0.0

# --- model ---
result = Part.makeBox(base_x, base_y, base_t, App.Vector(base_cx - base_x / 2, base_cy - base_y / 2, base_z0))
top = base_z0 + base_t
result = result.cut(Part.makeCylinder(hole_1_d / 2, base_t + 2, App.Vector(hole_1_x, hole_1_y, base_z0 - 1), App.Vector(0, 0, 1)))

Set hole_1_d = 12.0, run the macro again, and you have a Part::Feature with the bigger hole plus a fresh plate.step next to the macro. The cylinders and cones are analytic in FreeCAD, not $fn polygons like in OpenSCAD.

The parameter names are the same as in the CadQuery and OpenSCAD scripts (base_t, hole_1_d, hole_1_cbore_d, fillet_r, extrude_len, outline, cut_1, clip_1_d), so if you compare outputs side by side they line up. Under the hood it is FreeCAD's Part API: makeBox, makeCylinder, makeCone, a polygon extruded along X, Y or Z, fuse / cut / common, and makeFillet on the four vertical corners of a rectangular base.

It is checked before it is written

This is the rule I care about most in this project. A script that looks plausible but builds the wrong part is worse than no script.

So mesh2cad runs the macro with freecadcmd, meshes the resulting solid finely, and compares it with the input STL. The gate is the same as for the other two exporters: maximum deviation at most max(4 x tol, 0.1 mm), and volume error at most 1%. If the part is outside the supported shapes, or the solid misses, nothing is written and the command exits with code 2 and says why.

FreeCAD is not a Python dependency. If freecadcmd isn't on your PATH, the macro is still written, but the command tells you it is unverified.

Six real printer parts

I test on six printed parts from the Original Prusa i3 MK3S (Prusa Research's files, GPL-2.0). All six now export a FreeCAD macro that passes the check:

part	FreeCAD macro deviation	limit
plug-aligner	0.0000 mm	0.1 mm
endstop-block	0.0421 mm	0.1 mm
y-belt-idler	0.1693 mm	0.192 mm
y-belt-holder	0.0896 mm	0.154 mm
y-motor-holder	0.1843 mm	0.266 mm
y-rod-holder	0.1300 mm	0.138 mm

Each also stays under 1% volume error. Four of them match the CadQuery deviation exactly. The idler is a little farther from the mesh than the CadQuery script, and the belt holder is slightly closer than both other exporters.

The honest limits

The macro is a plain Part script, not a PartDesign body with constrained sketches. Editing means changing a number at the top and running it again. You don't get a feature tree you can click through.
It covers the same shapes as the other exporters: boxes, extruded outlines, holes and counterbores, 45 degree chamfers, drafted bosses, planar clips, fillets on four vertical corners. A boss on an extruded outline, a sphere, or a region that wasn't fitted is refused, and the message says which.
Six boxy parts from one printer is a small test set. Organic shapes, fillets everywhere and scanned meshes still get STEP at best.

For AI agents too

mesh2cad is also an MCP server (pip install "mesh2cad[mcp]", then mesh2cad mcp). There is a new to_freecad(input_path, output_path?, tol?) tool next to to_cadquery and to_openscad. It returns the parameters and, when FreeCAD ran it, the measured deviation, or verified: false when freecadcmd is missing.

If you want to see the before and after without installing anything, there is a small gallery on Hugging Face with precomputed parts.

If you try it on a part of your own and it gets refused, I'd like to see it. Open an issue with the STL (or a link) and I'll look at what is missing.

How to spot shrinkflation at Lidl and Carrefour online

Emir Mrkaljević — Sat, 31 Oct 2026 10:04:16 +0000

Shrinkflation rarely shows up on the price tag. The price stays at €2.49, but the pack goes from 500 g to 450 g. That is an 11.1% price rise per kilogram, and the only clue is a small number on the label.

Here is a simple routine for spotting it when you shop online at Lidl or Carrefour, plus a free tool that does the boring part for you.

1. Compare the price per kg or litre, not the pack price

EU shops must show a unit price next to the selling price (Directive 98/6/EC). On Lidl it usually appears under the price as "1 kg = 7.12 €". On Carrefour France it sits near the price as "€/kg" or "€/L".

The unit price is the only fair way to compare a 450 g pack with a 500 g one. If it is missing, divide the price by the pack size yourself: €2.49 / 0.45 kg = €5.53 per kg.

2. Watch multipacks

"6 x 1 l" or "4 x 125 g" packs are where mistakes happen. Check that the unit price uses the total size (6 l, 500 g), not a single item.

3. Remember what the pack used to be

This is the hard part. Neither shop tells you that the same product was bigger last month. You either remember it or you keep notes.

4. Let your browser remember for you

ShrinkWatch EU is a free, open-source extension for Chrome, Edge and Firefox. On a product page it:

shows the unit price in a small badge, worked out from the price and pack size,
cross-checks the shop's own unit price and shows it when the two disagree,
saves the pack size locally and warns you if the same product comes back smaller.

It was checked in a real desktop Chrome on Lidl in Germany, France, Spain, Italy, Poland and the Netherlands, and on Carrefour in France, Spain, Belgium and Poland. Lidl Germany works right after install; for the other sites you click "Enable on this shop" once in the popup. Some examples from those checks:

lidl.fr, olive oil 1.5 l: €5.66 / l, matching the shop's own figure
lidl.it, butter 125 g: €7.12 / kg
carrefour.fr, 1 l of milk: €1.26 / l
carrefour.pl, 1 l of milk: 4.49 zł / l

If a page prints the pack size only on the product photo, the badge shows the price and says the pack size is missing, so you know to check the label.

Privacy

No account, no analytics, no network requests. Prices and pack sizes stay in your browser.

Try it

Install steps: https://emirmrkaljevic.github.io/shrinkwatch-eu/#install
Lidl guide: https://emirmrkaljevic.github.io/shrinkwatch-eu/shops/lidl.html
Carrefour guide: https://emirmrkaljevic.github.io/shrinkwatch-eu/shops/carrefour.html
Source and issues: https://github.com/emirmrkaljevic/shrinkwatch-eu

Found a product with a wrong figure? Open an issue with the link and it will be fixed.

This post was written with AI assistance and checked by me against the extension running on the shops.

Telling a video stream to a case LCD apart from the commands: JPEG and raw RGB565 in USB captures

Emir Mrkaljević — Fri, 30 Oct 2026 18:06:48 +0000

Capture the USB traffic of an AIO cooler with a screen on the pump cap, change the brightness four times in the vendor app, and diff the clicks. What you expect is one small command with one byte that follows the slider. What you get is tens of thousands of 1 KB packets, because the app never stops sending the picture to the screen while you click.

This is the fourth post about usb-rea, an open-source tool I built that diffs USB captures per labelled click and writes a pyusb driver. The first one covered commands, the second one naming what the device reports back, the third one handshakes and session tokens. This one is about screens.

The weakness a real capture showed

A user on liquidctl issue 936 shared a public USBPcap capture of an ASUS TUF LC III LCD while changing the brightness. It was the first real capture of that kind I had run usb-rea on, and the old version got it wrong in an instructive way: the video packets landed inside the brightness actions, and the "brightness" usb-rea reported was made of image bytes.

The diff wasn't broken. It did exactly what it was told: find the bytes that change with the label. In a capture full of video, video bytes change with everything.

So since v0.7.4 usb-rea sets image streams aside before anything else runs. On that capture the stream turned out to be a 320x320 JPEG video on its own endpoint, and once it was out of the way the brightness command was easy: byte 4 on EP 0x01 is the percentage.

Encoded images: look for the magic bytes

JPEG, PNG and GIF are the easy case because every image starts with a known marker (FF D8 FF for JPEG). The rule:

On one host-to-device channel, at least 3 packets start an image at the same offset. That offset is the per-packet header length.
A frame runs from its start packet to the image's end marker (JPEG FF D9, counting embedded thumbnails so an EXIF preview doesn't end the frame early), the next start, or a pause.
Each header byte is constant, nn (number of packets in the frame) or ii (index of the packet in the frame).
A fixed device-to-host message sent about once per frame is the ack.

Here is the synthetic LCD from the demo, which streams a 240x240 JPEG video next to its brightness command. This is the real output of usb-rea demo --device lcd, with the 64-byte brightness line trimmed:

captured 5 labelled actions, device 1234:abcd

brightness   100%  0x12 | 0x01 | 0x00 | 0x80 | round(value * 1 + 0) | 0x00 | 0x00 | ...

image stream, kept out of the commands: jpeg stream on interrupt EP 0x03: 240x240, 159 frames in 950 packets of 512 bytes, header `08 nn 00 80` then `08 ii 00 00`; ack 08 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 on EP 0x84 (driver: send_image())

and the matching part of report.md:

- Frames: 159 (3 to 8 packets each, 950 packets in all, 2 of them from a frame cut off by the capture)
- Image size: 240x240, 1507 to 3985 bytes
- Rate: about 20 frames per second
- Chunk: 512 bytes per packet, the last one padded
- Header (4 bytes): first packet `08 nn 00 80`, then `08 ii 00 00`
- Ack: `08 81 00 00 ...` on EP 0x84, 160x (frames 8, 18, 28, 42, 54)

The image size comes from the JPEG SOF marker, so you also learn the panel resolution for free.

Raw pixels: no magic, so look at the size

Plenty of cheap case screens don't take JPEG at all. They take plain pixels: RGB565 (2 bytes per pixel) or RGB888 (3 bytes), usually behind a short "draw" command. Nothing in those bytes says "image". This is now on main (not released yet), and the trick is arithmetic:

Group packets on one channel into runs: large packets with no pause between them, all but the last the same length.
A run is a frame when its payload is exactly width x height x bytes per pixel for a common screen size (80x160 up to 1920x480, both orientations).
Or, better, when the short packet sent just before the run names a region and the payload is exactly that region. usb-rea tries x, y, width, height and x0, y0, x1, y1 as 16-bit fields in either byte order, plus four 10-bit fields packed into 5 bytes.
Three or more frames make a stream. The draw commands go with the pixels; other short commands on the same endpoint stay commands.

The region version matters because these screens rarely redraw everything. A clock or a temperature readout is a small rectangle sent every second, and without the region those frames would look like random large commands.

Output of usb-rea demo --device lcd --raw rgb565, where the synthetic screen is 160x128 and every 4th frame only redraws a 48x16 clock:

image stream, kept out of the commands: raw rgb565 little-endian stream on bulk EP 0x02: 160x128, 79 frames (20 redraw part of the screen) in 4937 packets of 512 bytes, each frame after a command `55 aa 02 00 xx xx yy yy ww ww hh hh`; ack 55 aa 82 00 on EP 0x82 (driver: send_image())

and from the report:

- Screen: 160x128 RGB565, 40960 bytes (2 per pixel) per full frame
- Pixel byte order: little-endian (neighbouring pixels are smooth that way)
- Region: the command gives x, y, width, height as 16-bit little-endian fields from byte 4; 20 of 79 frames redraw only part of the screen

The byte order line is my favourite small heuristic in this release. RGB565 can be sent little or big endian, and the capture doesn't say which. But real pictures are smooth: neighbouring pixels have similar colours. So usb-rea decodes a frame both ways and keeps the order where neighbours differ less. On a flat colour it says it can't tell instead of guessing.

As a ground truth I wrote a test fixture from the public description of the Turing Smart Screen rev A protocol: 6-byte commands with x, y, end x and end y packed as 10-bit fields, DISPLAY_BITMAP = 197, then RGB565 little-endian pixels. usb-rea finds the 320x480 stream, the draw command rr rr rr rr rr c5 (rr = packed region), the partial redraws, and leaves the hello, orientation and brightness commands on the same endpoint alone.

16-bit header fields

Raw frames are big. A 128x160 RGB888 frame in 64-byte packets is 1024 packets, which doesn't fit a one-byte counter, so devices use 16-bit ones. The header description now reads a count or index above 255 as a u16 and shows it doubled, with its byte order: 00 00 nn nn, then ii ii nn nn. The driver fills both bytes in.

The driver side

The generated driver gets send_image(). For a JPEG stream you pass JPEG bytes of the captured size. For a raw stream you pass a Pillow image (converted to RGB565 in the captured byte order) or bytes already in the stream's format, and if the app used region commands you can redraw just part of the screen:

from PIL import Image
from lcd_driver import Device

d = Device()
d.send_image(Image.open("wallpaper.png").resize((160, 128)))
d.send_image(clock_pixels, x=100, y=8, size=(48, 16))   # just the clock

Pillow is optional; the driver doesn't import it.

What it can't do (yet)

A screen size that isn't in the list and has no region command is missed.
The same byte count can fit several shapes: 320x480 RGB565 is also 480x320, and 320x320 RGB888. The report lists the alternatives so you can check on the device.
Region fields are only looked for in the separate draw command, and width is expected before height.
RGB888 channel order (RGB or BGR) is not worked out, and streams split over several endpoints are not detected.
A frame with a pause longer than 30 ms inside it gets split.

Try it

pip install -U usb-rea          # 0.7.5
usb-rea demo --device lcd
usb-rea demo --device lcd --raw rgb565

It's also an MCP server (usb-rea mcp), and the streams field in its output carries all of the above. Sending anything to real hardware still needs explicit confirmation from a human.

If you own a case or AIO screen whose app only runs on Windows, a capture while you change one setting would help a lot, especially raw-pixel ones. Issues are open: https://github.com/emirmrkaljevic/usb-rea

I built usb-rea with help from AI coding tools; the inference itself is deterministic and every claim in its reports points at captured frames.

Six of six: the last printer part that my STL to CAD tool refused now gets an editable script

Emir Mrkaljević — Thu, 29 Oct 2026 19:04:12 +0000

mesh2cad turns an STL into CAD. Every part gets a STEP file with real planes, cylinders and cones. When the part is simple enough it also gets a CadQuery or OpenSCAD script with named parameters, so you can change hole_3_d instead of editing triangles. Before any script is written, it is rebuilt and compared to the mesh, and it is refused if it misses.

I test on six real Original Prusa i3 MK3S parts. In the last post five of them had a script and one was refused. With 0.15.0 all six do.

Why y-belt-holder was refused

The script exporter builds a solid from outlines of the part seen along X, Y and Z, and intersects them. That works when each feature runs through the whole part. y-belt-holder breaks that in several ways at once:

the base is full height for part of the length and then steps down to a thin guide
a hexagonal nut pocket and a bore exist for only part of the length
five slits are only 0.2 mm thick
the belt teeth, including a few small B-spline patches, move along X

A silhouette taken along the full length fills every opening that exists for only part of it. The result was 2.517 mm off with a 1.97% volume error, against a limit of 0.154 mm and 1%. So it got exact STEP and no script.

What changed

When the three earlier approaches (silhouette intersection, partial-depth union, wall-snapped rebuild) have all missed, 0.15.0 tries one more:

start from one bounding extrusion along the axis where the part changes
split the length into spans where the outer cross-section stays within 0.05 mm of itself
on each span, cut the extrusion back to the real section (cut_N, with the kept section as cut_N_cutout_J)
a gap between two parallel faces from 0.12 mm to 0.55 mm becomes a polygonal cut, which covers the thin slits
an inner loop that keeps its place along the axis, like the hex pocket or the bore, becomes a polygonal cut over its span

A part that already passes with a simpler solid never reaches this step, so the other five results did not move.

The numbers

The gate is the same as before: max deviation at most max(4 x tolerance, 0.1 mm), volume error at most 1%.

part	exact STEP	script (CadQuery / OpenSCAD)
plug-aligner	0.0000 mm	0.0000 / 0.0000 mm
endstop-block	0.0168 mm	0.0421 / 0.0421 mm
y-belt-idler	0.0082 mm	0.1534 / 0.1639 mm
y-motor-holder	0.1001 mm	0.1843 / 0.1843 mm
y-rod-holder	0.2178 mm	0.1300 / 0.1300 mm
y-belt-holder	0.1602 mm	0.0943 / 0.0965 mm (was refused at 2.517 mm)

The y-belt-holder scripts have a 0.70% volume error, under the 1% limit but higher than the other parts. The new tests are a small synthetic bar that steps down along X, with a hexagonal tunnel and a 0.3 mm slit, checked in both exporters.

What "editable" means on this part

I want to be honest here. On the simpler parts most of the geometry is named: hole diameters, depths, chamfers, counterbores. On y-belt-holder the overall size, the bore and the spans are clean numbers, but the belt teeth and the slits come out as polygon points inside a cut. You can move them, and the script is far easier to change than a mesh, but you won't get a tooth_pitch parameter. Recognising repeated features like teeth is a separate problem I haven't solved.

Six parts is also a small test set, all from one printer and all fairly boxy. Organic shapes, fillets everywhere and scanned meshes still get STEP at best, and often not even a clean one.

Try it

pip install -U mesh2cad
mesh2cad convert part.stl -o part.step
mesh2cad convert part.stl --openscad part.scad

It also runs as an MCP server (mesh2cad mcp), so an assistant can convert a part and change a parameter for you. If you have an STL of a simple mechanical part that fails, an issue with the file attached helps most: github.com/emirmrkaljevic/mesh2cad.

I built a userscript and Firefox add-on that checks if EU discounts are real

Emir Mrkaljević — Thu, 29 Oct 2026 09:09:14 +0000

Every November the same thing happens: prices go up a little in October, then "drop" by 40% for Black Friday. In the EU there is actually a rule against this. I built truediscount to make that rule visible while you shop.

The rule: Omnibus 30-day lowest price

Since 2022 the EU Omnibus Directive (Article 6a of the Price Indication Directive) says that when a shop announces a price reduction, the "before" price must be the lowest price it charged in the previous 30 days. Not the RRP, not a price from last spring. Many shops now print this "lowest price in the last 30 days" somewhere on the page, often in small grey text far from the big red percentage.

So the honest discount is: (30-day lowest price minus current price) divided by the 30-day lowest price. Sometimes that number is much smaller than the badge. Sometimes it is zero or negative.

What truediscount does

Finds the current price, the advertised "was" price and the 30-day lowest price on a product page
Recalculates the discount against the 30-day lowest price and shows it next to the shop's claim
Keeps a small local price history so you can see a graph of prices you have already seen
Stores everything locally in the browser. No account, no server, no tracking

Three ways to install

Userscript (Greasy Fork). If you already use Tampermonkey, Violentmonkey or similar, this is the fastest option: https://greasyfork.org/en/scripts/602599-truediscount-is-this-discount-real

Firefox add-on. The add-on is currently in review on addons.mozilla.org. Until it is approved you can grab the Firefox zip from the GitHub releases.

Chrome-based browsers. Load the Chrome zip from the releases page as an unpacked extension.

A few things I learned

Price parsing is the hard part. "1.299,00 €", "€1,299.00" and "1 299,00 zł" all need to end up as the same number. I normalise by locale and treat the last separator followed by exactly two digits as the decimal mark.
Shops phrase the 30-day price differently in every language. "Niedrigster Preis der letzten 30 Tage", "prix le plus bas des 30 derniers jours", "najniższa cena z 30 dni" and so on. The extension keeps a list of phrases per language and searches near the price block.
One codebase, several targets. The MV3 extension and the userscript share the detection code. A small build script produces the Firefox zip, the Chrome zip and the .user.js from the same source.
Local-only is a feature. Not having a backend made the privacy policy short and the review process simple.

Try it, break it

The code is MIT licensed: https://github.com/emirmrkaljevic/truediscount

If you find a shop where detection fails, an issue with the product URL is the most helpful thing you can send. Happy (honest) Black Friday shopping.

AI tools helped with editing this post.

How to validate a list of LEI codes in bulk with the free GLEIF API (Python)

Emir Mrkaljević — Thu, 29 Oct 2026 09:03:31 +0000

If you work with counterparties, suppliers or KYC data, you've probably got a spreadsheet column full of LEIs (Legal Entity Identifiers, the 20-character IDs every regulated company needs to trade). Some of them are typos, some belong to companies that closed, and some lapsed because nobody paid the yearly renewal. GLEIF, the foundation that runs the global LEI system, publishes all of this through a free JSON API with no key, so checking a whole list takes one short script.

1. Catch typos before calling any API

An LEI is 18 letters or digits followed by 2 check digits (ISO 17442). The check uses the same MOD 97-10 trick as IBANs: turn each letter into a number (A=10 up to Z=35), read the result as one big integer, and it must leave a remainder of 1 when divided by 97.

def checksum_ok(lei: str) -> bool:
    digits = "".join(str(int(c, 36)) for c in lei)
    return int(digits) % 97 == 1

int(c, 36) does the letter conversion for free, because base 36 maps 0-9 to themselves and A-Z to 10-35. This alone catches most copy-paste mistakes, like a swapped or changed last character.

2. Look up 200 LEIs per request

The lei-records endpoint accepts a comma-separated filter[lei], so you don't need one request per code:

GET https://api.gleif.org/api/v1/lei-records?filter[lei]=LEI1,LEI2,...&page[size]=200

Anything valid that doesn't come back simply doesn't exist in the register.

3. The full script

Put one LEI per line in leis.txt and run python3 lei_check.py leis.txt > result.csv. It only needs requests.

import csv, re, sys, time
import requests

API = "https://api.gleif.org/api/v1/lei-records"
LEI_RE = re.compile(r"^[A-Z0-9]{18}[0-9]{2}$")

def checksum_ok(lei: str) -> bool:
    # ISO 17442 uses ISO 7064 MOD 97-10: letters become numbers (A=10 ... Z=35)
    digits = "".join(str(int(c, 36)) for c in lei)
    return int(digits) % 97 == 1

def lookup(leis):
    """Fetch up to 200 LEI records in one request."""
    r = requests.get(API, params={"filter[lei]": ",".join(leis), "page[size]": 200}, timeout=30)
    r.raise_for_status()
    return {rec["id"]: rec["attributes"] for rec in r.json()["data"]}

def main(path):
    raw = [l.strip().upper() for l in open(path) if l.strip()]
    valid = [l for l in raw if LEI_RE.match(l) and checksum_ok(l)]
    found = {}
    for i in range(0, len(valid), 200):
        found.update(lookup(valid[i:i + 200]))
        time.sleep(1)  # be polite to the free API
    w = csv.writer(sys.stdout)
    w.writerow(["lei", "status", "legal_name", "country", "entity_status", "registration_status", "next_renewal"])
    for lei in raw:
        if lei not in valid:
            w.writerow([lei, "invalid_format_or_checksum", "", "", "", "", ""])
        elif lei not in found:
            w.writerow([lei, "not_found", "", "", "", "", ""])
        else:
            a = found[lei]
            w.writerow([lei, "ok", a["entity"]["legalName"]["name"],
                        a["entity"]["legalAddress"]["country"], a["entity"]["status"],
                        a["registration"]["status"], (a["registration"]["nextRenewalDate"] or "")[:10]])

if __name__ == "__main__":
    main(sys.argv[1])

Output for a small test file:

lei,status,legal_name,country,entity_status,registration_status,next_renewal
5493001KJTIIGC8Y1R12,ok,Bloomberg Finance L.P.,US,ACTIVE,ISSUED,2027-01-25
7LTWFZYICNSX8D621K86,ok,DEUTSCHE BANK AKTIENGESELLSCHAFT,DE,ACTIVE,ISSUED,2027-06-02
HWUPKR0MPOU8FGXBT394,ok,Apple Inc.,US,ACTIVE,ISSUED,2027-03-08
5493001KJTIIGC8Y1R13,invalid_format_or_checksum,,,,,
NOTANLEI,invalid_format_or_checksum,,,,,

4. Read the two status fields correctly

They mean different things, and mixing them up is the most common mistake:

entity.status is about the company: ACTIVE or INACTIVE (merged, dissolved).
registration.status is about the LEI itself: ISSUED is fine, LAPSED means the renewal wasn't paid, RETIRED or ANNULLED means it shouldn't be used anymore.

A company can be perfectly active with a lapsed LEI, which is exactly the case your compliance team wants flagged. The next_renewal column tells you who is about to lapse.

5. Bonus: find an LEI from a company name

If you only have names, the same endpoint filters by legal name:

r = requests.get(API, params={"filter[entity.legalName]": "Siemens Aktiengesellschaft", "page[size]": 3}, timeout=30)
for d in r.json()["data"]:
    print(d["id"], d["attributes"]["entity"]["legalName"]["name"], d["attributes"]["entity"]["legalAddress"]["country"])

This returns both the German parent and the Austrian subsidiary, so always check the country before you trust a name match.

Limits worth knowing

The API is free but rate limited (around 60 requests per minute), so keep the small sleep between batches.
GLEIF data is published under CC0, so you can store and reuse it.
Parent and child relationships live under separate relationships links on each record, if you need group structures.

If you'd rather not run it yourself

Disclosure: I built and maintain a hosted version of this on Apify, GLEIF LEI Lookup. It does the same checks plus name search and exports to CSV or Google Sheets, and invalid or not-found codes are free. For a one-off list, the script above is all you need.

Is your grocery pack getting smaller? A free unit price checker for Lidl, Carrefour, Albert Heijn, Mercadona, ICA and more

Emir Mrkaljević — Wed, 28 Oct 2026 19:59:56 +0000

Shrinkflation is when a product keeps its price but the pack quietly gets smaller: 500 g becomes 450 g, 1 l becomes 900 ml. The price tag looks the same, so most people never notice.

EU shops must show a unit price (per kg or per litre) next to the selling price under Directive 98/6/EC. In practice it is often small, hidden, or missing in online shops, and it never tells you that the pack was bigger last month.

What ShrinkWatch EU does

ShrinkWatch EU is a free, open-source extension for Chrome, Edge and Firefox. On a product page it:

shows the price per kg, litre or piece in a small badge,
cross-checks the shop's own unit price and tells you when they disagree,
remembers pack sizes you have seen and warns you, for example "was 500 g, now 450 g, +11.1% per kg".

No account, no tracking, no network requests. Everything stays in your browser.

Shops checked on real product pages

Every shop below was opened in a normal desktop Chrome with the extension loaded, on a real product page, and the date and test product are logged:

Germany: Lidl, Kaufland, Rewe, dm, Rossmann, Netto
France: Lidl, Carrefour, Monoprix, Auchan
Netherlands: Albert Heijn, Lidl
Spain: Mercadona, Carrefour, Dia, Alcampo, Eroski, Lidl
Italy: Conad, Lidl
Poland: Lidl, Carrefour, Auchan
Nordics: ICA, Willys, Mathem (SE), Nemlig (DK), K-Ruoka (FI)

The full list (71 shops, 66 verified) with dates and test products is on the compatibility page. Per-shop guides: https://emirmrkaljevic.github.io/shrinkwatch-eu/shops/

Install in a minute

Instructions and the demo are on the project page. Source and issues: https://github.com/emirmrkaljevic/shrinkwatch-eu

If your favourite shop is missing or shows a wrong figure, open an issue with the product link. That is how most fixes so far started.

This post was written with AI assistance and checked by me against the project's test logs.

A slanted wall and a slot into a hole: getting one more printer part to an editable script

Emir Mrkaljević — Tue, 27 Oct 2026 19:02:36 +0000

I test on six real Original Prusa i3 MK3S parts. All six already come out as exact STEP. In the last post four of them had a script. 0.14.0 adds a fifth: y-rod-holder.

Why it was refused

Last time I said y-rod-holder had two problems: a Ø6.3 opening stored as a partial ring of small planes, and a body that isn't a uniform extrusion. 0.13.x fixed the first one and the part went from 1.503 mm to 0.745 mm max deviation. The limit for this part is 0.138 mm, so it was still refused.

The remaining error came from the outline. mesh2cad builds a script solid from outlines of the part, and it traced those outlines from the mesh. On this part that went wrong in two places:

there is a slot that breaks into the Ø8 rod bore, and the traced outline followed the bore round through the slot instead of stopping at the two edges where the slot meets the hole
the -Y wall is slanted, and the traced outline cut straight across its corner instead of following it

Neither looks like much on a picture, but each one adds or removes a thin wedge of material along the whole part, and that is what the self-check measured.

What changed

When both earlier approaches miss the gate, 0.14.0 tries a third rebuild:

each outline is rebuilt from a raster that is snapped to the vertical wall planes already found in the mesh, so a slanted wall stays slanted
where a slot breaks into a hole, the outline is closed at the two mouths, and a flare that sits outside the cylinder is kept
a planar 45 degree bevel with axis-aligned walls becomes a triangular cut (cut_N) along the wide part of the face
a leftover 45 degree cone becomes cone_N_r0, cone_N_r1, cone_N_h
shallow floors are scored again on that solid and only kept if they bring it closer to the mesh

A part that already passes with a simpler solid never takes this path, so the other four parts are unchanged.

The numbers

Every script is rebuilt and compared to the mesh before it is written. The gate hasn't changed: max deviation at most max(4 x tolerance, 0.1 mm), volume error at most 1%.

part	exact STEP	script (CadQuery / OpenSCAD)
plug-aligner	0.0000 mm	0.0000 / 0.0000 mm
endstop-block	0.0168 mm	0.0421 / 0.0421 mm
y-belt-idler	0.0082 mm	0.1534 / 0.1639 mm
y-motor-holder	0.1001 mm	0.1843 / 0.1843 mm
y-rod-holder	0.2178 mm	0.1300 / 0.1300 mm (was refused at 0.745 mm)
y-belt-holder	0.1602 mm	refused (2.517 mm)

For y-rod-holder the volume error is 0.096% (CadQuery) and 0.089% (OpenSCAD). The Ø3.3 hole along Y keeps its Ø6.3 counterbore as named parameters.

The new tests are small synthetic parts: a block with a 2 mm chamfer on the middle of one edge (it has to come out as cut_1 in both exporters), and a plate with a slanted wall and a slot into a hole (the outline has to keep the slanted corner and meet the hole at two mouths).

Still refused

y-belt-holder is the last one. Its belt pocket is a B-spline profile and its cross-section changes along X. Wall-snapped outlines and bevel cuts can't follow a curve like that, and I'd rather it get no script than a script that is 2.5 mm off. It still gets exact STEP.

Try it

pip install -U mesh2cad
mesh2cad convert part.stl -o part.step
mesh2cad convert part.stl --openscad part.scad

Ask for one site at a time: optional host permissions and dynamic content scripts in MV3

Emir Mrkaljević — Tue, 27 Oct 2026 09:04:04 +0000

ShrinkWatch EU is an open source extension that shows the price per kg or litre on 71 European supermarket web shops. Asking for all of them at install time would mean more than 180 site patterns in the permission warning, and a harder store review. So only six shops are enabled at install. Every other shop is switched on by the user, one at a time, from the popup.

This post is how that works in Manifest V3, and the three bugs I hit on the way.

The manifest

The six default shops go in host_permissions and a static content_scripts entry. Everything else goes in optional_host_permissions:

{
  "permissions": ["storage", "scripting", "activeTab"],
  "host_permissions": ["https://*.konzum.hr/*"],
  "optional_host_permissions": ["https://*.rewe.de/*", "https://*.lidl.fr/*"]
}

activeTab covers a "Check this page now" button that works on any site, once, without a standing permission.

Asking for the permission

The request must run directly in the click handler, or the browser refuses to show the prompt:

enable.onclick = async () => {
  const ok = await chrome.permissions.request({ origins });
  if (!ok) return;
  await chrome.runtime.sendMessage({ type: 'sync' });
};

Bug 1: asking for the wrong country. Several shops share one adapter (Kaufland DE, CZ and SK; Tesco IE and UK). My first version asked for the first domain in the list, so on tesco.ie the prompt asked for tesco.com, and the content script never ran. The fix: ask only for the origins of the domain in the open tab.

Registering the content script at runtime

A granted optional permission does nothing by itself. The background script registers one dynamic content script covering every granted shop:

const script = { id: 'optional-shops', matches, js: SCRIPTS, css: ['src/badge.css'], runAt: 'document_idle' };
if (exists) await chrome.scripting.updateContentScripts([script]);
else await chrome.scripting.registerContentScripts([script]);

Firefox does not keep dynamic scripts across browser restarts, so this sync also runs on every start.

Bug 2: "Duplicate script ID". onInstalled, onStartup, permissions.onAdded and the popup's message often fire at the same moment. Each one started its own register or unregister call, and they raced. Some failed with "Duplicate script ID" or "Nonexistent script ID", and sometimes no script was registered at all. The fix is a tiny queue so only one sync runs at a time:

let queue = Promise.resolve();
function sync() {
  const run = queue.then(syncNow);
  queue = run.catch(e => console.warn('sync failed', e));
  return run;
}

Each sync reads the current granted permissions and makes the registration match them, so running it twice is harmless.

Turning a shop off again

Bug 3: Disable did not really disable. After chrome.permissions.remove, clicking Enable again brought access back with no prompt. That is how Chrome works: a removed optional permission stays approved, so asking again is granted silently. To revoke it fully, the user has to use Site access on the extension's details page, and the popup now says so when removal fails.

There was a second part: a tab opened while access was being removed could still show a badge from a stale registration. So on opt-in shops the content script now asks the background whether access is still granted before it shows anything:

chrome.permissions.contains({ origins }).then(reply, () => reply(false));

Was it worth it?

Yes. The install prompt lists six shops instead of 71, the extension never gets access to a site you don't shop on, and every piece above is covered by tests with a simulated chrome object, run with node --test.

Website and install: https://emirmrkaljevic.github.io/shrinkwatch-eu/
Source (MIT): https://github.com/emirmrkaljevic/shrinkwatch-eu

This article was written with AI assistance. The code, tests and examples come from the repo.

Noticing when a smart device starts behaving differently

Emir Mrkaljević — Tue, 27 Oct 2026 09:03:42 +0000

A one-time audit of a smart plug or camera tells you what it does today. It says nothing about next month, after a firmware update or a change on the vendor's side. That gap is what I worked on in the last two releases of iotaudit, a small open-source (MIT) tool I use to audit the devices on my own network.

If you missed the earlier post about the per-device grade and the one-page report, it is here.

Everything below runs locally. There is no telemetry, no account, and it is meant only for your own network and devices.

Comparing two audits

capture and analyze already save a JSON report. Since 0.1.9 you can compare two of them:

pip install -U iotaudit

iotaudit diff yesterday.json today.json
iotaudit diff yesterday.json today.json --json

# or print the diff right after a new analysis
iotaudit analyze capture.pcap --device 192.168.1.50 \
    --json today.json --out today.html \
    --compare yesterday.json

Devices match by MAC, then by IP. For each device it lists new and gone destination domains and IPs, new countries, new open ports, grade changes, verdict changes, newly seen unencrypted traffic, and new UPnP forwards when the JSON has them.

Here is a made-up example of the kind of output you get (invented device and addresses, not from a real network):

EXAMPLE OUTPUT (made up)
device 02:00:00:00:00:01 (192.168.1.50)
  grade: B -> D
  new domains: telemetry.example.net
  new IPs: 198.51.100.23
  new countries: SG
  new open ports: 23/tcp
  new unencrypted traffic: HTTP to 198.51.100.23

The exit code is the part I care most about. It is 1 when something security relevant appeared: a new device, destination, country, open port, a worse grade, unencrypted traffic, or a UPnP forward. It is 0 otherwise, including when things only went away or the grade got better. A verdict change is printed but does not exit 1 on its own. A missing or unreadable file exits 2.

That makes it easy to put in cron and only hear about it when something new shows up. This is the script from the README:

#!/bin/sh
# 15 6 * * 1-5 "$HOME/iotaudit/check.sh"
report=$(iotaudit diff "$HOME/iotaudit/yesterday.json" "$HOME/iotaudit/today.json") || {
    printf '%s\n' "$report"
    exit 1
}
exit 0

The same comparison is available to MCP clients as the diff_results tool.

Offline known issue hints

0.1.10 adds a small curated list of public CVEs (14 entries right now) that is shipped inside the package. It is matched against version strings iotaudit already sees: nmap service versions, HTTP Server headers, UPnP and SSDP headers. Think MiniUPnPd, Dropbear, lighttpd, BusyBox, RomPager, the usual embedded suspects.

Each match shows up as known_issue_hints in the JSON and in the HTML/PDF report, with a link to the public NVD page. I was careful about the wording: every hint says the issue is possible based on the version string, and that you still need to check the actual firmware. Vendors backport fixes without changing banners all the time.

For the same reason, a hint only changes the grade when the observed version matches a listed version exactly and the entry is critical. Version ranges and lower severities stay as hints. There is no network lookup at runtime and no update command; the list is whatever shipped with the release.

What I would like to hear

If you run it against your own devices and the diff is noisy or a hint looks wrong, an issue on GitHub helps a lot. Suggestions for well documented CVEs to add to the list are welcome too.

Repo: https://github.com/emirmrkaljevic/iotaudit