v0.13.0

Concurrent live streams per station

• Add maxLiveStreamsPerStation (1 to 4, default 1). Above 1, every further
  concurrent live camera on a station opens its own P2P session, keyed by
  station and channel, with its own STOP confirmation, 120-second cap, abort
  cleanup and disposal. The primary session keeps control, snapshots,
  recordings and the first stream. The same camera twice, a start beyond the
  limit, and recording transfers or mode commands during live still fail with
  station_busy. Default behaviour is unchanged.
• Verified with two concurrent T8160 streams on one T8030, see
  the research note. Three or
  four streams are unverified on hardware.

Read-only local mower session

• Add EufyClient.mowers.openLocalSession(id, { host }) for one authenticated Tuya
  LAN protocol 3.5 session to one discovered E15. queryStatus() returns a copied
  snapshot with source, local observedAt and raw dps. No data point is
  interpreted or written. There is no command, setting, retry, reconnect or
  automatic polling.
• Borrow the private local key from the verified cloud binding only during key
  negotiation and erase it afterwards. Public results never contain the key,
  device ID or host. Every failure is a stable EufyError code without upstream
  detail, and failed or closed sessions release their socket and timers.
• Record every protocol fact with its permitted public source, pinned revisions
  and file digests in Mower transport provenance.
  The frame codec and session-key derivation are reproduced byte for byte with
  tinytuya 1.20.0 and covered by synthetic peer tests. The subsequent
  E15 6.9.28 observations
  confirm bounded local queries, schema retrieval and session cleanup.

Typed mower telemetry

• Add session.queryTelemetry() and the pure decodeMowerTelemetry() that turn
  one snapshot into status, battery, progress and network fields with
  source and observedAt, plus every reported data point typed by the device's
  own declared schema and the raw dps copy. Nothing is inferred from age or
  absence.
• Retain the device's data-point schema from discovery and expose a copy as
  session.schema. Typed values come only from confirmed definitions that also
  conform to the declaration. The shipped E15 registry now includes independently
  observed battery percentage, Wifi and signal percentage. signalPercent is
  additive and keeps DP 109's declared % unit separate from signalDbm.
  Activity, mowing progress and unobserved network modes remain unconfirmed.
  Consumers may pass their own confirmed definitions. See
  typed mower telemetry.

Spontaneous mower reports

• Add session.receiveReport() for bounded, authenticated command-8 reports.
  It preserves full-frame arrival time, distinguishes reports from query replies,
  and returns each report's own data points without merging older values.
• Keep a pending report read alive with transport-only heartbeats. Preserve one
  operation per session, bounded buffering, cancellation, timeout and shutdown.
  No DP refresh, command write, retry or reconnect is added. See the
  report API.

E15 activity report contract

• Establish the DP 107 robot_status envelope from the protocol owner's base64
  raw report path and the public Protocol Buffers encoding rules, verified
  against every retained raw value of the owner-operated windows. Add the pure
  bounded parseMowerWirePayload() and expose its structural result as
  fields[dp].wire for data points named by a wire definition.
• Add the wire decode kind for evidence-gated candidate readings of a raw
  payload. Ship the mowing, paused and returning candidates for DP 107 at
  observed, so status now reports unconfirmed with that level and no
  activity value until three app-correlated reproductions exist. Battery,
  network and the report freshness rules are unchanged. See the
  contract receipt.

Cloud identity renewal

• Discard the cached key-exchange identity and persist the cleared session when
  the Mega cloud answers with result code 4404 or 4416, also when that body
  arrives with a non-2xx status such as HTTP 463. That reset was unreachable
  before because every non-2xx response failed as http_error first, so a
  stored session whose identity had been invalidated elsewhere, for example by
  a key exchange on the same token from another host, failed every restore
  attempt. Observed with camera bridge client 0.12.3 on 2026-09-18 in #157.
• The rejected call now fails with request_rejected, key_exchange_failed or
  authentication_rejected carrying the remote code instead of http_error.
  Every other non-2xx response keeps http_error. No automatic retry is added.
  The next explicit call performs a fresh key exchange.

Upgrade and compatibility

Existing camera and mower APIs, identifiers, persisted sessions and the map
acquisition adapter are unchanged. Consumers that matched http_error for a
rejected cloud identity now receive the remote result code instead. The
MowerAdapter contract is unchanged, so custom adapters keep working and report
mower_protocol_unavailable for local sessions. The local session interface gains schema, queryTelemetry() and receiveReport().
MowerTelemetryValue gains the optional wire property and status definitions gain
the wire decode kind. Consumers that matched status against { state: 'unconfirmed' }
exactly now also see level: 'observed'.
Use the compiled versioned 0.13.0 tarball and its verified integrity from the
GitHub release. maxLiveStreamsPerStation defaults to 1, so consumers keep one
live stream per station until they opt in. Retain the previous package and
lockfile for rollback. The camera bridge pins this release separately in
keesmod/ha-eufy-cam. References #145, #147, #149, #150, #153, #157, #159, #160
and #161.

Source commit: dff52f391a576921914df76c70a58f648b0d2e64

