[BUG] - Home Assistant native Daikin integration - Fan Mode and Preset errors about esp32-faikin

[revk]

A couple more '6' entries I can send as well. I'll update again.

[revk]

That makes sense. May initialise to A in that case. Then cache any setting. I'll have to have a look.

[revk]

I am caching on get at present on basis that tools tend to do a get regularly - does that make sense.

I have defaulted to 20C and auto.

[revk]

Useful - I'll look when I am out of the hot tub...

[revk]

I wonder what it does at an S21 level!

[revk]

I have issued a new test for you to play with.

[Nick-Sills]

I was wrong for the Faikin response:

http://192.168.100.165/aircon/set_special_mode?spmode_kind=2&set_spmode=1
ret=OK,adv=

That's before the recent update

[revk]

The legacy mode should work in the same way to be honest, but it was a bit of a bodge.

Not entirely clears which mode you are using to make the changes.

Can you get a dump of the MQTT or URL/GET it is doing for these?

[Nick-Sills]

MQTT is working fine for the fan and preset, the only glitch is that there's no 'Home' preset for FTXM* units. I.e, The climate entity has 'Home', but there's no such preset for the AC unit.

Those videos are of the 'Legacy' Daikin integration which has the bugs.

I'll try and get the URL's.

[Nick-Sills]

I'm not sure if this helps, but here's a .pcap of comms between 192.168.100.11 (the pi hosting HA), 192.168.100.165 (the Faikin board). It should cover the events in the first video, Fan.Mode.mp4.

Filter by: ip.addr == 192.168.100.165

I've renamed Faikin,pcap to Faikin.txt because I couldn't upload .pcap. Just rename it back.

Faikin.txt

Let me know if you need anything else.

[revk]

FYI the pcap shows getting info, then

GET /aircon/set_control_info?pow=0&mode=7&stemp=16&shum=0&f_rate=0&f_dir=0 HTTP/1.1

With response

ret=PARAM NG,adv=Invalid f_rate value

My notes suggest an f_rate of 3 to 7 or A or B are valid, not 0

Do you know what 0 is meant to mean?

[Nick-Sills]

That's odd, I don't think 0 is a real fan rate. The "Fan mode" selection works perfectly, it's only when the set temperature changes that it causes an error. That smells like an uninitialized variable in the Daikin integration being sent rather than the current fan rate. I also have another Daikin unit with a BRP069B4 local API module, and that's working fine.

[revk]

We ignore the 0 (apart from reporting an error) so it should be working anyway, and not even change fan rate.

[Nick-Sills]

It reports the error, then the fan mode changes to an unset state in the UI. I don't know what would happen if no error was sent.

[revk]

We don't change fan if the error is reported though?!? Maybe it thinks it is an unknown state, what fan state is reported on the web interface.

[Nick-Sills]

It changes to unset:

From:

To:

[revk]

I meant the web interface on the Faikin!

[Nick-Sills]

That's unchanged and shows 'Auto'. Perhaps 0 means don't change, and it's the error returned that's causing a problem in the HA UI?

[revk]

I can try that (i.e. not sending error) - use next beta. But a better "don't change" would be not to send f_rate at all!

[Nick-Sills]

I'll do some more tests but I think that's fixed both problems! 👍

Faikin-S3-MINI-N4-R2: 32727c3 2024-06-04T10:39:47 S21

[Nick-Sills]

Sorry, I spoke too soon. There's still the same error being returned.

[revk]

The latest beta should ignore a 0. I'll double check. Can you do another pcap?

[Nick-Sills]

Sure, it'll be in an hour or so.

[Nick-Sills]

First pass, and the response from Faikin seems to be good, it's also immediately responding to get_control_info request with the correct f_rate. I can't see where f_rate=0 is coming from, or why it's causing an error, given that it's got the correct f_rate from get_control_info.

Changing Set Temp - Error - Fan mode is invalid
http://192.168.100.165/aircon/set_control_info?pow=1&mode=7&stemp=18&shum=0&f_rate=0&f_dir=0
ret=OK,adv=
http://192.168.100.165/aircon/get_control_info
ret=OK,pow=1,mode=7,adv=,stemp=18.0,shum=0,dt1=18.0,dt2=18.0,dt3=18.0,dt4=18.0,dt5=18.0,dt7=18.0,dh1=0,dh2=0,dh3=0,dh4=0,dh5=0,dh7=0,dhh=0,b_mode=7,b_stemp=18.0,b_shum=0,alert=255,f_rate=B,f_dir=0,b_f_rate=B,b_f_dir=0,dfr1=0,dfr2=0,dfr3=0,dfr4=0,dfr5=0,dfr7=0,dfrh=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd7=0,dfdh=0,dmnd_run=0,en_demand=0

