After reading some more of the messages I am starting the wondering if waiting is not a solution. If response times at OneCloud is an indication there shouldn’t be an issue as I have changed the login at the thermostat today and re-added the app at several phones and app is updating thermostat without any delay (wife issue was password!). Really like to understand what software version the people run at the thermostat that are currently having the “Unauthorized” when doing the curl with the bearer message OR if there are any folks running the latest version of software on the thermostat without login issues?
I have the same version and it works fine for me. Without any information on how your app is accessing the API, there’s not much I can do to troubleshoot the integration. It’s possible they’ve changed something and mine’s using a legacy interface. I got one of the first thermostats out there and never needed to create a skyport account. You set up the skyport account with the same username and password, right? Have you tried rebooting the thermostat? I have a feeling there are two methods the app uses to connect and it tries skyport first and goes to the other if that fails.
Maybe not having matching user/pass at SkyPort cloud is where the issue lies, however didn’t think that was related as it seems to be for different thermostat than the One+. As the user+password that I use on the thermostat to connect to the OneCloud successfully gets a bearer token made me think that is the only “cloud” needed, however maybe there is some backend connection between the two…so matched up the username + passwords…guess we wait now as its not working yet 
Fixed it, deleted old daikinskyport.conf that still had an old user/pass after restart new one was created with diff info.
OLD:
{
“EMAIL”: “<EMAIL_REMOVED>”,
“PASSWORD”: “<PASSWORD_REMOVED>”
NEW:
{“ACCESS_TOKEN”: “<BEARER_TOKEN_REMOVED>”, “EMAIL”: “<EMAIL_REMOVED>”}
I will do a test in a couple of days to see if the SkyPortCloud login is needed or if just the thermostat one is enough. Anyways stoked its working now!!!
Just this night, the indoor and outdoor power sensors started reporting 65535 instead of the real values. Any idea why that might be?
Thanks!
That value means the thermostat is not getting a proper reading from the system. The sensor is essentially unavailable.
Wouldn’t it be better then to mark it as unavailable in the integration?
Probably. This is the first time I’ve heard this issue. We’ve had some discussion on what to do with that number before, but it was in relation to whether the integration should include the sensor or not when it starts up. You can add a github issue and one of us might be able to fix it. I don’t have the energy sensors, so hopefully someone else can check it out. The bigger question is probably why is it not reporting properly in the first place. If you’ve had some other issues with it, your thermostat may be too far or there is interference.
Same read out seems to have recently changed as I remember different value, sadly no logging info when this changed as I recently redid my HA.
Different topic, am I right in saying that the auxiliary setting is informational as I seem to be unable to set it through the card, while the toggle changes when set manually on the unit…remember reading somewhere that Daikin has restricted setting aux through the API.
They may have changed the API then. If you post the output from your thermostat, I might be able to find where they stuck it. I don’t have energy sensors, so I would need someone who has it to hopefully find the values.
As far as the Aux, if it works in the Daikin app, then it should work on the card. It never gets cold enough here for me to need the Aux, so I can’t really say if it ever worked. I would think someone would have complained about it by now if it didn’t, though.
Gotcha, will take a peek when I have some time…its 20F here now and it should actually use the heatpump lockout temp (set to 25F) to automatically switch to emergency (AUX), which its not doing…working with Daikin tech on this right now. Thanks!!
Hi everyone I just wanted to come here and say thanks for this integration!
The only thing I wish is that we could somehow encrypt the password so it’s not in plain text in the config file. Other than that, for a HA newb as myself your instructions from the github page worked perfectly and I have one of my zones setup. I’m installing the other two thermostats today so hopefully they show up once I add them to my Daikin app.
Unfortunately I don’t see a native way to encrypt the password other than using a keyring (which would be up to you and not user friendly). I could just use the password once during the initial config and not save it, but if the token stops working (which does happen), you would need to re-enter the password again somehow. Most integrations I’ve seen don’t encrypt anything. It’s all stored in .storage/core.config_entries. I’ve been working on the config flow which stores the config info in core.config_entries under a different github branch. It works, but it’s not pretty yet.
https://www.daikinone.com/openapi/documentation/index.html
Has anyone tried and was successful with using the Daikin One Cloud Open API as document at the above referenced site?
I’ve tried it out. I haven’t looked at it in a while, but I didn’t bother to use it since the integration’s API is much more robust.
I have multiple DaikinOne branded touchscreen thermostats.
The Venstar LOCAL API plugin works for these.
I assume you mean Venstar - Home Assistant? If so, I tried it and couldn’t get it to work. What settings did you use to get it to work for your thermostats? Does your thermostat look like this? https://daikinone.com/
This is what I have:
I just set the Local Wifi Address in the plugin.
Had to turn on Local API access in the thermostat settings.
Ah, ok. Yeah, that’s not a Daikin One, or at least not the one we’re talking about in this thread. We do not have a setting for a local API. Good to know it works for that thermostat, though.