search

apetrycki / daikinskyport

API for accessing a DaikinOne+ Thermostat
63 stars 27 forks source link

climate.fan_cfm pulling from wrong api endpoint #33

Closed tlykken closed 1 year ago

tlykken commented 2 years ago

According to the api_info.md doc, I think the value for climate.fan_cfm is pulling from ctAHCurrentIndoorAirflow. For me, this value never changes from 65535.

I have found that the value of ctIFCIndoorBlowerAirflow does adjust up and down when the fan is running and matches the dealer stats menu of "current indoor CFM". I believe this is the number that should be represented in the climate.fan_cfm field.

Thank you!

knightjoel commented 2 years ago

I see the same behavior. However, I wonder if this another one of those "depends on your equipment" situations. My furnace is DM97MC1205DNAA. What's yours?

tlykken commented 2 years ago

My system is a DM97MC1005CN for the furnace and a DX17VSS481BA for the AC compressor.

I wonder what the best way to report this is going forward? Should there be branches for the different kinds of equipment found?

knightjoel commented 2 years ago

Right, we have the same type of furnace. If I recall correctly, apetrycki has something different (and we have seen differences between API values between our two systems).

A different branch would be really cumbersome to manage and wouldn't work nicely for users that bring in this component via HACS.

I think a more scalable way to handle this would be something like a 'quirks' table within the component that stored API property names for given furnace/AC models that differ from the "default" properties. The user would have to indicate to the component what type of furnace/AC they have so the component would know which quirks to use. It wouldn't be a small job to implement this, but would have the advantage of scaling easily as more of these differences are discovered.

apetrycki commented 2 years ago

I think the easier thing to do is check the value and see if it's 65535. If it is, use the other one. So far at least, it seems there are only 2 different configurations for these parameters. It would also be possible to pull the model number from the API if we do need to go down that route. Assuming you have model numbers populated somewhere. These are mine.

"ctAHModelNoCharacter1_15": "DV61PECD14     ",
"ctOutdoorModelNoCharacter1_15": "DZ18VC0481     ",

ctIFCIndoorBlowerAirflow comes up as 65535 for me. ctAHCurrentIndoorAirflow works correctly.

tlykken commented 2 years ago

I think the easier thing to do is check the value and see if it's 65535

Good idea! @apetrycki , are you maintaining this repository? Do you need some help? I have some python development experience but haven't done HA plug-ins before but am willing to learn. Thanks!

apetrycki commented 2 years ago

I had zero python or HA experience before starting this, so you're already better off than I was. Give it a shot and I can look at it if you need some help.

tlykken commented 2 years ago

Sounds good - not sure when I will be able to get some time to put into it but I will give it a shot at some point. Thanks!

knightjoel commented 2 years ago

I think the easier thing to do is check the value and see if it's 65535.

Bear in mind though that values like 65535 are also returned by the API when the tstat is unreachable, is powered off, etc. That value doesn't necessarily mean "not supported".

apetrycki commented 1 year ago

I put a check in the latest code for this. It doesn't really matter if the thermostat is giving 65535 since it's updated every poll. Try it out and see if your CFM shows correctly in the climate attributes.