Validation: Validated 2026-09-18. Camera path: default behaviour unchanged, one live stream per station. The new maxLiveStreamsPerStation option was exercised on one T8030 HomeBase 3 (firmware 3.8.7.4) with two T8160 cameras (firmware 3.4.3.0): two concurrent 3840x2160 live streams for 20 seconds at about 15 frames per second each, STOP confirmed by the device on each stream's own session, the first stream unaffected by the second start and stop, a cancel before media confirmed, station telemetry and snapshots intact afterwards, with one controlling client. See docs/research/CONCURRENT_LIVE_2026-09-18.md. Mower additions (read-only local session, typed telemetry, spontaneous reports, DP 107 contract) rest on the owner-operated E15 observations of 2026-09-16 in docs/research. The cloud identity renewal is covered by a test reproducing the observed HTTP 463 with code 4404 and is not yet verified on the affected bridge, which still runs 0.12.3. Unverified: three or four concurrent streams, other station models.

Download checksums and exact component versions are included in the release assets.

v0.12.3

Easier device maintenance

• Consolidate all 51 existing device profiles and per-feature media rules in
  one typed registry. Preserve exact model/type, owner and firmware admission,
  including the four established routes. Snapshot, live and recording
  capabilities retain their independent failures and current public shape.
• Generate and check the software-policy table from the same registry. Existing
  model/topology behavior is characterized before and after the refactor.
  This change adds no model, transport or hardware support claim.
• Give maintainers one place to review a known-family device addition and its
  snapshot, live and recording rules. Characterization tests detect changes to
  existing profiles. New protocols still require implementation and hardware
  validation before support can be claimed.

Late audio discovery

• Keep audio codec discovery open after bounded video-only startup. The first
  late AAC packet is classified and normalized without a second stream-start
  event or camera command. Live handle metadata reflects the observed codec.
• Preserve the three-second startup limit for cameras that send no audio.
  Consumers must explicitly support adding a late audio track. This library
  correction alone does not add audio to an existing browser connection or
  establish T8134 acceptance for camera issue #10.

Upgrade and compatibility

Use the compiled versioned 0.12.3 tarball and its verified integrity. The combined
camera 0.8.19 release consumes
this version. Other consumers must validate their own late-audio handling and
bridge behavior. Public API shapes, identities and admission boundaries remain
compatible. Retain the previous package and lockfile for rollback and preserve
the private credential/session store. No data migration is required.

References #139 and camera #78.

Source commit: 7dec87a39750a814c97370f3271229d0af6731a3

Validation: The 0.12.3 client centralizes the 51 existing device profiles without changing
model/type, owner or firmware admission. Main CI and a complete release rehearsal
pass, including 1106 tests and clean compiled-package validation. The exact
rehearsal artifact passes the combined camera consumer checks. This adds no
hardware support and makes no mower or new-transport claim.

Download checksums and exact component versions are included in the release assets.

v0.12.2

Logging improvements for diagnostics

• Add bounded firmware, hardware and received parent context to rejected security
  inventory rows. Distinguish absent, self, missing, ambiguous and invalid parents.
  Private parent identifiers are only for consumer-side anonymous correlation.
• Preserve model admission, topology guards and mixed inventories. This supplies
  support evidence for camera issue #40 without claiming its cause or a C30 fix.

Source commit: cd859e3c5737d03b7c28de9731e321d531245241

Validation: Logging improvements for diagnostics. Bounded rejected-device firmware and received parent context only. No model admission, protocol or device command changes. All 994 tests and required CI passed in PRs 135 and 136. Camera issue 40 remains open for reporter evidence.

Download checksums and exact component versions are included in the release assets.

v0.12.1

• Add optional bounded deviceModel and deviceType diagnostics to
  unsupported_device discovery issues. Omit invalid values without coercion
  or truncation. Keep existing error codes, identities and model admission.
• Allow consumers to diagnose unknown model/type pairs without logging raw
  inventory. Consumers must still exclude the existing private deviceId field.
• This diagnostic patch follows camera issue #40.
  It does not establish why the reported C30 is missing or add hardware support.

Source commit: 7d72fb0bb1fafa503b54eed28c60a87de91b3c0d

Validation: Diagnostic-only patch for camera issue #40, implemented in PR #134. Model admission, protocol behavior and device commands are unchanged. 993 Node 24 library tests and 55 bridge tests pass against the compiled package, including bounded diagnostics, privacy, mixed inventory and empty-inventory rejection. Reporter C30 hardware validation remains open.

Download checksums and exact component versions are included in the release assets.

v0.12.0

• Combine the unpublished SoloCam discovery/media work with exact H3 profiles
  for Indoor, Floodlight, Wall-light, eufyCam C35, T86P2 in Wi-Fi mode and camera
  functions in three integrated products. Reuse existing attributed protocol
  classes and command paths. Preserve T8134 admission and existing identities.
• Add stored snapshots, live video/audio and recording software coverage only
  behind the actual admitted owner and existing firmware guards. Preserve
  acknowledged stop/cancel, bounded cleanup and independent owners. Missing
  battery or availability observations remain unknown.
