search

wuwentao / midea_ac_lan

Auto-configure and then control your Midea M-Smart devices (Air conditioner, Fan, Water heater, Washer, etc) via local area network.
MIT License
275 stars 12 forks source link

Missing Dehumidifier Tank Status #250

Closed holocronweaver closed 1 month ago

holocronweaver commented 2 months ago

Device type and model (or SN)

Dehumidifier 00000Q12 (41377)

The description of new feature

The Midea app (called SmartHome) notifies me if the dehumidifier tank is full, but I do not see any sensor for tank fullness in Home Assistant. The only thing exposed are the controls and current humidity.

Is this a limitation of my dehumidifier model (say, by not exposing tank fullness to HA), or is this a bug or missing feature?

wuwentao commented 1 month ago

maybe the same issue as #235 as we don't have these device， we should understand the feature and the details. could you help to share the details or join discord group online chat via readme document.

holocronweaver commented 1 month ago

I believe this is a different issue than #235 in that Home Assistant does not provide a 'tank full' sensor entity (i.e., no binary_sensor.DEVICE-ID_tank_full or sensor.DEVICE-ID_tank entity exists), whereas in #235 the sensor is exposed but does not report state correctly.

What information do you need? Happy to provide logs, etc.

chemelli74 commented 1 month ago

We need to improve logging if it still doesn't work with v0.5.7

wuwentao commented 1 month ago

@holocronweaver thanks for your answer. so you have enabled these extra sensors in your device configs ? or you have tried to enable these sensors and not found it in your device configs?

just follow the README document to enable/config these extra sensors: https://github.com/wuwentao/midea_ac_lan?tab=readme-ov-file#configure

holocronweaver commented 1 month ago

Thanks @wuwentao! I wasn't aware the entities required integration-level configuration to enable.

Every other integration I have used automatically enables all entities available for a device when it is added. Any that aren't considered generally useful are disabled by default. Why doesn't midea_ac_lan do the same?

wuwentao commented 1 month ago

@holocronweaver there is more device types and subtypes supported by current midea_ac_lan(just refer to README document), and we can't define with one default settings for all the users devices, so user can enable or disable it based on different device type or requirements.

if it can works for you ,just close current issue. or still have some bug like #235 , just enable debug log and attach the log file to current issue(not paste the log content to issue).

holocronweaver commented 1 month ago

I do not have the issue in #235, my device tank full boolean entity works!

Couldn't device type and subtype be resolved programmatically using the model number to determine device capabilities, avoiding the need for user intervention in cases where the device type / subtype is known? Or is the model info needed to resolve not programmatically available? I could cut a issue requesting this in case it helps track similar requests and progress towards automating feature discovery, at least for certain device types where this is possible. Fallback when device type is not known could just be current behavior, allowing user to enable entities manually.

I'll go ahead and close this issue since my tank full entities work now.

wuwentao commented 1 month ago

@holocronweaver thanks for your confimration.

it's hard for us to confirm which feature should available for user device based on type/subtype, as there is no official documents, and we also not have any device to do test, only the device owner can confirm it.

I don't think we should do it, just add feature and add more device types, user can select and confirm it, it's only onetime setup jobs.

support more devices and more feature should important for it, thanks.

holocronweaver commented 1 month ago

it's hard for us to confirm which feature should available for user device based on type/subtype, as there is no official documents, and we also not have any device to do test, only the device owner can confirm it.

A simple solution would be a small file-based (yaml?) database of device model -> supported features, which users contribute to that have the devices on hand. It would fallback on the current manual entity selection if the device is not in the database. This wouldn't interfere with adding more devices or features - users who have the physical devices on hand and know what they support could maintain it rather than the primary package maintainers.

user can select and confirm it, it's only onetime setup jobs.

While the current setup technically functions, it is not clear which features the integration actually supports (even after reading the documentation), and it is not consistent with most other Home Assistant integrations I've used which largely use automatic feature discovery based on models. Basically, the current manual approach isn't as intuitive or automated as it could be.

I suspect adding simple automatic feature discovery based on a user-maintained model database like mentioned above would be relatively low effort to build and maintain.

Just something to consider!

wuwentao commented 1 month ago

thank you very much for your detail and suggestion. we can have a try in future, but may have a long time delay, as this is not a ugrent requirement. will add new device and new feature at first now, also fix bug and keep version more stable when new feature introduced.