Add support for Tapo DL100 Smart Wi-Fi Door Lock (uses DLKLAP encryption over HTTP)
Device info
- Model: Tapo DL100 (US), launched June 2025
- Encryption scheme reported by device:
DLKLAP (not currently supported)
- Transport: HTTP port 80 (
is_support_https=False)
- Device family:
SMART.TAPOLOCK
- Login version:
2
Reproduction
Running devtools/dump_devinfo.py against a DL100 on the local network (on feature/dl110 branch from PR #1646, though the same failure happens on master):
python devtools/dump_devinfo.py --host 192.168.x.x --username <email> --password <pass> --autosave
Fails with:
kasa.exceptions.UnsupportedDeviceError: Unsupported device 192.168.x.x of type SMART.TAPOLOCK
with encrypt_scheme EncryptionScheme(is_support_https=False, encrypt_type='DLKLAP',
http_port=80, lv=2)
Forcing --encrypt-type KLAP --device-family SMART.TAPOLOCK is silently ignored because kasa/device_factory.py:200-207 hard-codes DeviceFamily.SmartTapoLock → SmartCamProtocol(SslAesTransport) — so every connection attempt goes to HTTPS/443, which the DL100 doesn't listen on (gets ConnectionRefusedError on port 443).
Why the DL110 support in #1646 doesn't cover DL100
PR #1646 adds the SMART.TAPOLOCK device family, DoorLock device type, and a smartcam Lock module. Those are all above the transport layer. The DL110 uses HTTPS + AES (same as Tapo cameras/doorbells), so reusing SslAesTransport works. The DL100, despite sharing the SMART.TAPOLOCK family string, uses a different transport/encryption entirely (DLKLAP over plain HTTP).
What's needed
- Add
DLKLAP = "DLKLAP" to DeviceEncryptionType in kasa/deviceconfig.py.
- Register
SMART.TAPOLOCK (no .HTTPS suffix) in kasa/device_factory.py's get_device_class_from_family() mapping.
- Implement a new
DlklapTransport in kasa/transports/ — the wire protocol is currently undocumented and will need to be reverse-engineered (Tapo app ↔ DL100 packet capture).
- Update
get_protocol() so SmartTapoLock with encryption_type=DLKLAP and https=False picks the new transport instead of SslAesTransport.
References
Willingness to help
I have a DL100 on my local network and can run any debug captures, test builds, or pcaps that would help an implementer. Happy to test PRs against real hardware.
Add support for Tapo DL100 Smart Wi-Fi Door Lock (uses
DLKLAPencryption over HTTP)Device info
DLKLAP(not currently supported)is_support_https=False)SMART.TAPOLOCK2Reproduction
Running
devtools/dump_devinfo.pyagainst a DL100 on the local network (onfeature/dl110branch from PR #1646, though the same failure happens on master):Fails with:
Forcing
--encrypt-type KLAP --device-family SMART.TAPOLOCKis silently ignored becausekasa/device_factory.py:200-207hard-codesDeviceFamily.SmartTapoLock→SmartCamProtocol(SslAesTransport)— so every connection attempt goes to HTTPS/443, which the DL100 doesn't listen on (getsConnectionRefusedErroron port 443).Why the DL110 support in #1646 doesn't cover DL100
PR #1646 adds the
SMART.TAPOLOCKdevice family,DoorLockdevice type, and a smartcamLockmodule. Those are all above the transport layer. The DL110 uses HTTPS + AES (same as Tapo cameras/doorbells), so reusingSslAesTransportworks. The DL100, despite sharing theSMART.TAPOLOCKfamily string, uses a different transport/encryption entirely (DLKLAPover plain HTTP).What's needed
DLKLAP = "DLKLAP"toDeviceEncryptionTypeinkasa/deviceconfig.py.SMART.TAPOLOCK(no.HTTPSsuffix) inkasa/device_factory.py'sget_device_class_from_family()mapping.DlklapTransportinkasa/transports/— the wire protocol is currently undocumented and will need to be reverse-engineered (Tapo app ↔ DL100 packet capture).get_protocol()soSmartTapoLockwithencryption_type=DLKLAPandhttps=Falsepicks the new transport instead ofSslAesTransport.References
Willingness to help
I have a DL100 on my local network and can run any debug captures, test builds, or pcaps that would help an implementer. Happy to test PRs against real hardware.