Device

Yamaha HTR-3064 receiver, version G (Europe)

Symptom

The unit powers up just fine, but when an HDMI source is switched on, the unit turns off. Upon the next power-on, the display indicates a PS PRT alert protection, with a numeric indication between 098L and 100L. This does not happen, however, if the unit is powered up and left for 15-30 minutes to heat up before switching on the HDMI source.

With the unit idle (no HDMI source active), enabling the self-diagnostic function and monitoring the PS voltage shows values varying significantly between values below 120 and slightly above 130.

Background information: the PS value

PS appears to be an internal A/D monitoring point that averages several voltages in the power supply chain. From the Service manual (p. 37):

PS: Power supply voltage protection detection
Detected: AC2, ±12A, S9, +7D, +5A, +5I, -VP
Detection port: 93 pin (PS_PRT)
Normal value: 101 to 155
(Reference voltage: 3.3 V=255)

which indicates that the normal range at that point is between 1.31 V and 2.01 V (circuit diagram mentions 1.7V). A 098 reading would correspond to 1.27V, a 100 reading to 1.29. So the observed PS shutdowns would correspond to undervoltage by a good fraction of a volt at this test point.

Service manual oddity

In the documentation of messages displayed when starting the self-diagnostic function, the HTR-3064 service manual lists a number of possible protection faults at previous shutdown, with associated messages displayed on the device shown as illustrations.

The ADC conversions (section 9 of self diagnostics) and the IC221 pin list describe parameters monitored:

Examination of the circuit diagrams confirm that the PS_PRT pin indeed averages the voltages of various test points in the power supply section. So it looks like the wrong messages might be shown in the description of self-diagnostic conditions, and PS_PRT: xxxL on the display would indicate undervoltage in the power supply section (i.e. should be shown to illustrate 2-4 and not 2-1).

Interestingly, no ADC pin of the CPU is labeled as PRV_PRT.

The service manual for the HTR-3067 has very similar text, but shows the PS_PRT illustration for the “abnormal voltage in power supply” condition, which contributes to confirming the logic here:

Investigation

Visual inspection

Opening the case reveals two swollen electrolytic capacitors C1317 and C1320 on the OPERATION (2) board.

Both are smoothing capacitors located right after rectifier bridges fed from the main transformer.

• C1320 is 10,000 µF and smoothes the +7D rail monitored by PS_PRT.
• C1317 is 4,700 µF and smoothes the input of IC132, a 7805 regulator providing the +5I rail also monitored by PS_PRT.

In-circuit measurement

In-circuit measurement of course cannot provide reliable component values but suggested that the capacitance for both caps was way off. By comparison, measurement for other caps on the board (C1318, C1319) showed values within range of the nominal ones.

Out-of-circuit measurement

Once the two swollen capacitors were desoldered (using a power desoldering pump, which posed no difficulty), out-of-circuit measurement confirmed values way off the nominal ones, as well as substantial voltage loss. The ESR figure was not remarkably high, but still one order of magnitude higher than the one observed on new replacement parts.

Parts replacement

I ordered replacement caps from Reichelt, which has the lowest shipping rates for small orders among reputable online sellers. I wanted to avoid cheap Chinese knockoffs this time, as I don’t fancy going through the whole repair process too often.

Component tester readings for the replacement parts

Soldering new caps

Soldering the two new caps in place proved more difficult than anticipated. The solder tended to ball instead of flowing nicely onto the pads. This is likely due to using too high a temperature on the soldering iron, resulting in burning the flux before it had a chance to actually remove the thin oxydization layer on the pads. Light scraping of the pad with a fiberglass abrasive pen likely would have helped as well.

Post-repair testing

Once the two new caps were installed, the readings for the PS ADC value in the self-diagnostic function became much more stable, both before and after switching on the HDMI source. It remains in the vicinity of 130, consistent with the expected 1.7V (reading 131) shown on the service manual circuit diagram.

The amplifier no longer shut down upon connecting an HDMI signal: repair was declared successful.

JS-910B is the designation for generic Chinese binding posts with 4mm banana socket connections for panel mounting. (AliExpress).

The order in which all of the parts go is not 100% obvious until you have figured it out:

• socket body
• plastic insulating ring (hollow)
• panel
• shouldered plastic ring
• metal washer
• connection tab
• tightening nut
• locking nut