• Recognize four wired doorbell and two garage camera model/type pairs with
  explicit standalone/owner blockers. Recognition does not activate their
  missing authentication, events or media. No lock, lid, garage-door, light or
  PTZ controls are added.
• Record reproducible standalone, older-owner, LTE and PoE/NVR protocol limits,
  including a bounded offline descriptor inspector that omits private values.
  Unimplemented connections and unresolved model variants remain open.
• Allow one explicitly tracked unpublished candidate version across related
  runtime PRs. Updated release notes are required. Existing tags, releases or
  drafts and failed remote checks reject that exception. All CI and immutable
  publication checks remain required.
• See the 0.12.0 candidate notes for exact models,
  source evidence, consumer limits and remaining obligations. Software tests
  do not add hardware support or resolve the T8134 audio report. No session
  migration is needed. Retain the previous package, lockfile and private store
  for rollback. This candidate has not been published or deployed.

Source commit: 6fbf2dcb493b6c37739187294211d0545ee1f156

Validation: Camera-only release of reviewed experimental profiles, exact main 6fbf2dc. Release rehearsal 34625446787 passed with 992 Node 24 tests and 34 release tests. Existing attributed protocol paths are reused, with no new wire protocol or session migration. New physical support and audio fixes are not claimed. Existing hardware reports retain their original tested versions. Scope and remaining limitations: https://github.com/keesmod/eufy-mega-client/blob/6fbf2dcb493b6c37739187294211d0545ee1f156/docs/RELEASE_0_12_0.md. Publication and recoverable installation explicitly authorized by the owner.

Download checksums and exact component versions are included in the release assets.

v0.10.0

• Add getCameraCapabilities() for snapshot, live and recording software admission.
  Results use the existing media and owner guards without connecting to devices.
  Available operations remain experimental. Hardware acceptance is unchanged.
• Preserve existing methods and private session stores. No migration is needed.
  Retain the preceding package and store for rollback.

Source commit: 41690f73f1ed4397f378a6eb9ba6612fc41d998a

Validation: Camera consumer package prerequisite #95 for ha-eufy-cam#19. Exact main 41690f7 passed Validate 34577148234 with 452 client tests. Camera capabilities and newly admitted camera profiles are software-validated and experimental. No new hardware support, HA deployment or mower/map acceptance is claimed. Camera hardware #55/#56/#58 and remaining programme obligations stay open. Existing independent session stores and prior-package rollback are preserved. Direct user authorized all necessary camera-chain execution in originating task 01a08f26-abde-7b01-91ae-007914b09c1a, recorded at #7 (comment). Release evidence tracked at #95.

Download checksums and exact component versions are included in the release assets.

v0.1.1

• Include eufyCam S220 / 2C Pro T8142 and SoloCam S220 T8134 in Mega
  discovery when paired with T8030 HomeBase 3. Fixes the model exclusion
  described in ha-eufy-cam issue #10 when using the Mega backend.
• Retain the HomeBase 3 parent requirement and existing device-specific protocol
  commands. Standalone SoloCam operation is outside this change.
• Upgrade the consuming bridge to a release that pins library 0.1.1. Keep the
  previous bridge version and private session backup for rollback.
• S220 hardware validation is pending; automated tests do not establish live
  video, audio, recording or event compatibility.

Source commit: 8cfaeac58ff976b51eb97db6bdc755cf8ecd2b9e

Validation: Discovery-only model inclusion for HomeBase-paired T8142 and T8134; existing protocol commands unchanged. 47 library tests and 57 consuming bridge tests passed locally, and main CI plus release rehearsal passed. S220 physical validation remains pending with the issue #10 reporter; this release does not claim S220 media or event acceptance. Existing T8030/T8160/T8213 hardware acceptance is documented in docs/COMPATIBILITY.md.

Download checksums and exact component versions are included in the release assets.

0.1.0 — Independent Eufy Mega client

An unofficial, independent MIT-licensed Node.js 24 / TypeScript client for Eufy
Mega and the local HomeBase protocol. Tested with T8030 HomeBase 3, three T8160
cameras and a T8213 doorbell through Home Assistant.

Includes fresh authentication and challenges, persistent sessions, discovery,
cover snapshots, live video/audio, detections and recognized names, recording
calendars and complete lists, thumbnails/downloads, observed Guard Mode, and
bounded cancellation and shutdown. Connection credentials are explicit and
there is no legacy cloud fallback. FFmpeg and HA playback remain in the bridge.

Install the compiled GitHub package and commit your application's lockfile:

npm install --save-exact https://github.com/keesmod/eufy-mega-client/releases/download/v0.1.0/keesmod-eufy-mega-client-0.1.0.tgz

This package is not published on npm. SHA256SUMS accompanies the release asset.
See the API guide,
compatibility results
and upstream attribution.

Validation includes 41 protocol/lifecycle tests, real HA playback and cleanup on
all four cameras, a 138-record day, Guard Mode restoration, fault recovery and
an agreed overnight observation of about 11 hours 26 minutes. An auxiliary
observer token defect is documented; HA recorder supplied independent evidence.
This is not a completed 24-hour reliability or battery-life test. Local LAN
discovery is required; other device families and relay-only layouts are untested.