Changing the fan speed - OK
http://192.168.100.165/aircon/set_control_info?pow=1&mode=7&stemp=18.0&shum=0&f_rate=B&f_dir=0
ret=OK,adv=
http://192.168.100.165/aircon/get_control_info
ret=OK,pow=1,mode=7,adv=,stemp=18.0,shum=0,dt1=18.0,dt2=18.0,dt3=18.0,dt4=18.0,dt5=18.0,dt7=18.0,dh1=0,dh2=0,dh3=0,dh4=0,dh5=0,dh7=0,dhh=0,b_mode=7,b_stemp=18.0,b_shum=0,alert=255,f_rate=B,f_dir=0,b_f_rate=B,b_f_dir=0,dfr1=0,dfr2=0,dfr3=0,dfr4=0,dfr5=0,dfr7=0,dfrh=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd7=0,dfdh=0,dmnd_run=0,en_demand=0

faikin.txt

Not sure what adv= is

[Nick-Sills]

Perhaps return from aircon/set_control_info?pow=1&mode=7&stemp=18&shum=0&f_rate=0&f_dir=0

with ret=OK,f_rate=B ( or whatever the current fan rate is )

[revk]

I thought all the set commands just return ret=OK. Not sure about changing that incase it upsets something else. All seems very odd.

[Nick-Sills]

Agree, it's very odd.

It's currently retuning ret=OK,adv=, so it isn't just OK at the moment.

[revk]

OK I am not keen on tinkering with what is returned on a set command.

[Nick-Sills]

I can fire the same url at an actual Daikin WiFi board to see what happens. Give me a miute...

[revk]

OK, that is a sensible.

[Nick-Sills]

http://192.168.100.171/aircon/set_control_info?pow=1&mode=7&stemp=18&shum=0&f_rate=0&f_dir=0
it returned:
ret=PARAM NG

for

http://192.168.100.171/aircon/set_control_info?pow=1&mode=7&stemp=18&shum=0&f_rate=B&f_dir=0
it reurned:
ret=OK,adv=

[revk]

Which fits with f_rate=0 not being valid, and what we were sending (along with adv= and error).

[revk]

I can't imagine the adv= being an issue with the PARAM NG.

But it suggests the issue is not in the Faikin.

[Nick-Sills]

I'll grab a .pcap of the same Fan speed change, followed by a set target temp change on the real Daikin wifi unit. This works OK in HA, so it'll be interesting to see if anything is different....

[revk]

Ok thanks, that should give us some way to get a comparison of the way it works.

[Nick-Sills]

Not checked it yet....
daikin.txt

[revk]

That looks like it sends f_rate=A or f_rate=B

Can you see any other differences?

[Nick-Sills]

The fan speed selections were different for the Daikin unit. With Faikin it reset to nothing on error, so I put it back to Auto.

I can't see any smoking gun. get_control_info is returning an extra two parameters on the Daikin unit, but that doesn't seem relevant. ,dfr6=5,dfd6=0

Still looking...

[revk]

Yeh, for some reason we exclude 6 on that, not sure why, but will be based on previous message dumps like this.

[Nick-Sills]

I think it has to be something with get_control_info as that's the only data that is effectively 'configuring' the climate entity states in HA. Unless I've missed something.

However, the unit with the Daikin WiFi board is a different model, so it's not a direct comparison.

[revk]

Can you see any other difference? I mean, I can add the dfr6/dfd6 maybe?

[Nick-Sills]

All other parameters match. If we try dfr6/dfd6 and it doesn't work then it could be reverted,

[revk]

OK, try that beta

[Nick-Sills]

No change I'm afraid...

Faikin-S3-MINI-N4-R2: cc5100f 2024-06-04T13:20:35 S21

[revk]

No change, as it not sending those extra values? or still not working? Might be a typo on my part, I'll try again.

We should be doing test builds not beta for this, but hopefully this is the last one.

[Nick-Sills]

I meant it didn't fix the problem. I haven't check for the parameters, give me a minute

[Nick-Sills]

The extra parameters are there, so it's back to square one. I'll spend some time later studying the .pcap dumps to see if there's anything else

[Nick-Sills]