Panel mounting details

The clever part of the design is the shouldered plastic ring: the shoulder goes through the panel hole, to ensure insulation between the metal body of the socket and the panel (essential in the case of a conductive panel!). The hollow ring goes on the front and covers whatever height of the shoulder protrudes through the panel hole (in case the panel is thinner than the height of the shoulder).

:warning: Of course this means that the panel must be drilled to the outer diameter of the shoulder (8mm).

Here is what the completed panel mounting looks like:

If you’re running Drone with Gitea, Woodpecker is a natural migration target — it has strong Gitea integration and an actively maintained codebase. Here is what the migration actually involves, based on a real setup using Docker Compose and Traefik.

Docker Compose

The server and runner/agent images change, and there are several environment variable renames. Woodpecker also uses different ports: the web UI runs on 8000 (not 80), and the agent communicates with the server over gRPC on port 9000.

  woodpecker:
    image: woodpeckerci/woodpecker-server:latest
    container_name: woodpecker
    restart: unless-stopped
    environment:
      - WOODPECKER_HOST=https://drone.example.org   # full URL including scheme
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=https://gitea.example.org
      - WOODPECKER_CRON_DISABLED=true
    env_file:
      - ./woodpecker.env
    volumes:
      - woodpecker:/var/lib/woodpecker   # different path from Drone's /data
    networks:
      - services
      - woodpecker
    labels:
      traefik.enable: "true"
      traefik.http.services.woodpecker.loadbalancer.server.port: 8000  # not 80!

  woodpecker-agent:
    image: woodpeckerci/woodpecker-agent:latest
    restart: unless-stopped
    environment:
      - WOODPECKER_SERVER=woodpecker:9000   # gRPC port, not HTTP
      - WOODPECKER_GRPC_SECURE=false
    env_file:
      - ./woodpecker.env
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - woodpecker

Make sure both the server and agent containers are on the same Docker network. If the agent can resolve the server’s hostname but port 9000 is refused, it is likely a startup ordering issue — simply restarting the agent container after the server is fully up will fix it.

Environment Variables

Your drone.env secrets need to be renamed in a new woodpecker.env file:

Note that WOODPECKER_AGENT_SECRET (RPC) and WOODPECKER_SECRET (cookie signing) are separate variables — do not conflate them.

You also need to set WOODPECKER_ADMIN to your Gitea username, otherwise Woodpecker will not allow you to register or access the admin panel:

WOODPECKER_ADMIN=yourusername

You will also need to create a new OAuth application in Gitea pointing at your Woodpecker URL, since the callback URL changes.

Pipeline Files

You must rename .drone.yml to .woodpecker.yml. Despite what the documentation suggests, Woodpecker (at least on the next tag) does not fall back to .drone.yml — it will silently ignore it, and pushes will not trigger any pipelines.

The pipeline syntax is largely compatible. Steps, images, commands, secrets, and when conditions mostly work as-is. A few things to check:

Move trigger to the pipeline level. In Drone it was sometimes written under individual steps; in Woodpecker it must be a top-level key.

Drone plugins still work. They are just Docker images, so plugins like drillster/drone-rsync are fully compatible.

DRONE_* environment variables become CI_*. If your pipeline scripts reference injected variables like DRONE_COMMIT, these are renamed in Woodpecker (e.g. CI_COMMIT_SHA).

What Does Not Migrate

Woodpecker does not import Drone’s database. This means:

• Build history is lost — you start with a clean slate
• Secrets must be re-entered via the Woodpecker UI for each repository
• Repos must be re-activated in Woodpecker

If retaining build history matters, you can keep the old Drone instance running read-only alongside Woodpecker temporarily, since they can coexist on different hostnames.

Summary

For a straightforward Drone + Gitea + Docker Compose setup, the migration is low effort. The main steps are:

1. Update docker-compose.yml with the new images and port numbers
2. Rename secrets in your env file and set WOODPECKER_ADMIN
3. Create a new OAuth app in Gitea
4. Rename .drone.yml to .woodpecker.yml in each repository
5. Move any pipeline-level trigger blocks to the top level
6. Re-activate repos and re-enter secrets in the Woodpecker UI

Validate-Job client-error-not-found

Cause

