Dyson pure cool link integration


#1

I searched but couldn’t find anything.

I ordered a Dyson pure cool link air purifier, and would like to find out if there’s a (potential?) ST integration I can take advantage of.

Thanks.


(Tim Slagle) #2

I own one too… Can’t find any docs on it and can’t figure out the API…


#3

Google search takes me here. I am not technical enough to understand anything, I hope you (or someone) can find it useful to make it work with ST…


(Howard Bates) #4

anyone get anywhere with this? The documentation @Gergor gor found looks promising but it’s out of my depth. Mine arrives tomorrow though so I’ll have a play around


#5

It’s unfortunate this hasn’t picked up any steam. Anecdotally it seems to be doing a better job monitoring the air quality than the foobot I have in the same room. Possibly because it actively suck in air for monitoring.


(Howard Bates) #6

I’m working on it now and will report back over the weekend if I can - I appear to be making some progress but I’m sure I’ll hit a brick wall sooner or later.

feel free to prod me if you haven’t heard anything by Sunday!


(Howard Bates) #7

as I thought a brick wall has been hit - mainly because I have no idea what I’m doing - I managed to get as far as installing it and entering login details, but I don’t seem to actually be able to login to Dyson.

I was contemplating opening an issue on the github page but I don’t think my ineptitude is a reasonable issue!

Anyone out there familiar with python who could chime in?


(Cara Rynerson) #8

I am also interested in this. I have seen it integrated via Harmony Hub… but am expecting someone smarter than me knows how to link it via the wifi access.


#9

looking for DH too!


(Howard Bates) #10

if you want to do this - you can add:

Manufacturer: Dyson
Model: HP02

To your devices list to control it - it’s not very good - but gives me and the lady our own remote. Currently I’m using Alexa to do it, but I find it cumbersome to say “Alexa, tell Dyson…”


(Cara Rynerson) #11

@sh20 Is there a thread that explains how to add a device the way that you mention? So far I’ve only used the app for adding devices like Aeotec and Qubino which are recognized via zwave. Thanks!


(Howard Bates) #12

You mentioned in your original comment you had seen it integrated via harmony hub so my comment was geared towards that, as the device codes are not easily accessible.

You add the device to your harmony hub as an entertainment device, then in the example that I presume you saw, they had added a routine to the remote and set a geofence to start the routine. I personally don’t think it’s a great use so I never went beyond adding it to the hub. I just thought I’d share the device code as the article/video doesn’t mention the codes to use.


(Cara Rynerson) #13

Ahhh! Ok. I misunderstood. I thought you were saying you know a way to add it directly to SmartThings via WiFi.

I don’t have the harmony hub yet. Will refer back to this at that point.


(Howard Bates) #14

Tim did you see the documentation gergor found?


(Joe H) #15

@sh20 That’s not actually “documentation” per se, but it is a reference implementation that accesses the same APIs that the device apps (i.e., their Android app) uses to communicate with Dyson and the devices on your account.

I started creating a “(Connect)” labs app that would work like many of the other web service device handlers. The current roadblock is a combination of three things that together make this integration impossible:

  1. Dyson’s API uses a self-signed certificate, issued by a self-signed Dyson CA (certificate authority)
  2. Dyson’s API only listens on the HTTPS port (443), and does not accept requests on the insecure HTTP (80) port.
  3. SmartThings has no way to support self-signed certificates.

Elaborated info:
Dyson has chosen to use a self-signed certificate for their SSL encryption. That means they aren’t using a publicly known CA (certificate authority) to issue a certificate for their https web server, but instead they have their own internal CA certificate, and have issued a certificate for the server using that CA.

The device apps themselves are able to use certificate pinning to communicate with that server, by holding the “expected” certificate inside the app, and then ensuring that the api’s certificate matches the certificate that it expects. So the application can still verify that you aren’t victim to a MITM attack, even though it’s not from a CA that is known by the device (since it is at least known by the app). But that means that your web browser (and all other HTTP request libraries) will not be able to verify that the SSL certificate is valid, because it’s not a public, well-known, and trusted CA issuer.

In both the Python and nodejs implementations, they have gotten around that by explicitly instructing the HTTP libraries to ignore SSL errors. What that means is when the library makes the request, it sees the Dyson certificate, which was issued by the Dyson self-signed CA certificate holder. When it tries to make a request to that host, it will fail because it cannot validate the Dyson CA. By instructing those libraries to ignore errors (rejectUnauthorized: false in nodejs, and Verify: False in Python), it can continue making the API calls because it is not validating the SSL certificate. That leaves those implementations open to a MITM attack, since it cannot verify that the host it’s communicating with is in fact Dyson.

