TuyaBeGone: free firmware for a cheap LSC camera

A cloud-only indoor camera now runs a small Buildroot system. Video and audio go through the kernel drivers only: we traced the vendor’s closed libraries with an LD_PRELOAD shim and rewrote what they do. It streams over RTSP and ONVIF, with motion events from the ISP’s own statistics. Audio switched to AAC because UniFi Protect dropped G.711. It installs from an SD card in two stages, keeping the factory sensor calibration, and its first setup requires a press on the physical button. → TuyaBeGone: free firmware for a cheap LSC camera

A TwinCAT 3 machine moves from Windows to TC/BSD

A large-format 3D printer moved from the Windows TwinCAT runtime to TwinCAT/BSD on the same industrial PC. The traps: an engineering version that did not know the target, a corrupted drive startup command the older version had ignored, a drive moved to the wrong sync unit, Windows-only calls in the PLC code, and persistent positions left behind. → Moving a TwinCAT 3 machine from Windows to TC/BSD

How it connects

1. Both are about leaving a vendor’s platform (a cloud app, a Windows runtime) while keeping the hardware.
2. In both, the hardest part was the data that lives on the device: the camera’s sensor calibration, the machine’s saved positions.
3. In both, the old software quietly worked around something that the replacement had to discover: the vendor library read audio one period at a time (larger reads block forever), and the old TwinCAT version skipped a corrupted startup command.

Written by Jonathan (462engineering) and Claude (Claude Opus 5.5, Anthropic) — research, debugging and drafting done together in a Claude Code session.

Network map: Wi-Fi, Zigbee, moved cables

Our inventory tool now draws Wi-Fi and Zigbee next to the cables, and it recognises a machine replugged on another switch port (one alert and a one-click fix instead of three alerts). The Wi-Fi collector has to deal with an old access point that ejects your admin session. The Zigbee collector talks to Home Assistant’s websocket from plain PHP. After the power cut, a storage-network switch came back with its old address: its settings had never been saved. → Network map: Wi-Fi, Zigbee, moved cables

The AC stayed off, and a loop with no hidden state

The air conditioner, used here as a fan, had stayed off since the afternoon. No automation had done it: a power cut had restarted Home Assistant, and the smart plug’s power-on state was set to Off. We then made it start on high CO2 or VOC. The first version kept a flag remembering who had switched it on. It was replaced by helpers recomputed every minute (one per pollutant, each with its own hysteresis), which the plug follows. → A stateless air-circulation loop in Home Assistant

Heating load from a power meter

Total power is also the heat produced indoors. From it we got the convector’s real power (980 W), the room’s heat loss (about 105 W/K) and its base load (about 620 W). This gives a heating-load percentage, measured and forecast from the weather service, relative to the convectors that are actually online (one is broken). The dashboard icons turn green, yellow, red or purple depending on whether the setpoint can be held. There is also a card-mod 4.2 gotcha with glance cards. → Heating load from a power meter, with a forecast

How it connects

1. Airing the room to clear CO2 and VOC means bringing in outdoor air, and in autumn that adds heating load.
2. Knowing the heating load is how a future fan, which will also open a ventilation damper, can decide whether airing the room is cheap or expensive right now.
3. Both use the same pattern: helpers recomputed from sensors on a schedule, and devices that follow them.
4. The power cut explains two surprises: the storage switch that forgot its settings, and the AC plug that came back off.
5. The Zigbee view of the network map showed the plug of the broken convector offline since late September. The power meter told the same story: in a week of data, the second convector never ran.

Written by Jonathan (462engineering) and Claude (Claude Opus 5.5, Anthropic) — research, debugging and drafting done together in a Claude Code session.

Bring-up: Debian 13, RDNA4, Valve Index

The GPU box is a Debian 13 machine with a Radeon AI PRO R9700 (RDNA4). RDNA4 needs the kernel, Mesa and firmware from trixie-backports. evdi needs version 1.15.1 to build on kernel 7.1. We also hit a few boot-time problems (a missing display manager unit, an initramfs that picked up .link backups) and a few Steam and Index details. → Small notes: Debian 13 + RDNA4 + Index

Playing from the desk: sRemFB

To use the GPU box from the workstation, sRemFB creates an evdi virtual display on it and streams uncompressed or LZ4 damage rectangles to a new windowed viewer. Keyboard, mouse and gamepad go back over uinput, and audio over UDP. Key to pixel: 8.7 ms median on 2.5 GbE. → Playing on the GPU box from the desk, without a video codec

SteamVR judder, and moving to Monado

In SteamVR, menus and overlays judder. On Linux, SteamVR runs without async reprojection. Enabling it, or asking for 120 Hz, ends with flip_done timed out and a killed compositor. Monado with SteamVR’s own Lighthouse driver, xrizer and WayVR runs smoothly at 90, 120 and 144 Hz on the same hardware. → SteamVR on Linux: overlay/UI judder on RDNA4, and why Monado fixes it

mutter never forgets an unplugged GPU

mutter never removes a GPU that has been unplugged, and Xwayland keeps its DRM fd. Every removed evdi card leaves a stale DRM lease device. In the end, SteamVR and Monado both stall on them. → mutter never forgets an unplugged GPU (and what it does to VR)

How the problems connect

1. sRemFB creates evdi cards on the GPU box.
2. With evdi cards present, SteamVR’s DRM lease breaks (dc_stream_state is NULL, flip_done timed out).
3. The first fix was to remove the evdi cards before starting VR.
4. But mutter never forgets a removed GPU. Each removed card leaves a stale wp_drm_lease_device_v1 global, and Xwayland keeps its fd.
5. The stale globals block VR: SteamVR loops after LeaseDevice_Done, and Monado waits forever for done events, or picks a stale device that advertises the Index’s connector.
6. With a patched Monado (bounded wait, no silent fallback, optional DRM node pinning), Monado ignores the stale devices. It also runs fine alongside evdi, which SteamVR does not.
7. So there is no longer any reason to remove evdi cards: sremfb-server now runs permanently. No cards are removed, so no stale devices are created.

A mutter patch for the root cause exists but has not been tested. It is published as an RFC in the mutter post.

Written by Jonathan (462engineering) and Claude (Claude Opus 5.5, Anthropic) — research, debugging and drafting done together in a Claude Code session.