Cloud & Direct Connected Device Pros and Cons

Developer Programs Writing Device Types
1

I haven’t seen a lot of discussion on this topic, presumably because not too many of you have bitten the bullet and started to really figure out how you are moving your custom Groovy/DTH/IDE stuff (including all those virtual devices!) onto your own execution environment yet.

When you do, you’ll see there are basically 3 options: AWS Lambda, your own self-managed internet server, or the direct-connected device route. I’ve done a lot of work with the direct connect method (which is great, BTW), and just started to look at cloud options too (Lambda and webhoook schema connectors).

I’d like to get a discussion going on the pluses and minuses of going with Lambda vs. setting up your own internet server vs. using direct-connected device approach. This could really help out the community as they start looking at this for their own individual environments, as reading the existing documentation on these topics isn’t going to help a whole lot. Plus it seems with all the lack of info coming from Samsung there is so much uncertainty, that it’s driving more people off the platform. We really need to start talking about how things are going to work on the ‘new platform’ and help share best practices.

Here are some of my initial thoughts on the pros and cons of each of these approaches, but would love to hear some other opinions and experiences:

Cloud - AWS Lambda

Pros

  • No server to manage
  • Free Tier (up to 1M transactions/mo)
  • Likely decent performance communicating with ST since ST also runs on AWS
  • Programmatic device creation

Cons

  • Potential monthly cost if exceed free tier
  • No integrated OAUTH solution

Cloud - Your own Internet Server

Pros

  • Total control
  • Performance
  • No monthly AWS fees
  • Programmatic device creation

Cons

  • Server hardware required
  • Complexity / skills required
  • Static IP required (or use DNS service)
  • Ongoing security concerns opening home LAN to internet
  • Ongoing server maintenance/management
  • Still requires an OAUTH solution

Direct Connect

Pros

  • Theoretically the fastest option (no cloud-to-cloud)
  • Low/no cost
  • No OAUTH requirement
  • Complete control
  • Additional tasks (e.g. command/query other devices, execute automations) can be accomplished through SmartThings API

Cons

  • Still requires something to run your device apps (i.e. Raspberry Pi or MCU)
  • Some additional device profile definition in Dev Workspace
  • Individual device onboarding
  • Not a solution for smartapps; can’t subscribe to ST events
2 Likes
2

Good topic, it will be interesting to see how different people evaluate this.:thinking:

Unfortunately, we still don’t have any details on how hub connected devices are going to work, correct?

3

Right - I’m kind of leaving the hub-connected discussion including zwave and zigbee stuff off to the side for now.

We’ve all seen the cryptic hints that more things will be able to run locally in the future, but I’m betting on that being more applicable to Rules and zwave/zigbee-related hub stuff. The tea leaves I’m reading says that things like virtual devices - whose function can’t be otherwise solved by using Rules - will have to run elsewhere.

1 Like
4

Understood. I’ve been asking for specifics on how virtual devices will work on the new platform, and specifically how they will be created by individual customers, for about six months, but haven’t gotten any answer yet.

There is a virtual device creator in the smartthings labs now for those who live in a country and have a Device which offers that feature, and it’s pretty new, so it may be able to survive once groovy goes away. But nobody has said for sure one way or the other.

https://www.smartthings.com/partners/smartthings-labs

SmartThings Labs feature is available only on Android app in US and KR with English and Korean languages supported.

1 Like