[tomquist]

• Added VNSA (Venus A) device type support for issue Add support for VNSA device type (Venus A) #121
• Added VNSD (Venus D) device type support for issue Pls Add support for Venus D (VNSD-0) #111
• Both device types added to deviceTypes array in src/types.ts

Summary by CodeRabbit

• New Features

  • Added support for two additional Venus series models (VNSA, VNSD), expanding compatible devices.

• Bug Fixes

  • Improved error message for a specific authentication failure to be clearer to users.

• Chores

  • Standardized firmware compatibility checks across Venus series devices.
  • Updated release/changelog and addon version handling to surface a "Next" state for upcoming releases.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds new Venus device types (VNSA, VNSD) and corresponding min-version entries, broadens firmware-compatibility check from VNSE3-only to any VNS-prefixed devices at the same firmware threshold, and adds a short-circuit error handling branch for API response code "4". Also updates release and addon/versioning automation and changelog insertion.

Changes

Cohort / File(s)	Summary
Device type definitions src/types.ts	Added "VNSA" and "VNSD" to the exported deviceTypes constant (expands DeviceType union).
Firmware compatibility logic src/topic.ts	CommonHelper.isSupportVid() updated: VNSE3-specific check replaced with startsWith("VNS"), applying existing 139.0 firmware threshold to all VNS-series devices; clarifying comment added.
Broker/version data brokers.json	Added VNSE3: 0, VNSA: 0, and VNSD: 0 under hame-2025.min_versions.
API error handling src/hame_api.ts	fetchDeviceToken now short-circuits when data.code == "4", throwing a descriptive "incorrect password" error before generic validation.
Release & changelog automation release.sh, CHANGELOG.md	release.sh updated to set hassio-addon/config.yaml version to next, insert a [Next] changelog section, stage changes and conditionally amend the develop-sync commit; CHANGELOG.md gains a new "Next" subsection insertion.
Addon manifest version hassio-addon/config.yaml	Version field changed from "1.3.2" to "next".

Sequence Diagram(s)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• Add support for VNSA device type (Venus A) #121: Matches change request to add VNSA (and related VNS handling) to src/types.ts and broaden VNS firmware detection.

Possibly related PRs

• Ensure develop sync updates amend into single commit #110: Similar changes to release.sh (setting addon version to next, inserting [Next] changelog section, conditional amend).
• feat: Add support for latest firmware versions #86: Related to adding VNSE3/VNS handling and device-type/version updates (touches same device/type data and topic logic).
• Improve incorrect credential error messaging #114: Modifies fetchDeviceToken error handling for API response code "4", matching the same code-path adjustment.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change in the pull request, which adds support for two new device types (VNSA and VNSD) across multiple files including types, brokers configuration, and device handling logic.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/add-device-types-Ieuj9

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/hame_api.ts (1)

190-194: Document the Hame API response code meaning and verify it corresponds to incorrect password.

The error handling for code "4" is logically sound, but lacks documentation. The Hame API response codes are not documented anywhere in the codebase. Add a comment explaining what this code represents for future maintainability:

// Code "4" indicates incorrect password from Hame API
if (data.code === "4") {
  throw new Error(
    `Incorrect password for ${mailbox}. Please double-check the credentials configured for the add-on and try again. (${data.code} - ${data.msg})`,
  );
}

Additionally, confirm this change aligns with the PR scope—it appears unrelated to the recent work on Venus firmware 139 encryption support.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ccaa251 and af1f604.

📒 Files selected for processing (7)

• CHANGELOG.md
• brokers.json
• hassio-addon/config.yaml
• release.sh
• src/hame_api.ts
• src/topic.ts
• src/types.ts

✅ Files skipped from review due to trivial changes (2)

• CHANGELOG.md
• hassio-addon/config.yaml

🚧 Files skipped from review as they are similar to previous changes (3)

• src/topic.ts
• brokers.json
• src/types.ts

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: tomquist
Repo: tomquist/hame-relay PR: 86
File: src/types.ts:6-19
Timestamp: 2025-10-03T08:30:57.007Z
Learning: Device type names in src/types.ts (including VNSE3) are manufacturer-defined and cannot be modified to follow a consistent naming pattern. The codebase must accommodate both HM* prefixed types and manufacturer-specific names like VNSE3.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: build-addon (linux/arm64)
• GitHub Check: build (linux/arm64)
• GitHub Check: build-addon (linux/arm/v7)
• GitHub Check: build (linux/arm/v7)

🔇 Additional comments (3)

release.sh (3)

178-189: LGTM! Clean tracking logic for version updates.

The needs_amend flag correctly tracks whether changes were made to the config file. Using git diff --quiet to detect actual changes avoids unnecessary amends when the version is already set to 'next'.

---

205-210: Confirm that amending the merge commit is the intended workflow.

The script amends the develop-sync merge commit (line 176) to include version and changelog updates. While this keeps changes atomic, amending a merge commit can cause history divergence if others have already pulled develop. In a controlled CI/CD environment or with proper coordination, this approach is acceptable.

Please confirm:

1. Is this script typically run in a controlled environment (CI/CD, single release manager)?
2. Are team members aware not to pull develop until the release completes?
3. Would creating a separate "prepare for next development" commit be preferable to amending?

---

191-203: The sed insertion point is correct for the CHANGELOG.md structure.

The assumption about the first line containing the changelog title (# Changelog) is accurate, and the sed command '1a\' correctly inserts the new [Next] section after it. The multiline syntax with backslashes is properly formatted and compatible with macOS. The grep-based condition also prevents duplicate [Next] sections from being inserted.