External integration - Daikin Cloud

Development
1

Hello,

For information and to avoid duplicates, I will have to launch Claude on a Daikin integration tomorrow :wink:

The video on developing an external integration really gave me the urge to get started :grin:

I might also need testers :winking_face_with_tongue:

I’ll keep you posted :smiling_face:

2

It’s developed and available only for testing at the moment:

However, I’ll wait for the next version to test authentication after this PR is released:

@pierre-gilles Any idea when the next version with the redirect page will be released?

Thanks

3

I’m trying to do that tonight :slight_smile:

4

It’s live in 4.84.4:

5

Thanks :slight_smile:

OAuth2 works well and I was able to run some tests
There are still a few bugs being fixed, but I’m waiting for the next Claude reset to continue :slight_smile: I’ve used up all my tokens :sweat_smile:
I should be able to release a stable version tomorrow

6

The integration is ready :slight_smile:
It should be available to everyone in about 1 hour :wink:

7

@prohand

For my personal information, which Daikin devices would be compatible with this integration?

8

The air conditioners will be compatible :wink:
What Daikin device do you have?

You can check the readme here:

9

currently no ahah
but maybe soon ^^

10

Attention, here we only handle air conditioners that are connected to the Daikin cloud and use the Onecta app :wink:

11

It’s available :slight_smile:

12

Small fix because the values were not refreshed after the first cloud connection:

On a first installation, the order is: the container connects to Gladys before the Daikin account exists. The connected handler (index.js:241) detects !api.isConnected, displays “no linked account” and returns — it never reaches step 4, startPolling().

Then the user does the OAuth: onOAuthCallback did a single read (refreshAndPublish) to populate the Discovery screen
 and nothing more. The timer was therefore never armed. The only ways to start it were a container restart, or a change in the interval in the config (only case where onConfigUpdated called startPolling()).

Hence the exact symptom: first correct values, then no refresh every 900 s.

Version 1.0.7 available :slight_smile:

13

Great integration and thanks. I have a suggestion. I find your logo/icon way too generic. I’ll add the brand or protocol on top. It will be more explicit.

14

Available in the next version, which should be available within the hour:

Make sure to clear your cache if you don’t see the correct image after the update

15

I wanted to get your opinion on a feature I started developing with claude, but it involves a counterpart in energy tracking.

Basically, I noticed that in the energy tracking section, this appeared:

image
image865×192 9.55 KB

This was also at level 0 initially, but you’ll understand better a bit later :upside_down_face:
image

I thought we could leverage Gladys’ energy tracking with this information that comes back to Gladys:

image
image381×185 2.2 KB

So I asked him to create two features for me: « 30-minute Consumption Â» and « 30-minute Cost Â».

After testing it on August 8th, the consumption value exactly matches what I have in the Daikin app (same for September 9th):

image
image580×450 12 KB

The catch is that in energy tracking, « Energy this month Â» and « Energy this year Â» remain at level 0 from the integration, as indicated in the doc here:

image
image1094×455 41 KB

Basically, it looks like this:

image
image784×446 25.4 KB

For you, can I push this version to production with the 30-minute consumption and cost, or are there things to review?

Thanks :wink:

16

Hi @prohand, great job, I looked at the branch code and the result is consistent with what the core does. You can push, the mechanics are good. Three points though, two of which deserve a fix before or just after going into production.

1. The parent is a counter that resets to zero, not an index

You publish « Energy today Â» in energy-sensor / energy, which Gladys documents as « cumulative energy consumption Â» and treats as an index. The calculateConsumptionFromIndex job does index(t) − index(t−1) and discards negative deltas (« counter reset detected Â»). So nothing is counted twice — that’s why your daily total is accurate — but everything consumed between the last poll before midnight and the first poll after is lost, every night. With 900 s of polling, that’s the last quarter of an hour of the day; and if Daikin doesn’t fill its 22h–24h bucket until after midnight, it’s two hours that disappear.

The clean fix: have the integration keep its own cumulative total (in its store, total += max(0, today − previous_today)) and publish a true energy-sensor / index that is monotonic. The core then derives exactly, and the midnight case disappears.

2. The 2-hour buckets distort the cost in HP/HC and Tempo

Daikin only exposes 12 2-hour slots. Your 30-minute series will therefore look like 0, 0, 0, 1.8 kWh, 0, 0, 0, 
. The daily total is correct (hence the match with the Onecta app), but the distribution throughout the day is not. Yet calculateCostFrom bills each 30-minute window at the price of that window: on a Base contract it’s inconsequential, on peak/off-peak or Tempo the cost can be seriously wrong, depending on the time the poll was taken.

Two options: clearly document it (« reliable cost in Base, indicative in HP/HC Â»), or better — saveStates accepts a created_at, so you can publish the index states timestamped at the boundaries of the Daikin buckets rather than at the poll time. Consumption then falls into the correct half-hours.

3. Deriving your own UUIDs is my problem, not yours

Choosing the ids of the features to be able to point energy_parent_id before the lines exist works (the device.create inserts the features then resolves the links in a second pass), and your safeguard — only naming features that Gladys doesn’t know yet — is the right one. But publishing an id in the discovery payload is not in the spec for external integrations: it works today because nothing validates it, and I don’t want it to become an implicit contract.

I will therefore wire addEnergyFeatures() (the one from Zigbee2mqtt/Tasmota) to external integrations, in getDiscoveredDevices: any integration that publishes an index will automatically get the 30-minute pair, with ids and links managed by the core. Keep your code well isolated (featureUuid.js + the block in buildDevice) so you can remove it in one block when it’s available.

The request:

And two details:

  • The energy level of your capabilities scale serves no purpose: energy_parent_id arrived in Gladys in August 2025, well before external integrations. Any instance capable of running your container already has energy tracking.
  • « Energy this month Â» and « Energy this year Â» must stay at level 0, it’s normal and you should not link them at all: they are also typed energy, so they appear as possible parents in Settings → Energy Tracking, and a user who wires them would count the same kWh multiple times. A line in the documentation saying « only link the day’s consumption Â» will avoid the question.

In short: go for production, and I’ll take care of point 3 on the core side.

17

Ok thanks for the super detailed review and for point 3 which you’re handling :wink:
I’ll follow up with Claude on the subject Wednesday evening
I’ll see if I do a production release before :winking_face_with_tongue:

18

Release of 1.0.10 with energy management
I suggest checking the docs directly for the implementation :wink:

19

Release of 1.0.11 with a bug fix for on/off in scenes
Don’t forget to update the device

image
image432×416 12 KB