M1: Define lock driver and power transient measurement protocol

[mastertape]

Goal

Define the M1 lock-driver requirements and measurement protocol before choosing a final lock module, MOSFET board, relay board or custom driver path.

This is not a schematic or final PCB task. It is a safety and reliability checkpoint for the DHL parcel box retrofit.

Context

The M1 retrofit will likely drive a 12 V lock, door opener, solenoid, cabinet lock, motor latch or reused DHL lock mechanism. The ESP controller must not reset or unlock unexpectedly when the lock is actuated.

The lock path is a power and safety boundary:

• ESP logic and credential storage stay on regulated low-voltage rails.
• Lock actuation uses a separate protected 12 V load path.
• The lock output must be boot-safe and pulse-limited.
• Solenoids and inductive loads need transient/flyback handling.
• No 230 V is allowed on prototype boards.

Questions to answer

• What lock-driver strategy is acceptable for the first bench prototype?
• Which ready-made modules are acceptable for testing only?
• Which module patterns are good enough to influence a later OpenParcelBox Core/backplane?
• What must be measured before selecting a lock mechanism?
• How should firmware prevent accidental or long lock activation?

Measurement protocol

Document how to measure:

• lock cold resistance
• lock warm resistance where relevant
• inrush / pulse current
• minimum reliable unlock pulse duration
• voltage drop on the 12 V rail during actuation
• ESP 3.3 V rail stability during actuation
• driver and lock temperature after repeated attempts
• behavior with long/thin cables
• behavior after ESP reset, boot and firmware crash

Driver requirements to evaluate

• real 3.3 V-compatible logic-level MOSFET or suitable driver module
• relay or isolated driver only where isolation or mechanical simplicity helps
• flyback / transient protection for inductive loads
• fuse or current limiting on the 12 V lock branch
• defined off-state during boot and reset
• gate/base pulldown or equivalent safe-state handling
• configurable pulse duration in firmware
• watchdog / maximum-on-time protection
• no normal solenoid Dauerbestromung unless explicitly rated and thermally validated

Avoid treating generic IRF520-style modules as automatically suitable for 3.3 V GPIO drive. They may be useful only as bench examples after verification.

Firmware requirements

The first firmware lock abstraction should support:

• configurable pulse duration
• maximum allowed activation time
• explicit lock command source in the audit log
• boot-safe initialization
• no unlock pulse during reboot/reset
• optional lock-driver fault/status input later

Backplane requirements to derive

Capture requirements for a later OpenParcelBox Core/backplane:

• dedicated protected 12 V lock output
• branch fuse or overcurrent protection
• transient/flyback protection
• optional current measurement
• optional driver-fault feedback
• connector and cable-rating expectations
• separation from ESP regulator path

Acceptance criteria

• A measurement checklist exists in project docs or this issue.
• Candidate lock-driver module classes are categorized as prototype-only or reference-pattern.
• Firmware safe-state and pulse-limit requirements are documented.
• The issue links to the M1 module matrix.
• No final production schematic or compliance claim is made.

References

• docs/hardware/m1-module-matrix.md
• docs/roadmap/m1-dhl-retrofit-beta.md
• docs/security/remote-command-security.md