That is great to know.
I’ll update my original post, and make this change to my pistons
That is great to know.
I’ll update my original post, and make this change to my pistons
One more thing, as others have already mentioned… SmartThings has stated publicly that their legacy Groovy-based platform will be retired sometime in 2021. Since webCoRE is 100% dependent on Groovy, one should be fairly safe to assume that webCoRE only has at most 7 months left in its current state on the ST platform. If webCoRE is very important to you, it will still available on another platform, that runs webCoRE Pistons locally on that hub, with no need for the internet to be up and running. So, this may be one way to preserve one’s hard work in developing webCoRE Pistons if running them on ST ceases to be an option in the future. Hopefully there will be a webCoRE-like replacement for SmartThings in the future, once the Groovy platform is shut down.
If you plan to stay on the ST platform for a long time, I would encourage you to use the newer ST Automations and Scenes to try to achieve your goals. These should continue to function, and are being improved by the ST team.
I take onboard the impending demise of webCoRE in its current form and accept there will be changes to my automations/pistons to come.
As I understand it, if/when webCoRE stops working, the automations that I’ve already set up will not stop as they are run/stored by ST Cloud.
I would happily use the standard automations in the new ST app but I need to consider the following:
1, needs to be easy to manage basic edits and updates, without having to start from scratch if for instance the trigger device is replaced
2, performance isn’t impacted too much. I.e. if having lots of automations exist in the system (for different combinations of values/devices states/times of day) - going from non smart to smart devices, a delay between cause and effect will be noticeable and potentially annoying.
My particular reason for choosing smartthings was that lots of devices will talk to (or at least through) the ST hub, where alternatives seemed to have limitations to manufacturers and/or device types.
At this point I would only assume that true for Rules API stuff. I wouldn’t assume this to be true for anything running in Groovy after the platform shift. If they kill off the Groovy IDE then we have no reason to believe the code will still be running - when the code running your automations stops the automations stop too.
I would not assume this to be the case. Once the Groovy Platform is shut down, all Groovy SmartApps may simply cease to run.
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.
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.
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 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:
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.
@mwav3 has done a lot with MQTT and smartthings and might have some more suggestions on this.
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.
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.
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.
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.)
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:
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:
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
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.
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.
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