Some DA_WM_TP1/TP2-class boards populate /wm/editcourse/vs/0 without ever filling in editCourseList itself (issue #1), so the Cycle select never gets created even though the device clearly has one (confirmed via SmartThings app screenshots and a currently-selected course). /course/vs/0's own x.com.samsung.da.supportedOptions turns out to already carry the course list, just undocumented: a 1-hex-nibble header followed by one fixed-width record per course, self-indexed by a course-code first byte rather than positional like editCourseList. Confirmed against six independent real-world dumps pulled from open and closed GitHub issues. cycle_options() now falls back to deriving this when editCourseList is empty, gated on two checks: the derived codes must all be distinct, and must include whatever course is currently selected. Larger multiples of the true record width trivially re-pass both checks too (they're just a sparser sampling of the same table), so the smallest passing width wins rather than requiring one unambiguous match. Also fires on the washer_flexwash fixture, newly creating a Cycle select there -- unconfirmed against any ground truth for that device (a different, older board generation with no editCourseList and no screenshots to check against), flagged for follow-up discussion rather than silently accepted.
24 lines
432 B
JSON
24 lines
432 B
JSON
{
|
|
"state_keys": [
|
|
"alarm_code",
|
|
"child_lock",
|
|
"cycle",
|
|
"cycle_active",
|
|
"delay_start_hours",
|
|
"detergent_low",
|
|
"diagnosis_status",
|
|
"drum_clean_cycles_remaining",
|
|
"energy_kwh",
|
|
"finish_time",
|
|
"job_beginning_status",
|
|
"machine_state",
|
|
"power_switch",
|
|
"progress",
|
|
"progress_percentage",
|
|
"remote_control",
|
|
"rinse_cycles",
|
|
"spin_speed",
|
|
"wash_temperature"
|
|
]
|
|
}
|