To beta testers: @alison, @alexander_romanov_pv
Please test the following on your system
curl --insecure -v "https://10.100.100.97/common/basic_info"
and
curl --insecure -v "https://10.100.100.97/test"
I’m trying to see whether a non existent url with 404 (page not found) still requires authentication.
@alexander_romanov_pv, @alison
Daikin binding to support BRP074C42 Beta 2
https://github.com/jimtng/openhab-addons/blob/binaries/org.openhab.binding.daikin-2.5.4-SNAPSHOT-Beta2.jar?raw=true
What’s new:
To test:
Testing the auto registration feature:
** Generate a new UUID4 e.g. from https://www.uuidgenerator.net/. You can use the UUID4 verbatim in the things file without stripping the dashes
** In your Things file, comment out your old Thing definition and duplicate it. On the active Thing definition, use the new UUID4
** Add key=“xxxxxxxxx” using the 13-digit key required to register a uuid from your adapter. The binding will perform the uuid registration for you.
Example Things
Thing daikin:ac_unit:pickwhatevername [ host="x.x.x.x", secure=true, uuid="ANEW-UUID-HERE", key="xxxxxxxx", refresh="15" ]
Even though the configured uuid4 is new, it should work (after the second poll, which by default is 60 seconds each poll, so it will be 2 minutes in that case)
Testing the autodiscovery
Please let me know how it goes.
For me both return the same:
* HTTP 1.0, assume close after body
< HTTP/1.0 403 HTTP_FORBIDDEN
< Content-Length: 0
< Content-Type: text/plain
<
* Closing connection 0Hmm at this point, it will be fine because the other controller (Airbase) currently doesn’t support HTTPS yet. So when a https controller is detected, it would be detected always as BRP072C42 instead of Airbase.
If one day they release an Airbase controller that does https, it will become an issue with autodiscovery.
I was hoping that non existent pages will return 404 instead of 403!
Could you please double check this again:
curl --insecure -v "https://10.100.100.97/test"
Thanks for your help!
Full output:
$ curl --insecure -v "https://10.1.1.34/test"
* Expire in 0 ms for 6 (transfer 0x5607453edf50)
* Trying 10.1.1.34...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5607453edf50)
* Connected to 10.1.1.34 (10.1.1.34) 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=015F4441494B494E0000004300125E02.svr
* start date: Nov 10 21:36:45 2018 GMT
* expire date: Oct 17 21:36:45 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 /test HTTP/1.1
> Host: 10.1.1.34
> User-Agent: curl/7.64.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 403 HTTP_FORBIDDEN
< Content-Length: 0
< Content-Type: text/plain
<
* Closing connection 0Could you try this with a valid uuid header please:
curl --insecure -H "X-Daikin-uuid: validworkinguuid" "https://<controller-ip>/test"
[/quote]
* HTTP 1.0, assume close after body
< HTTP/1.0 404 Not Found
< Content-Length: 30
< Content-Type: text/plain
<
* Closing connection 0
ret=PARAM NG,msg=404 Not FoundUpdate: Currently testing the beta7 version - waiting for feedback from @alison before posting it here.
Try restarting the binding if necessary
bundle:restart org.openhab.binding.daikin
Things to test:
I’ve submitted a PR:
Compiled jar (renamed as txt)
org.openhab.binding.daikin-2.5.4-SNAPSHOT-beta9.txt (60.6 KB)
After dropping the jar file in your addons folder, issue a
bundle:restart org.openhab.binding.daikin
If you encounter any bugs, please report back here.
PR submitted https://github.com/openhab/openhab-addons/pull/7487
BTW is there a list of devices that the binding supports ?
It just says it’s about air conditioners.
I’m looking to get a Altherma R (ex Rotex) heatpump, how about those ?
And how does it relate to the OpenDaikin binding available on marketplace?
I can’t answer the question about which devices the binding supports, but in terms of opendaikin - this is the successor to that binding. When the binding was added to the openhab source code, the binding was renamed- history is here https://github.com/openhab/openhab-addons/pull/3044
The beta9 above also works for me!
I have three BRP072C42 and three BRP072A42 adapters, I can use all six of them now.
Thank you!
@madsing thanks for your feedback. Please test this latest beta10. There have been some minor changes during the PR process. I hope it won’t affect the functionality but it’s better to test before it gets included in the official 2.5.5 release
Rename .txt to .jar then drop it into your addons folder
org.openhab.binding.daikin-2.5.5-SNAPSHOT-beta10.txt (63.3 KB)
After making sure there’s only one of these daikin beta jar files in the addon directory, please issue this command to be sure
bundle:restart org.openhab.binding.daikin
AFAIK this just supports Daikin air conditioners where a Wifi adapter (it’s a separate box afaik) has been connected to. So this binding is actually communicating with the Wifi adapter, not to the air conditioner directly. The wifi adapter has a somewhat standardised syntax to communicate over http, and it then translates what proprietary signals need to be sent to the connected air conditioner via a proprietary wired link.
Currently it is known to support 2, soon to be 3, different kinds of Wifi adapter models: BRP072A42, BRP072C42 and the so called “Airbase adapter” BRP15B61. These adapters support quite a few different kinds/models of Daikin air conditioners, usually the split type or ducted type. Perhaps someone else can add more details about this and whether they also support heaters / heat pumps.
If you can get the documentation of how Altherma R (ex Rotex) heatpump works/communicates and if it looks similar to the other adapters’ protocol, perhaps we can incorporate it / add support for it into this binding.
FYI, this binding communicates with the wifi adapters using HTTP / HTTPS. You can see some of the sample http requests in the posts above.
Beta10 works fine for me. No issue detected.
Question: I have several BRP072C42 adapters. Should I generate a different UUID for each of them, or can I use the same one?
Thanks again!
I don’t see a reason why you should use a different UUID for each of them. The only possible reason would be how paranoid you are about people getting on your network and hijacking your air conditioning system after they’ve managed to intercept your SSL session, which is probably easy to do since the binding doesn’t verify the SSL certificate in any way.
PS Thanks for testing beta10.
@madsing while you’re doing some tests, would you mind testing the autodiscovery feature please? You can just discover / add the thing without deleting your existing things. I’d like to know whether discovery works and whether a new UUID registration done by the binding works. I believe it should, but it’s nice to get a confirmation from a real test.
In principle, Altherma control works the same way with the BRP069A62 controller.
Maybe you can try to use the code in this post/thread on an aircon of yours ?
At least I think you should synchronize with @kbecker to find out what your and his code have in common.
Yes, I think that the autodiscovery works fine. This is what I see: