Saves the current PTZ position to a preset

• name Required: Name of the preset. Cannot be empty or a number

Deletes a preset

• preset Required: PTZ preset ID or a Name. See possible presets in entity attributes

tapo_control.set_record_plan updates the weekly recording schedule on cameras that support it. Target one camera entity for the device (HD, SD, or Direct).

• enabled (required): Enable or disable recording. Disabling does not clear the schedule.
• sunday through saturday (optional): Lists of HHMM-HHMM:mode periods in the camera's local time. Mode 1 records continuously; mode 2 records on motion. Use 2400 for the end of the day. Split overnight periods across two days.
• Omitted days remain unchanged. An empty list ([]) clears that day's schedule. Gaps between periods have no recording.

For example, update Monday and clear Sunday while leaving the other days unchanged:

action: tapo_control.set_record_plan
target:
  entity_id: camera.your_camera_hd
data:
  enabled: true
  monday:
    - "0000-0700:1"
    - "0700-2400:2"
  sunday: []

After the call, check the camera entity's record_plan attribute and the schedule in the Tapo app. The Record to SD Card switch reflects whether recording is enabled.

These steps apply even if camera worked before, and now does not (for example, after firmware update).

After every step, test if camera works in HA, and after each step try checking Third-Party Compatibility off and on again.

1. Ensure you have Third Party Compatibility turned on in official Tapo app on your smartphone. Tapo App -> Me -> Third-Party Compatibility -> On
2. Try checking Third-Party Compatibility off and on again and opening the camera via Tapo App, while being on the same network as the camera is.
3. Reset your password.
4. Make sure your camera can access the internet.
5. Reboot your camera a few times.
6. Reset the camera. Remove it from your account, do a factory reset, add it back with internet access, add it back to the integration.
7. If all of this fails (unlikely) repeat from step 1, wait a few hours and try again.

This integration exposes 4 different camera entities:

• HD Stream
• SD Stream
• HD Stream (Direct)
• SD Stream (Direct)

Direct streams use proprietary TP-Link streaming protocol. Non-direct ones use standard RTSP protocol.

Why use the Direct streams?

1. If you have a device which does not have RTSP functionality, it is the only way. This includes battery devices, solar devices, as well as devices working through a hub.
2. If you have used up all your RTSP streams and/or your RTSP streams are unstable in Home Assistant.
3. Direct streams are extremely fast to load and have less than a half a second delay in stream* (*make sure to DISABLE Use Stream from Home Assistant (restart required) in integration options for the fastest experience). Under the hood, the new streams are a binary stream of data "straight to your browser", with no unnecessary translations or overhead.

Configuring Direct stream parameters

Open the integration options, choose Configure device, and edit Direct stream FFmpeg parameters. This advanced YAML mapping overrides parameters for direct streams and snapshots on that device, including both HD and SD. Changes apply when a new stream starts. Reload the integration after saving to stop existing streams.

For example, to try the settings reported for the C560WS in PR #1279:

-probesize: 50000
-analyzeduration: 1000000
-vsync: null

These settings have not been verified across all cameras. To try only removing -vsync, enter just -vsync: null. Set the mapping to {} to restore the original behavior: probe size 32 bytes, analysis duration 0 microseconds, and -vsync 0 for direct MJPEG and snapshots (no -vsync for Home Assistant stream playback).

Supported keys are -loglevel, -probesize, -analyzeduration, -frames:v, -map-video, -vsync, -c:v, and -f, matching the video arguments supported by pytapo. Values must be non-empty strings or numbers; only -vsync accepts null, which omits that flag. Codec, format, frame count, and video mapping overrides also affect snapshots, so changing them can prevent playback or image capture. RTSP streams use the existing Extra arguments for ffmpeg option instead.

Why not use the Direct streams?

If you have an option to use RTSP, it is recommended to stick with RTSP streams.

1. Direct streams take a bit more CPU resources since the device running this integration is now handling the binary stream directly, instead of camera exposing a standardized RTSP stream.
2. Direct streams cannot be used with webrtc card, or go2rtc.
3. RTSP streams are very fast with almost no delay using the webrtc Home Assistant camera card

Motion sensor is added only after a motion is detected for the first time.

It also requires ONVIF support on the device. If the device is not exposing Onvif interface (most likely if it is battery or solar powered), motion events will not work.

If the initial ONVIF connection fails, integration setup continues and ONVIF is retried during camera updates. Motion events and time synchronization require a successful ONVIF connection. Enable debug logging for custom_components.tapo_control to see the camera address, failed operation, initialization duration, and exception traceback. For event subscription failures handled internally by Home Assistant, also enable homeassistant.components.onvif debug logging:

logger:
  logs:
    custom_components.tapo_control: debug
    homeassistant.components.onvif: debug

• Make sure the camera has motion detection turned on
• Make sure the camera has privacy mode turned off
• Make sure the camera can see you and your movement
• If you have webhooks enabled, and your Home Assistant internal URL is reachable on HTTP, make sure camera can reach it.
• Make sure you have correct IP set for Home Assistant. Turn on Advanced Mode under /profile. Go to /config/network and under Network Adapter verify correct IP is shown for the device. If it is not correct, under Home Assistant URL uncheck Automatic next to Local Network and set it to http://<some IP address>:8123. DO NOT USE HTTPS.
• Certain camera firmwares have pullpoint broken, with only webhooks working. If you are not able to run webhooks because of above (https, or vlan setup), binary sensor will never show up.
• Try walking in front of the camera
• If above didn't work, restart the camera and try again

