-
-
Notifications
You must be signed in to change notification settings - Fork 41
Settings Visual Guide
This guide explains the key numerical parameters in WashData using visual graphs. Tuning these advanced settings allows the integration to adapt to any appliance's specific power behavior.
If you see sensor.<name>_suggested_settings (e.g. sensor.washer_suggested_settings or sensor.laundry_sensor_suggested_settings, where <name> is your device identifier) above 0, WashData has actionable recommendations ready.
To review them safely:
- Open the WashData panel (sidebar) and go to the Settings tab.
- Suggested values appear inline next to the relevant fields, each with a one-click Use (or an Apply all banner).
- Review each suggestion (hover the field for its explainer), apply the ones you want, and press Save.
Suggestions are optional and are never applied automatically — you choose which to keep before saving.
Controls how much the raw power signal is smoothed before processing.
- Low Value (e.g., 2): Responsive but susceptible to noise.
- High Value (e.g., 5): Smooths out spikes but introduces lag.

The absolute minimum power (Watts) considered "active".
- Readings below this line are treated as 0 W (Standby/Off).
- It filters out the "phantom load" of smart plugs or standby LEDs.

By default, the system uses min_power for both starting and stopping.
- However, you can configure split thresholds to prevent rapid toggling.
- Start Threshold (Green): Power must rise above this to become ACTIVE.
- Stop Threshold (Red): Power must fall below this to become IDLE.
- Gray Zone: If power is in between, the state doesn't change (it keeps doing whatever it was doing).

Prevents false starts from brief power spikes (e.g., a pump check or accidental button press).
- The appliance must consume a certain amount of Energy (Wh) (Power x Time) before the state changes to
RUNNING. - A high-power spike that lasts a fraction of a second has very low energy and is ignored.

The most critical parameter for Dishwashers and machines with pauses.
- It is the time the system waits after power drops to 0 before declaring the cycle Finished.
- If power resumes within this window, the cycle continues (bridges the gap).
- If the window expires, the cycle ends.

Controls how "strict" the matching algorithm is regarding total duration.
- It defines a +/- percentage band around the stored profile's average duration.
-
Example: If profile is 60 mins and tolerance is 0.25 (25%):
- Matches cycles between 45 mins and 75 mins.
- If a cycle falls outside this band, it gets a lower score or is rejected.

Filters out short, invalid cycles that might be caused by test runs or accidents.
- If a cycle finishes (power drops to 0) but the total duration is less than this value, it is discarded as a "Ghost" cycle.
- Example: Opening the door to add a sock might start a 1-minute "cycle", which we want to ignore.

Prevents a single cycle from being split into two if there is a short pause.
- If two detection events happen close together (gap <
min_off_gap), the system treats them as one continuous session. - Useful for machines with very long soak times or drying pauses.

Failsafe for when your smart plug drops off the network.
- If the integration stops receiving updates for this long while the cycle is running, it assumes something is wrong.
- Default: 600s (10 minutes) to allow for cloud/mesh network lag.
- It will force-stop the cycle or flush the buffer to prevent a "Zombie Cycle" running forever.

Ensures a cycle doesn't end prematurely on a low-power "trickle".
- Some machines spin down slowly or have an anti-crease mode that consumes small power (< min_power).
- If the accumulated energy during the
off_delayperiod exceeds this threshold, the system resets the timer, keeping the cycle alive.

Defines the acceptable "Length" of a cycle relative to the profile.
- Even if the shape matches perfectly, the duration must be plausible.
-
Example: If profile is 60 mins:
- Min Ratio 0.9 (90%) = Cycle must be > 54 mins.
- Max Ratio 1.3 (130%) = Cycle must be < 78 mins.

A time-based filter complementing start_energy_threshold.
- Even if power is high, it must stay high for this many seconds to be valid.
- Prevents split-second "On/Off" toggles from starting a cycle.

The "Almost Done" Alert.
- Proactively notifies you when the estimated time remaining drops below this value.
- Useful for getting ready to unload.

