Tuya BLE v0.10.0b2

Tuya BLE 0.10.0b2 — limited-scope beta

Changes since published v0.10.0b1

This beta combines the reviewed S1 last-confirmed-state work, metadata-only
Device Status observations, and the explicit Refresh Status button.

• Battery, Auto-Lock, Authentication Mode and Auto-Lock Delay retain their last
  valid device-confirmed values after disconnect. Attributes data_fresh,
  last_confirmed_at and value_source distinguish a current-session reading
  from stale retained or safely restored state. Writes are not confirmations.
• Last Status Update is diagnostic and tracks only these four datapoints.
  Confirmation times are monotonic UTC whole seconds; equal timestamps within
  one second are valid. Restored state is validated per entity and remains
  stale until confirmed again. Other products do not inherit this S1 model.
• Device Status request, exact-session ACK and DP-batch chronology are recorded
  without payload values or persistent device identities. Wrong response codes
  and overlapping requests cannot claim another request's outcome. Batch
  chronology does not prove every DP was caused by the status request.
• Refresh Status sends exactly one explicit status request per accepted press,
  with no automatic retry or replay. It can reuse the authenticated session and
  uses the normal configured On-Demand hold. Concurrent presses are rejected.
  Conditionally absent DPs preserve their previous value and confirmation time.
  A DP69-only batch can complete the protocol without newly confirming battery
  or configuration, and without advancing Last Status Update. This is not an
  instruction to refresh every mapped DP, nor a background polling feature.

The earlier connection-policy, control, transport and migration features of
v0.10.0b1 remain
included. The default hold is still 15 seconds, not 105. No new defaults,
lock commands, observer tooling or research harness are added by this release
preparation. All 37 integration paths match tested PR47 except manifest version
0.10.0b1 → 0.10.0b2; production Python contents are unchanged.

Owner-approved hardware boundary

One full COLD → RETAINED → RELEASE pair passed on one selected S1 at 105
seconds hold, with authenticated-session reuse, target continuity, normal
release, no observed automatic reconnect and no owner-observed mechanical
change. The full repetition matrix is incomplete. At least one further
owner-reported press has no usable observer association; that product outcome
is unassessed, not a pass or proven product defect. No separate Lock/Unlock
follow-up was tested. There is no complete retained hardware proof at default
15 seconds, nor a long-term, battery-life or success-rate claim.

The owner accepted this limited scope for beta preparation and deferred the
missing repetition/follow-up evidence. This is not a complete hardware PASS
or stable acceptance. See the exact acceptance record.

Upgrade and return

Before an owner-directed installation, create a full Home Assistant backup and
record the current version and relevant automation choices. No backup or
installation is performed by this release-preparation task. In HACS explicitly
show beta versions and select v0.10.0b2 after publication; follow the normal
download/restart workflow. Do not edit HACS or Home Assistant .storage files.

Existing settings and entity ownership remain in place. Treat restored values
as stale, not as a new reading or proof of physical lock state. Update
state-sensitive automations to inspect freshness attributes; a visible retained
Auto-Lock value is no longer synonymous with a live connected device. Battery
history/statistics can contain retained observations, not new measurements.
Refresh does not recover missed events unless the device later reports them.

To leave this beta, explicitly select the previous published v0.10.0b1 in
HACS and follow its normal reinstall/restart process; adjust automations that
refer to new entities/attributes. Stable v0.9.0 remains separately available,
but predates the 0.10 connection-policy feature set. Do not assume a source
downgrade reverses saved HA settings. Use the pre-upgrade full backup when a
complete prior HA state is required. Keep another authorized access route for
owner-directed lock-integration changes. No stable/latest promotion is implied.

Published from reviewed candidate 6ee8a8fe6b505f64f4ec770638d9768b0511c094 through merge b47f370d0e48f12cfd33391a958a5f1f81eb02b7, tree 2eb5c06b530a3882065cd66f414acd040b2fb28f. See PR #48. No Home Assistant or device operation was performed for this publication.

Tuya BLE v0.10.0b1

