I would not assume this to be the case. Once the Groovy Platform is shut down, all Groovy SmartApps may simply cease to run.
1 Like
The ST Cloud will no longer run Groovy in the future, and customers Will no longer be allowed to create code that runs in the ST cloud. so this assumption is incorrect. When Webcore stops working (and that is a when, not an if), then all previously existing pistons will also stop working. So that’s why people are suggesting that you get prepared for that.
There is a competing hub, Hubitat, from a company founded by some former smartthings users who wanted local operation and more customer control. It does run groovy and a form of webcore. So some people are already planning to run both hubs in order to preserve their groovy code.
In the future architecture, custom code has to be hosted by the author on their own server (and can be written in any language you like) and then communicate with smartthings through the API. Typically but not exclusively using MQTT.
The options for writing rules that will continue to work on the new platform are:
-
create rules through the existing smartthings app using the built-in automation creator
-
create rules through the new “rules API“ which has a lot of webcore like features, but is still in development and not fully documented. For more information see:
-
write any code you like, using any language you like, host it yourself, and communicate to smartthings using MQTT.
-
continue to write groovy code and either run it now on Hubitat or plan to do so in the future
Any or all of these will work now and in the future. But webcore in the ST cloud is going away sometime this year.
1 Like
Hue products can technically be used without a hue bridge, but neither smartthings nor hue recommend that as it can mess up your Zigbee network. The official integration requires the hue bridge, and you do get a lot of advantages that way.
See the community FAQ (the topic title is a clickable link)
There’s no reason to be concerned about having multiple Bridge/Hub Devices in your home automation set up, any more than you should be afraid of having multiple circuit breakers on your home’s electrical system. It can spread out the load, add additional features, and provide engineering efficiencies.
If your concern is the interface, that’s a different issue, and smartthings itself is an app that can handle many different brands of devices. You may have to set up different devices with their own app initially, but after that, you can generally treat them as all one system. 
1 Like
The architecture is actually somewhat different than that. You don’t have to have a smartthings hub at all . Its real purpose is to establish a local zwave and zigbee network, but smartthings is still primarily a cloud-based system and pretty much everything, including the smartthings hub, runs through the smartthings cloud. Most code, even mode changes, runs there. In the future, most code will run on servers provided by the customers and then communicate to the smartthings Cloud through a REST API. So you still don’t need an ST Hub. (Technically you don’t even need one for zwave and Zigbee devices, you could, for example, use Hubitat or Home Assistant for that and then use the API to communicate with your smartthings account.)
Here’s a recent discussion on the architecture:
Thanks @nathancu , @ogiewon and @JDRoberts
Thanks for your explanation and I totally accept my understanding was incorrect.
So, I was aware of the smartthings API - and have in fact already used the API for activating scenes.
As a developer I’m totally at home with writing code and hosting it on my own platform, and I frequently write code to communicate with 3rd party services via APIs.
My goal when starting my smart home journey was to start somewhere that would give me the flexibility to achieve the automations I want to achieve. Then I could look to make them more efficient and introduce offline/local processing as I better understand the architecture.
I’m totally fine with whatever those things look like and I have no preconceptions of timeframe.
I think, based on everybody’s advice and help, my timeline looks like this:
- short term - use a combination of automations in the smartthings app and webCoRE depending on requirements and software abilities
- mid term - as the smartthings API is developed, and documentation is published, I’ll look to move my automations over to my own solutions/hosting, putting me fully in control of possible outcomes
- long term - find a solution for on-site/local/offline processing (perhaps with online backups and remote communication and notifications).
1 Like
Sounds like a plan!
One more thing… With most non-compiled languages, including groovy, the usual best practices is to keep each processing block, in this case a piston, as small as possible. Again, the experts over on the webcore forum can give you more advice and examples specific to webcore, but there have been many times when people have reported in this forum that their code didn’t run because the cloud timed it out or they hit some other “guardrail.“ And usually advice from smartthings engineers was to break it up into smaller pieces. 
Note that as has been historically typical with smartthings, these guardrails were rarely documented or announced. They were just implemented. Then things stopped working. Then people came to the forum and try to figure out what was going on. 
Of course shifting to customer hosted servers should get rid of this problem for most people, but it is something to be aware of now.
1 Like
@mwav3 has done a lot with MQTT and smartthings and might have some more suggestions on this.
Thanks @JDRoberts
Oh yes, I would totally agree with making many, small procedures in almost any other circumstance.
Of course, if all of the ‘processing’ brains are hosted on my own platform, I can work to make that part as efficient as possible.
As long as I have somewhere to send the ‘doing’ commands to (such as ‘turn on light 1’, ‘turn off light 2’) I’m happy.
And as long as I can subscribe to event triggers (such as ‘button 1 pressed’, ‘button 1 double pressed’, ‘button 1 held’) I’m happy.
I realise there may be limitations and considerations as to what can be achieved with the ‘doing’ commands, which will be a learning curve.
2 Likes
I highly recommend node red for local processing. It can integrate and link to to webcore, mqtt, the Smartthings API, and many other systems. More on that on this thread Node-Red and Smartthings - #39 by mwav3.
I started off with webcore, then a hybrid node red/webcore setup. Now all my automations are done in Node red. I did ultimately transition to Home-assistant from Smartthings, but Smartthings was a very important step on the way, and can still be very useful for many.
2 Likes
Hi @mwav3 thanks for the advice.
I’ve not heard of Node-Red before, so just trying to wrap my head around how it works/operates.
Does it work with the smartthings hub, or replace it?
How does it communicate with the smart bulbs and buttons? does data travel by: button > sm hub > node-red > sm hub > bulb?
I love that it would run locally, but short-term while I get my feet under the table so to speak, I think I need to start with the smartthings app, webcore (short term) and the smartthings api. My internet connection here is pretty good (average about 550Mbps, with very few outages), so I’m not to concerned with running everything locally from day 1.
It sounds like you may still be thinking of the ST hub as a server. It’s often more helpful to just think of it as a router, a box of radios used to send and receive messages from RF devices and the ST cloud. It doesn’t care about the content of the messages. Like a post office, it just delivers the letters, it doesn’t compose the messages or read them and make decisions about what to do next.
Node Red may be described as a rules engine, a dashboard, or an app creator depending on the original goal of the person doing the describing. It’s a graphical programming interface (layered over JavaScript) which is used to create If statements for IOT use cases. IBM made the unfortunate decision to describe it as being used to “wire together IOT components,” which is exactly what it doesn’t do, since Node Red has no hardware or real world parts. And no radios. It’s software.
In a SmartThings context, Node Red is a replacement for WebCore, but you have to host it yourself.
It has built in blocks to handle incoming and outgoing MQTT messages.
MQTT is a lightweight messaging protocol for IOT. You can use it to interface with the SmartThings cloud, for example.
But if you have zigbee or zwave devices you still need a hardware router with those radios to deliver the messages you created as output from Node Red. (And probably to convert them from the MQTT format you output them from your Node Red flow to the message format the receiving device understands.) That’s where the ST hub comes in. It’s the radio operator.
Since you’re a programmer, you might find the following “Hello World” introduction to Node Red of interest. (Those following along who are not programmers should skip this particular article, as it will only be more confusing unless you have a strong programming background.)
2 Likes
Thanks @JDRoberts this explanation is definitely helpful.
As you mentioned above, Node Red does not run on a Smartthings hub, but can run with it. Actually not much runs on a Smartthings hub other then stock device handlers, so thinking of it like a router is probably best.
To run Node Red locally, most run it on a raspberry pi, but you can run it on any android tablet by paying $5 to download the app from the play store. You can run it on any old computer/laptop lying around by using docker to try it out. Its also possible to run it in the cloud with no local hardware, but to me that defeats the benefits of local processing.
Things link together with “palettes” and there is a Samsung Automation Studio palette to bring Smartthings connected devices into Node Red. I haven’t used that personally, but should bring them in in a similar way that home assistant brings in devices. It uses the API so will continue working after the Groovy IDE goes away. node-red-contrib-samsung-automation-studio-nodes (node) - Node-RED and use the Smartthings nodes Samsung Automation Studio
Node Red might be a bit advanced to start out, but could be a goal to get to when you get more comfortable with everything, and I think fits well into your “long term” goal outlined above. Smartthings app automations can probably do a lot for you now and I would try those out first. I honestly would not invest too much time in Webcore. It will not exist in its current form within a year with the Groovy IDE phaseout, and its uncertain future is why I moved everything to Node Red in my case. You might still want to check it out but just go into it with the thought anything you do there will be probably be temporary and will have to get redone in something else.
Here is an example from my Node Red to show visually. Its what happens when someone gets home and mainly turns on and off lights based on weather and time of day, and other conditions. There are many youtube videos showing node red as well, but those will be geared towards running it with Home Assistant. Its very popular for Home Assistant users and comes as a built in addon:
3 Likes
Thanks @JDRoberts and @mwav3
I was fully understanding the usage of the ST Hub as per @JDRoberts description.
Really what I was asking is where the data travels and how it would travel between the ST Hub and Node-RED. obviously if its to work without internet, the node-red code can’t communicate via the SmartThings cloud or SmartThings API.
I was expecting that the Node-Red would run on a RPi or other machine - I realise Node-Red is software.
I wasn’t sure if you would have to have Hardware also connected to the RPi to talk to the Zigbee/ZWave devices (bulbs/switches/buttons) or if you would still use the ST Hub (or an alternative) to do that talking
so basically by my understanding:
- Button is pressed
- Message is sent from button to SmartThings Hub via Zigbee/ZWave protocol
- SmartThings Hub sends the message to the RPi with Node-RED via LAN
- Node-RED interprets that message and decides what it needs to do
- Node-RED sends all the instructions for all devices to SmartThings Hub via LAN
- SmartThings Hub sends the instructions via Zigbee/ZWave protocol
- Bulb receives instruction, and turns on/off
That’s not how ST currently works… Node-RED would be communicating with the ST Cloud. The ST Mobile App communicates with the ST Cloud. Thus, your internet connection must be up all of the time, and you’re dependent on the ST Cloud servers being up and running.
Pretty much nothing communicates with the ST hub except Zigbee, Z-Wave, and a select group of LAN-connected Devices. Even the ST Mobile App must always communicate to the ST Cloud. It cannot connect directly to the ST Hub, even if connected to the same LAN.
Here is the corrected data flow
- Button is pressed
- Message is sent from button to SmartThings Hub via Zigbee/ZWave protocol
- ST Hub sends button events to ST Cloud via internet
- SmartThings Cloud sends the message to the RPi with Node-RED via internet
- Node-RED interprets that message and decides what it needs to do
- Node-RED sends all the instructions for all devices to SmartThings Cloud via internet
- ST Cloud sends requests to ST Hub via internet
- SmartThings Hub sends the instructions via Zigbee/ZWave protocol
- Bulb receives instruction, and turns on/off
If you’re really hoping for full local processing, at this time I would advise you take a look at Hubitat or Home Assistant. SmartThings is a very cloud-centric platform.
1 Like
Or Homeseer. Or even ahem Apple’s HomeKit. 
All of these use the Internet only for remote location control and integration with cloud-based third party devices like voice assistants.
And HomeKit even has a slick consumer-friendly mobile app that works just fine on local WiFi, no Internet required.
But then Samsung designed a WiFi mesh router that requires an active Internet connection, so…different design philosophies for sure.
1 Like
Aha!
Forgive me @ogiewon I’ve obviously got mixed up - I was thinking you had suggested Node-RED specifically for local processing.
This makes much more sense to me now 
On an absolutely separate thought
I’d be interested to know how the ST Hub talks to ST Cloud - is it via IP address or Domain? If it sends messages to a domain, you could theoretically intercept the DNS request and make the ST Hub send it’s messages to a local IP address instead of the ST Cloud IP.
Then it would just be a matter of interpreting the message ST Hub sends to ST Cloud, and responding to the message as expected. This of course is a much more involved task and clearly outside the scope of this string
No problem. Node-RED wasn’t my suggestion, although I do use it with Hubitat for a few things (all local on my LAN, by the way )
The traffic is all encrypted. You’re not going to hack the ST hub to cloud communications.
2 Likes
As @ogiewon noted, pretty much all mainstream commercial home automation systems started locking down their message channels in 2015 to avoid eavesdropping attacks, which were a hot press item at the time. SmartThings tightened up everything, bigtime.
SmartThings Hub-to-Cloud Communications
.
Communication between the SmartThings Hub and SmartThings Cloud take place using a persistent TLS encrypted socket that is maintained by the Hub. To ensure trust between the Hub and the cloud service, mutual certificate verification is employed. Additionally, SmartThings Hubs authenticate with the SmartThings Cloud using a combination of parameters that cannot be eavesdropped or replicated.
.
SmartThings Client-to-Cloud Communications
.
Communications between SmartThings Clients and the SmartThings Cloud are handled by OAUTH2-protected HTTPS endpoints or using a TLS encrypted socket connection that is opened by the client whenever it is in the foreground. To ensure trust between the client and the cloud service, mutual certificate verification is employed.
If that weren’t true, there’d be no point in having combinations for the locks or alerts for the sensors.
2 Likes
Yeah I suggested Node Red for local processing of the automations, ie the code that reacts to inputs/conditions to trigger actions happens locally with Node Red.
However, as pointed out above, Smartthings is entirely cloud dependent to actually read the states of the devices and send commands to change them. You can use webcore to make a local http web request from Smartthings to your Node red server, but even that relies on the cloud to tell the hub to initiate the local http request.
I think it always makes sense to reduce cloud dependency where possible. With Home Assistant, all my mqtt, zwave and zigbee devices keep working along with the automations to control them if the internet goes out. However Alexa, Blink, Ring, and MyQ all require cloud connections still and would stop working. You usually won’t get totally away from the cloud .
However if a goal is most things keep chugging along fine during an internet outage, Smartthings is not the right system for that. When I had Smartthings and internet went out, the only control I had were zwave devices directly associated with eachother, and that was it. It can be a good intermediate step on the way though to get started out with Home automation.
2 Likes
Alexa now offers a very small amount of local voice processing, only for Zigbee devices connected to one of the echo devices that has a zigbee hub inside. So you can’t use the same device with ST as well unless you use an echo routine as an intermediary and The routines don’t work when the Internet is out. So it’s limited, but it can be useful when planning for outages.
In our case, since I am in a wheelchair we do have two switches to create a pathway from my room to the front door that will work by voice even if the Internet is out. 
2 Likes