The "Unloading Phase".
- After a cycle finishes (Status: Completed), the progress stays at 100%.
- This timer holds that state (default 30 min / 1800 s) to let you see "Completed" on dashboards before resetting to "Idle" (0%).

Exit power for anti-wrinkle / anti-crease mode.
- Power must fall below this threshold between tumble pulses for anti-wrinkle mode to stay active.
- Default: 0.8 W — slightly above zero, so a momentary standby glitch does not break the anti-wrinkle sequence.
- Raise it if your appliance has a slightly elevated standby draw during anti-crease cycles.
Self-Learning Trigger.
- The system counts how many "Ghost Cycles" (too short to be real) happen in 24 hours.
- If this count exceeds the threshold (e.g. 3), it assumes your
min_poweris too low (picking up noise) and suggests a new, higher threshold. The suggestion appears in the panel's Settings suggestions banner / per-field pill; it is not applied automatically and does not raise a persistent notification.

Rate-limiting for sensor updates.
- If your power sensor fires very frequently (e.g. every 100ms), this setting throttles processing.
- Low Value (e.g., 2s): More responsive detection but higher CPU usage.
- High Value (e.g., 30s): Lower CPU, acceptable for most smart plugs that poll every 30-60s.
How often the background watchdog task runs its checks.
- Default: 30s - every 30 seconds, it checks if sensors are still updating and if timeouts have elapsed.
- A smaller value catches issues faster but uses more resources.
How often (in seconds) to attempt profile matching during a running cycle.
- Low Value (e.g., 60s): Faster program detection but more CPU overhead.
- Default (300s = 5 minutes): A good balance for most scenarios.
Consecutive low-power readings required before ending a cycle.
- Prevents a single noisy reading from prematurely stopping detection.
-
Example: If
end_repeat_count = 3, the power must be below the stop threshold for 3 consecutive samples.
The minimum composite similarity score (0.0–1.0) for a profile to be considered a match. This is not a raw DTW score - it is the final blended score from the whole matching pipeline: shape correlation + peak-relative MAE (Stage 2), DTW refinement (Stage 3), and duration/energy agreement (Stage 4). DTW is only one component.
- Higher Value (e.g., 0.6): Stricter matching, fewer false positives, but may miss valid runs if noisy.
- Lower Value (e.g., 0.3): More lenient, catches more matches but may have false positives.
- Default: 0.4
The score below which a previously matched profile is rejected mid-cycle.
- This should be lower than
profile_match_thresholdto prevent "flickering" (rapid match/unmatch toggling). - Example: Match at 0.4, unmatch at 0.35 creates a small hysteresis band.
- Default: 0.35
Tolerance for time-remaining estimates during a running cycle.
- This is NOT for profile matching (that's
profile_duration_tolerance), but for learning feedback. - When the cycle ends, if the actual duration is within ±X% of the estimate, it's flagged as a "good match".
- Default: 0.10 (±10%)
Minimum confidence to trigger a user verification request.
- When a cycle ends, if the match confidence is above this threshold (but below
auto_label_confidence), the finished cycle is flagged for review in the panel's Cycles queue so you can verify or correct the identified program. WashData does not raise a persistent notification for this. - Default: 0.6 (60%)
Confidence threshold for automatic labeling.
- If a cycle completes with confidence above this value, the integration automatically assigns the matched profile name without asking.
- Default: 0.9 (90%) - only highly confident matches are auto-labeled.
Opt-in (0.5.1). When on, WashData budgets each cycle stage (heating, wash, spin) separately instead of scaling one whole-cycle duration model, which makes the time-remaining estimate more accurate for temperature/spin variants of the same program (a 60 °C wash spends far longer heating than a 30 °C wash, even though the overall shape looks similar).
- It refines time remaining only - it never changes which program is matched.
- Early in a cycle the per-phase budget dominates the estimate; later, the proven whole-cycle estimator takes over. With the toggle off, the estimate is identical to previous versions.
- Currently available for washing machines and washer-dryers. Requires a few clean, labelled cycles per profile so the per-phase budgets can be learned.
- Default: off
User Docs
Reference
Development
Repository