Hub Firmware Release Notes - 19.17

( #41

I would make sure your not overloading your hub

  • InfluxDB Logger can do this if not used correctly
  • Turn off any debugging in apps and devices handlers
  • remove any apps,device handlers you no long need/use
  • Only give apps devices they need i.e alexa/google home can only use switches & lights. actiontiles if you don’t use a device remove it
  • Try to reduce need on apps that a webcore piston could do

(Joe) #42

When can we expect the Battery Levels to be fixed? Why do they work on non Smartthings devices but the Smartthings devices are the ones with the issue? Shouldn’t they be the easiest to fix since they are your devices? I just ordered 3 more multi-sensors in hopes this will be fixed soon which brings my count up to around 8 or so. I do not want to go around my house every few months and just swap out batteries which currently is the solution to this per Smartthings.

( - Make your home your butler!) #43

Will this include local execution of the new z-Wave/zigbee DTH’s?

(Adam V) #44


I got really excited when I saw the note re: local execution… then read the details…same as before - no changes in practice.

Quite timely, as last night I was doing some experimenting with a new OpenHab box. I connected to it a Wall Controller ( WallC_S) and all of my LIFX bulbs. I then made a simple rule to turn the lights on and off. The exact same setup I already have with Smartthings. With Smartthings, connected to the LIFX bulbs over the cloud (because after all these years there is still no UDP support), connected to Smartthings backend over the cloud, even with my 200mb internet connect the lag between pressing the button and having the lights respond is anywhere between 1-4 seconds. With Openhab connecting directly to the bulbs over LAN (UDP) and the execution running locally - there is no perceivable lag at all - I suddenly remembered what it was like to not have a smarthome… and it got me thinking how important this topic is… if we are all here to build the home of the future, this lag that we must currently contend with to use Smartthings is utterly unacceptable - simply put, if the “smart devices” cant do things as well as a “dumb” device, i.e. turn on instantly when you press a button, then we have a big problem. I really hope that local support will be extended to all devices (not just official device handlers because most of my devices use a custom handler, and I don’t think I’m alone here), and that proper support is added for LAN protocols so that there are far more actons that can be run locally

(PPO16) #45

@tmleafs and @Cobra, are you both on a UK or US setup?

just wondering seeing the time of your answers and .uk in @tmleafs

( #46

Yea both of us are in the UK

(PPO16) #47

That could be a difference in the behavior. ST support acknowledged some fmw updates caused many disconnections when i faced that issue. I wasn’t alone these weeks, this forum had many users experiencing that too. I am on US version.

(Chris) #48

That‘s fine that users are forced at some point to update. I think the mentioned option that HUE allows is totally acceptable. I don‘t expect to run old firmware forever. I just want to be able to delay an upgrade to when I am home and not be surprised by an upgrade when I am traveling. This is not just an issue for vacation. I travel a lot on business and when I am away I can‘t explain to my family if something stops working while I‘m away because my home automation vendor decided to upgrade while I was gone. That ruins any acceptance by the family for home automation when this occurs.
So, please start giving more advance notice and allow the user to manually upgrade within a two-month period at least. That would be acceptable for me. But sending a notice out with two days notice is totally unacceptable. I can accept a notice that an upgrade is available and that users should upgrade within the next two months and after that time any system that has not been upgraded would then automatically be upgraded from the cloud.

(Tony) #49

How can I know if my Zigbee Bulbs and switch can run localy?
Can WebCore \ core run locally (as most of my complex rules are done in WebCore)?

Bulbs (Zigbee):

  • Osram Lightify RGBW Classic A60
  • Osram Lightify Par16 Tunable White Spots


  • AEOTEC Wall Mote Quad (Z-Wave)

Please advise how I can bring the execution locally rather than in the cloud…



(Allan) #50

webCore does not run locally. Anything you have in it requires the cloud. Only things like SmartLighting with local devices will run 100% locally. This is the main reason I use stock/generic DTH’s for all devices I can and use SHM custom routines and SmartLighting whenever possible.

( #51

Is the no benefit of local devices handlers when you use webCoRE? Not even a little?

(Allan) #52

Not really since if your internet doesn’t work the webCoRE automations also wouldn’t work.


It would be great if this contained an official list of the devices as well that someone else was looking for yesterday.


I am in the US and I have never experienced an issue with any of the firmware updates or anything funky happening with my hub. That includes the one at the beginning of the year that was a slight fiasco (where a couple hubs got bricked). I believe that firmware update was the one to setup in making future updates a lot easier with the ability to back down to a previous update (not from our end).

And I travel a lot for business so I’m not there to babysit my hub :slight_smile:

(Mike) #55

Any news on how far along the updates have got. Im in the Uk and no update yet !

(Bob) #56

Received an email with the following:-
_Hello, _

Between Thursday, November 16, 3:00 PM GMT and Friday, 12:00 AM GMT, we will automatically update your SmartThings Hub v2 to the latest firmware (version 0.19.17). Your Hub will briefly go offline as it reboots and applies the update; most customers will experience less than one minute of downtime. This update will provide the following improvements:
_• Add support for local execution of lights connected to the Hue Bridge and many types of directly connected Zigbee and Z-Wave lights and switches. See here to learn more about local execution. _
_• Firmware updates for the most recent Samsung SmartThings Sensors _
• Increased reliability and performance for Z-Wave networks

(David) #57

The sad part about more Light DTHs (All my lights but one are Hue) going local and Smart Lighting Running local is that if you are using a Sunrise/Sunset as a trigger it is still cloud processed, unless that has changed.

I got all excited but then realized ALL of my lighting rules use Sunrise/Sunset :frowning:

(Jimmy) #58

I have one that goes from a fixed time to sunrise and it runs local. And another that is sunset -60 to sunrise +60 and runs local.

(David) #59
  1. SmartApp must be able to run locally
    Additionally, sunrise/sunset and mode changes cannot process locally. Using these as triggers for Smart Lights will prevent the automations from performing without an active internet connection. Use a different trigger, such as At a specific time, instead to ensure your automations can run locally.

I will be very happy if this article is wrong, can more confirm?

(Zach Varberg) #60

Oops, this needs to be updated. Sunrise/sunset triggers can execute locally now. There are a few other things on that page that are not completely true anymore. I’ll make a task to get it updated.