You could try dfr6=5 rather than dfr6=0. That's what the Daikin board returned.

[revk]

OK set otahost to test.revk.uk and turn off otabeta and upgrade.

[Nick-Sills]

done

[revk]

Ok that will send =5

[Nick-Sills]

My pi seems to have crashed/hung. Apologies, I'm going to have to go offline for a bit to fix this and attend to something else....

[Nick-Sills]

I'm afraid it didn't work. I think we may be barking up the wrong tree here, so I'll give it some thought and get back if I have any other ideas, Perhaps study the HA Daikin integration in more detail.

[revk]

Thanks.

[Nick-Sills]

I'm posting this here before properly looking at the data, so apologies if this isn't helpful.

It seems that the control communication between HA and Faikin is faultless when compared with a Daikin WiFi board. The problem might be due to the configuration of the Climate entity in HA, and that only happens on discovery when the device is added. So, I removed the Daikin native AC unit, and one of the Faikin units, then added them back and captured the discovery of both units. I've not had a chance to digest what's going on, but I thought it'd be useful info regardless.

Daikin Discovery

http://192.168.100.171/common/basic_info
ret=OK,type=aircon,reg=eu,dst=1,ver=1_14_88,rev=8A618141,pow=1,err=0,location=0,name=%20%46%72%6f%6e%74%20%42%65%64%72%6f%6f%6d,icon=22,method=polling,port=30050,id=a9706479-4a61-4a57-aa06-66c09f145a9d,pw=,lpw_flag=0,adp_kind=3,pv=3.20,cpv=3,cpv_minor=20,led=1,en_setzone=1,mac=346F240A90C8,adp_mode=run,en_hol=0,ssid1=Silvia42,radio1=-69,ssid=DaikinAP75416,grp_name=,en_grp=0


http://192.168.100.171/common/get_datetime?cur=
ret=OK,sta=2,cur=2024/6/4 21:22:25,reg=eu,dst=1,zone=211


http://192.168.100.171/common/get_remote_method
ret=OK,method=polling,notice_ip_int=3600,notice_sync_int=10

http://192.168.100.171/aircon/get_sensor_info
ret=OK,htemp=21.0,hhum=-,otemp=21.0,err=0,cmpfreq=16,mompow=2

http://192.168.100.171/aircon/get_model_info
ret=OK,model=135E,type=N,pv=3.20,cpv=3,cpv_minor=20,mid=NA,humd=0,s_humd=0,acled=0,land=0,elec=1,temp=1,temp_rng=0,m_dtct=0,ac_dst=--,disp_dry=0,dmnd=1,en_scdltmr=1,en_frate=1,en_fdir=1,s_fdir=1,en_rtemp_a=0,en_spmode=3,en_ipw_sep=1,en_mompow=1,en_onofftmr=1,hmlmt_l=10.0


http://192.168.100.171/aircon/get_control_info
ret=OK,pow=1,mode=0,adv=,stemp=20.0,shum=0,dt1=20.0,dt2=M,dt3=18.0,dt4=19.0,dt5=19.0,dt7=20.0,dh1=0,dh2=50,dh3=0,dh4=0,dh5=0,dh7=0,dhh=50,b_mode=0,b_stemp=20.0,b_shum=0,alert=255,f_rate=B,f_dir=0,b_f_rate=B,b_f_dir=0,dfr1=B,dfr2=5,dfr3=5,dfr4=5,dfr5=5,dfr6=5,dfr7=B,dfrh=5,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0,dmnd_run=0,en_demand=0

http://192.168.100.171/aircon/get_target
ret=OK,target=0

http://192.168.100.171/aircon/get_price
ret=OK,price_int=27,price_dec=0

http://192.168.100.171/common/get_holiday
ret=OK,en_hol=0

http://192.168.100.171/common/get_notify
ret=OK,auto_off_flg=0,auto_off_tm=- -

http://192.168.100.171/aircon/get_day_power_ex
ret=OK,curr_day_heat=0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0,prev_1day_heat=0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0,curr_day_cool=2/2/1/1/2/1/1/2/1/2/1/2/2/3/0/0/0/0/2/2/2/0/0/0,prev_1day_cool=1/2/1/2/1/2/1/2/1/2/2/1/2/0/0/0/0/0/0/0/0/0/0/1

http://192.168.100.171/aircon/get_week_power
ret=OK,today_runtime=1025,datas=0/0/100/0/100/200/200

