Clothes Dryer Automations

I’ve seen several folks attempting, with success, to integrate their clothes dryer to Home Assistant. However, most of these require high-voltage plugs, rewiring their dryer, and/or passive electricity monitoring. If you want to know the electrical output, I get that. However, I just wanted to know when my clothes were dry (actually dry) and receive notifications as such.

I don’t run Zigbee or Z-wave (long story, I’m writing a blog post about it), so passive motion sensors reporting on vibrations wasn’t going to cut it. Additionally, that wouldn’t actually tell me the clothes were dry, just that the dryer has started/stopped running.

Enter: SmartDry

I read a few reviews, it’s dead simple to set up (just place the sensor in your dryer drum, then plug in a USB “hub” nearby, then pair to your phone. It works really well, notifying me often 10 minutes early that my clothes are dry, I then interrupt the drying cycle and have never been disappointed at the humidity of the clothes, they’re dry.

I even get notifications when I’m not home. So, I know there is a cloud service involved and that provides a potential to integrate to Home Assistant.

I’m currently working to reverse engineer the protocol, but curious if anyone has seen/used these?

3 Likes

Please, no more cloud integrations!

1 Like

A vast array of cloud integrations are the primary reason I leverage Home Assistant. I want WAY MORE of them…

< opinion >
You can talk philosophically about how they fragment the market, create complexity, and disallow personal data from being kept personal; but, the industry isn’t going to stop creating their own networks, their own apps, and their own services. As a result, I just want a way for them to all work together and Z-wave and ZigBee aren’t it (especially in HA).
< /opinion >

1 Like

Ignoring privacy issues and market fragmentation entirely for a moment…

There are four big issues with cloud ONLY based solutions as I see it:

  1. Internet goes down, my device goes down
  2. Company goes out of business, my device becomes a paper weight
  3. Integration generally means more developer effort
  4. They are SLOW

All three of these problems are solved by devices that implement local, standard APIs.

If there’s a cloud piece too, that’s fine. If there are additional features (control away from home, usage reports, automatically ordering new ac filters, whatever) that are only available over the cloud, that’s fine. As long as the core functionality is available locally.

When a device requires a “hub”, as this one does, there’s even less excuse for it to not have a local API, since the hub is no longer limited by battery constraints and such.

I agree with you that, as long as cloud ONLY devices exist, in cases like this SmartDry where there is no other similar product available, having a Cloud Integration available is nice. Better than nothing at all, certainly. But it’s a thin line. If I buy this device, it encourages the market to continue like this. If I don’t buy this device, then it encourages the market to do better.

As a programmer I can say this: if a device requires a hub, the API can be provided by the hub and there’s no excuse. Adding parts/resources, if needed, to the hub to support the API is almost unnoticeable in the end price. And consumers of devices like this don’t even know the difference between a few dollars since the device doesn’t exist anywhere else. If a device doesn’t require a hub (i.e. it speaks WIFI) then all the tools needed to provide an API are already there and already being used to speak to the cloud. It’s not much programming effort to open that up to allow local control.

3 Likes

Another cloud service bites the dust.

As if google’s nest debacle wasn’t convincing enough.

1 Like

This is all well and good, but I’m not here to promote or denegrate cloud-based home automation services. In a perfect world, everything would have a local API and not rely on any cloud services. The reality is that doesn’t pay the bills, it’s not the world we live in, and this isn’t a thread to debate it.

There’s isn’t another, viable, workable, solution on the market. If something comes along, supports these features, and doesn’t require a cloud service and has a local API…I’ll buy it. But there isn’t one.

I don’t see the point of debating it in this thread.

3 Likes

I am very interested in this as well. Here is the update from the seller.

1 Like

Hi @pickerin. I have an old Maytag dryer that frequently stops mid-cycle because of some error that doesn’t actually exist. I ran into SmartDry about the same time you originally posted, and it’s worked really well for me. Like you said … it’s dead simple to setup, it’s affordable (about $50 at Amazon), and the notifications work really well. I’d love to see more open integration from the SmartDry folks so it can work with platforms like HA, but in the mean time it’s well worth using even as a standalone platform.

FWIW, I’m trying to intercept the traffic on the SmartDry to see if I can reverse-engineer the API.
Would be nice if they just opened up their API.

1 Like

@pickerin did you ever make any progress?

Brother any progress on this?

Hey all, unfortunately no. My SmartDry is non-operational. It was working fine, but then just suddenly stopped working. I tried replacing batteries, it worked for about a week, then quit again.

So, unfortunately, just as I got my https proxy up and running, it died and I haven’t been able to get back to it (which probably means buying another one).

Well, some progress! I got my SmartDry working again. I also found out they’re conducting a Beta Trial with SmartThings. I’ll have to dust mine off and see if I can use that to build out an integration for HA.

You can find out more here: https://www.connectedlifelabs.com/beta-programs

Hi @pickerin, just checking in to see if you have had any success with this. Thanks!

@pickerin, anything? Or anyone else have any ideas?

Hey all,

Well, I’ve made a bit of progress. I’ve been able to capture the SmartDry app on iOS as it talks via the API to the server. Now I’m working on reverse engineering the API code itself. For anyone interested, here is what I’ve found:

  • The SmartDry sensor appears to just send updates with it’s serial number to a central store regularly. These are then stored
  • The iOS application sends an API call with the registered serial number and fetches the current “state” (the last update) from the server

The status update looks like this:

[
    {
        "Dry": 83,
        "LessDry": 80,
        "VeryDry": 85,
        "active": 1,
        "avgCount": 10,
        "datalog": 1,
        "delicateTemp": 52,
        "dtSum": 7986170,
        "failCode": 0,
        "firstDataFlag": 0,
        "heartBeat": null,
        "heartBeatFlag": 0,
        "hubHeartBeat": null,
        "hubName": "[REDACTED]",
        "humAvg": 21.5022,
        "humidity": 21.98,
        "idDryerballList": 302,
        "lastReminder": null,
        "linkActive": 1,
        "loadCount": 128,
        "loadStart": 0,
        "loadWeek": 126,
        "moveCount": 2,
        "multiUser": 0,
        "name": "[REDACTED]",
        "notifyAlexa": 1,
        "notifyDelicate": 1,
        "notifyDelicateShd": 1,
        "notifyDry": 1,
        "notifyDryShd": 1,
        "notifyHighHeat": 0,
        "notifyHighHeatShd": 1,
        "notifyLessDry": 1,
        "notifyLessDryShd": 1,
        "notifyLowBat": 0,
        "notifyLowBatShd": 0,
        "notifySleep": 1,
        "notifySleepShd": 1,
        "notifyStop": 1,
        "notifyStopShd": 1,
        "notifyVeryDry": 1,
        "notifyVeryDryShd": 1,
        "npoints": 1070,
        "phoneEndpoint": "arn:aws:sns:us-east-1:074171373810:endpoint/APNS/SmartDryProduction/[REDACTED]",
        "phoneToken": "[REDACTED]",
        "phoneType": 1,
        "processStep": 0,
        "rDate": 1593295030222,
        "reminder": 1,
        "reset": 811,
        "resetCount": 0,
        "rowLock": 0,
        "shake": 0,
        "shakeCount": 4,
        "stDate": 1593295025313,
        "stEnable": 1,
        "tempAvg": 40.7517,
        "tempUnits": 0,
        "temperature": 40.33,
        "vbat": 130
    }
]

I [REDACTED] sensitive information about my particular setup, but you can see the section for the APNS and what I redacted from that line. That’s the line that is passed in the API as an “auth token”.

I’ve also been able to replicate the API call outside of the iOS application and appear to be receiving updates normally. This means that I have everything I need to create a REST API within Home Assistant and have it actually polling their cloud service and returning current status.

Unfortunately, the API appears to be authenticated with your iOS device APNS (Apple Push Notification Service) ID, which I assume is saved by the server for your SmartDry at registration and thereafter is used as an “authentication key”.

It’s possible you could capture this over-the-air, as the API call itself is over HTTP (no TLS), and a HA component could then be built with those two variables and work properly. But this is a non-trivial exercise for most people.

I’m going to build a REST API call for myself and see if I can have it working reliably. If so, then we can look at a programmatic way to get the APNS ID.

-Rob

Progress!! How can an Android user help?

Well, it would be nice to see what the API call looks like for an Android user. If you’re interested in building a “man-in-the-middle” WiFi proxy. This is what I built, then I joined my iPhone to the associated wireless and captured the API call itself.

https://www.dinofizzotti.com/blog/2019-01-09-running-a-man-in-the-middle-proxy-on-a-raspberry-pi-3/

Once you have that running and your Android using it, you should then be able to capture a few uses of the SmartDry application. If you copy that URL request, you should be able to replay it in a browser and get back JSON output.

Android looks to be using https sending to different aws ips. I tried pcap remote on cell using decrypt option but it didn’t work. I don’t have a spare ssd to spin that up in my pi. Wonder if there is a hacs add-on that’ll work as proxy?

Yea, you’ll need a proxy to actually decrypt the SSL connection and pull all of the payload data. MITM installs a root ca certificate and then re-issues certs as the host being contacted so that all of the data in the connection can be interrogated.

It also requires multiple NICs to pull off (one wireless, one wired (or two wireless)). So, most HA installs won’t work without a bit of tinkering to get the WiFi operational, providing DHCP, etc…