Summary

A light strip can be cut shorter than it ships, and the device has to be told how much of it is actually there so effects and colours span the right distance. The Tapo app exposes this as "Light Strip Length". python-kasa has no way to read or change it, so the setting is missing from Home Assistant. This PR adds it as a number.

Under the hood, strips advertise a segment component for this, but there is no module for it, even though six fixtures already in the repo carry the data.

• add a Segment module: REQUIRED_COMPONENT = "segment", QUERY_GETTER_NAME = "get_device_segment"
• expose one Number feature, strip_segments, range 0-50, Category.Config
• add a segments property and set_segments(), which writes set_device_segment

Notes

• A run is addressed in 10cm segments up to 5m, giving a maximum of 50. Confirmed on a physical L920 cut to 4.7m: setting 47 lights the full run with no dark tail, and the Tapo app reports 4.7m.
• The maximum is not discoverable. It is absent from sys_info, get_device_info and the component descriptor, and larger values are only rejected with PARAMS_ERROR(-1008), so it is defined as a constant with the reasoning in a comment.
• It appears to be per-run rather than per-model. An L920-10 ships two 5m spools into a single controller and still caps at 50, and the protocol has no per-run addressing: get_device_segment ignores start_index, index and id, and there is no list variant.
• Every strip fixture in the repo reports 50, across L920-5 and L930-5, both regions, firmware 1.0.7 through 1.4.3.
• The device silently accepts unknown parameters rather than rejecting them. {"segment": 47, "index": 1} returns success and does nothing, so read back rather than trusting a successful write.

Test plan

• uv run pytest tests/smart/modules/test_segment.py - 42 tests across the six existing strip fixtures, so no new fixture is needed
• uv run pytest - full suite passes
• uv run pre-commit run -a - clean

Beyond the fixtures, the module was exercised against a physical L920: the feature registers with the expected range and category, set_segments() round-trips, and out-of-range values are rejected before reaching the device.

One caveat if you want to reproduce that on hardware. Running the suite with --ip reconnects for every parametrisation, so a test parametrised across six fixtures fires 42 handshakes in under a minute. These strips allow 15 failed logins before a timed lockout, after which even discover returns ACCOUNT_ERROR(-2101) until it expires. Worth knowing before pointing --ip at a light strip.

Relation to #1702

No functional overlap. #1702 adds segment_effect, the per-segment custom effects applied with apply_segment_effect_rule. This is segment, the strip length read and written with get_device_segment / set_device_segment. Different components, different methods.

They do collide trivially: both insert an import after from .reportmode import ReportMode in kasa/smart/modules/__init__.py, where segment sorts before segmenteffect. I will rebase behind whichever lands first.

The two module names end up adjacent, Segment next to SegmentEffect. Both mirror their component names, which follows the existing convention, but say the word if you would rather this were something like StripLength.