Hi,
Do you mean this issue: Daikin AC Integration with BRP072C42 , Unexpected error creating device · Issue #51919 · home-assistant/core · GitHub?
1 Like
seems like it @fredrike
only impacting my Split aircond not the Ducted Aircon…
I see you are on to it already!
Yes, the code in pydaikin 2.4.2 that is used in HA 2021.6.5 had some issues (I didn’t write it all by my self and was sloppy in the code review).
1 Like
@Borgy if I recall correctly you helped me implement the AirBase support.
We set the outside sensor to not be supported but I’ve been contacted by another guy that say that it is. Could you please verify what happens if you run the code from mustang51 / pydaikin / airbase-get_sensor — Bitbucket.
Ping @vijaykbhatia.
with my Daikin Airbase BRP15B61
using http://192.168.x.y/skyfi/aircon/get_sensor_info
i get
ret=OK,err=0,htemp=-,otemp=-
1 Like
just confirming 2021.6.6 has fixed the problem!
1 Like
Hi Fredrike, Was there something you wanted me to do?
Cheers
Great to see this issue with the fan speed addressed - I was planning to start looking into it this week and sure enough it was fixed! Running on 2021.6.6, when I change the temperature, the Lovelace UI is still jumping back to the non-auto fan speed (e.g. Mid/Auto goes to Mid); then next update it jumps back to the Mid/Auto setting.
Looking at the logs I see HA is seeing the event change reportedly being just “Mid”:
2021-06-24 12:58:16 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.daikin_ac, old_state=<state climate.daikin_ac=heat; hvac_modes=[‘fan_only’, ‘dry’, ‘cool’, ‘heat’, ‘heat_cool’, ‘off’], min_temp=7, max_temp=35, target_temp_step=1, fan_modes=[‘Low’, ‘Mid’, ‘High’, ‘Low/Auto’, ‘Mid/Auto’, ‘High/Auto’], current_temperature=23.0, temperature=21.0, fan_mode=Mid/Auto, friendly_name=Daikin AC, supported_features=9 @ 2021-06-24T12:19:48.316122+10:00>, new_state=<state climate.daikin_ac=heat; hvac_modes=[‘fan_only’, ‘dry’, ‘cool’, ‘heat’, ‘heat_cool’, ‘off’], min_temp=7, max_temp=35, target_temp_step=1, fan_modes=[‘Low’, ‘Mid’, ‘High’, ‘Low/Auto’, ‘Mid/Auto’, ‘High/Auto’], current_temperature=23.0, temperature=22.0, fan_mode=Mid, friendly_name=Daikin AC, supported_features=9 @ 2021-06-24T12:19:48.316122+10:00>>
… and then on the next polling interval update it reverts itself back:
2021-06-24 12:58:48 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.daikin_ac, old_state=<state climate.daikin_ac=heat; hvac_modes=[‘fan_only’, ‘dry’, ‘cool’, ‘heat’, ‘heat_cool’, ‘off’], min_temp=7, max_temp=35, target_temp_step=1, fan_modes=[‘Low’, ‘Mid’, ‘High’, ‘Low/Auto’, ‘Mid/Auto’, ‘High/Auto’], current_temperature=23.0, temperature=22.0, fan_mode=Mid, friendly_name=Daikin AC, supported_features=9 @ 2021-06-24T12:19:48.316122+10:00>, new_state=<state climate.daikin_ac=heat; hvac_modes=[‘fan_only’, ‘dry’, ‘cool’, ‘heat’, ‘heat_cool’, ‘off’], min_temp=7, max_temp=35, target_temp_step=1, fan_modes=[‘Low’, ‘Mid’, ‘High’, ‘Low/Auto’, ‘Mid/Auto’, ‘High/Auto’], current_temperature=22.0, temperature=22.0, fan_mode=Mid/Auto, friendly_name=Daikin AC, supported_features=9 @ 2021-06-24T12:19:48.316122+10:00>>
Any ideas on where to start digging or what might be causing this?
I’m not sure I fully understand what’s happening.
Are you saying that the status changes from Mid/Auto to Mid right after changing setting but reverts to the right value during the next pull?
The quick solution would be to call self.update_status() in line 111 of https://bitbucket.org/mustang51/pydaikin/src/master/pydaikin/daikin_airbase.py. But that adds more requests and the Daikin units are not super fast in updating.
Perhaps reusing the code from line 49-50
if response.get('f_auto') == '1':
response['f_rate'] = f'{response["f_rate"]}a'
But updating the self.values I.e. (also at line 111)
if self.values['f_auto'] == '1':
self.values['f_rate'] = f'{self.values["f_rate"]}a'
Yes that’s exactly what’s happening - you can see it here, all I do is click the button to change the temperature, as soon as the temperature change is confirmed it changes to Mid, then there’s about a minute and a bit where it shows the “wrong” value that’s set immediately post temperature change, and then it updates to the “right” fan value (Mid/Auto) as it polls to update:
2 Likes
I’ve added some extra debugging and it looks like the issue is from some of the logic in _update_settings() around line 151:
Before this block, the f_rate value is 3a for Mid/Auto; afterwards its changed to 3. I’m working through that block now so once I wrap my head around it I will hopefully will have a patch shortly…
In case anyone is digging into this in the future, this may help:
- It appears the Daikin AC units will store certain settings based on the operating mode of the unit (specifically, the set point, humidity and fan speed settings)
- The PyDaikin module mirrors this by storing (in this case) fan rate in a set of
dfr#properties - When
_update_settings()is called, it only passes in the values that are being changed; as a result the library only changes the specific setting in the stored settings array - It subsequently updates the fan speed, set point and humidity values based on the stored value for that mode - these are stored in separate dictionary key values
- … however the stored fan speed here has never been updated to account for the automatic fan mode, hence why it gets cleared.
I’m working through the best way to address this - currently thinking either storing f_auto as dfr_auto# or making dfr# append the ‘a’ suffix the same as f_rate does currently. @fredrike if you had any views on the ‘most correct’ approach let me know, otherwise I’ll post something soon…
This is my suggestion:
We should document this in _update_settings
@fredrike I found it needed more than that to handle the different cases (e.g. actually setting fan speed vs not, switching between modes and restoring the correct settings, etc). Here’s the changes I’m currently running with at the moment which seem OK so far:
diff --git a/pydaikin/daikin_airbase.py b/pydaikin/daikin_airbase.py
index 14cea2a..f567271 100644
--- a/pydaikin/daikin_airbase.py
+++ b/pydaikin/daikin_airbase.py
@@ -99,6 +99,14 @@ class DaikinAirBase(DaikinBRP069):
"""Set settings on Daikin device."""
await self._update_settings(settings)
+ # The respective mode checks in _update_settings() will set the value of f_rate
+ # to the last reported value from the AC unit for its active mode if we are not
+ # explicitly seting the fan speed, however this will not include the f_auto
+ # value. If we are not trying to set f_rate, Check if f_auto is set, and if so,
+ # re-append the 'a' suffix for our automatic fan modes.
+ if 'f_rate' not in settings and self.values['f_auto'] == '1':
+ self.values['f_rate'] = f'{self.values["f_rate"]}a'
+
self.values.setdefault('f_airside', 0)
query_c = (
'aircon/set_control_info'
diff --git a/pydaikin/daikin_brp069.py b/pydaikin/daikin_brp069.py
index 406fbf7..dca7072 100644
--- a/pydaikin/daikin_brp069.py
+++ b/pydaikin/daikin_brp069.py
@@ -139,6 +139,11 @@ class DaikinBRP069(Appliance):
self.values.update(current_val)
self.values.update({k: self.human_to_daikin(k, v) for k, v in settings.items()})
+ # f_auto requires special handling, as we map it into f_rate within home assistant
+ # and so won't update it as a result of the changes here
+ if 'f_auto' in current_val and 'f_rate' in settings:
+ self.values['f_auto'] = '1' if 'a' in self.values['f_rate'] else '0'
+
# we are using an extra mode "off" to power off the unit
if settings.get('mode', '') == 'off':
self.values['pow'] = '0'
@@ -148,8 +153,8 @@ class DaikinBRP069(Appliance):
self.values['pow'] = '1'
# Use settings for respecitve mode (dh and dt)
- for k, val in {'stemp': 'dt', 'shum': 'dh', 'f_rate': 'dfr'}.items():
- if k not in settings:
+ for k, val in {'stemp': 'dt', 'shum': 'dh', 'f_rate': 'dfr', 'f_auto': 'auto'}.items():
+ if k not in settings and (k != 'f_auto' or 'f_rate' not in settings):
key = val + self.values['mode']
if key in current_val:
self.values[k] = current_val[key]
The brp069 model doesn’t have f_auto… Please overload the _update_settings in daikin_airbase with the correct settings.
I thought as much - I’m still getting my head around all the pieces of it and how it works. At the moment some of the changes depend on fetching the current values from the Airbase unit, which _update_settings in the brp069 retrieves (and so why I had made the changes there for testing purposes). I really wanted to avoid putting a second call to fetch this in the Airbase set() call.
So my thoughts were:
Option 1 - duplicate the _update_settings() into the airbase model and make the changes there. I dislike duplicating code but it’s the lowest risk….
Option 2 - change _update_settings() in brp069 to return the current_val values, so that the auto handling can all move into the set() call in the airbase class and have access to the current system values as well
I’m leaning towards option 2 unless you have any other suggestions on how best to refactor it? I’ll have a go at it and do some testing and once all looks good post the diff here (or I can raise a PR in Bitbucket…)
1 Like
Here’s the current approach I’m testing at the moment (so far so good):
diff --git a/pydaikin/daikin_airbase.py b/pydaikin/daikin_airbase.py
index 14cea2a..39ef1ab 100644
--- a/pydaikin/daikin_airbase.py
+++ b/pydaikin/daikin_airbase.py
@@ -97,7 +97,31 @@ class DaikinAirBase(DaikinBRP069):
async def set(self, settings):
"""Set settings on Daikin device."""
- await self._update_settings(settings)
+
+ # Call the base BRP069 method to update the settings; it will
+ # return the current values it retrieves from the controller
+ # so we can further process them
+ current_val = await self._update_settings(settings)
+
+ # f_auto requires some special handling, as it is managed as an
+ # attribute of f_rate and we don't directly set it - so when f_rate
+ # is being changed, ensure we update f_auto accordingly if it is
+ # defined in the current device's returned settings
+ if 'f_auto' in current_val:
+ # The system supports f_auto; if we are setting the fan speed
+ # then ensure we update the f_auto setting as well
+ if 'f_rate' in settings:
+ self.values['f_auto'] = '1' if 'a' in self.values['f_rate'] else '0'
+ else:
+ key = 'auto' + self.values['mode']
+ if key in current_val:
+ self.values['f_auto'] = current_val[key]
+
+ # The f_rate value would have been retrieved from the unit's current
+ # operating mode fan rate setting, and needs the 'a' suffix reinstated
+ # if we are running in an automatic fan speed mode
+ if self.values['f_auto'] == '1':
+ self.values['f_rate'] = f'{self.values["f_rate"]}a'
self.values.setdefault('f_airside', 0)
query_c = (
diff --git a/pydaikin/daikin_brp069.py b/pydaikin/daikin_brp069.py
index 406fbf7..902c9a1 100644
--- a/pydaikin/daikin_brp069.py
+++ b/pydaikin/daikin_brp069.py
@@ -154,6 +154,8 @@ class DaikinBRP069(Appliance):
if key in current_val:
self.values[k] = current_val[key]
+ return current_val
+
async def set(self, settings):
"""Set settings on Daikin device."""
await self._update_settings(settings)
@ajmawer do you know what is going on here: Daikin BRP15B61 incorrect fan modes · Issue #52344 · home-assistant/core · GitHub
@fredrike it looks like the unit has Auto/Low/Med/High fan speeds instead of the 3 fixed speed + 3 auto currently supported in Airbase. I suspect (but not yet certain) the Airbase may support both types and so might need to be modified to handle both styles of fan speed depending on the unit it is connected to… It seems like it may be similar to the BRP069 fan speeds…
1 Like