fix(diivoo): unreachable "4 days" weather delay, transposed operation dps (#5718)
Two defects in diivoo_wt05.yaml (Dual water timer), found while onboarding
a Diivoo/Insoma SGW02 (product id hfgdqhho) and cross-checking every dp
against the Tuya cloud thing-model for category ggq.
1. "4 days" is mapped to dps_val "3" in both weather delay selects
(dp 117 and dp 114), so:
- selecting "4 days" transmits 3, silently setting a 3-day delay
- "3 days" and "4 days" both map to 3, so the value shown after a
round trip is whichever matches first
- a device reporting "4" has no mapping at all
The cloud thing-model gives the enum range as
["OFF","1","2","3","4","5","6","7"], so "4" is a valid value.
2. Operation 1 and Operation 2 are transposed. The cloud model has
status_1 = dp 112 and status_2 = dp 113, but the config had
Operation 1 -> 113 and Operation 2 -> 112. This also contradicts the
comment block at the top of the file, which already documents 112
under "Valve 1:" and 113 under "Valve 2:". Every other paired dp in
the file is the right way round (valve 105/104, countdown 106/103,
last run 111/110, weather delay 117/114), so this is an isolated swap.
Valve numbering was confirmed against the vendor app: with valve 1
(drip) set to 30 min and valve 2 (hose) to 10 min, a local read gave
dp 111 = 1800 and dp 110 = 600, matching the existing _1/_2 suffixes.
diivoo_dwv010.yaml carries defect 1 verbatim (dp 10 and dp 124, same
"4 days" -> "3" pair) and is fixed identically. I do not own that device,
so unlike the WT-05 this one is not confirmed against a cloud model - it
is inferred from the identical mapping. Happy to drop that file from the
PR if you would rather it be verified against hardware first.
jeremyames-gmail