Also make sure that:

• binary sensor is not disabled via entity, check .storage/core.entity_registry for disabled entities, look for "disabled_by": "user" on platform "tapo_control". If it is, remove the whole entity or change to "disabled_by": null, and restart HASS.
• binary sensor is enabled in tapo integration options
• onvif port 2020 on camera is opened
• onvif on camera is not being used more than once concurrently, and is only used by this integration

This is a known issue of Home Assistant.

There is an ability to disable usage of Home Assistant Stream component for the camera, which might lower the delay very significantly at cost of higher CPU usage.

You can choose to disable stream component when adding the camera, or via Options when camera has already been added. This change requires a restart of Home Assistant.

There might be some disadvantages to doing this, like losing option to control playback and a higher CPU usage. Results depend on your hardware and future Home Assistant updates.

If you disable stream and your hardware is not up to the task, you will get artifacts, bigger delay and freezes.

If you wish, try it out and see what works best for you.

Another possibility is using WebRTC Camera by AlexxIT.

Example working configuration:

type: custom:webrtc-camera
entity: camera.bedroom_hd

Supported audio codecs in Home Assistant are "aac", "ac3" and "mp3".

Tapo Cameras use PCM ALAW (alaw) which is not supported.

More details here.

You can get sound working using WebRTC Camera by AlexxIT.

Example working configuration:

type: custom:webrtc-camera
entity: camera.bedroom_hd

You might be entering incorrect password or are encountering a camera limitation.

• Check logs for any error messages
• Check that HA can reach the camera on ports 554 and 2020

Finally, most likely issue, see official Tapo documentation

Q3: Can multiple accounts/devices view the Tapo camera at the same time?

A: Currently, each camera can be controlled or managed by only one account on the Tapo App. You can share it with 5 different accounts at most, and these two accounts can only access live view and playback features of the camera.

Each camera also supports up to 2 simultaneous video streams. You could use up to 2 devices to view the live feed of the camera simultaneously using the Tapo App or via RTSP. You may also only view the playback of a camera using one Tapo app at a time.

As well as:

Q4: Why can’t I use Tapo Care, SD card, and NVR at the same time?

A: Due to the limited hardware performance of the camera itself, Tapo Care works best with one of the NVR or SD card recordings.

If you are using an SD card and Tapo Care at the same time, the NVR(RTSP/ONVIF) will be disabled.

To restart the recording on the NVR, please remove the SD card from the camera.

Users reported full functionality with following Tapo Cameras, Doorbells and Chimes:

• TC55
• TC60
• TC70
• TC(A)72NL/EU
• TC82
• TC85
• C100
• C110
• C120
• C200
• C201
• C206
• C210
• C211
• C216
• C220
• C225
• C236
• C260
• C310
• C320WS
• C401
• C402
• C403
• C410
• C420
• C420S2
• C425
• C460
• C500
• C510W
• C520WS
• C530WS
• C610
• C710
• C720
• D100C
• D130
• D205
• D230
• D235

The integration should work with any other Tapo Camera based devices and chimes.

If you had success with some other model, please report it via a new issue.

Note: If the device is not exposing Onvif interface (most likely if it is battery or solar powered), motion events will not work.

Camera uses ONVIF standard to communicate motion events. This communication can work with 2 ways:

1. Pullpoint: Client opens connection to the camera and waits until the camera responds. Camera responds only when there is some event to communicate. After camera responds, client reopens the connection and waits again.
2. Webhook: Client tells the camera its URL to receive events at. When an event happens, camera communicates this to the URL client defined.

Webhooks are the preffered method of communication as they are faster and lighter. That being said;

• Webhooks require an HTTP only HA setup because Tapo cameras do not support HTTPS webhooks
• Webhooks require a proper base_url to be defined in HA, so that the URL communicated is correct (you can check URL sent by enabling debug logs for homeassistant.onvif)

Points above are automatically determined by this integration and if the HA does not meet the criteria, webhooks are disabled. That being said;

• There are camera (and/or firmwares) which freeze when both webhooks and pullpoint connection is created, which happens at the start to see if webhooks is supported at all so that communication can fallback back to pullpoint.
• There are camera firmwares which have pullpoint broken (1.3.6 C200) and only webhooks work

For webhooks to work, all the user needs to do is make sure he is using HA on HTTP and that the HA is available on the URL communicated.

Yes, the integration is free and does not require any paid subscriptions. It is also fully local requiring no internet access from the camera or this integration.

Firmwares of cameras expect messages in sequential order. Sending them in parallel can lead to 401 code from camera which shows us with this exception.

You will need to send the automation actions in sequence instead, possibly with delay as well if needed.

See https://github.com/JurajNyiri/HomeAssistant-Tapo-Control/issues/488 for more information.

Due to unknown root cause some cameras behave differently than others when setting time through ONVIF standard and so far no root cause was found.

Setting time is not possible through the official application and this integration uses an undocumented and unsupported camera functionality through ONVIF standard.

If the time is set incorretly, eg. 1 hour ahead:

1. Ensure correct timezone is set both for Home Assistant and device
2. If still experiencing issue, navigate to /config/integrations/integration/tapo_control
3. Click on Configure under device you wish to synchronize time for
4. Select Configure time synchronization, Submit
5. Adjust the time offset either for period of DST, or outside of DST