Skip to content

feat: support the DYD-P40 - #70

Open
Dixiao-L wants to merge 1 commit into
stackia:mainfrom
Dixiao-L:feat/dyd-p40-support
Open

feat: support the DYD-P40#70
Dixiao-L wants to merge 1 commit into
stackia:mainfrom
Dixiao-L:feat/dyd-p40-support

Conversation

@Dixiao-L

Copy link
Copy Markdown

What breaks today

A DYD-P40 (product id d71936c6951c11f0a8200242ac480009) reports WindSpeed = 5, which DeyeFanSpeed doesn't define, so every poll raises:

File ".../libdeye/device_state.py", line 92, in _parse_state_fog
    self.fan_speed = DeyeFanSpeed(state.get("WindSpeed", DeyeFanSpeed.STOPPED))
ValueError: 5 is not a valid DeyeFanSpeed

The enum member alone isn't enough. Consumers map state through ordered_list_item_to_percentage(feature_config["fan_speed"], …), which raises for a speed absent from the product's list — and this product has no PRODUCT_FEATURE_CONFIG entry, so it inherits the default listing speeds 1–4.

Everything here was measured, not guessed

The product catalogue carries no capability metadata (the P40 entry has only name/brand/picture/config_guide), so I set each property on the real appliance and read it back, capturing a baseline first and restoring it afterwards (zero drift):

Property Accepted Rejected
Mode 1, 2, 3, 4, 6 0 (MANUAL), 5
WindSpeed 1, 2, 3, 5 4 (FULL)
SetHumidity 40–70 20, 25, 30, 35, 75, 80, 85, 90
NegativeIon 1 → sticks
SwingingWind 1 → sticks
WaterPump 1 → reads back 0

Since 4 is rejected while 5 is accepted, 5 is not a step above FULL — most likely an auto/smart speed. I named it UNKNOWN_SPEED, following the existing convention for unidentified values (DeyeDeviceMode already carries UNKNOWN_MODE and UNKNOWN_MODE_2). Happy to rename if you know what it is.

Two further observations, not addressed here

Recording them since they affect how this model maps, but neither is expressible in a product config:

  1. Fan is read-only on this model and stays 1 even with Power = 0 (CompressorStatus goes to 0 instead). _parse_state_fog maps it to fan_running, so that flag is effectively stuck true — which makes the derived "is it running" state wrong.
  2. UV is settable on this unit but has no model here.

Separate PR against ha-deye-dehumidifier (#108) fixes an independent issue that had to be cleared before any of this was reachable: the Fog client isn't connected for devices whose platform isn't exactly Fog, and the P40 reports platform = 3.

Adds the fan-speed value this model reports and a product feature config
for it. Without the enum member, every poll raises:

    ValueError: 5 is not a valid DeyeFanSpeed

The enum member alone is not enough: the consumer maps state through
ordered_list_item_to_percentage(feature_config["fan_speed"], ...), which
raises for a speed absent from the product's list, and this product had no
entry at all, so it inherited a default listing speeds 1-4.

Every value below was measured against the appliance -- each property set
and read back, baseline restored afterwards -- because the product
catalogue carries no capability metadata:

    modes       1/2/3/4/6 accepted; 0 (MANUAL) and 5 rejected
    fan speeds  1/2/3/5 accepted; 4 (FULL) rejected
    humidity    40-70 accepted; 20/25/30/35 and 75/80/85/90 rejected
    anion       NegativeIon settable  -> present
    oscillating SwingingWind settable -> present
    water pump  WaterPump 1 reads back 0 -> not present

Note 4 is rejected while 5 is accepted, so 5 is not a step above FULL --
most likely an auto/smart speed. Named UNKNOWN_SPEED following the
existing convention for unidentified values (DeyeDeviceMode already
carries UNKNOWN_MODE and UNKNOWN_MODE_2); rename if you know what it is.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant