Conversation
HonMeanWaterConsumption declared device_class=WATER together with
state_class=MEASUREMENT, a combination Home Assistant rejects: WATER (like
VOLUME) only permits total / total_increasing. HA logged on startup:
Entity sensor.<name>_consumo_idrico_medio (HonMeanWaterConsumption) is
using state class 'measurement' which is impossible considering device
class ('water'); expected None or one of 'total_increasing', 'total'
The sensor is an average litres-per-cycle figure (totalWater / (cycles - 1))
that rises and falls, so MEASUREMENT is the correct state_class: it records
min/mean/max long-term statistics. The only volume-family device_class that
allows MEASUREMENT is VOLUME_STORAGE, which means "amount currently stored in
a container" -- wrong for a per-cycle average. Dropping device_class keeps the
litre unit and the statistics while staying semantically honest; the entity
already sets a custom icon (mdi:water-sync), so there is no visual change and
the entity_id / unique_id are untouched (no history or statistics reset).
Verified against homeassistant/components/sensor/const.py
(DEVICE_CLASS_STATE_CLASSES) on HA 2026.6.4.
Added additional tested appliances to the README.
Fridge "modes" (super cool, super freeze, holiday, iot_* presets) are startProgram/stopProgram PROGRAMS, not writable settings booleans, so they were exposed only as read-only binary_sensors with no way to change them. Add HonRefProgramSelect: a single capability-gated select per fridge whose options are `off` plus the device's live startProgram.program enum. Selecting a program sends startProgram(program=X) immediately (swap-aware, no washer-style buffer/Start-button cycle); `off` sends stopProgram (the global mode reset). current_option is derived from the live device mode flags (quickModeZ1 -> super_cool, quickModeZ2 -> super_freeze, holidayMode -> holiday, intelligenceMode -> auto_set), double-gated on the live enum, never from startProgram.program (which only carries the recovered default category). The option source and the send target are both resolved specifically from startProgram so they cannot diverge. New async_send_program helper mirrors the proven washer swap-and-send flow. Bilingual en/it state labels for the known fridge program superset. Validated against roberglezz's live REF schema (HCW58F18EWMP) from the discussion #40 diagnostics.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Caution Review failedAn error occurred during the review process. Please try again later. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@custom_components/addhon/program_options.py`:
- Around line 82-104: The startProgram send path mutates the active command and
may swap appliance.commands["startProgram"] before send(), but it does not
restore the original state if await command.send() fails. Update the
startProgram handling in program_options.py to mirror the rollback behavior used
by async_send_command: keep the previous command/category state, and on any send
exception restore the original command object and program selection so select.py
and later interactions don’t keep the unsent local mutation. Use the
startProgram command flow, the refreshed lookup, and the PROGRAM_PARAM_NAMES
handling as the main points to hook the rollback into.
In `@README.md`:
- Around line 15-16: The Buy Me a Coffee badge in README.md is pointing to the
GitHub Sponsors URL instead of a Buy Me a Coffee destination. Update the link
target for the markdown badge so it matches the label, or rename the badge to
Sponsor if the GitHub Sponsors URL is the intended destination. Use the badge
markdown near the existing Sponsor and Buy Me a Coffee entries to locate the
change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4c585682-b09b-4983-90e0-98f9958723d9
📒 Files selected for processing (9)
README.mdcustom_components/addhon/manifest.jsoncustom_components/addhon/program_options.pycustom_components/addhon/select.pycustom_components/addhon/sensor.pycustom_components/addhon/translations/en.jsoncustom_components/addhon/translations/it.jsontests/test_entity_translation_keys.pytests/test_ref_program_select.py
|
@coderabbitai help |
ChatThere are 3 ways to chat with CodeRabbit:
CodeRabbit commands
Other keywords and placeholders
Status, support, documentation and community
|
|
@coderabbitai summary |
✅ Action performedSummary regeneration triggered. |
Removed 'Buy Me a Coffee' badge from README.
Address CodeRabbit review (PR #41): async_send_program mutated the program parameter and swapped appliance.commands["startProgram"] to the selected category before send(), with no rollback. Since the REF select skips the coordinator refresh on a failed send, a rejected command left a local command/category the cloud never accepted in place until the next poll. Mirror async_send_command's rollback: snapshot the pre-swap parameter state and, on any send exception, restore it and reset the swapped command pointer to the original, then re-raise. Add a mutation-proof test asserting both the command pointer and the program value are reverted (and no refresh runs) on failure.
The REF program select read current_option only from the four mode flags (quickModeZ1/Z2, holidayMode, intelligenceMode), so the iot_* download presets (which set no flag) always read back as "off" after being applied, making the control look like the command was ignored. The cloud persists the active program in programName/prStr/prCode (the field the official app reads to show the running program, e.g. after an app reinstall). Extend current_option to consult it after the flags: match it (whole token and last dotted i18n-key segment, case-insensitively, exact only - no fuzzy match) against the offered option codes, else off. startProgram.program is still never used (it is only the recovered default category). This is real device feedback, not optimistic "remember what was clicked" state. The exact programName format for an active iot_* preset is to be confirmed against a live dump.
| recovered default category, not the running program).""" | ||
| by_lower = {code.lower(): code for code in self._program_codes} | ||
| for attr in self._REF_ACTIVE_PROGRAM_ATTRS: | ||
| raw = self._get_attr(attr) |
There was a problem hiding this comment.
This fallback still misses REF presets when the refreshed device state does not contain a string program code. For real REF schemas where programName is computed as No Program, prStr is absent, and prCode is numeric, selecting an offered preset such as iot_extra_cold can send successfully and refresh, but _active_program_code() cannot match any of these fields back to the offered option. The entity then falls through to off, so Home Assistant can still report the preset as not applied after a successful selection.
Automated release PR for
v5.6.0-beta.Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Greptile Summary
This PR prepares the v5.6.0-beta release with a new fridge program selector. The main changes are:
Confidence Score: 4/5
This is close, but the fridge preset state issue should be fixed before merging.
offafter a successful selection.custom_components/addhon/select.py
Important Files Changed
offwhen refreshed feedback has no matchable string program code.Reviews (3): Last reviewed commit: "Reflect active fridge program from cloud..." | Re-trigger Greptile