macOS sends a Validate-Job IPP request before submitting the actual print job. If the queue URI is incorrect, the server cannot find the printer and rejects it with this error.

The most common culprit is the queue name field when adding the printer via System Settings → Printers & Scanners → Add Printer → IP tab. Leaving it blank or entering just the printer name causes macOS to target the wrong IPP endpoint.

Fix

When adding the printer, set the Queue field to:

/printers/<printername>

(note /printers/ prefix, it’s not just the CUPS queue name)

For example, if your printer is named office-laser:

/printers/office-laser

The full URI should resolve to:

ipp://<server>:631/printers/<printername>

Fixing an already-added printer

No need to remove and re-add it. Update the URI in place with lpadmin:

lpadmin -p <printername> -v ipp://<server>:631/printers/<printername>

Verifying the correct URI

You can confirm the printer name and path on the CUPS server with:

lpstat -v

And test the endpoint directly from the Mac before adding the printer:

ipptool -tv ipp://<server>:631/printers/<printername> get-printer-attributes.test

What started as an accidental reverse polarity event on an ESP32-U DevKit board turned into a surprisingly successful recovery. This post documents the full diagnostic process and the steps that ultimately brought the board back to life running Tasmota.

The Incident

Reverse polarity was applied directly to the 3V3 pin of an ESP32-U DevKit board. This is arguably worse than reversing the 5V input, because it bypasses the onboard LDO regulator entirely — the reversed voltage goes straight onto the 3.3V rail feeding the ESP32 and all other components directly.

Initial Symptoms

• The USB-to-UART bridge was alive and enumerating correctly (expected, as it is powered from the 5V USB rail, upstream of the LDO)
• The board was unresponsive to flashing attempts
• 0V measured on the 3V3 pin while powered from USB

Diagnosis

Ruling out a shorted rail

Measuring resistance between GND and 3V3 with the board unpowered showed 750Ω — a healthy value indicating no shorted decoupling capacitors or blown ESD diodes on the rail. This was an encouraging sign pointing to the LDO as the failed component rather than the ESP32 itself.

LDO thermal shutdown

The AMS1117-3.3 LDO on ESP32 DevKit boards includes built-in thermal shutdown protection. The reverse polarity event likely caused excessive current through the LDO, triggering thermal shutdown. After sufficient cooling time during the resistance measurements, the LDO recovered on its own and 3V3 was restored — consistent with thermal shutdown behaviour rather than permanent damage.

Flash chip diagnosis

With power restored, flashing still failed with:

Warning: Failed to communicate with the flash chip, read/write operations will fail.

Using esptool with the --no-stub flag also failed, and flash-id returned 0xff/0xffff — indicating no response on the SPI bus from the ROM bootloader.

However, running flash-id with the stub flasher returned a valid response:

Manufacturer: 68
Device: 4016
Detected flash size: 4MB

Manufacturer 0x68 is Boya Micro (BY25Q32) — a legitimate, working flash chip. The discrepancy between ROM bootloader and stub was due to different SPI bus initialisation methods; the stub’s optimised driver worked where the ROM’s did not.

Recovery Steps

1. Erasing the flash in chunks

A full erase-flash operation failed mid-way with:

A fatal error occurred: Packet content transfer stopped (received 9 bytes).

This was consistent with marginal LDO stability under sustained load. Erasing in smaller regions worked reliably:

esptool erase-region 0x3D0000 0x20000

2. Reflashing Tasmota

Direct reflash via esptool succeeded:

esptool --baud 115200 write-flash 0x0 tasmota32-FR.bin

3. Diagnosing the safeboot loop

