I’m currently building a RESTful call within HA to see if I can reliably pull the data for mine. If that works, then I’ll look at how it can be turned into a custom component and configured for everyone.
How complicated is it to make that happen?
By “it” are you referring to setting up a MITM proxy to get your own data?
Or are you referring to building a custom component?
I posted the instructions on building MITM proxy, it was straightforward for me, but it’ll depend on your skill level and comfort with Raspberry Pi hardware.
As for the custom component, I think it’ll be relatively easy to build one for myself, but it’s going to require a configuration variable that’ll be hard to find (your APNS ID). I’m looking for a way to make that happen. I’m also working to ensure that what I believe I’ve done is actually stable and allows me to do things like trigger notifications and automations based on state.
The custom component part.
I’ll try and figure out how to get the same data from an Android this week.
Just wanted to tell you I’ve been continuously watching this thread, hoping for a breakthrough. I’m extremely new to Home Assistant and have had a blast learning how best to use it. SmartDry is very tempting but with notifications only on your phone or via asking Alexa, I’m not ready to take the plunge yet. I really hope you can get this custom component to work!
Agreed. I have mine actually working in HA, but it’s not a scalable solution, as it requires that you get your APNS number by capturing traffic from your iPhone/Android to their server. I was able to do that and then able to build a REST call that seems to work reliably.
Here’s what I’m able to capture if you can get over the hump of acquiring the “token”:
@pickerin This looks really interesting, do you have some repo with the work you’ve done?
Do you have to have a MITM proxy? Can’t we create a “server” to impersonate them?
Just reading this topic and had an idea. Has anyone attempted a humidity sensor in the dryer venting hose? This may be a simple method to detect the air humidity passing through the vent and thus determine the dryness of the clothes.
4 Likes
Well, I had to great a MITM proxy in order to find the actual APNS number for my iPhone application that was talking to SmartDry. Once I had that, I was able to create a REST API call that appears to be stable and functioning properly.
I don’t have a repo, because there’s nothing “generic” I can put in it. I’m happy to share what I have, but it’s a one-off solution because you need your individual APNS number and I’m unsure how to get it by any means other than a MITM proxy, which is far beyond most folks.
Interesting concept. Doesn’t really have anything to do with SmartDry, but could be a way to achieve the same thing without one…
Maybe we might create a docker container MITM Docker container allowing for easy catching of the APN. Or even better would be to use a Python library which could be used for catching it (easier setup)
What does the traffic look like that you caught to get the APN?
Also once you have the APN what does the REST call look like? How did you setup your sensor?
The Rest API sensor looks like this:
- platform: rest
name: SmartDry
json_attributes:
- active
- temperature
- humidity
- tempUnits
- shake
- shakecount
- rDate
- loadStart
- stDate
- LessDry
- Dry
- VeryDry
- tempUnits
resource: https://_REDACTED_.execute-api.us-east-1.amazonaws.com/prod/RDSQuery
?Id=<_ID_HERE_>&Write=1&SQLString=update%20DryerballList%20set%20PhoneEndpoint=%22arn
:aws:sns:us-east-1:_REDACTED_:endpoint/APNS/SmartDryProduction/_APNS_HERE_%22,linkActive=1,phoneType=1
value_template: 'OK'
scan_interval: 5
The entire “resource” value is the URL I pulled via the MITM proxy call. The reason you need a MITM is that you have to break the TLS encryption. It’s not as simple as grabbing it with a python script.
Ok, I get it now. So you’re basically simulating your phone’s app to access the data from their servers.
So the device sends the data to the server which you pick up with a rest call your phone would send.
You got it! That was the only way I could figure out how to do it. My original intent was just to reverse engineer the API call(s) itself, but they appear to be authenticated with the APNS of the phone where the App lives. That makes it WAY harder.
The must just be monitoring the temp/humidy to determine when the load is done. A simple idea, but one that didn’t occur to me.
I put an Aqara temp/humidity sensor (Zigbee based) in my dryer and ran a load. I saw that the humidity started high, the temperature started to rise, and the relative humidity started to rapidly fall. When the load was done, the temperature was approximately 122°f (low heat setting on dryer) and the relative humidity was about 14%. That’s not particularly dry from an absolute level, but with more data there must be algorithm to discovered.
You actually put it in the dryer?
Just loose, or stuck in there somehow?
Be interesting to see how robust it is long term.
I attached to a non moving part near the door of my front loading dryer using one of the sticky adhesives that come with the sensor.
I don’t think it would last long if the adhesive failed 
, but it’s just an experiment at this point. It’s only a 10 dollar part. I need to test it at high heat as well — it just so happened that my laundry required the low heat setting.
They’re monitoring temp, humidity, AND “shake” or relative motion. The “shake” value (you can see it above in some of my output) is used to actually determine if the dryer is “done” whereas the temp/humidity is being used to determine “how dry” the clothes are…
I did see the “shake” parameters in your earlier report and wondered if they used it. When I was casually monitoring my dryer temp/humidity in my test, I noticed that the temperature started to rapidly drop. I thought there might be a problem because I was expecting a longer cycle, but, in fact, the machine has stopped and the load was dry. I don’t know for sure at this point, but a rapid drop in temperature may be adequate to determine that the dryer has stopped.