http://192.168.100.171/aircon/get_year_power
ret=OK,previous_year=0/0/0/0/0/0/2/2/3/1/0/0,this_year=1/1/0/1/1/0

http://192.168.100.171/common/get_datetime
ret=OK,sta=2,cur=2024/6/4 21:30:39,reg=eu,dst=1,zone=211

Faikin Discovery - (I played back the same URLs from the Daikin discovery)

http://192.168.100.165/common/basic_info
ret=OK,type=aircon,reg=eu,dst=1,ver=f690972+,rev=f690972+,pow=1,err=0,location=0,name=Villacana AC Back Bedroom,icon=1,method=none,port=0,id=34B7DA588E44,pw=,lpw_flag=0,adp_kind=0,pv=0,cpv=0,cpv_minor=0,led=0,en_setzone=0,mac=34B7DA588E44,ssid=Silvia42,grp_name=,en_grp=0

http://192.168.100.165/common/get_datetime?cur=
Nothing matches the given URI

http://192.168.100.165/common/get_remote_method
Nothing matches the given URI

http://192.168.100.165/aircon/get_sensor_info
ret=OK,htemp=21.00,hhum=-,otemp=21.50,err=0,cmpfreq=-

http://192.168.100.165/aircon/get_model_info
ret=OK,model=FTXM20R

http://192.168.100.165/aircon/get_control_info
ret=OK,pow=1,mode=7,adv=,stemp=20.0,shum=0,dt1=20.0,dt2=20.0,dt3=20.0,dt4=20.0,dt5=20.0,dt6=20.0,dt7=20.0,dh1=0,dh2=0,dh3=0,dh4=0,dh5=0,dh6=0,dh7=0,dhh=0,b_mode=7,b_stemp=20.0,b_shum=0,alert=255,f_rate=A,f_dir=0,b_f_rate=A,b_f_dir=0,dfr1=0,dfr2=0,dfr3=0,dfr4=0,dfr5=0,dfr6=5,dfr7=0,dfrh=0,dfd1=0,dfd2=0,dfd3=0,dfd4=0,dfd5=0,dfd6=0,dfd7=0,dfdh=0,dmnd_run=0,en_demand=0

http://192.168.100.165/aircon/get_target
Nothing matches the given URI

http://192.168.100.165/aircon/get_price
Nothing matches the given URI

http://192.168.100.165/common/get_holiday
Nothing matches the given URI

http://192.168.100.165/common/get_notify
Nothing matches the given URI

http://192.168.100.165/aircon/get_day_power_ex
Nothing matches the given URI

http://192.168.100.165/aircon/get_model_info
ret=OK,model=FTXM20R

http://192.168.100.165/aircon/get_week_power
Nothing matches the given URI

http://192.168.100.165/aircon/get_year_power
Nothing matches the given URI

daikin_init.txt
faikin_init.txt

[Nick-Sills]

Just for giggles I asked ChatGPT. It could be total nonsense of course:

Detailed Fan Rates (dfr1, dfr2, ..., dfr7):

Real Unit: dfr1=B, dfr2=5, dfr3=5, dfr4=5, dfr5=5, dfr6=5, dfr7=B, dfrh=5
Reverse Engineered: dfr1=0, dfr2=0, dfr3=0, dfr4=0, dfr5=0, dfr6=5, dfr7=0, dfrh=0

Issue: The detailed fan rates (dfr1 to dfr7) are mostly zeros in the reverse-engineered output, except for dfr6=5. In contrast, the real unit has specific values for these settings, indicating a more complex configuration that adjusts the fan speed at different stages or modes. The lack of detailed fan rate configuration in the reverse-engineered module could lead to incorrect fan speed settings.

Recommendations:
Align Fan Rate Settings: Ensure that the f_rate and b_f_rate parameters in the reverse-engineered module match those of the real unit. This can be set to B or the appropriate setting as per the real unit's configuration.

[Nick-Sills]

So, I think dfr1 to dfr7 is the last fan rate setting for each operation mode This enables you change from Auto to Cool for example, and the fan speed changes to whatever the last speed was when Cool was last selected. I don't know why the HA integration substituting dfrx for the fan speed when the set temp changes, but that's what appears to be happening, and it's sending '0', which is invalid.

Perhaps we should cache the value of f_rate in the appropriate dfrx field, depending on the current mode, and return the populated dfr1 to dfr7 values in get_control_info. At startup set the dfr array values to auto.

