core
core copied to clipboard
Daikin breaking changes - renaming devices
The problem
The Daikin integration has some breaking changes with 2023.6.0b.
The upgrade creates new devices and markes the legacy devices as unavailable.
https://discord.com/channels/330944238910963714/427516175237382144/1113968404311842929
Daikin integration behaving poorly in beta:
added new devices with new names, replacing old devices which are no longer available - breaking change added weird switches to the new devices.
I only have one device upstairs and one downstairs but it is now showing two upstairs and two downstairs.
Old device was named: climate.daikin_ap33073 New device named: climate.downstairs
What version of Home Assistant Core has the issue?
core-2023.6.b.1
What was the last working version of Home Assistant Core?
core-2023.5
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
Daikin
Link to integration documentation on our website
https://rc.home-assistant.io/integrations/daikin
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
2023-06-02 09:13:21.275 DEBUG (MainThread) [pydaikin.daikin_base] Updating ['aircon/get_sensor_info', 'aircon/get_control_info', 'aircon/get_zone_setting']
2023-06-02 09:13:21.788 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,err=0,htemp=-,otemp=-
2023-06-02 09:13:21.899 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,pow=0,mode=1,operate=1,bk_auto=2,stemp=23,dt1=23,dt2=24,f_rate=5,dfr1=5,dfr2=5,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
2023-06-02 09:13:22.020 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,zone_name=-%3b-%3b-%3b-%3b-%3b-%3b-%3b-,zone_onoff=0%3b0%3b0%3b0%3b0%3b0%3b0%3b0
2023-06-02 09:12:23.856 DEBUG (MainThread) [pydaikin.daikin_base] Updating ['aircon/get_sensor_info', 'aircon/get_control_info', 'aircon/get_zone_setting']
2023-06-02 09:12:23.985 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,err=0,htemp=-,otemp=-
2023-06-02 09:12:24.100 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,pow=1,mode=1,operate=1,bk_auto=2,stemp=23,dt1=23,dt2=24,f_rate=5,dfr1=5,dfr2=5,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
2023-06-02 09:12:24.212 DEBUG (MainThread) [pydaikin.daikin_airbase] Parsing ret=OK,zone_name=%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d,zone_onoff=0%3b0%3b0%3b0%3b0%3b0%3b0%3b0
Additional information
No response
Hey there @fredrike, mind taking a look at this issue as it has been labeled with an integration (daikin) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of daikin can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign daikinRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
daikin documentation daikin source (message by IssueLinks)
@mover85 is this a side effect from the pydaikin bump in https://github.com/home-assistant/core/pull/93635?
If an entity is registered under a new name, it means the unique ID has changed.
Do you see any errors in your logs?
@balloob It is a side effect in relation to the switches that will be fixed in #93782. The unique id is based on the mac address so shouldn't of changed.
@balloob @fredrike I have found the problem in pydaikin. I have created a pull request which solves this issue https://bitbucket.org/mustang51/pydaikin/pull-requests/63
I'll build a new version in a few hours..
@mover85 new version available on pypi.
The unique id is based on the mac address so shouldn't of changed.
mac addresses didn't change, it appears to have adopted the daikin platform name as the climate entity, whereas previously it was named after the ap:
Old device was named: climate.daikin_ap33073 New device named: climate.downstairs
I don't know if it's related, but since upgrading and reconfiguring my units after deleting everything following that duplication issue, now my daily energy usage doesn't get populated. Just sits at zero.
I think I have found the issue, on init the Airbase class isn't updating common/basic_info which has the device name. https://bitbucket.org/mustang51/pydaikin/pull-requests/66
Updated to 2023.6.2 tonight.
Have a new set of climate entities based on IP addresses.
Not sure what happens if IP address changes.
Also no name is now assigned to these devices.
My devices do not have power support, so that is unchanged.
Erratic switches have now disappeared.
Airbase app:
Other end points that work for me:
NB: "%44%6f%77%6e%73%74%61%69%72%73" decodes to "Downstairs" in ASCII.
http://192.168.86.30/skyfi/common/basic_info
ret=OK,type=aircon,reg=au,dst=0,ver=1_1_8,rev=1F,pow=1,err=0,location=0,name=%44%6f%77%6e%73%74%61%69%72%73,icon=15,method=home only,port=30050,id=,pw=,lpw_flag=0,adp_kind=3,led=1,en_setzone=1,mac=48E7DA018736,adp_mode=run,ssid=DaikinAP33073,err_type=0,err_code=0,en_ch=1,holiday=0,en_hol=0,sync_time=0
http://192.168.86.30/skyfi/aircon/get_model_info
ret=OK,err=0,model=NOTSUPPORT,type=N,humd=0,s_humd=7,en_zone=0,en_linear_zone=0,en_filter_sign=1,acled=1,land=0,elec=0,temp=1,m_dtct=0,ac_dst=au,dmnd=0,en_temp_setting=1,en_frate=1,en_fdir=0,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_scdltmr=0,en_mompow=0,en_patrol=0,en_airside=0,en_quick_timer=1,en_auto=0,en_dry=1,en_common_zone=0,cool_l=16,cool_h=32,heat_l=16,heat_h=32,frate_steps=2,en_frate_auto=0
http://192.168.86.30/skyfi/aircon/get_control_info
ret=OK,pow=1,mode=1,operate=1,bk_auto=1,stemp=21,dt1=21,dt2=24,f_rate=5,dfr1=5,dfr2=5,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
http://192.168.86.30/skyfi/aircon/get_sensor_info
ret=OK,err=0,htemp=-,otemp=-
http://192.168.86.30/skyfi/common/get_datetime
ret=OK,sta=2,cur=2023/6/15 21:42:39,reg=au,dst=0,zone=54
$ pydaikin -l -vvvv
DEBUG:pydaikin.discovery:Discovered ('192.168.86.30', 49155), ret=OK,type=aircon,reg=au,dst=0,ver=1_1_8,rev=1F,pow=1,err=0,location=0,name=%44%6f%77%6e%73%74%61%69%72%73,icon=15,method=home only,port=30050,id=,pw=,lpw_flag=0,adp_kind=3,led=1,en_setzone=1,mac=48E7DA018736,adp_mode=run,ssid=DaikinAP33073,err_type=0,err_code=0,en_ch=1,holiday=0,en_hol=0,sync_time=0
DEBUG:pydaikin.discovery:Discovered ('192.168.86.34', 49155), ret=OK,type=aircon,reg=au,dst=0,ver=1_1_8,rev=1F,pow=1,err=0,location=0,name=%55%70%73%74%61%69%72%73,icon=15,method=home only,port=30050,id=,pw=,lpw_flag=0,adp_kind=3,led=1,en_setzone=1,mac=48E7DA01943A,adp_mode=run,ssid=DaikinAP46401,err_type=0,err_code=0,en_ch=1,holiday=0,en_hol=0,sync_time=0
DEBUG:pydaikin.daikin_base:Updating ['common/basic_info']
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,sta=2,cur=2023/6/15 22:9:3,reg=au,dst=0,zone=54
DEBUG:pydaikin.daikin_base:Updating ['aircon/get_control_info', 'aircon/get_model_info', 'aircon/get_sensor_info', 'aircon/get_zone_setting']
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,pow=1,mode=1,operate=1,bk_auto=1,stemp=21,dt1=21,dt2=24,f_rate=5,dfr1=5,dfr2=5,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,err=0,model=NOTSUPPORT,type=N,humd=0,s_humd=7,en_zone=0,en_linear_zone=0,en_filter_sign=1,acled=1,land=0,elec=0,temp=1,m_dtct=0,ac_dst=au,dmnd=0,en_temp_setting=1,en_frate=1,en_fdir=0,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_scdltmr=0,en_mompow=0,en_patrol=0,en_airside=0,en_quick_timer=1,en_auto=0,en_dry=1,en_common_zone=0,cool_l=16,cool_h=32,heat_l=16,heat_h=32,frate_steps=2,en_frate_auto=0
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,err=0,htemp=-,otemp=-
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,zone_name=%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d,zone_onoff=0%3b0%3b0%3b0%3b0%3b0%3b0%3b0
192.168.86.30 (48E7DA018736): Downstairs - Unsupported energy consumption
DEBUG:pydaikin.daikin_base:Updating ['common/basic_info']
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,sta=2,cur=2023/6/15 22:9:3,reg=au,dst=0,zone=54
DEBUG:pydaikin.daikin_base:Updating ['aircon/get_control_info', 'aircon/get_model_info', 'aircon/get_sensor_info', 'aircon/get_zone_setting']
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,pow=1,mode=1,operate=1,bk_auto=1,stemp=21,dt1=21,dt2=24,f_rate=5,dfr1=5,dfr2=5,f_airside=0,airside1=0,airside2=0,f_auto=0,auto1=0,auto2=0,f_dir=0,dfd1=0,dfd2=0,filter_sign_info=0,cent=0,en_cent=0,remo=2
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,err=0,model=NOTSUPPORT,type=N,humd=0,s_humd=7,en_zone=0,en_linear_zone=0,en_filter_sign=1,acled=1,land=0,elec=0,temp=1,m_dtct=0,ac_dst=au,dmnd=0,en_temp_setting=1,en_frate=1,en_fdir=0,en_rtemp_a=0,en_spmode=0,en_ipw_sep=0,en_scdltmr=0,en_mompow=0,en_patrol=0,en_airside=0,en_quick_timer=1,en_auto=0,en_dry=1,en_common_zone=0,cool_l=16,cool_h=32,heat_l=16,heat_h=32,frate_steps=2,en_frate_auto=0
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,err=0,htemp=-,otemp=-
DEBUG:charset_normalizer:Encoding detection: ascii is most likely the one.
DEBUG:pydaikin.daikin_airbase:Parsing ret=OK,zone_name=%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d%3b%2d,zone_onoff=0%3b0%3b0%3b0%3b0%3b0%3b0%3b0
192.168.86.34 (48E7DA01943A): Upstairs - Unsupported energy consumption
no issues here with 2 daikin units, after installing 2023.6.2. work as before..
Same issue as Purcell. First it broke my automation because of previous changes had to manually fix this one and this from 2023.06.2 ruined it again
When I delete and let it auto discover it creates two devices with naming based on IP addresses.
I have this same issue. My home assistant instance in docker updates on Friday. The last two weeks, the entitites have been renamed, breaking my existing controls.
Can confirm same issue here which generated errors when trying to rename and recover:
Logger: homeassistant.components.recorder.entity_registry
Source: components/recorder/entity_registry.py:66
Integration: Recorder (documentation, issues)
First occurred: 09:21:33 (5 occurrences)
Last logged: 09:22:16
Cannot migrate history for entity_id `switch.none_family_zone1` to `switch.daikin_ac_zone1` because the new entity_id is already in use
Cannot migrate history for entity_id `switch.none_bedroomzone2` to `switch.daikin_ac_zone2` because the new entity_id is already in use
Cannot migrate history for entity_id `switch.none_lounge_zone3` to `switch.daikin_ac_zone3` because the new entity_id is already in use
Cannot migrate history for entity_id `climate.daikin_192_168_1_38` to `climate.daikin_ac` because the new entity_id is already in use
Cannot migrate history for entity_id `sensor.none_inside_temperature` to `sensor.daikin_ac_inside_temperature` because the new entity_id is already in use
Error executing query: (MySQLdb.IntegrityError) (1062, "Duplicate entry 'sensor.daikin_ac_inside_temperature' for key 'ix_statistics_meta_statistic_id'") [SQL: UPDATE statistics_meta SET statistic_id=%s WHERE statistics_meta.statistic_id = %s AND statistics_meta.source = %s] [parameters: ('sensor.daikin_ac_inside_temperature', 'sensor.none_inside_temperature', 'recorder')] (Background on this error at: https://sqlalche.me/e/20/gkpj)
Oddly, I cannot access the Daikin via AirBase now either. My initial troubleshooting was to re-add the adapter via airbase which didnt appear to work - it would connect and perform all the steps, but when finished wouldnt show the unit. It would however still connect via HA... odd
The naming should be the same as the airbase app which is not working. I am currently working on a fix.
naming should be the same as the airbase app which is not working. I am currently working on a fix.
Naming based on airbase would be great! It did briefly for 2023.6.1.
I've created a PR for the fix https://bitbucket.org/mustang51/pydaikin/pull-requests/67
The naming should be the same as the airbase app which is not working. I am currently working on a fix.
Would need to ve careful with this, as other parts of the world such as ours does not use airbase. We use daikin mobile controller.
Would need to ve careful with this, as other parts of the world such as ours does not use airbase. We use daikin mobile controller.
Naming in 2023.5 and earlier for me was based on ssid field returned by pydaikin. (Airbase controller with old head unit)
There should be some method of transition to avoid lots of breaking changes.
It gets the name field from /skyfi/common/basic_info so will work with other apps too. By default it is the same as the ssid. The issue was introduced by #35767
@fredrike I have created another PR, can you let me know if I need to make any changes?
https://community.home-assistant.io/t/daikin-airbase-testing-new-version-of-pydaikin/584104
@fredrike We have found an issue with the unique id generation. The ip address is being used instead of the mac address.
This is still appearing as a breaking change for lots of users: https://community.home-assistant.io/t/daikin-airbase-testing-new-version-of-pydaikin/584104?u=markpurcell
Legacy sensor naming was based from Daikin ssid field, new sensor name is from Daikin name field.
The name field makes sense long term, but there is no migration path currently identified and people are tripping over this issue one by one.