Tuya BLE v0.10.0b1

Summary

This prerelease contains the complete delta from stable v0.9.0 through the
reviewed next state, not only PR #34. It introduces the reviewed connection
policy, transport/lifecycle hardening, compatibility fixes, and S1 hold-time
work while preserving the unaffected Tuya BLE product set. Stable v0.9.0
remains available.

Connection policy

The reviewed S1 and V1 smart-lock products now expose Always Connected and
On Demand modes, a persistent Home Assistant BLE Control switch, and an
authenticated Bluetooth Connection diagnostic. Existing saved policy
choices are preserved.

On Demand connects for explicit work and sends no periodic keep-alive. A
successful intentional release schedules no reconnect and does not increase
reconnect-failure pressure. Active leases and response drains protect complete
operations and physical release ownership. S1 Always Connected does not gain a
periodic keep-alive in this release; its peer/application inactivity behavior
remains relevant.

S1 On-Demand hold time

S1 adds an On-Demand Connection Hold Time number from 15 to 105 seconds,
defaulting to 15 seconds and applying only in On Demand mode. Its deadline uses
the latest successfully confirmed activity in the exact authenticated session.
The same owner protects the complete DP70, required delay, and DP71 Unlock
operation. V1 and unrelated products do not use this S1 timer.

S1 reliability and presentation fixes

The beta includes exact-session Device-Info bootstrap, same-session template
selection after connection, at-most-once command handling, truthful release
ownership, bounded S1 failure pressure, and whole-percentage presentation for
integral battery values. Invalid percentages remain unavailable and explicitly
configured display precision is retained.

V1 and unrelated-device compatibility

V1 Lock/Unlock transport and command semantics remain the reviewed v0.9.0
behavior. The V1 registry migration preserves legitimate cross-cutting Home
Assistant option namespaces. Open remains unsupported where it was already
unsupported. No registered product or platform mapping was removed, and
unaffected upstream products retain their behavior.

Security and privacy

Control remains fail closed. Ambiguous commands are not replayed, unavailable
S1 template material performs no command write, and stale callbacks cannot
mutate replacement sessions. This release contains no credentials, complete
private identifiers, packet contents, lock values, S1 template material, Store
records, raw private logs, or private Home Assistant timestamps. Production
logging retains its nonpersistent process-local opaque-label boundary.

Upgrade and installation

This is a prerelease. HACS users must explicitly show/select beta versions and
verify v0.10.0b1 before downloading. Create a full Home Assistant backup
before installation. Do not edit HACS or Home Assistant .storage files.
Existing persisted connection-policy choices are preserved.

Use S1 On Demand where continuous event capture is unnecessary. It can reduce
persistent GATT and proxy use, but repeated connection setup also consumes
energy and local access or alarm events can be missed while disconnected. Use
Always Connected when continuous access-event monitoring is required.

See the smart-lock guide,
the upgrade guidance,
and the complete comparison.

Validation

• Python 3.14.6 / Home Assistant 2026.7.4: 503 passed, 0 skipped, 157 warnings.
• Python 3.13.11 / Home Assistant 2025.1.4: 501 passed, 2 expected skips, 157 warnings.
• Focused connection policy, hold-time, S1/V1 transport, migration, Store,
  privacy, security, shutdown, product-regression, and release assertions:
  442 passed on the newer environment; 440 passed and 2 expected skips on the
  older environment.
• Compileall, Black 24.8.0, Codespell, JSON/JSONC/YAML, Actionlint, official
  Hassfest, HACS validation, Gitleaks, archive safety, and exact runtime identity
  passed. Ruff improved from 24 to 2 findings with no new category. Mypy 0.901
  retained the same baseline internal error and is not reported as passing.
• Release preparation changes six metadata, documentation, and assertion files.
  All 27 production Python paths/blobs remain byte-identical to reviewed
  next@6f9f55b646069e2ddf96fce4acd2d4c5db0d25a7.

Hardware scope and limitations