Similary, the dt1 array appears to be the set temp cache for the target temperature in each mode, the dh1 array is humidity, but that isn't relevant to most units, and the dfd1 array is the fan direction states.

Does that sound plausable?

[Nick-Sills]

I'm not sure how the climate entity updates when a remote control is used to change the fan speed, but ideally the dfr array should reflect the AC unit current setting, not just when set_control_info is received. Perhaps this already happens anyway.

[revk]

Ok I am going to try and cache at get_control_info - I have issued new test code.

[Nick-Sills]

Yep that fixed the set temp change error! Fantastic👍

Initializing the dt1 array to 20c and caching the set temp would be great, as well as dfd1.

The empty dt1 array causes the set temp to go to `0' when changing mode.

There's still a problem changing the Preset mode, but I think that could also be a related issue to a cache.

[Nick-Sills]

Now I know how it's meant to be working, I can go through all combinations of settings to make sure it behaves itself.

[Nick-Sills]

We.re nearly there! And the set temp is no longer 'null' on a reboot. Not sure if that was an intentional change.

Set temp seems to be remembering the last mode value.
Fan mode is remembering the setting when the mode changes, and not causing an error when changing the set temp

Swing mode remains static, i.e. doesn't remember the state when the mode changes. I don't really care about that, but I guess for perfection it should.

Preset isn't working correctly though. If set to 'Eco' it switches to 'None' and occasionally 'Boost'.

I haven't yet checked yet to see what happens when changing with the remote or MQTT, but it's probably best to iron out the remaining issues before checking that.

[revk]

I don't don't what the other numbered settings are for. Maybe that covers some.

What's the preset command? I'll look.

[Nick-Sills]

Daikin:
none, away, eco, boost

Faikin:
none, eco, boost

[Nick-Sills]

.pcap files when changing the preset:

daikin_preset.txt
faikin_preset.txt

[Nick-Sills]

Not sure if this is relevant:

Daikin:
http://192.168.100.171/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=OK,adv=2

Faikin:
http://192.168.100.165/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=PARAM NG,adv=Unsupported spmode_kind value

[revk]

Sounds like an incomplete legacy url handler. I'll have to look.

[Nick-Sills]

ChatGPT again:

The set_special_mode function in the Daikin API is used to control various special operating modes of a Daikin air conditioner. These modes can include settings such as "Powerful", "Econo", and "Streamer" (ionizer), among others. The function allows you to enable or disable these modes by sending specific HTTP requests to the air conditioner's API endpoint.

Here are some examples of how to use the set_special_mode function:

Enable Powerful Mode:

/aircon/set_special_mode?set_spmode=1&spmode_kind=1

This command enables the Powerful mode, which can be verified by the response showing adv=2.

Disable Powerful Mode:

/aircon/set_special_mode?set_spmode=0&spmode_kind=1

This command disables the Powerful mode.

Enable Econo Mode:

/aircon/set_special_mode?set_spmode=1&spmode_kind=2

This command enables the Econo mode, which can be verified by the response showing adv=12.

Disable Econo Mode:

/aircon/set_special_mode?set_spmode=0&spmode_kind=2

This command disables the Econo mode.

The spmode_kind parameter specifies the type of special mode you want to set, with different values corresponding to different modes. The set_spmode parameter indicates whether to enable (1) or disable (0) the mode.

[Nick-Sills]

[Nick-Sills]

This is probably a step too far...

There's an 'Away' preset mode for the Daikin WiFi unit integration, but it isn't a 'special mode'

Daikin
http://192.168.100.171/common/set_holiday?en_hol=1

Faikin
http://192.168.100.165/common/set_holiday?en_hol=1
Nothing matches the given URI

However, the 'Away' Preset doesn't exist in the Faikin climate entity, so we might as well ignore it.

[Nick-Sills]

Damn! the Preset still isn't operating.

I've got to go offline for a couple of hours, but I'll check the comms when I get back. This is so much fun. 😄

[Nick-Sills]

http://192.168.100.165/aircon/set_special_mode?spmode_kind=1&set_spmode=1

Is still returning:
ret=PARAM NG,adv=Unknown mode

test.revk.uk
Faikin-S3-MINI-N4-R2: f690972+ 2024-06-05T10:24:15

[revk]

Ok will look.

[revk]

Grr, all down to converting GET form args to JSON internal. Try now.

[Nick-Sills]

We're Close. It now correctly sets Boost, but doesn't update the UI (The climate button jumps to 'None').

Daikin
http://192.168.100.171/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=OK,adv=2

The climate entity imediately responds with:
http://192.168.100.171/aircon/get_control_info

http://192.168.100.171/aircon/set_special_mode?spmode_kind=2&set_spmode=1
ret=OK,adv=12

http://192.168.100.171/aircon/set_special_mode?spmode_kind=3&set_spmode=1
ret=PARAM NG

Faikin
192.168.100.171/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=OK,adv=
No further response from the climate entity

192.168.100.171/aircon/set_special_mode?spmode_kind=2&set_spmode=1
ret=OK,adv=12

192.168.100.171/aircon/set_special_mode?spmode_kind=3&set_spmode=1
ret=PARAM NG

So it looks like the adv parameter must be set to indicate that it's worked.

ChgatGPT again:
If the context involves setting special modes, adv=2 might mean that the Powerful mode is currently active.

[revk]

OK so what do we thing adv= should be exactly?

[revk]

Ooh, my code has

     jo_string (j, "adv", daikin.powerful ? "2" : "");

Do we think it is blank, 1, 12, 13, 123, 23, ...

[Nick-Sills]

Should be adv=2 for spmode_kind=1

[revk]

FFS, do we have any clue what adv actually means, even in get_control_info

[revk]

And you have ret=OK,adv=12 in one case?

[revk]

Ok we have adv=2 for powerful in another place, so I'll add to all responses maybe. Try that.

[Nick-Sills]

Maybe 12 is Quiet and Powerful?

[revk]

OK I am assuming the numbers stack up, try that! Though quiet and night being separate may mean I have that wrong. I think quiet may be a special mode for external fan rather than fan in night mode... try that!

[Nick-Sills]

Unfortunately it's not working:

Faikin:
BOOST
http://192.168.100.165/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=OK,adv=23

ECO
http://192.168.100.165/aircon/set_special_mode?spmode_kind=2&set_spmode=1
ret=OK,adv=23

Perhaps it should be:
BOOST
http://192.168.100.165/aircon/set_special_mode?spmode_kind=1&set_spmode=1
ret=OK,adv=2

ECO
http://192.168.100.165/aircon/set_special_mode?spmode_kind=2&set_spmode=1
ret=OK,adv=12

The table above is wrong I've deleted the post with the table of adv values

ael-code/daikin-control#11

"GET HTTP requests):
/aircon/set_special_mode?en_streamer=0
this command disables the ion streamer on the AC (or it enables substituting ?en_streamer=1). The response has the form:
ret=OK,adv=13
or
ret=OK,adv=
where '13' means that the streamer has been activated or '' means that it has been deactivated
/aircon/set_special_mode?set_spmode=1&spmode_kind=1
this command enables the power mode of the AC and this can be seen looking at the adv=2 return message (even in the get_control_info)
/aircon/set_special_mode?set_spmode=1&spmode_kind=2
this command enables the econo mode of the AV and this can bee seen looking at the adv=12 return message (even in the get_control_info)
/aircon/set_special_mode?set_spmode=0&spmode_kind=1
this command disables the power mode of the AC (I think it also works without the spmode_kind variable and also that it also disable the econo mode, but I haven't checked so far)"

[revk]

OK still not sure I follow, sorry.

Do we think adv= is a current state (even in get_control_info), and that 2, 12, 13, reflect specific modes/states? If so which ones?

[Nick-Sills]

Yes, it's the current state.
adv=2 = Boost Enabled
adv=12 = Econo Enabled
adv=13 = Streamer mode enabled

I don't have streamer mode to test

[revk]

Try again now

legacy_adv (jo_t j)
{
   jo_int (j, "adv",            //
           daikin.powerful ? 2 :        //
           daikin.econo ? 12 :  //
           daikin.streamer ? 13 :       //
           0);
}

[Nick-Sills]

It's working perfectly!

[revk]

I'll issue a beta, so you can change back to ota.revk.uk and otabeta when ready.

[Nick-Sills]

That's great, and thanks for your efforts.

The Faikin units are now behaving exactly like the Daikin WiFi AC unit with the remote control as well. If I change to 'Boost' using the remote, the UI is updated on the next 'get_control_info' call.

[Nick-Sills]

#347

Just to add that I was wrong about the above issue being resolved. It's not a major problem, but it's still there and I have to move the slider in the web UI after most (all - perhaps) reboots.

Anyway, thanks again for this project, and I'm pleased that the native Daikin integration is now working so well in HA.