Separate Washer and Dryer classes

[NodeJSmith]

Currently there is one class for these, WasherDryer. While there is not much implemented for washer/dryer appliances, the few attributes that are implemented are for the washer and do not make sense for the dryer.

Examples:

• cycle statuses of filling, soaking, rinsing, etc
• WashCavity_OpStatusBulkDispense1Level - this is currently only in HA, which is it's own issue I think, but when we do get this implemented in the library directly we will only want it on the Washer, not the Dryer

[abmantis]

IIRC, that was added using the data from someone that has a appliance that is both washer and dryer, so I am not sure if it makes sense to split them because that will break the 1-SAID <> 1-Appliance mapping.

[abmantis]

OTOH, we have if "dryer" in data_model or "washer" in data_model: on the ApplianceManager, meaning it has only one type in "DATA_MODEL_KEY", so maybe we could indeed split them. But I am not sure what would go into the Dryer, since I do not have one.

@mkmer do you happen to have one?

[mkmer]

I have a whirlpool dryer, but not connected :( Only washer.

[NodeJSmith]

I have a washer and a dryer, and the test data folder contains each of their data. That's currently only used for the appliances manager tests but I added it so that it can be used as more W/D functionality is added.

[abmantis]

But you can use the WasherDryer class with both Washer and Dryer, but if we split them, how would we represent an appliance the is both?

[NodeJSmith]

I think there is an api we can call that returns the device capabilities. If that works to determine if it's a washer, dryer, or W/D combo we could have distinct classes for each of those, maybe using mixins or something to keep things cleaner.

But I do think it'd be better to have the option to have more specific devices in HA, however we do it.

[abmantis]

Yeah, good point. So for now we could just convert the washer/dryer into Washer only?

[NodeJSmith]

Yeah I think so. With the device data model api call (api/v2/DeviceDataModel) we can get data that should let us determine if the entity should be a washer or dryer. I've left examples below of the differences in attributes. These come from the response object, which is keyed by the SAID and then under dataModel.attributes. I think if we convert the existing WasherDryer to a Washer and create a new Dryer class that should be a good start, and then we can see about a combined washer and dryer, although I'm not sure how we're going to be able to test that without any data from that kind of appliance. Maybe that one could just be a class that has a washer entity and a dryer entity and we delegate calls to the correct one?

My dryer has these attributes that my washer doesn't have:

{'AirFlowStatus',
 'ControlLockChangedByAppliance',
 'CoolDown',
 'CustomerFaultCodeNotification',
 'Damp',
 'DampNotificationToneVolume',
 'DrumLightOn',
 'Drying',
 'Dryness',
 'EcoBoost',
 'EcoBoostEnable',
 'GetApplianceVersionNumber',
 'GetSubscribeListVersion',
 'ISPReasonCode',
 'ISPStep',
 'InServiceDate',
 'LimitedCycle',
 'M2MSubscribeListVersion',
 'MAC_Address',
 'ManualDryTime',
 'ProjectReleaseNumber',
 'PushTrigger',
 'SetDNSNames',
 'SmartID',
 'StaticGuard',
 'StaticGuardEnable',
 'StaticReduce',
 'SteamChangeable',
 'SteamEnable',
 'Steaming',
 'Wet',
 'WrinkleShield',
 'Zip',
 'cc_uri',
 'online',
 'sys-parser-type',
 'trid_result',
 'uid'}

And my washer has these ones:

{'AddGarment',
 'BulkDispense1',
 'BulkDispense1Concentration',
 'BulkDispense1Enable',
 'BulkDispense1Level',
 'CleanDetection',
 'CleanReminder',
 'DeepFill',
 'DeepFillEnable',
 'DelayTime',
 'DelayTimeRemaining',
 'DispenserDrawerOpen',
 'Dispensing',
 'DoorLocked',
 'Draining',
 'ExtraRinse',
 'ExtraRinseSelect',
 'FabricSoftener',
 'FabricSoftenerEnable',
 'Filling',
 'Online',
 'PresoakTimed',
 'ProductDev1',
 'Rinsing',
 'Soaking',
 'SoilLevel',
 'SpinSpeed',
 'Spinning',
 'Washing'}

Edit:

For reference, here's the structure of that call, as it took me longer than I would like to admit to figure out the uppercase I in the saIdList parameter. The below example is using httpie. I don't think the country or brand headers are required though, I just had those left in there from other calls.

https POST https://api.whrcloud.com/api/v2/DeviceDataModel WP-CLIENT-COUNTRY:US WP-CLIENT-BRAND:$WP_BRAND saIdList:='["SAIDVALUEHERE"]'  --auth-type=jwt --auth=$WP_TOKEN

[abmantis]

That saIdList is a security feature to detract us from reverse engineering the API! :rofl:

I think for now it would be fine to just split them then. Later, if someone with a combined Washer+Dryer comes up, we can discuss the best way to have the combined class. But it is fine to leave that for later anyway.