Issue: Expose Countdown module for plugs/strips (HS300) in IotDevice path

Summary:
The TP-Link HS300 (and other Kasa plugs/strips) support the device-side countdown timer (count_down / countdown) module at the protocol level. The kasa CLI can access it via command / raw-command, but the Python API does not expose this functionality. In python-kasa 0.7.7, the IotDevice path detects the Countdown module but marks it as “not supported,” resulting in no countdown entry under dev.modules or child.modules.

This prevents programmatic use of the hardware failsafe timer from Python (e.g., “turn outlet ON and automatically turn it OFF in N seconds if the controller dies”), forcing applications to shell out to the CLI.

I’m requesting that the existing internal Countdown module class be fully wired into the IotDevice module mapping for plugs/strips, similar to how Schedule and Antitheft are integrated.

Background & Prior Discussions

Discussion #284 – “Set countdown timer on plug?”

#284
This discussion confirms the correct JSON structure and usage of count_down.get_rules, add_rule, and edit_rule, but notes that countdown is only accessible via the CLI’s raw-command. There is no clean high-level Python interface.

Relevant CLI usage from Discussion #284:

kasa raw-command count_down get_rules
kasa raw-command count_down add_rule '{"enable": 0, "delay": 5, "act": 0, "name": "test"}'
kasa raw-command count_down edit_rule '{"id": "1234", "enable": 1, "delay": 45, "act": 0, "name": "test"}'

This illustrates that countdown works at the protocol level and that python-kasa users already rely on it.

Evidence the Countdown module exists but is not supported

Several issues show the module being detected during discovery but skipped as unsupported by python-kasa:

Issue #818

#818
Includes logs like:

Adding module <Module Countdown (countdown) ...>
Module <Module Countdown (countdown) ...> not supported, skipping

Issue #830

#830
Similar output from HS220/other devices:

IotDevice: Module <Module Countdown (countdown) for 192.168.x.x> not supported, skipping

Issue #1102

#1102
Also shows countdown detected but skipped:

Module Countdown (countdown) detected
Not supported, skipping module

These confirm the module is recognized in the new IotDevice architecture but isn’t bound to an implementation.

Request

Expose the existing internal Countdown module (class Countdown(Module)) as a supported module for plugs/strips under the IotDevice path.

Specifically:

1. Register Countdown in the module mapping for devices that report "countdown" / "count_down" in their capability list.

2. Ensure child devices (e.g., HS300 outlets) receive a countdown entry in child.modules[...].

3. Expose basic rule operations, similar to Schedule:

   • get_rules()
   • add_rule(...)
   • edit_rule(...)
   • delete_all_rules()

4. Optionally add a helper similar to Schedule:

   • arm_off_after(delay_seconds)
     (a common pattern is setting a single OFF-after-X-seconds failsafe timer)

Why this matters

The countdown timer is a hardware-level safety feature on many Kasa plugs/strips. Applications such as environmental controllers, heaters, pumps, or battery-powered Pis rely on it for “turn off even if the controller dies” behavior.

The functionality exists in:

• TP-Link firmware
• The Kasa mobile apps
• The python-kasa CLI via raw-command

…but not in the Python API, forcing developers to shell out to the CLI or re-implement the TP-Link command protocol themselves.

Making Countdown a first-class module would:

• Align python-kasa with the Kasa device feature set
• Allow controllers like Spriggler, Home Assistant integrations, etc., to use the failsafe timer natively
• Mirror the design of the existing Schedule and Antitheft modules
• Reduce need for raw-command hacks

Environment

• python-kasa: 0.7.7
• Device: HS300(US)
• Behavior: CLI countdown commands work; Python API has no countdown module under child.modules.

If helpful, I can contribute a PR that:

• Ports the existing Countdown implementation to the IotDevice flow
• Adds the module mapping
• Adds tests modeled after the Schedule module tests
• Updates the docs with usage examples

Thanks for considering adding this small but high-impact feature!