I’m ordering Hunter Douglas Duette shades and need to decide whether to stay with the legacy Gen 2 hub, or go with the newly available Gen 3 gateway. Gen 3 moves to a BLE connection and offers more discreet control, but is incompatible with earlier integrations. HD has announced that new orders for Gen 2 will be cut off in 6 months, but support will continue for the foreseeable future.
Is anyone in the community already working on, or considering working on, a Hunter Douglas Gen 3 Gateway integration?
Unfortunately Hunter Douglas have not made API documentation public for Gen3 at this stage and development is quite difficult without one on hand to test code against.
Fingers crossed that the non-release means there isnt signifigant change, but it could mean the complete oposite and they have to finalise the changes still.
The api is pretty solid already so from a development perspective i hope the major change is the hub providing better shade data
Sorry we cant give you much more than that at the moment
I got some shades and a Gen 3 gateway installed today. Unfortunately GET requests to /api/scenes/ and /api/ return 404 (which from what I’ve read is not the case for Gen 2?). Home Assistant did discover the gateway automatically, however trying to add the integration resulted in a “Failed to connect” error in the integration addition flow.
sudo nmap -p1-65535 -Pn powerview-gen3.local
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-17 11:59 EDT
Nmap scan report for 192.168.1.172
Host is up (0.0022s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE
80/tcp open http
111/tcp open rpcbind
5355/tcp open llmnr
56641/tcp open unknown
MAC Address: 00:26:74:A4:36:B2 (Hunter Douglas)
Nmap done: 1 IP address (1 host up) scanned in 334.09 seconds
The current (older) API uses plain text over HTTP with no encryption and no authentication. So it is pretty archaic. Therefore my guess is that they will have moved to HTTPS and some form of authentication (perhaps password based or token based).
However the discovery process obviously cannot be subject to authentication; it can only be done via a plain text (i.e. the old) mechanism.
@wbradmoore since Hunter Douglas has not yet published their new access mechanisms, our only way forward would be to reverse engineer it. I don’t know what your hacking skills are like, but the approach that I would try is as follows…
Beginner: run a network sniffer (Wireshark) on your LAN and record any traffic between your PowerView App and the hub.
Advanced: run an SSL proxy server (Charles) on your LAN, have your mobile device connect to the Internet via the proxy server (rather than directly), and record any traffic between your PowerView App and the hub.
i don’t know much about homekit: are you suggesting the gateway is responding to homekit discovery pings (on one of the open ports?) but isn’t actually serving a homekit integration?
regarding reverse engineering: i haven’t used charles, but it looks like i wouldn’t be able to force the app to trust the proxy certs anyway? “As of Android N, you need to add configuration to your app in order to have it trust the SSL certificates generated by Charles SSL Proxying. This means that you can only use SSL Proxying with apps that you control.” SSL Certificates • Charles Web Debugging Proxy
Gen 2 will display a json error return if the method isn’t supported
Port 80 is open so curious what it will return. Not many ports open for any type of secure connection to be made with encryption so I’m kind of hoping the api end point may have just changed as a starting point
$ curl -X GET -i 'http://192.168.1.172'
HTTP/1.1 404 Not Found
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 41
ETag: W/"29-4AgnkdNMQ5VNVlXzmDK1/yTSOe0"
Date: Mon, 20 Jun 2022 12:53:01 GMT
Connection: keep-alive
404 error at: [/] params:{"0":""} body:{}
i was planning to brute force through potential api endpoints, but hadn’t gotten around to writing or finding a tool to do so. if anyone knows of a linux cli tool to do so, let me know
as an aside, i’ll probably activate the google home integration and have HA send requests through that for now, to activate scenes i’ve created in the powerview app. since that’s the only way we’ll be modifying shade position, the lack of state reporting from the shades shouldnt be a problem for now…
Yes, the hub advertises itself as a ‘_hap._tcp’ (HomeKit) service via the mDNS (multicast DNS) infrastructure platform. So other applications like HA (or OpenHAB) can discover hubs by doing an mDNS scan for that service. Note: this uses DNS (UDP) mechanics, which would not show up on your (TCP) ping port scan.
Dunno. Never tried it. But the ability to respond to mDNS scans, certainly does not guarantee such an integration…
Yes that is certainly the case for Android Apps. You would need to do it on an iOS device. Whereas Android requires the certificate to be pre-installed in the App, on Apple devices the certificates can be installed at the O/S level and set to be trusted via the O/S settings UI.
PS this is interesting. It has to do with resource caching. So it indicates that the hub is indeed running a server of some sort, that will produce resources of some sort…
And this is also interesting, since it tells us that the server is expecting some kind of request params, and essentially failed because those params were not provided in the request. To be specific it suggests to me that if one were to supply (say) a ?shadeId=1234 in the HTTP GET request, one might actually get a response other than 404…
EDIT: i.e. GET 192.168.1.172/api/shade?shadeId=1234 or variations thereof ???
EDIT: baby steps but as it is evidently still using HTTP rather than HTTPS, I would suggest adding a basic authentication header to the client GET request. The security sucks, but it might be all that is required to make it work…
@Kingy444@HAChamp - I can confirm that Hunter Douglas will eventually enable swagger on the Gen3 Gateway describing the Gen3 endpoints for ‘unsupported’ integrations like Home Assistant later this year.
That’s great news - would be great if shade capabilities and friendly names are made available
We only have community driven data at the moment so I for one would like to make sure shades just work - this is quite difficult without the info from HD on capabilities of each shade
@Kingy444 I don’t want to disappoint you but adding swagger to the gateway will probably not fulfil your wishes. Swagger is a mechanism for describing url endpoints, http methods, and semantics of the JSON request and response payloads. It describes the interface not the contents. So it will probably tell you that there is (say) a capabilities JSON element of type number; but it will not tell you the full list of actual capabilities values, or their respective meanings…
no http response on 56641