Groovy going away - how screwed am I?

Between having a young family, the pressures of running a small business (and at the same time, closing another down) and the general state of the world and my wellbeing, I’m finding the timing and demands of this transition away from Groovy device handlers really difficult.

From an end user perspective; I’ve jumped through the IDE hoops needed to install custom code, and it’s worked for literally years. I’ve even at one point waded in and figured out that an API endpoint for our heating system had unceremoniously moved, and shipped / shared a fix for it.

But I’m tired. And now I find that the following things that Smartthings currently does for me are seemingly going away unless I start scrabbling around to patch them:

  • Honeywell Evohome zoned heating control & temp reporting per room
  • Simulated Alexa button, so that I can run an Alexa Routine when a physical device triggers (the physical device triggers a press of the simulated button, which Alexa uses as a trigger). This powers warnings about my garage door being left open and also our doorbell
  • Our doorbell itself uses a custom groovy DH
  • 2-wire capable back box switch (Zigbee, from Vesternet) for our overhead kitchen lights;
  • 8 button wall switch (Zigbee, from Vesternet) controlling lights, automations and other devices on our kitchen wall.

I feel really, really frustrated that my peers in software development at Smartthings haven’t found a way to just have legacy stuff run until the user stops using Smartthings. I’m sure there are Very Important Architectural Reasons™. I am a low-energy user with a difficult enough existence without the stuff in my house stopping working because somebody has decided to push forward at the cost of users.

I have made a spreadsheet of my current dependencies to research. If anyone has any advice on this, I’d really appreciate it. I’ll try and add some specific model numbers etc. I don’t really know where to start.

1 Like

Community developers have already created edge drivers for virtual devices, including devices to trigger Alexa routines, that work well. You do need a ST/Aeotec hub to run them, but it sounds like you have that. You can find these on the quick browse list for virtual devices in the community-created wiki.

How to Quick Browse the Community-Created SmartApps Forum Section - Things That Are Smart Wiki

So I think that one’s ok in the long run, although there’s a lot of tedious work needed to recreate everything. :disappointed_relieved:

Hopefully others will be able to comment on your other devices.

1 Like

Thanks - that’s one bit I was definitely worried about. I’ve also spotted the doorbell sensor has some progress - [ST EDGE] Sage/Echostar Doorbell Sensor

1 Like

Yes. Money. You are costing them a fortune in cloud computing costs with little to no return to thier bottom line.

5 Likes

Hi @ben_seven ,

I bet the Vesternet 2 wire device will convert to a Zigbee switch, either through a mfg fingerprint or generic switch cluster. The 8 button device may be something @Mariano_Colmenarejo may already have in his library of community developed edge drivers.

Unfortunately I can’t speak to the Honeywell Evo’s converting over other than to say the Smartapp will be DOA at conversion time.

To @nathancu’s point, it is costing them a pretty penny in AWS costs (I believe that’s their provider), and the more complex SmartApps that run there, the more they pay without any of us users generating any revenue back. It’s been a while, but I remember one SmartApp had such an impact that ST forced us not to use it anymore, at least that’s kind of how I remember the story.

3 Likes

This statement shows some naivety about how major conglomerates operate. You do realize some of them like Google provide services at a loss, even supermarkets sell products at a loss, I don’t think a company like Samsung that made 173 billion last year is shutting down groovy because it’s costing them money.

I’ll plump for the legacy system being a steaming pile of poo that has been holding back development for years.

2 Likes

I for one am happy that Samsung is cutting ST costs, because it should help ensure the long-term survival of SmartThings.

And as far as the changed bring made I see a lot of improvements such as local operation, & quicker operation. I have been switching over to Edge drivers as they became available over the past year. When the switchover occurs I do not expect any problems since I have already made the needed changes.

My only complaint is that Samsung could have done a much better job of communicating the proposed changes to all users over the last couple years.

5 Likes

But a command line interface, and LUA!? Seems they’ve invested as little as possible for users. The old IDE was junk, but at least had a method for testing. This is way worse.

Funny. Ask someone thier history before making assumptions. I was a support manager for one of the outfits you mentioned and a cloud architect…It’s part of my job to help clients understand and plan cloud costs.

SmartThings was born and run in the cloud by its original creators with intent to provide a highly configurable solution and use the revenue from hardware to fund the cloud portion. There were other side agreements of course and some theorize it was purely built to be a sales target… Either way, in the early days of ST - your hub purchase and your sensors subsidized the cloud. Yes that seems kind of silly now looking back 10-12 years later but even as few as 10 years ago the ‘cloud’ as it exists now was barely a thing.

(we now know that’s not a sustainable model by the way… Cloud use WILL ramp and will not stay flat. Either you compensate in the price of the device or pay to play.)

Samsung bought SmartThings and never bought into that philosophy. As far as we (the community) know they never had intentions on keeping the cloud aspect running. We do know they saw it as a necessity for thier appliances. As early as 2015 people already saw the benefits of a cloud connected TV or washing machine. (ok washer is debatable but you get the point) but Samsungs use case does not rely on the cloud and it became a major drag on the bottom line of the operation.

John is 100% correct about the one smartapp. It was Echo Speaks, and yes it was that bad. Less than a few percent of the entire user base (single digits) were responsible for 80%or more of all cloud compute in the AWS tenants hosting ST. It wasn’t only racing the ST servers - the number of poll calls from ST to Amazon was bad enough that Amazon TOLD SmartThings it was going to stop. It was not an ask.

So now we’re here in present times. Samsung is no longer selling ST hubs kr sensors or hardware of any kind. The original revenue streams covering the cloud usage is gone. So would you continue operating it?

We’re not talking Xboxes and Xbox Live here (XBL/GamePass is why Microsoft offers Xbox at a loss, it’s a vehicle to sell more GamePass which at the end of the day has LIGHTYEARS more margin on the revenue than an Xbox) For Samsung there’s no paid subscription here and your average TV user just wants an app to turn on the TV. They couldn’t care less if the cloud can support thier groovy smartapp.

9 Likes

I’m glad you’ve managed to thoroughly derail what was meant to be a practical thread. Still, as long as your ego is fed, that’s the important part right?

1 Like

With Edge drivers you can actually use an IDE with full autocomplete/intellisense and it has a framework for integration tests which basically allows you to write and test the entire driver before even installing it on the hub…

1 Like

please expound on this

I love developing locally with full GitHub integration right in Visual Studio Code. For development, its way better than the web based Groovy IDE (that was barely an actual IDE from a developers POV. At best it was an editor with an added on GitHub module).

IDE:

Testing Framework:

2 Likes

Not to mention a convenient terminal window for running the CLI. The CLI is an incredibly useful tool in the development environment.

2 Likes