Issue #29 physical evidence came from one selected S1; no claim is made that
all four S1 devices exercised every command path. W15, W100, and W105 passed
three times each, and dynamic 105-to-15 and 15-to-100 changes passed. One
owner-operated cold Lock and one warm same-session Unlock each produced exactly
one physical action.

The final confirmed-activity timestamp of that physical run was not
independently exposed. The 105-second production timer contract was established
by the separate non-actuating W105 runs against the same reviewed runtime. No
S1 battery-saving percentage, battery-life improvement, stable Always-Connected
battery profile, complete On-Demand event capture, or vendor-firmware-internal
behavior is claimed.

Beta/soak guidance

Observe connection ownership, expected event visibility, and battery behavior
under your normal usage before relying on this beta. Stable promotion to
v0.10.0 is a separate future decision; this prerelease does not modify
main or replace stable v0.9.0.

v0.9.0

Tuya BLE v0.9.0

This is the first stable release of the maintained downstream 0.9 line. It
supersedes v0.9.0b1, v0.9.0b2, and v0.9.0b3 for installation while
retaining the unaffected upstream Tuya BLE product set.

Smart-lock support

• Adds product-specific S1-TY-BLE-PRO Lock and Unlock using complete DP70/DP71
  templates learned from the same device and held in a private, atomic,
  mode-0600 Home Assistant Store. Missing, incomplete, conflicting, or
  cross-device material fails closed; there is no product-wide fallback.
• Adds product-specific V1 / Lock P1 bidirectional control. Lock sends one DP46
  Boolean true secure/uncouple action; Unlock builds the observed two-field
  DP6 access/couple action for each request. Open remains unsupported.
• Keeps DP33 as Auto-Lock configuration and DP47 as a read-only physical-state
  source. V1 is represented by a Lock entity, and S1 Motor State is represented
  by a read-only binary sensor with an ownership-safe registry migration.

Security and privacy

• Removes embedded complete unlock payloads and cross-device S1 template
  fallback material.
• Replaces the beta releases' deterministic, address-derived, twelve-hex log
  pseudonym with a non-persisted process-local opaque label that changes with a
  new Home Assistant process.
• Sanitizes transport exception paths so identifiers and credentials do not
  re-enter Tuya BLE logs through exception text.

Compatibility and validation

• Requires Home Assistant 2026.5 or later for the maintained downstream support
  contract. Back up Home Assistant before upgrading and follow the repository's
  upgrade guide; do not edit Home Assistant or HACS .storage files.
• Preserves the documented v0.1.11b2 migration path, config entries,
  credentials, device ownership, S1 Store records, entity associations, user
  customizations, and unaffected upstream products.
• The exact v0.9.0b3 runtime passed supported HACS installation, two
  restart-window privacy gates, owner-operated V1 Lock/Unlock testing, and one
  representative S1 Lock/Unlock hardware smoke cycle. Each tested command
  produced exactly one expected physical action. This is deliberately not a
  claim that all four S1 devices were physically exercised.
• A final non-actuating Home Assistant Core 2026.7.4 restart loaded all five
  custom Tuya BLE entries with no custom Tuya BLE reauthentication. The
  separate built-in Tuya integration did not request QR reauthentication on
  that final restart. No global Home Assistant no-reauthentication claim is
  made.
• Python 3.13.11 / Home Assistant 2025.1.4: 200 passed, 2 skipped.
• Python 3.14.6 / Home Assistant 2026.7.4: 202 passed.
• GitHub Actions, HACS, Hassfest, Black, Codespell, Ruff, compileall,
  Actionlint, Gitleaks, documentation links, JSON/JSONC/YAML, archive checks,
  release assertions, and a fresh independent exact-head review passed.

Stable release preparation changed only the manifest, changelog, and release
assertions. All 27 integration Python files are byte-identical to v0.9.0b3;
no additional stable installation or hardware test was required for this
metadata-only promotion.

No raw log, real identifier, credential, lock payload, packet, frame, template,
or capture is included in this release.

v0.9.0b3

Tuya BLE v0.9.0b3

This beta supersedes v0.9.0b1 and v0.9.0b2 for installation.

