Add support for Tapo lock device DL110 and implement lock control features by cristian-rincon · Pull Request #1646 · python-kasa/python-kasa

cristian-rincon · 2026-01-15T03:47:49Z

Introduced new device type for Tapo lock in device_type.py
Updated device family to include Tapo lock in deviceconfig.py
Added lock control commands in cli/lock.py
Implemented lock and lock history modules in smartcam
Created tests for lock module and history functionality
Added JSON fixture for Tapo lock device

cristian-rincon · 2026-01-15T04:11:35Z

ZeliardM · 2026-01-15T07:28:32Z

@cristian-rincon Huge thanks for pulling this together. I would suggest instead of making it a SMARTCAM device, it be under just the SMART device category. You may need to make adjustments to the device_factory.py and discover.py to handle making sure the correct protocol and transport are used since it looks like this device_type uses the SSL AES Transport, but there should be a clear separation here since it is not a camera at all.

Also, when submitting, making sure that all checks pass is best.

To help with submissions, in your local repository folder run these commands following commands:

uv sync --all-extras
uv run pre-commit run -a
uv run pytest -n auto --cov kasa --cov-report xml

That will setup a local Python .venv and run all the test coverages and make sure the code is following existing guidelines. You can fix errors and make sure all lines of code are covered for CodeCov as well.

DocJr90 · 2026-01-22T03:41:27Z

@cristian-rincon Will this also support the DL100? If not, anything I can do to help make that so?

rytilahti

Thanks for the PR, @cristian-rincon! I added some initial feedback inline, please take a look and let me know what you think.

rytilahti · 2026-01-26T21:37:22Z

+        # lock commands runnnable at top level
+        "unlock": "lock",
+        "history": "lock",


Let's avoid polluting the main command namespace given how specific these are to the locks (albeit history could be something similar to trigger logs on some devices, but that's for another discussion).

rytilahti · 2026-01-26T21:41:01Z

+    "Lock",
+    "LockEvent",
+    "LockMethod",


Interfaces are used to provide common interface for different device families, but as there are currently no locks for other types (iot, smart), let's avoid abstracting things and adding these interfaces until we have a need for the level of abstraction.

rytilahti · 2026-01-26T21:42:44Z

+    assert hasattr(lock, "is_locked")  # type: ignore[attr-defined]
+    assert hasattr(lock, "battery_level")  # type: ignore[attr-defined]
+    assert hasattr(lock, "auto_lock_enabled")  # type: ignore[attr-defined]


These are already tested by the code below.

rytilahti · 2026-01-26T21:43:51Z

+    assert lock
+
+    # Test properties exist and can be accessed
+    is_locked = lock.is_locked  # type: ignore[attr-defined]


There should be no need to ignore the type for every individual check. Does not adding a type hint to the assignment fix the type for all the checks below?

Same applies to check in other test functions in this file.

rytilahti · 2026-01-26T21:45:44Z

+        "SMART.TAPOLOCK": SmartCamDevice,
+        "SMART.TAPOLOCK.HTTPS": SmartCamDevice,


Isn't this always HTTPS as the test implies?

rytilahti · 2026-01-26T21:47:25Z

    Vacuum = "vacuum"
    Chime = "chime"
    Doorbell = "doorbell"
+    DoorLock = "doorlock"


I was thinking whether this should be Doorlock to keep the consistency with the doorbell above, but would Lock be enough? It is what you also use in the cli, and it is descriptive enough, IMO.

rytilahti · 2026-01-26T21:49:36Z

+    def _get_lock_status(self) -> dict:
+        """Get lock status data."""
+        return self.data.get(self.QUERY_GETTER_NAME, {})
+
+    def _get_lock_config(self) -> dict:
+        """Get lock config data."""
+        return self.data.get("getLockConfig", {})


Would it be possible to use dataclasses for the responses to allow typing and letting mashumaro to deal with the validation?

rytilahti · 2026-01-26T21:51:31Z

+        self._add_feature(
+            Feature(
+                device,
+                id="lock_battery_level",


If you would use battery_level here, this would be exposed correctly to homeassistant (and other downstreams) without extra configuration. Or would that collide with the battery module on this device?

gwynnebaer · 2026-02-13T02:49:58Z

I am interested in adding DL100 implementation to this effort, for selfish reasons (I have a DL100).
The DL100 does not have a camera, so it fits more of the "this is just a lock" interfaces question (@rytilahti). However, since the DL110 is both a lock and a camera, might be easier to split this into "lock" and "camera" logic?
@cristian-rincon - Do you want to collaborate to update the PR with the feedback above?
It would ideal to solve both devices together.

Add TS15(US) device fixture

Add P105(US) device fixture

…e and remove unused features

…ocks

… files

linkian19 · 2026-03-30T20:09:04Z

Hi there! Saw this PR and am just putting my +1 in for requesting Tapo DL100 support! Let me know if there is any information that I can provide to help out with getting this device added!

Thanks!

Add support for Tapo lock device and implement lock control features

261f824

cristian-rincon changed the title ~~Add support for Tapo lock device and implement lock control features~~ Add support for Tapo lock device DL110 and implement lock control features Jan 15, 2026

cristian-rincon mentioned this pull request Jan 15, 2026

Add support for DL110 #1634

Open

rytilahti added the enhancement New feature or request label Jan 26, 2026

rytilahti requested changes Jan 26, 2026

View reviewed changes

rytilahti added the new device New device supported due to fixture being added label Jan 26, 2026

This was linked to issues Jan 26, 2026

Add support for DL110 #1634

Open

Support for Tapo Door lock Dl100 #1589

Open

ZeliardM and others added 7 commits February 19, 2026 22:46

Add TS15(US) device fixture (python-kasa#1649)

df05e98

Add TS15(US) device fixture

Add P105(US) device fixture (python-kasa#1644)

682c29c

Add P105(US) device fixture

Add L430C(EU) device fixture (python-kasa#1643)

0dff0a9

Merge remote-tracking branch 'origin/master' into feature/dl110

78a43e6

refactor: lock module and CLI commands to use updated module structur…

62648d6

…e and remove unused features

feat: add DL110 smart lock fixture and update tests to exclude door l…

470e860

…ocks

refactor: update JSON formatting and improve code readability in test…

7b5e117

… files

MohitDeshwal mentioned this pull request Apr 21, 2026

Add support for Tapo DL100 Smart Wi-Fi Door Lock (uses DLKLAP encryption over HTTP) #1693

Open

		"SMART.TAPOLOCK": SmartCamDevice,
		"SMART.TAPOLOCK.HTTPS": SmartCamDevice,

Uh oh!

Conversation

cristian-rincon commented Jan 15, 2026

Uh oh!

cristian-rincon commented Jan 15, 2026

Uh oh!

ZeliardM commented Jan 15, 2026

Uh oh!

DocJr90 commented Jan 22, 2026

Uh oh!

rytilahti left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gwynnebaer commented Feb 13, 2026

Uh oh!

linkian19 commented Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants