Added elecram ramses esp quirk

[IMMRMKW]

Proposed change

For the project ramses_cc I am working on Zigbee communication for my Ramses ESP board. Until now, only serial and MQTT communication was possible.

Additional information

The device supports two custom clusters, in similar fashion as the MQTT communication. One cluster is for sending received messages to Ramses RF, the other for receiving messages from Ramses RF.

Device diagnostics

diagnostics.txt

Checklist

[x] The changes are tested and work correctly
[x] pre-commit checks pass / the code has been formatted using Black
[x] Tests have been added to verify that the new code works
[x] Device diagnostics data has been attached

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.67%. Comparing base (23015b4) to head (d414ca6).
⚠️ Report is 31 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #4782      +/-   ##
==========================================
+ Coverage   92.35%   92.67%   +0.31%     
==========================================
  Files         371      381      +10     
  Lines       12234    12789     +555     
==========================================
+ Hits        11299    11852     +553     
- Misses        935      937       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Adds a new ZHA quirk for the ELECRAM “Ramses_esp32c6” device to support its custom RX/TX Zigbee clusters, along with initial test coverage to validate the quirk signature and cluster wiring.

Changes:

• Added RamsesESP v1 quirk and two custom clusters (RamsesRXCluster, RamsesTXCluster) using manufacturer-specific cluster IDs.
• Introduced the zhaquirks.elecram package.
• Added tests validating signature matching, cluster replacement, and command definitions.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
zhaquirks/elecram/ramses_esp.py	Implements the ELECRAM Ramses ESP quirk and custom clusters.
zhaquirks/elecram/init.py	Adds the new manufacturer package initializer.
tests/test_elecram.py	Adds tests for signature matching, cluster replacement, and command IDs.

[Copilot]

The package docstring appears to be copy/pasted from zhaquirks/aurora (it says "Aurora devices"), which is misleading for the new elecram quirks package. Please update it to describe ELECRAM/Elecram devices (or RAMSES ESP specifically).

Suggested change

	"""Module for Aurora devices."""
	"""Quirks for Elecram (ELECRAM) devices, including RAMSES ESP-based hardware."""

[Copilot]

tests/test_elecram.py imports zhaquirks.elecram.ramses_esp but never uses that name, and the subsequent from zhaquirks.elecram.ramses_esp import ... already imports the module. This will trigger Ruff F401 (unused import). Remove the redundant import zhaquirks.elecram.ramses_esp line (or reference it explicitly if you really need the side effect).

Suggested change

import zhaquirks.elecram.ramses_esp

[Copilot]

The quirk signature endpoint definition omits DEVICE_TYPE. In this codebase, v1 quirks typically include DEVICE_TYPE for each endpoint (e.g., zhaquirks/texasinstruments/router.py:38-48, zhaquirks/aurora/aurora_dimmer.py:75-83). Consider adding the device type from diagnostics (your test signature shows 0x0000) to make matching more specific and keep endpoint metadata consistent.

[Copilot]

The replacement endpoint definition also omits DEVICE_TYPE. If the original device type is important for ZHA entity creation/metadata, leaving it out can lead to inconsistent behavior. Add DEVICE_TYPE here as well (matching the device’s actual type from diagnostics) to align with other v1 quirks.

[puddly]

A few questions:

• This device communicates via character strings. Is the protocol ASCII or can it be condensed? Why not use dedicated Zigbee command IDs for device functionality instead of tunneling an entire protocol?
• How much traffic is exchanged? Zigbee is not a very high bandwidth protocol.
• I noticed mention of ACK strings in both directions. How are they used? Zigbee has an APS ACK bit that you can flip to ask for a delivery receipt. You can also use the default response to convey status codes.

[IMMRMKW]

@puddly

1. Yes, the protocol is ASCII. I tried to stay as close as possible to the original protocol as possible which is via USB serial, and MQTT. The device is basically a gateway passing on commands that come via Serial/MQTT/Zigbee to 868 MHz communication. The huge variety of commands and devices that use this protocol and could potentially be communicated with make it impractical to do it another way. This is also how Ramses cc expects it.
2. This depends on the number of devices, but let's say 1 message every 1-2 minutes.
3. As far as I know, the maximum character string length is limited. I thought ZHA is limiting it to like 64 or so, and ESP32 C6 would allow it but the buffer would every once in a while crash. As I did not manage to use this flag you are mentioning in the state machine, I explicitly send an ACK back to manage the flow of the program and prevent the buffer from being filled before a previous message is sent.