Earlier betas used a deterministic, address-derived, twelve-hex log pseudonym. Although it was not the literal BLE address, it was stable, linkable, and address-shaped, and therefore did not meet the downstream privacy policy.

Security and privacy

• Replaces the persistent address-derived pseudonym with a process-local opaque device label.
• The label is not derived from a persistent identifier, is not stored, and changes with a new Home Assistant process, preventing correlation through that label across restarts.
• Sanitizes transport exception paths so device identifiers and credentials do not re-enter Tuya BLE logs through exception text.
• Includes current security, logging/privacy, upgrade, smart-lock, contributor, and release guidance.

Behavior invariants

This release does not change V1, S1, generic-device, BLE-command, entity, Home Assistant Store, or registry behavior. In particular, the previously hardware-validated V1 DP46 Lock, product-specific DP6 Unlock, read-only DP47 state, unsupported Open, and at-most-once ambiguous-error contract are unchanged. The S1 same-device DP70/DP71, private Store, and fail-closed boundaries are also unchanged.

Validation

• Python 3.13.11 / Home Assistant 2025.1.4: 200 passed, 2 skipped.
• Python 3.14.6 / Home Assistant 2026.7.4: 202 passed.
• GitHub Actions, HACS, Hassfest, Black, Codespell, Actionlint, Gitleaks, documentation links, JSON/YAML, and release assertions passed.
• A fresh independent exact-head release review passed.
• Integration Python files at the release-preparation head are byte-identical to its reviewed base.

Create a full Home Assistant backup before installation. In HACS, explicitly select the v0.9.0b3 prerelease and verify the shown version before downloading. Do not edit Home Assistant or HACS .storage files.

No raw log, real identifier, credential, lock payload, frame, template, or capture is included in this release.

Tuya BLE 0.9.0b2

Superseded by v0.9.0b3 because earlier betas used a persistent, address-derived log pseudonym that did not meet the downstream privacy policy.

This beta adds product-specific bidirectional coupling control for V1 / Lock P1
on top of v0.9.0b1. It retains all S1 and unaffected upstream behavior.

Fixed

• Presents the V1 manual_lock control as a Home Assistant Lock entity instead
  of a one-way button while preserving its registry identity, device ownership,
  customizations, and restart persistence.
• Uses the physically confirmed protocol-v3 command contract: Lock sends the
  product-specific DP46 Boolean true secure/uncouple action, while Unlock
  builds the observed two-field DP6 access/couple action semantically.
• Requires an exactly correlated sender-DPS response with a one-byte zero status
  and prevents automatic command replay after ambiguous transport failures.
• Keeps DP33 exclusively as Auto-Lock configuration and DP47 exclusively as the
  read-only physical state source. Open remains unsupported.

Security and compatibility

• Stores no captured V1 command, complete payload, or additional device secret.
  Fresh protocol framing is used for each command; receiver-side rejection of
  externally replayed ciphertext is not claimed.
• Keeps the S1 and generic lock paths on their existing response and retry
  behavior, and retains every unrelated product mapping.
• Exact runtime head 5bfbd7c0b9a67cd1416ee3a21b6acdc5ea4a968c
  passed non-actuating Home Assistant 2026.7.4 validation, complete physical
  V1 Lock/Unlock cycles, exactly one motor action per command, distinct expected
  motor directions and sounds, restart persistence, and a representative S1
  Lock/Unlock smoke test.

Release preparation changes only manifest, changelog, and test metadata. The
integration's Python runtime remains byte-identical to the hardware-tested head.

Tuya BLE 0.9.0b1

Superseded by v0.9.0b3 because earlier betas used a persistent, address-derived log pseudonym that did not meet the downstream privacy policy.

This downstream beta is based on ha-tuya-ble/ha_tuya_ble 0.8.1. It retains
every upstream product registration and unaffected device mapping. The embedded,
device-specific raw-DP71 Unlock actions for jtmspro/hs21i377 and
jtmspro/kholoaew are intentionally withdrawn; those product registrations and
their other evidenced behavior remain.

