Renpho ES-CS20M communication fixes (with Claude help)

[davidhildebrand]

This fixes issue #1190 for Renpho ES-CS20M scales, similar to the PR #1243 fix for QN-Scale type 1 scales. Relied heavily on assistance from Claude Code.

[Copilot]

Pull request overview

This pull request fixes communication issues with Renpho ES-CS20M scales where the app could pair but failed to record measurements. The fix applies a similar approach to the QN-Scale Type 1 fix (PR #1243), correcting the Bluetooth protocol handling based on analysis of captured device traffic.

Changes:

• Removed incorrect notification subscription to write-only characteristic (CHR_CUR_TIME/0x2A11)
• Corrected START/STOP detection logic from byte[10] to byte[5] based on protocol analysis
• Removed per-frame "stable" flag check, now relying on STOP message to indicate stable measurements
• Added weight validation (0.5-300 kg) to filter garbage values during initial connection
• Enhanced documentation with protocol examples and detailed comments explaining the communication flow

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The logic for detecting START vs STOP has a subtle issue. The code defines isStart = startStopFlag != 0 and isStop = startStopFlag == 0, which means both variables can be true when startStopFlag is 0 (since 0 != 0 is false, but 0 == 0 is true).

While the when expression will work correctly because it evaluates conditions in order, the naming is misleading. Consider either:

1. Defining only one variable (e.g., val isStop = startStopFlag == 0) and using !isStop for the start case, or
2. Using else in the when block instead of the second condition.

The current implementation works but could be clearer about the mutual exclusivity of these states.