Power-consumption-based automation trigger

In audio and AV systems, automatic device startup is often based on dedicated control signals, such as a 12 V trigger or digital bus-based solutions. However, not all devices provide such controls, and especially in a purely analog signal chain, an individual device may remain effectively “invisible” from the perspective of the overall system.

In this project, I examine a solution in which a device’s actual operating state is inferred from its power consumption. The goal is not a universal automation solution, but a clearly defined, concrete need within an existing audio system. The article describes the background of the idea, the implementation of a prototype, and the reasons why a seemingly simple solution turns out to be surprisingly challenging when considered as a product.

Existing technologies

Power management solutions since ~1970

In stereo equipment, a traditional approach has been to include AC out sockets on the rear panel of an amplifier. When the amplifier is powered on, it supplies power to another device. The weaknesses of this approach are:

• The number of outlets is often insufficient.
• The outlets may lack grounding, and plugs may not physically fit the enclosure.
• The output current may be rated for too low a load.

Power management solutions since ~1990

A later and more widely adopted approach is the 12 V trigger signal. When a device is powered on, it outputs a 12 V signal via a cable to the next device. If the receiving device supports this signal, it can automatically power on in response.

This approach is reliable and commonly used in hi-fi and AV equipment, but it requires explicit support from the device. If a device lacks a trigger output, it cannot participate in this kind of automation without modification.

Digital-world solutions

In digital systems, device state and startup behavior can also be controlled as part of the data connection itself. In AV systems, this is seen in HDMI-CEC control, and in the computer domain through USB-C, where power and state information may be conveyed alongside data.

In this project, such bus-based control mechanisms were deliberately excluded. The goal was not to build a solution as part of a digital control chain, but to determine a device’s operating state in a situation where only an analog signal path and mains power are available.

Example case

The mixer is the most central device from the user’s point of view in this setup. It would be natural for turning on the mixer to also power up the rest of the devices. In practice, however, this kind of support is not available, as the device does not fall into the hi-fi or AV categories where such features are typically provided.

A turntable, on the other hand, is inherently a mechanical and analog device. Power management and automation-related features do not belong to this category either.

Searching for a solution, one component at a time

Amplifier

The amplifier supports a standard 12 V trigger input. When a suitable control signal is present, the amplifier can be powered on automatically.

Turntable

A slave device was added between the turntable and the mains outlet. The device passes power through when a 12 V signal is received, allowing the turntable itself to be left permanently in the powered-on position. In the example case, the turntable is the DJ classic Technics SL-1210, whose on/off switch is not easy for an occasional user to locate.

The auxiliary device was sourced from the French retailer Audiophonics. The unit is simple and well designed, and it fits into the unused space on the rear panel of the Technics, remaining completely out of sight.

Mixer

The mixer does not support a trigger signal either as an input or as an output. This is where the core of the problem becomes apparent.

A mixer user typically wants to be certain that, when desired, the signal is actually routed to the speakers. Using the audio signal itself as a trigger would be ambiguous. The most reliable and fastest approach would be to base detection on power consumption.

In the first experiment, I ended up soldering an output connector for a 12 V signal directly to the power switch. The result was functional and clean, but not scalable. The device only happened to operate at the same voltage by coincidence.

A second approach was to develop a device that would resemble the Audiophonics receiver, but act as the transmitting side. The mixer would be connected through a mains socket. When current flows through the socket, the 12 V outputs would be activated — and deactivated accordingly. This way, no modification of the devices themselves would be required.

Prototype implementation

Building the prototype progressed relatively smoothly. Based on the anticipated complexity of the device logic, it was decided early on to implement the solution on top of a microcontroller. The Arduino platform was a natural choice, as it is well supported and components are readily available.

Components used:

• A 12 V DC power supply module repurposed from a previously dismantled device.
• A small and inexpensive Arduino Nano clone with a built-in regulator, allowing both the operating voltage and the 12 V trigger to be supplied directly from the same power source.
• A MOSFET switch.
• A CT sensor.
• A flush-mounted Schuko AC socket.
• A flush-mounted IEC socket.
• 3.5 mm jack sockets.
• An enclosure.

I underestimated how challenging the physical layout would be when fitting the components into a small enclosure. The AC and DC sections are clearly separated from each other. Current measurement using the CT sensor is performed without a direct electrical connection. The CT sensor is operating close to its sensitivity limits due to the mixer’s relatively low current consumption.

Logic implementation

The logic is based on threshold values and time delays. A simple current spike is not sufficient to indicate actual use; instead, the system must distinguish between standby consumption, startup transients, and sustained operation.

This requires filtering, hysteresis, and timing logic to avoid false positives and unintended switching.

Challenges of productization

Although the prototype demonstrates that current-based state detection is feasible, turning the concept into a robust, general-purpose product introduces additional challenges. Startup currents, varying loads, and differences between devices make it difficult to define universal thresholds.

In addition, safety considerations, certification requirements, and clear documentation become increasingly important once development moves beyond a single, known system.

Conclusion

The goal of this project was to develop a functional automation product for a scenario where a device’s operating state cannot be determined through existing control interfaces. The starting point was practical: to evaluate whether power consumption can be used as a reliable indicator of actual use within an existing system.

The prototype showed that the approach works under certain conditions, but it also quickly revealed situations in which simple threshold tuning is no longer sufficient. Startup currents and load variations are not exceptional cases but normal operation, and they directly affect how reliably power consumption can be interpreted as a device’s true state.

At this stage, the prototype primarily served as a tool for identifying boundaries. It clarified under which conditions the solution could be developed further toward a production-ready automation product, and when additional effort would shift away from the core technology toward interpretation and safety.