Yes that would be much appreciated!
Where did you try the pip command (which environment are you running)? I think pip and python is part of most major distributions.
Iām running HASS.OS with the terminal plug in.
Iāve actually got it working now though, and as much as I would like to help out, Iām hesitant to stuff around with something thatās working now. Perhaps someone with more experience with linux may be of more help anyway.
1 Like
I have had some time to test, I pulled the copy from the core dev branch (d8222a8eb601ff55f0481e84a3706d798a0f8546) and used the interactions to add all of my devices and it works. There are some things that might need to be tweaked to make it easier for users:
name and mac are not being set
Looking at the calls being made I donāt see anything going to the basic_info call anymore which maybe why this is happening. This then results in all the units being added as climate.daikin_ac rather than by the name they have been configured with. The mac is also set to the IP address rather than the mac value from basic_info
Invalid key still adds the device
I was initially scratching my head as to why the code was returning errors about python keys not being found. It looks like there is no error handling for the 403 error returned by the commands (could possibly bail if the register_terminal fails) so Home Assistant is adding the device and is then confused later on as to why its not working.
The key is only needed for the register_terminal
I donāt think we need to store the key in the configs, this is only needed to register the UUID (like an oauth token) so if we have a previously registered UUID we dont need to send the key again. This may make the process a little faster and follows with what the app does
The best option for the above two might be to only register the key (in pydaikin) when a key is given (with our without a UUID). If only a UUID is given then it assumes it has been registered and skips that initial step.
During Home Assistantās config flow the current process of asking for the key is done, at that point pydaikin is called with both a generated UUID and the key, pydaikin registers the terminal and/or returns a failure. All that is then stored in the config is the UUID that was generated.
Net discovery is giving an error
I think my code was doing this for an unregistered device, but because the units respond to the UDP request discovery is being confused. I am not sure how this could be fixed but its worth noting as they may show up in Home Assistant but be unusable.
File "/usr/src/homeassistant/homeassistant/components/discovery/__init__.py", line 199, in scan_devices
results = await hass.async_add_job(_discover, netdisco)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/discovery/__init__.py", line 224, in _discover
netdisco.scan()
File "/usr/local/lib/python3.7/site-packages/netdisco/discovery.py", line 72, in scan
self.daikin.scan()
File "/usr/local/lib/python3.7/site-packages/netdisco/daikin.py", line 26, in scan
self.update()
File "/usr/local/lib/python3.7/site-packages/netdisco/daikin.py", line 77, in update
'id': entry['id'],
KeyError: 'id'
If anyone wants me to update my githuib copy with a version that works in 0.109.4 let me know (The dev copy needs a couple of small changes and you would need to readd the devices), although I dont think its too far away from being releasable.
Yes, that seems to be a bug. I tried to make things smart with skipping basic_info as it were added in BRP069 init. Iāve changed that.
Yes, there is no check that the response is OK, Iāve tried to dig trough this thread. And you suggest to do --head so i donāt know what to expect from register_terminal, if you give an output of: curl --insecure -H "X-Daikin-uuid: d53b108a0e5e4fb5ab94a343b7d4b74a" "https://192.168.1.20/common/register_terminal?key=0103056789012" Iāll update it in every part.
As we donāt know for how long the UUID is kept at the Dakin unit side I think itās safer to keep the key in HA. The only time it is registered is when HA is restarted and this would only add a few seconds for the startup of HA. Iām not planning to change that behavior.
Not much we can do here as netdisco is deprecated in favor for zeroconf/SSDP: GitHub - home-assistant-libs/netdisco: š Python library to scan local network for services and devices.
Feel free to chip in on this issue: Add zeroconf discovery to Daikin Ā· Issue #34551 Ā· home-assistant/core Ā· GitHub
Failure returns a status code of 403 HTTP_FORBIDDEN and no body, success returns a code of 200 and body of āret=OKā. Here is the full output of an error with --verbose:
curl --verbose --insecure -H "X-Daikin-uuid: d53b108a0e5e4fb5ab94a343b7d4b74a" "https://192.168.1.23/common/register_terminal?key=0103056789012"
* Expire in 0 ms for 6 (transfer 0x558f8d28d8b0)
* Trying 192.168.1.23...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x558f8d28d8b0)
* Connected to 192.168.1.23 (192.168.1.23) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=JP; ST=Osaka; O=DAIKIN INDUSTRIES, LTD; CN=015F4441494B494E00000043000E0B7E.svr
* start date: Aug 13 20:22:52 2018 GMT
* expire date: Jul 20 20:22:52 2118 GMT
* issuer: C=JP; ST=Osaka; O=DAIKIN INDUSTRIES, LTD; CN=CA.daikindev.com
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /common/register_terminal?key=0103056789012 HTTP/1.1
> Host: 192.168.1.23
> User-Agent: curl/7.64.0
> Accept: */*
> X-Daikin-uuid: d53b108a0e5e4fb5ab94a343b7d4b74a
>
* HTTP 1.0, assume close after body
< HTTP/1.0 403 HTTP_FORBIDDEN
< Content-Length: 0
< Content-Type: text/plain
<
* Closing connection 0
(untested) Suggestion would be
async def _run_get_resource(self, resource):
"""Make the http request."""
async with self.session.get(
f'https://{self._device_ip}/{resource}', headers=self._headers, ssl=False,
) as resp:
if resp.status == 200:
return self.parse_response(await resp.text())
elseif resp.status == 403::
return INVALID_KEY
Fair enough, the app only ever asks for the key once and has options to invalidate all existing sessions which I assume is the only time it would forget a registered UUID. But I suppose it could be possible sometime in the future they could require the app to revalidate.
1 Like
Iām going to go with:
async def _run_get_resource(self, resource):
"""Make the http request."""
async with self.session.get(
f'https://{self._device_ip}/{resource}', headers=self._headers, ssl=False,
) as resp:
if resp.status == 200:
return self.parse_response(await resp.text())
elif resp.status == 403:
raise aiohttp.web.HTTPForbidden()
https://docs.aiohttp.org/en/latest/web_exceptions.html#aiohttp.web.HTTPForbidden
and let the caller handle the exception (in the HA case it makes things really easy core/homeassistant/components/daikin/config_flow.py at f4168a0e074b741acd4e9409dceb25c30f21f7e2 Ā· home-assistant/core Ā· GitHub).
Edit: New PR submitted: Bump pydaikin to 2.0.1, catch HTTPForbidden exception by fredrike Ā· Pull Request #35466 Ā· home-assistant/core Ā· GitHub
Hey @fredrike and @nzhook, I just wanted to confirm that nzhookās work on the newer adpators has finished being transitioned to the native daikin component? Iām still using the custom and itās working great, Iād just like to remove the āusing a custom addonā message etc and it may be best moving forward.
Any tips for a smooth transition?
Appreciate the work on one the most important addons in my setup 
Linton
Hey!
Yes, BRP072C support is live in the 0.110 version. The smoothest transition is:
-
make a note of the idsā of the entities
-
delete the integration (from the Integrations page)
-
shutdown HA, and remove (or just move) the custom component
-
start HA and add you device from the integration page (make sure to enter the API key)
-
change the idsā of the entities to the one you noted in 1.
2 Likes
Yep that was pretty smooth thank you I did get a little stuck on āPasswordā in the config flow but I hit the button without one and my 3 units seem to have come back just fine.
Also a wonderful surprise, an energy consumption sensor!!! Just doing a quick test and it looks like the enegery gets updated every couple, maybe 5 minutes?
The energy sensor is all done by @mlemainque all credits to him. Iām happy to hear that Energy works for BRP072C, you @LintHart are the first one to report that it works 
.
well then, thank you @mlemainque Realistically have no idea for its accuracy but I turned the heater on and after ~5 mins of so it was using 600watts for a few degrees higher than ambient goal. It climbs (updates?) slowly so maybe if it gave it more time it would have been higher but the number didnāt seem unrealistic. Definately a feature that helps the system feel smart though
Glad to hear this is working for someone else than me
Their are 2 kind of sensors:
Total Power Consumption
It will report the power consumption of all modes and all AC summed. It is updated each time the API reports a 100Wh consumption and then smoothed over 30min to get a power in kW. So you should have a lag up to 30min to get accurate results. But in the end the integral should be 100% accurate
Last Hour Cool/Heat Energy Consumption
It will report the energy consumption of one mode and one AC alone. It is updated when the API updates its own energy consumption history, on a hourly basis (10 minutes past each hour actually). So every hour +10min this sensor will report the energy consumption (in kWh) of the last hour. In the end the integral is 99% accurate (should be 100% with the next release)
1 Like
I can also confirm that the integration works with two Daikin Alira units. The climate entities were recognised when I renamed them, but the temperature sensors were not.
After manually selecting them in my automations, all works well.
Hi everyone, awesome work on the integration. I just had an Daikin Alira installed this afternoon, I setup the wifi for the BRP072C42 and added to HA - too easy!
When adding through the integration youāll need the IP address on your local network and the āKeyā (mine is a 13 digit number). The password field can be left blank.
Thanks again!
2 Likes
To avoid new people scrolling through this post I have updated the top post to say its now in 0.110.
I have been running on the 0.110 code base for over a week with no issues so if you were using my custom component version or a version of @fredrike changes you can now remove these when upgrading to 0.110. You may need to re-add the integration if it does not automatically upgrade the existing entities.
2 Likes
Hey,
New to HA and I do have a new Daikin that was installed in 2020 with wifi comp built in, does this work with it?
I have tried:
curl --insecure -H "X-Daikin-uuid: acebc2096cfc454f87d0505cd313106b" --head "http://192.168.86.41/common/register_terminal?key=0109822841945"
Result:
HTTP/1.0 404 Not Found
Content-Length: 30
Content-Type: text/plain
If I try with HTTPS:
curl: (7) Failed to connect to 192.168.86.41 port 443: Connection refused
If I try:
curl --insecure -H "X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd" -v "http://192.168.86.41/common/basic_info"
* Trying 192.168.86.41...
* TCP_NODELAY set
* Connected to 192.168.86.41 (192.168.86.41) port 80 (#0)
> GET /common/basic_info HTTP/1.1
> Host: 192.168.86.41
> User-Agent: curl/7.64.1
> Accept: */*
> X-Daikin-uuid: 7b9c9a47c9c64ee19063848e67cc7edd
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Length: 305
< Content-Type: text/plain
<
* Closing connection 0
ret=OK,type=aircon,reg=eu,dst=1,ver=1_2_51,rev=D3A0C9F,pow=1,err=0,location=0,name=%44%61%69%6b%69%6e%41%50%35%34%38%37%38,icon=0,method=polling,port=3005ad
Seems that I have a connection but I canāt run the register command, and nothing is showing up in HA.
Any help would be appreciated.
Thanks in advance.
Only the newer controllers that use https use the register_terminal command.
If it is only responding to http then it sounds like one of the older controllers which should be detected as a new device automatically by the standard component built into Home Assistant.
If it is not being detected by Home Assistant it should be possible to manually add it under Configuration > Integrations > + (in a circle at the bottom right) > Daikin AC.
The only detail you will need for the Configure Daikin AC page that pops up is the IP address which you have there as 192.168.86.41.
If that doesnāt work have a look at the sticker on the WIFI unit and let us know the model number, it should start with something like BRP. If its not the model I have I cant say Ill be able to get it to add but I can point you at the right place.
You are awesome! I really appreciate the help.
When I try to add it via Configuration > Integration I cannot see Daikin AC. Just Daikin.
If I try to add it via the Daikin addon I get after submitting:
https://monosnap.com/file/1YFbgaAWnHeRgf5AX9ZgiotA8P4CMR
My model is:
https://monosnap.com/file/J66USHRyEotfIrlISjvPWbNuwfXwnc
Thanks again!
Unfortantly thats not the model I have and it doesnt list the model number on the sticker which makes it much harder to point you somewhere.
As the main componentās developer @fredrike may recognise the model and give some guidance.
Although Iām not sure why my Home Assistant says Daikin AC and yours just says Daikin. This may just be a translation difference but just to make sure are you running the latest version of Home Assistant (0.112.0)?