Highlights

• Adds S1-TY-BLE-PRO support with unified S1/V1 entity presentation.
• Captures, validates, and persists same-device DP70/DP71 templates for
  serialized S1 Unlock handling.
• Removes embedded complete unlock payloads and cross-device or product-wide
  fallback material.
• Uses private, atomic S1 Store handling; regular Store files are protected with
  mode 0600 before loading, while symlinks, FIFOs, directories, and other
  special paths fail closed.
• Replaces writable Motor State switches with read-only binary sensors and
  provides ownership-safe, collision-safe, idempotent registry migration.
• Preserves upgrade compatibility for existing v0.1.11b2 config entries,
  credentials, Store records, devices, entities, and customizations.

Hardware scope

Exactly one of four S1 devices was physically tested against the byte-identical
release runtime: Lock PASS, Unlock PASS, exactly one physical action per command
PASS, and Motor State read-only PASS. The other three devices were not
physically retested at that exact runtime head; no four-device physical-success
claim is made.

Known V1 limitation

V1 / Lock P1 remains intentionally one-way: DP46 true secure/uncouple only.
Coupling/Unlock and Open are not implemented. DP33 remains Auto-Lock
configuration, DP47 remains read-only, and no DP60/DP61 control is included.

Deployment status

Publishing this prerelease does not install it on Home Assistant. The already
tested runtime remains installed and continues to report manifest version
0.8.1; HACS may show v0.9.0b1 as available.

v0.1.11b2

Tuya BLE 0.1.11b2

This second beta aligns the Home Assistant presentation of the supported
S1-TY-BLE-PRO and V1 smart locks while retaining their different physical
capabilities.

Changed

• Shared entities now use matching visible names, icons and Home Assistant
  categories.
• Both lock controls are displayed as Lock with mdi:lock.
• S1 remains a bidirectional LockEntity; V1 remains a one-way lock-only
  ButtonEntity.
• Auto-Lock, Auto-Lock Delay and shared diagnostics use the agreed canonical
  presentation.

Fixed

• S1 Motor State is now a read-only diagnostic binary_sensor instead of a
  writable switch.
• Existing S1 Motor State registry entries are migrated before platform
  registration.
• Supported cross-domain customization is retained.
• Switch-domain options and switch device-class overrides are deliberately
  not copied into the binary sensor.
• Existing binary-sensor target-domain options and device-class overrides
  remain authoritative.
• The migration is idempotent and converges old/new duplicate states to one
  binary sensor.

Compatibility notice

The S1 Motor State entity domain changes from switch.* to
binary_sensor.*. Automations, scripts, dashboards and voice-assistant
configuration that directly reference the old entity ID may require
updating.

Physical command behavior is unchanged:

• S1 Lock still uses DP 46.
• S1 Unlock still sends DP 70 followed by DP 71.
• V1 Lock still writes DP 46 true exactly once.
• V1 local Unlock remains unsupported.

This is a beta release. Hardware retesting on both supported locks is still
required.

v0.1.11b1

Tuya BLE v0.1.11b1

First public beta of the maintained c7fen fork.

Included

• V1 Smart Lock / Lock P1 local support
• Expanded S1-TY-BLE-PRO entities
• Last Unlock Method correctness fix
• JTMSPRO privacy and logging hardening
• HACS, Hassfest, test, and secret-scan CI
• Corrected installation and safety documentation

Important limitations

• V1 local unlock is not implemented.
• S1 Motor State remains the legacy switch pending registry migration.
• Sound, LED, iBeacon, temporary-password, and offline-password controls are
  not implemented.
• Real V1 and S1 hardware validation is still pending.

Test safety

• Create a Home Assistant backup before installing the beta.
• Test with the physical door open.
• Keep another authorized access method available.
• Validate read-only entities before invoking motor or lock commands.

Automated validation

• Python 3.14.6
• Pytest: 59 passed, 1 warning
• Hassfest: success
• HACS: success
• Secret scan: success

v0.1.10

Stable baseline release preceding the V1 and expanded S1 smart-lock beta.