After reflashing, the device booted but the web interface was unresponsive (IP pinged but empty HTTP answer from http://192.168.4.1/). Serial console output revealed:

Project tasmota - Tasmota Version 15.3.0(release-safeboot)-3.3.7(2026-02-19T13:53:54)
WARNING This version does not support persistent settings

The erase operations had wiped the OTA selection flag at 0xe000, causing the bootloader to fall back to the safeboot partition instead of the main firmware.

The safeboot firmware is a special trimmed down version of Tasmota used during OTA upgrades. It specifically does not include the initial configuration web page.

4. Full PlatformIO reflash

A complete PlatformIO rebuild and reflash restored all partition components including the OTA flag:

This restored normal boot into the full tasmota32-FR firmware.

How the Tasmota32 Safeboot System Works

The Tasmota32 dual-partition safeboot architecture is worth understanding:

• On every normal boot, the OTA flag at 0xe000 points the bootloader to the main firmware at 0xe0000
• If the device reboots 4 times in quick succession (crash loop), Tasmota automatically switches the OTA flag to the safeboot partition as a recovery mechanism
• Safeboot can also be triggered manually via Restart 99 from the Tasmota console
• From the safeboot web interface, you can OTA flash a new main firmware, which resets the OTA flag back to normal

The safeboot partition is intentionally minimal (~300–400KB) — it includes only a web server, OTA flash capability, basic WiFi AP, and a stripped console. It has no persistent settings, no MQTT, and most Tasmota commands are unavailable.

Outcome

The board made a full recovery with no permanent damage:

• ESP32 SoC: intact
• Flash chip: intact
• LDO: recovered from thermal shutdown
• Tasmota: running normally

Lessons Learned

• Reverse polarity on the 3V3 pin is more dangerous than on the 5V pin as it bypasses the LDO entirely
• The AMS1117 thermal shutdown can mimic permanent failure but recover after cooling
• Always use the stub flasher (esptool without --no-stub) for flash communication — the ROM bootloader SPI initialisation can fail where the stub succeeds
• Partial flash erase operations can corrupt the OTA selection flag, causing unexpected safeboot behaviour
• A full PlatformIO reflash is the safest way to restore a complete and correct partition layout
• Consider adding reverse polarity protection (Schottky diode or P-channel MOSFET) on power inputs in future designs

Alternate exit path from Safeboot

I could have reset the safeboot flag using:

esptool write-flash 0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin

This just rewrites the OTA selection flag directly, telling the bootloader to boot the main firmware partition — without touching anything else. A full reflash would not have been necessary. From within the safeboot console, there isn’t a direct command to flip the flag — that’s intentional, since the whole point of safeboot is to force you through the OTA web interface to upload known-good firmware before returning to normal boot.

On a Dell Precision 7520 running Debian, I found myself switching between UEFI / secure boot and legacy BIOS boot, and having trouble restoring the right boot settings after reenabling secure boot.

The first problem was to identify the correct file to boot from: EFI/debian/shimx64.efi.

Kernel module load issue

After disabling secure boot and then reenabling it again, kernel modules not loading despite updating nvidia-driver and kernel-image

solution: reenroll MOK (Machine Owner Key):

• mokutil --import /var/lib/dkms/mok.pub (set an import password)
• mokutil --list-new
• reboot into MOK management => provide import password => key reenrolled
• modules loding :thumsbup:

Debian documentation: Secure Boot

I captured more traces showing voltage before L600 (i.e. at the net labeled “8” from the power supply in Sams Computer Facts) (yellow) and after it (i.e. at the CPU’s Vcc pin) (purple), also recording the min and max voltage.

We are seeing:

• very large voltage variations downstream of L600 when it’s not shunted
• interstingly, slightly different readings on the two probes even when shunted with a wire :thinking:

Replacing the CPU & a provisional conclusion

The hypothesis at this stage is a marginal CPU that draws a little too much current, so I’m trying to replace it with another one from eBay.

… and this time it works (and no longer shows large variations on Vcc) even with L600 not shunted :tada:

So I’m considering the machine repaired, and hoping that there isn’t some other issue with the power supply or the mainboard that will fry one CPU after another…

• Exporter les notices ouvrages en UNIMARC ISO PMB (:warning: ISO se rapporte à la flaveur d’Unimarc, pas à l’encodage !)
• Exporter les notices autorité associées

Import dans PMB

Notices autorités

Autorités > Gestion > Import

Encodage: Forcer en ISO 5426

Notices ouvrages

Administration > Modules > Imports > Notices UNIMARC

Fonction d’import: PMB

Encodage: Forcer en ISO 5426

• fenêtres de toit oscillantes motorisées sur secteur Integra GGU avec stores intérieurs motorisés sur secteur DML (4 UK08, 1 SK06)
• télécommandes unidirectionnelles
  • KLI 311 (fenêtres)
  • KLI 312 (stores)
• passerelle Internet/HomeKit Velux Active KIX 300
  • capteur intérieur KLA 300
  • commande de départ KLN 300

Fermeture incomplète

Symptôme

Fermeture imparfaite avec le clapet d’aération pas complètement rabattu

• détecté comme ouverture manuelle donc plus d’ouverture motorisée
• ne se referme pas plus car déjà en fin de cycle de fermeture
• sur fermeture manuelle
  • échoue à rouvrir avec le moteur
  • ne désengage pas la chaîne => ouverture manuelle impossible

Solution

• forcer la fermeture manuellement
• essayer d’ouvrir avec le moteur
  • si ça marche, OK
• essayer d’ouvrir manuellement
  • impossible si la chaîne n’est pas dégagée

• sinon ouvrir avec le moteur en accompangnant l’ouverture à la main

• une fois en position ouverte, dégager la chaîne
• réinitialiser (pression 5-10 s sur bouton test) chaîne dégagée, la chaîne rentre complètement
• la chaîne revenue en position de fermeture complète, refermer manuellement

Perte d’appairage

Reonnexion des télécommandes unidirectionnelles

• Ouvrir manuellement la fenêtre
• Réinitialiser (appui 10 s sur le bouton, le store puis la chaîne bougent)
• Sur chacune des télécommandes (fenêtre et store)
  • appuyer 5 s sur le bouton d’appairage (deux rectangles)
  • appuyer 1 s sur STOP
  • appuyer 1 s sur DOWN

Reconnexion à la passerelle

Pour chaque appareil (store, fenêtre) :

• Appuyer 5 s sur * : l’appareil va et vient
• Sur la passerelle : appuyer longuement sur *
  • la lumière se met d’abord à clignoter blanc
  • continuer d’appuyer
  • la lumière se met à clignoter bleu : c’est bon, c’est en train d’appairer
  • attendre que ça ne clignote plus

Si l’appareil était injoignable, il peut être nécessaire de le supprimer de l’app avant de réappairer.

Pour associer un store à une fenêtre, dans Gestion de la maison, aller sur la fenêtre, menu ⠇, Éditer le groupe.

Vcc (pin 2) of the CPU is oscillating wildly unless I shunt L600. With L600 shunted, the machine seems to start up just fine (nice beep, and title screen displays).

Desoldering L600 and testing it off circuit is inconclusive: it seems to behave just fine. Measuring its inductance with the oscilloscope (through the period of amortized oscillation with a known capacitor) as shown here shows a consistent behaviour vs a new replacement part.

The old part’s amortized oscillation damps down faster, which is consistent with a higher resistance (on the LCR-T7, the old part reads at 0.50 Ω, whereas the new one reads at 0.25 Ω), but both measure a period of 520 ns, which is ballpark-consistent with a 6.8 μH inductance.

I soldered the new part instead of the old one, and I’m seeing a similar behaviour as before: failure when starting up (continuous tone, wild variations at TMS9900 Vcc), apparently working fine when shunting L600.

Just to be sure, with L600 shunted I hooked up the display and confirmed that:

• the title screen displays fine;
• when pressing a key, I get the main menu;
• when pressing 1, I get the TI basic prompt, and key strokes appear on screen.

So L600 may not be the culprit, but some other connected part.

Could it be C611?

Another possible culprit nearby might be C611. Desoldering it and measuring it off-circuit, it reads just under 1000 pF on the LCR-T7, which is as expected, so I’m deciding it’s good and soldering it back.

Something else near ~MEMEN~?

Next hypothesis is a marginal component sinking too much current from Vcc:

• either R607, which looks like a pullup on ~MEMEN~
• or U605 input pin 2?

A closer look at R607

In-circuit, R607 reads at 4.6 kΩ, which seems in a reasonable ballpark, so I’m disinclined to desolder it, which is fortunate because annonyingly, the new L600 is a bigger form factor than the original one, and so it’s blocking access. I could desolder it and solder back the original one: since the original one measures fine, and replacing it didn’t change the behaviour, I’m assuming that the problem was not there. But since the in-circuit reading looks within spec, that would really be a shot in the dark.

Vcc fighting ~MEMEN~?

Next step is to look at Vcc and ~MEMEN~ simultaneously to see if there’s a correlation between changes on MEMEN and Vcc variations.

Finging: The Vcc variations do not appear to be correlated with ~MEMEN~: there are big oscillations on Vcc even when ~MEMEN~ is stable (whether low or high).