Hi JimT, many thanks for your replay.
I try adrres you gave me but no one work.
I have 3 new air unit who keep IP address on my local network like this :
IP : 192.168.1.58
HOST : daikinap60715.local
pls see attacche file who I can see at http://192.168.1.58/
no authentication is request
(pls note I’m not a developer, I’m only a maker and OH user…)
Thanks!!
192.168.1.58.pdf (62.7 KB)
@tebraxin I think @Paul_Smedley has got the answer up there.
@jimtng the correct post is that, mine is the exact same situation, so I follow that post. thanks to all for the replies.
I have the same issue with the new BRP069C4x wifi interface. The feedback I got from Daikin Belgium is that they will be using this type of interface for their current and future products …
the github thread basically describes how the communication works, next step will be to incorporate this in a new type of daikin binding.
But as I am not a developper, I can only offer my possibility to help testing … hopefully somebody will pick this up.
is there an API to update the date-time?
is sync time?
Hey Paul,
Anyone would think daylight savings just started in Australia 
There is definitely no current code for time sync, however, the Airbase app can do it, so there must be an API to do it.
Cheers,
Paul
well I did try the Airbase App (which is rubbish) and I couldn’t get it to sync the time so I gave up and manually entered it.
Its unclear how and when it syncs the clock.
OK, spent some time on my phone with ‘packet capture’, and Android app that works kinda like Wireshark…
Query time:
http://192.168.1.220/skyfi/common/get_datetime
Returns output like:
ret=OK,sta=2,cur=2021/10/3 10:22:38,reg=au,dst=1,zone=5
Note: time is in local time
Setting time:
http://192.168.1.220/skyfi/common/notify_date_time?lpw=&date=2021%2F%2F10%2F03&zone=GMT&time=23%3A51%3A46
Returns output like:
ret=THROUGH
Note time/date are in GMT, not in local time
I have no time right now to work on the binding, but documenting this in case anyone want to look at it.
interesting my /get_datetime returns zone=345 not sure what that means??
ret=OK,sta=2,cur=2021/10/3 11:12:47,reg=au,dst=1,zone=345
update:
actually I think it relates to “Sydney”
I’m curious. I live in QLD, no DST, and I just set the date/time on the aircon once and never thought about it again. I have absolutely zero use for the date/time on the aircon, but I do realise it’s displayed on the controller on the wall. Is that the only reason why you’d like to set it programmatically? If it has DST settings / proper timezone, shouldn’t it auto-adjust for the DST changes?
Hi Jim,
I tend to check the time in the controller twice per year when DST starts or ends.
I think that if sync is enabled, it only syncs when the airbase app is loaded.
I don’t see a massive need to add the binding - I guess it would be nice to keep the time accurate, but not sure if there’s any way way to trigger a sync once per day (or whatever) frequency.
Cheers,
Paul
Hi @Bl00d_b0b would you mind testing the changes I made to control streamer / powerful / eco mode here:
https://github.com/jimtng/openhab-addons/releases/tag/daikin-specialmode-v0.0.1
Since it is not Airbase related, could you please post the result in this thread instead:
hello, there I have just notice the Binding doesn’t seem to respond some commands eg switching modes
eg COLD → HEAT.
I’ve seen on a couple of occasions that if multiple commands are sent in a short period (for example from a rule), then the 1st command doesn’t ‘stick’. Is this your scenario too?
oh right it looks like I was too clicky when I tried.
is there a way to “debounce” these requests to avoid this behavior?
I’m not sure yet… I worked around it in my script by adding a delay…
It happens due to the way the Daikin API works - it send multiple commands in one string.
for example:
http://192.168.1.7/skyfi/aircon/set_control_info?lpw=&mode=0&dt0=--&f_airside=0&f_rate=3&shum=--&pow=0&stemp=--&f_dir=1&f_auto=0
This one command sets mode, temperature, fan speed and power.
All parameters have to be sent in the command - even the unchanged ones. If you get too clicky or send commands close together, the second command sends the ‘old’ values that were read from the controller, and overrides the 1st command. (Hope that makes sense).
I need to think on how to resolve this, but it hasn’t made it very high on my todo list since I worked around it 
thanks for the update,
another question about the FAN speeds , there are 5 levels is that correct as my display only has 3 levels is there a hidden levels between low,med,high?
ie are there actually 5 speeds + auto
It might depend on the controller. Someone else (I forget who) added the other two fan speeds - they believed there was a difference between fan speed 1, 2, 3, 4, 5 even though the wall controller only shows the 3 speeds.
re: the commands in quick succession not doing what’s expecting, I’m thinking that polling the status rom the Airbase after successfully sending the command should do the trick
Poll should need to be done somewhere around here: https://github.com/psmedley/openhab-addons/blob/main/bundles/org.openhab.binding.daikin/src/main/java/org/openhab/binding/daikin/internal/DaikinWebTargets.java#L218C35-L218C35
https://smedley.id.au/tmp/org.openhab.binding.daikin-4.0.0-SNAPSHOT.jar may fix the problem of rapid commands not all ‘sticking’. NB: this is built for OH 4.0 - I’m getting an error trying to build for 3.2 → 4.0 - probably due to some changes in main for Java 17…