The crux of the issue is that the SmartThings HTTP library has no mechanisms in place for either a) ignoring SSL errors, such as how the nodejs and Python libraries do, or b) supplying a known certificate for the API service itself, or the issuing CA. Because of that, the default behavior is to totally abort the API call, because of the unknown certificate authority.


I understand SmartThings’s stance to reject unverified SSL requests, as that is the most secure way to do this. The other option that would allow this to work, without sacrificing security, would be to allow us to supply the expected certificate for either the Dyson API server, or the Dyson self-signed CA, so that the hub would be able to verify that it is in fact communicating with Dyson and not a fake MITM spy. Theoretically, they could allow that by either letting the device owner upload and install certificates that will add to the trusted certificate chain that can be used to verify any matching HTTP requests from any smartapp; or allowing the developer to supply the known certificate in a “sandboxed” way so that the certificate override is only used within the smartapp itself. Either of those options would allow making these API calls without SmartThings rejecting it, and maintains the security of preventing MITM attacks.

Another option would be to run your own HTTP proxy on your local network, and have the smartapp hit that proxy instead. That proxy could be exposed over HTTP (insecure), and then make its own API calls to the HTTPS (secured with self-signed cert) API, using the Python or NodeJS library; or simply proxy the HTTP calls straight to the HTTPS server, ignoring the certificate errors.

One last-resort option would be to communicate directly with the fan itself, completely bypassing the Dyson API. Based on information I was able to find, it looks like the app communicates locally with the fan using the MQTT protocol (a realtime protocol, similar to XMPP, like how instant messaging services operate). That has its own problems, because there’s no way for the SmartThings hub to “speak” the MQTT protocol. I have not explored whether the fan can respond to HTTP requests or not, as if it can support that, then you can bypass both the Dyson API and the Fan’s MQTT service, and just speak directly to the fan over HTTP.

Then yet another last-last-resort option would be to bypass the Dyson API server, and instead scrape the HTML frontend of the dyson website. The problem with this option is that the website does not have a way to monitor or control the machines – it only shows you which machines you have registered on your account.


(Joe H) #16

And for those who have been suggesting using the Harmony Hub to link, there are a couple issues with that:

  1. Harmony’s integration with SmartThings (and others like Google Assistant, etc) tends to only expose Activities, not Devices. So you can’t say something like “Ask Harmony to turn the Dyson Fan on,” because it can only start/stop activities, but cannot power devices on/off, or otherwise interact directly with a device.
  2. Activities on Harmony are like highlander: you can only do one activity at a time. So if you set it up as an activity (like “Fan On”), then sure you could set that up with SmartThings and when you want the fan to turn on, just turn on the “Fan On [Harmony Activity]” virtual switch. But doing so will turn off whatever other activity you were using (i.e., “Watch TV” will turn off).
  3. The API that SmartThings uses to interface with Harmony does not use the local harmony hub communication, and instead hits the public Harmony API. Because of that, there’s no easy way to fetch the device list, or the command list of the devices, or to execute individual IR commands of individual devices. I had started to modify the Harmony smartapp to add the ability to add child virtual devices for the Harmony devices, but ran into issues trying to receive the broadcast response from the hub when trying to discover the hub on the local network. I could get it working if I explicitly entered my Harmony Hub’s IP address, but then it wouldn’t be easily portable for others. My goal was to let it find your hub on the local network, then from there list the devices associated with each hub, and then list commands for each device. That would basically allow creating a virtual momentary push button in ST that triggers executing a single IR command of a single device (on a single hub), which would then allow sending commands to the Fan (or any other IR device).
    I was able to get that working by setting up a local server that could communicate with the Harmony Hub directly, based on a REST API request. And then the SmartThings hub could hit that REST API successfully, and everything worked fine. The problem is that it requires having that local proxy to do it.

#17

Thanks for the in depth investigation, although the prognosis doesn’t look good :frowning:

Just to throw it out there, dyson link has an alexa skill. It may sound convoluted, but is it possible to control the dyson from ST thru the alexa integration?


(Cara Rynerson) #18

Oi Vey I think I’ll just use the Dyson app for now.


(Howard Bates) #19

wow Joe thank you so much for your detailed answers. It’s a shame but at least we know for sure. I have a friend of a friend who works at Dyson, so I’m going to see if they have any interaction with the smart/link team, and see if I can get our requests put forward.

For now I am also using the alexa skill - it’s just quite clumsy saying “alexa tell dyson to…”


(Joe) #20

Looks like someone got it working in homebridge

https://www.npmjs.com/package/homebridge-dyson-link

I am going to be testing this to see.