[Release] Vehicle Remote Start (SmartStart) Integration

Hello folks,

I had an older version of this mentioned here.

I had some time before the start of the summer semester so I created this updated version. This is a release updates the web requests to be asynchronous drastically increasing their reliability. I have also added the trunk and locate back in and dramatically updated logging instrumentation.

Personally, I use IFTTT / Smartthings / Google Assistant to allow voice commands like, “Lock/Unlock/Start my truck” etc. You must use IFTTT right not because Google Assistant does not natively allow you to operate locks (or “Timed Sessions” which I am using for the start/stop verbs).

If you are using a Smart Start app on android/ios you can likely use this device handler. I use a Viper brand however they utilize a directed backend (which the DH is communicating with directly). That said directed says it is the backbone for other brands “Smart Start” systems like Viper, Clifford, AutoStart, AstroStart, AutoMate, Python, Avital, Install Essentials and Directed as well so it should work just fine, of course, YMMV.

    * Change log:
    * 2018-05-03 - (v00.02.01) Updated Instrumentation
    * 2018-06-16 - (v00.02.02) Lots of code cleanup, added proper encoding for user/pass & properties for Alexa
    * 2008-11-13 - (v00.02.03) Added automatic retry on error, IFTTT Webhooks (https://ifttt.com/services/maker_webhooks/settings) and some code cleanup
    * 2018-11-19 - (v00.02.04) Smart retry (only retry needed requests), store vehicle id between attempts, ignore additional calls while processing

Adding a new device handler
If you need help adding a custom device handler JDRoberts has a great post FAQ: An Overview of Using Custom Code in SmartThings (SmartThings Classic)

Hello,
I get the following errors:

Org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: script_dth_metadata_27ff0251_3141_4c7d_81b6_0b8c11ba5883: 562: unable to resolve class Desktop @ line 562, column 10. Desktop version ^ 1 error

Thanks Parth Patel

Looks like you might have introduced some errors when you copied the code. Make sure you copy from https://raw.githubusercontent.com/rleonard55/rleonard-SmartThings/master/devicetypes/rleonard55/smart-start-2-0.src/smart-start-2-0.groovy the ‘raw’ version (at the above link) and don’t have anything else in your groovy file.

Regards,

Rob

Thank you so much!
I got the device handler added. But now how do I add it as a device?
Thanks

Parth

got it to work!

Awesome, congrats

1 Like

Please always support this. Thank you so much this is awesome. I just installed a python rs with the directed dsm 300 and I can now tell Alexa to start my car.

1 Like

I will do what I can. My wife and I both have vipers smart start systems so we do have a vested interest. :slight_smile:

this is all greek to me, but I am interested in getting my viper smart start to work with smart…any and all help would be greatly appreciated

Rob I use this with webCoRE and now have my car set to auto start depending on my local temp and my work schedule. You did excellent work with this. It would be awesome if it could return state of the the lock.

1 Like

@rleonard55 is there anyway that if an error is received that a push notification could be sent to my phone? I would have no clue how to build this into the code if I wanted to.

@rleonard55 any idea why this wouldn’t play nice with webCoRE? webCoRE is sending three to four commands at a time because the smart start handler is sending errors back. This is causing issues with my car starting properly because it’ll start it then shut it down, start it again, shut it down and then error out.

I don’t know right off but I can take a look. (Just been much busier than I expected to be this semester)

That said, there is an updated version uploaded to github now that add setting for an optional automatic retry in case of a timeout option and well as an optional IFTTT webhook integration to allow potential alerts of an ultimate failure.

-I’ll take a look at the logs some tonight

1 Like

webCoRE utilizing command optimization disabled is causing it. With that enabled it allows the car to start properly, but makes it so I can’t put the lock in any of the pistons because it doesn’t recognize state. This isn’t too big of deal as long as the car starts based off the weather before/after work I’m thrilled lol.

I wondered about that. Honestly not allot more I can see to do about that. Even the SmartStart native app polls the vehicle (…slowly…) to get current state only when requested and without that the SmartThings device would have no idea about any actions taken with a key fob or SmartStart app. All that said I did try webCore tonight to lock/unlock/start/stop my truck and all was seemed fine for me.

It works perfect as long as i have command optimization off. Not a big deal seeing as i have the keys in my hand lol.

I love the update though. Now i know my vehicle will be running… thank you so much.

The thing is to they only allow so many commands so you could never regularly poll the vehicle either.

Agreed, that was one reason why I hadn’t initially added a retry function too.

I’ll likely leave that at zero just for that reason. I used the webhook to have it send a notification via autoremote so if it errors I’ll know to use the native app or keyfob.

@rleonard55 Today webCoRE kept sending commands until it errored out, even with command op turned off.

Can’t tell you for sure what Webcore is doing there though you could ask it’s dev. The only error displayed was a web timeout, which unfortunately is the nature of the beast sometimes with web calls, especially to Smart Start. Of the top of my head I’d guess that Webcore is trying it and then checking to see if it works or not. If it doesn’t, or hasn’t yet at least, Webcore might be trying to help by resending it. This is of course an issue when commands get stacked and successfully sent, you end up with a start/off merry go round.

Rob