This is an updated driver for Skyport linked thermostats, such as:
- Daikin One+ Thermostat
- Daikin One Touch Thermostat
- Daikin One Lite Thermostat
- Amana Smart Thermostat
- Goodman Connected GTST
This thermostat builds on the drivers from @trevor.deane, @woodard.thomas, and @thebearmay
Enhancements in this version:
- Thermostat credentials can be set in the web UI- no more hardcoded keys
- Auth Token caching- improves latency and reduces round-trips by not discarding authTokens after each cloud connection
- (very large) Integrator Token no longer stored in session - reduces Hubitat database serialization/deserialization overhead on every update
- Outdoor Temperature Child Device (exposed for automations to access)
Plus a few bug fixes and stability enhancements.
You can find the repository and documentation on github:
Github Repository
Driver code
This driver uses the Daikin One Open API (integrator API). This is a newer and fully documented API. It is fairly basic compared to the older API, but hopefully stable
Please let me know how this works for you and any issues you discover.
1 Like
Many thanks for your work on this.
I had written a driver a while back (prior to the change to Skyport) that got the job done, but needed further development. I will be switching to this driver for sure.
Suggest that you add capability "ThermostatSetpoint" and associated code to the driver, this is intended to reflect the current thermostat setpoint regardless of the current thermostat mode. Very useful for automations, etc.
Thanks! Excellent suggestion.
I've added ThermostatSetpoint as well as RelativeHumidityMeasurement and TemperatureMeasurement capabilities in version 1.0.1
That was fast! I pulled the new version and after a Refresh there is now a thermostatSetpoint attribute.
Another thing you might consider - I like that you have added a child device for the outside temperature, reflecting the tempOutdoor attribute. It could be helpful if in a similar fashion you add a RelativeHumidity child device for the outdoor relative humidity attribute (humidOutdoor) that the API provides in the update message.
Thinking out loud, maybe that is superfluous given you have added RelativeHumidityMeasurement capability to the device already. I am struggling to think of a case where the child device would be advantageous.
Much appreciated.
Yes, you're thinking like me. I couldn't come up with a use case for the outdoor humidity yet, so I haven't written that. And I wanted to see how devs and users felt about the child device idea, so I didn't go wild creating a bunch of child devices.
The Daikin One API exposes indoor and outdoor temp as well as indoor and outdoor humidity. The Hubitat Thermostat capability exposes a "temperature" attribute, as does the TemperatureMeasurement capability I added today. And I added the RelativeHumidityMeasurement for its humidity attribute. So that covers the most important sensor data from an automation standpoint.
Personally, I only have one thermostat in my home, but I know others have multiples. I'm not familiar how things work with multiple thermostats. Perhaps they operate entirely independently. @trevor.deane added a way to select which thermostat the driver should be managing. I presume one would add multiple devices to Hubitat using this driver and select which one to control for each instance using that UI.
What I don't yet know is if the Daikin One API exposes satellite temperature and humidity sensors, i.e. Daikin ONE Wireless RHT Sensor (DSEN-TH-BWS-A). I think these devices only came out a couple of months ago. Perhaps the thermostat just makes its own determination of what the "temperature" and "humidity" are based on the active sensor, whether it's the in-built ones, or these external ones, and exposes those values to the API. Or maybe it ignores them? Or does something else entirely?
Ultimately, none of that may be important for the application I plan to write, because I will likely just support whatever temperature and humidity sensors Hubitat supports. But I would like to handle those Daikin sensors in this driver well, if technically possible.
So I had an Amana communicating heat pump system installed in my home's upstairs zone about this time last year, controlled by the Amana Smart Thermostat. It would be nice to take advantage of the Daikin wireless RHT sensor, but it is not clear that it is compatible with my Amana thermostat. I did review some of the vendor info for the RHT sensor, it states the thermostat averages up to 8 RHT sensors plus the thermostat temperature to arrive at the ambient temperature used to control the unit.
I have a few Zooz ZSE44 sensors that I use to derive a weighted average temperature across the upstairs zone. I've implemented a little Rule Machine automation to jack with the thermostat setpoint to compensate for the lack of built-in remote temperature sensing from other areas upstairs.
I'm about to replace the downstairs 25 year-old Trane system with the same Amana system as upstairs. I will add another of your Daikin Skyport thermostat devices in Hubitat for that new system. The two systems will work independently, but I will replicate some setpoint scheduling/coordination logic I currently have in Hubitat for the upstairs Amana system and the downstairs (soon to be replaced) Trane system.
Ideally I would like to have the remote temperature sensors and some type of averaging logic integral to the Amana thermostat. I can compensate with Hubitat automations and the Zooz sensors, but that is invisible to the occupants. Seemingly random setpoint changes by Hubitat are not met with gratitude, even though the indoor comfort level is improved!
Thank you for this integration!
I have a Daikin One+ stat controlling my Amana communicating HVAC (inverter cool/gas heat), and I use the stat to monitor the condenser performance.
One thing that I have been looking for is a way to control the indoor fan speed for circulate and fan only run.
I know it is exposed and your driver displays it, but is there a way to actually set the speed without having to used the stat to set it?
That would be wonderful!!!
Thanks again.
The Daikin API allows this using the endpoint
/v1/devices/<id>/fan
In my old device code I implemented a "Fan Circulate Mode" command that looked like this:
Maybe something equivalent could be added?
Yes, as @Guffman noted, it should be doable on some, but not all systems. The API docs say it doesn't work on Mini Splits or VRV (which I think are large commercial systems)- Unitary only. Glancing over the API I don't see a way to test programmatically on a given system, but it sounds like worst-case it'll just run the fan at 100%.
Right now I'm working on filling out the missing attributes for the "Thermostat" capability, including supportedThermostatFanModes and supportedThermostatModes. Fan circulate speed is beyond the general thermostat capability, but I'll put that next on my TODO list.
Just to set expectations, the Daikin One Open API supports speeds "low", "medium", and "high" for "circulating on a schedule". Which may or may not mean that those are not available when you set the fan to "always on". I may need to test it to see what my system does. Maybe someone else already has first-hand knowledge.
So I just tested the fan speed control endpoint on my Amana Smart Thermostat, I can definitely control the fan speed (low, medium, high) in both "Always On" and "On a Schedule" modes.
1 Like
Thanks for testing this!
I, too, can control the fan speed on both "always on" and "on a schedule", low, med. hi, with my Daikin one+ stat.
Next the ultimate, would be to be able to control with your driver!
Making a rule, or other automation in HE, to turn the fan on at a certain speed.
This could be based on room temp, VOC's, or other sensors and turn the fan on and set a speed at different times of day and/or room temp.
This would be great!
More notes on the fan mode/speed testing topic...
The Daikin One Open API documentation defines the related parameters in the "Get Thermostat Information" endpoint:
Observing the response to this endpoint after cycling through all the " Update Thermostat Fan Settings" endpoint command combinations, it appears that the property fan never changes. So the Hubitat thermostat device fan mode maps to the Daikin fanCirculate property as follows:
Hubitat Daikin
on 1: always on
auto 0: off
circulate 2: on a schedule
Fan speed is independent of the above, and as @user3639 states is not a declared attribute of a Hubitat Thermostat device.
Frankly, I don't understand what the "fan" mode is supposed to represent in contrast to "fanCirculate". That's a lot of what's tripping me up. I think what I'm going to do is map Daikin's "fanCirculate" to Hubitat's "thermostatFanMode".
I'll expose the fan separately as an extra attribute, even if I don't understand what it is.
And then I'll expose another extra attribute for fanCirculateSpeed.
Oh, maybe this is what it's all about... I just noticed that the Daikin "fan" attribute is available on all systems, while "fanCirculate" is unitary only. So if you have a mini split or something you would set fan "on" to have the blower on even when it's not heating or cooling. I'm guessing if you have a Unitary system "fanCirculate: always on" is probably identical to "fan: on".
But I'll expose both and hopefully we can get a few datapoints about how our systems behave.
New version: 1.0.3
fixes:
- Moved integratorToken back into state because data values were not surviving power cycles. The new driver should (hopefully) automatically migrate your tokens back into state.
- More stable refresh behavior and error checking
The new fan behavior is not in this release- these were important enough fixes that I wanted to put this out first.
Minor suggestion, consider adding capability "RelativeHumidityMeasurement" to the child device, and moving the thermostat attribute "humidOutdoor" there (as the "humidity" attribute).
Then the child device becomes a virtual temperature/relative humidity sensor.
Could alternatively add an outdoor relative humidity child device and move the "humidOutdoor" attribute there, eliminating the need to also distribute a new combination device driver.
I've release version 1.0.4
This version adds fan circulation support.
Once you have imported the new code you will need to enable the "Supports scheduled fan circulation" setting in Preferences to indicate that you have a unitary system. Only unitary systems support setting fan circulation modes and speeds.
Please let me know how this version 1.0.4 works for you.
Version 1.05 released
Child Device now a temperature and humidity sensor. You will need to run "Initialize" on the thermostat manually to migrate to the new childDevice sensor type. Sensor data will appear on the next thermostat refresh.
Just tried it on my Daikin one+....
and..........
IT WORKS!!!!!
Thank you for this!
I am going to incorporate this into my IAQ rule that I am going to make, using my IAQ sensors!
Fantastic. Thank you for the report!
