Daikin BRP072C42 WIFI custom component

Share your Projects! Custom Integrations
31

Sorry moorey81 for taking so long to respond and my answer may not be much help, someone else was having this issue (earlier in the post) but it is not something I can replicate. Since what you are descibing is what the original component does (as the units respond to the UDP query but then dont respond on http) my assumption would be the name of the device is confusing the pyDaikin code or the IP address cant be reached/timesout during discovery. I know in my case I had to increase the timeouts to get it to show up but assuming you have the component installed correctly the timeouts will match mine…

I hope that gives a hint for where the issue may be, but as I cant replicate it with my units I cant be of more help.

32

To answer the original question LintHart I have 4 running on this code and as each run on different IP addresses you need to register each unit separately, I dont think there would be a limit except for how long you want to wait during startup since each unit is probed and the startup process has to wait for them to respond which can be 20-30 seconds for each.

As far as I am aware there are no presents on the units or even the app, you would need to do something with automatons or scripts in Home Assistant, eg. I use this to cool the room down to help me wake up.

- alias: Climate Masterbedroom cooldown in morning
  trigger:
    platform: time
    at: 08:00:00
  condition:
    - condition: state
      entity_id: group.all_devices
      state: 'home'
  action:
    - service: climate.set_temperature
      entity_id: climate.daikin_masterbedroom
      data_template:
        temperature: 18
    - service: climate.set_hvac_mode
      entity_id: climate.daikin_masterbedroom
      data_template:
        hvac_mode: "heat_cool"
33

Hey @nzhook,

I’m getting some nasty little error logs, wondering if they’re to be expected?

ServerDisconnectedError 3

Prior to this my system was just being annihilated with aiohttp (iirc) failures but of course I can’t Reproduce those when needed :stuck_out_tongue:

Now granted for the next good while I have a cellular home broadband connection that pretty much doesn’t allow for any outbound communication/ports and I’m quite certain it has a lot to do with that.

Is it possible to I guess, have the component to be more offline/local? I assume it’s trying to communicate with Daikin https servers, hence the point of your components. The units do behave when needed so far :slight_smile:

Cheers :slight_smile:

Linton

34

The component code is all internal, it doesn’t connect to any external Daikin servers just the WIFI modules connected to the units directly. For that reason make sure that the internal IPs against the controllers has not changed.

35

Interesting thank you. Everything is static at a router level and the component has the IPs specified so that’s not it then. Just a mystery. Do you know what the server disconnection error is typically trying to say? Perhaps it’s Wi-Fi stability. Router is in the middle of the house, right under 1 unit. Other 2 units just upstairs less than 10m away with just a wood floor Between and overall a small place.

36

Hey @nzhook!
I’m the maintainer of pydaikin and the Daikin integration. It would be great if we could integrate your changes into the main Daikin integration.
Please send a pr on https://bitbucket.org/mustang51/pydaikin/ and I’ll try to merge it as soon as possible. (I believe that we only need minor changes in the Daikin integration after that.)

Edit:
I’ve started a branch with support for the BRP072C42 controller:
https://bitbucket.org/mustang51/pydaikin/branch/BRP072C42#diff

The idea is that we generate an UUID at HA side and pass that together with the KEY during init. Something like this: https://github.com/home-assistant/core/compare/dev...fredrike:daikin-BRP072C42

The changes are untested so beaware :slight_smile:.

The new config is:

daikin:
  hosts:
  - host: 192.168.1.123
    key: ABCD  # only used by BRP072Cxx
  - host: 192.168.1.12
37

That would be great to get it merged in, I wanted to try and get config flow added for the key and SSID since most of the people commenting here are expecting it to work when it shows up in discovery. But even having the basic changes would be good.

One thing I did find at least with my units is they are really slow to respond, hence the increase in timeout from 10 seconds to 30. Without that change the units dont respond fast enough and Home Assistant ignores them.

I am currently unable to test any code changes but as soon as I can Ill give the code and test and confirm if the timeouts need to be there.

1 Like
38

I’ve increased the timeout too.

Edit: And it is pushed and merged into the 0.108.6 release. Would be really great if we could push the fixes for BRP072C too.

39

Hi. I’ve tried the config as described. Did everything as described. When I request hte basic_info, it seems to come back with all the correct response.

However when I select hte Daikin A/C integration and put in the IP, I get “Timeout connecting to device” and if I use the config.yaml entry, I get nothing in my entity list. I’m at a bit of a loss.

Any advice?

40

Described by whom?

My integration is pending verification on a Daikin unit so unless you manually have changed the files that I linked to it will not work.

If you do a pip install pydaikin=2.0.0.dev1 you should be able to run the pydaikin command to test the connection. (pydaikin - h gives you usage instructions).

41

Apologies Fredrike. I meant as described in the original post. It took a while to get the correct basic_info response, but I still got the timeout.

I can give your beta version a try if you think it’ll help?

Edit: I tried the pip install pydaikin=2.0.0.dev1 command and it said bash: pip: command not found. Not sure if I can help. I’m a bit of a noob with linux, I’m afraid.

1 Like
42

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.

43

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
44

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.

45

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

46

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
47

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

48

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 :slight_smile:

Linton

49

Hey!

Yes, BRP072C support is live in the 0.110 version. The smoothest transition is:

  1. make a note of the ids’ of the entities

  2. delete the integration (from the Integrations page)

  3. shutdown HA, and remove (or just move) the custom component

  4. start HA and add you device from the integration page (make sure to enter the API key)

  5. change the ids’ of the entities to the one you noted in 1.

2 Likes
50

Yep that was pretty smooth thank you :slight_smile: 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?