Hub Firmware Release Notes - 19.17

Expanding on what farlicimo said, you can get a similar effect with SmartLighting currently you just have to make a couple different rules. You can use turn On and set level, and then specify only run during specific times. You have to create a different rule for each different level you want to support, so it is certainly not ideal if you want a lot of variability, but that is how you could get it to run locally currently.

1 Like

@Zach_Varberg, @tpmanley its nice to see that more and more devices now runs locally.

One thing that I dont have been able to find is a DTH that works local with a secure dimmer, If this becomes available I will be able to get all my light automations to run locally

The .18 beta team also have no issues an look at what a complete cluster f**k that was.

I would have thought that after that fiasco ST would have reexamined how they conduct the f/w betas and widened the audience but reading some of the messages above it appears this has not happened. Seems such a shame as they simply never seem to learn from previous experiences, well at least from what I read on here :grinning:

Thanks, tried creating a simplified version. Is there an option to check if light is already switched on then not change level etc? Could not find any option

Not true. It blew up my hub, so they modified the development to the masses. I had to rebuild everything for 280 devices.

They did. Much more formal and thorough.

1 Like


How does SmartThings development determine which devices they will move to local execution? It seems the larger companies are being moved to local execution, such as Hue, GE, etc.

What about companies such as inovelli? I guess I’m just trying to understand the process as I would of course love if all of my dual outlet inovelli products were running locally.

Is it just a matter of the company reaching out to you all with the device type handlers that they would like to run locally on the SmartThings hub?

It was sarcasm John :grinning:

Whatever issues they did have were pretty much ignored and the update (apologies it was the version a few weeks before .18) still went live and then they has to release the previous version to fix it all.

The first I heard about this version was the email telling me it will happen so I would like to see how many people were involved in the beta and how they were selected as again it does appear that certain tings were missed which have effected people. I have come off lucky and only have one issue where my LIFX bulbs are reports as offline/unavailable yet if I clear the message I can control them without issue. No time to completely remove them (then re-add) at the moment as they are linked to apps etc. all over the place. Not even sure if that will fix it or not lol

You were the one with the hundreds of devices in the beta group?! LOL I long for the day to have that many devices…

1 Like

As I understand it, it’s not a “who makes what device” decision as much as it is a grouping of fingerprints. Most of the device handlers they are moving to local execution are what I call “blanket” device handlers. These are device handlers that can cover a few or more different devices from various manufacturers so long as their fingerprint matches the DTH. If you look at the code history for the Zigbee RGBW DTH, you’ll notice that it is actually the older OSRAM Lightify DTH that has been updated/renamed to “Zigbee RGBW”. ( This was done to accept a larger array of devices under that DTH.

So, it’s not so much SmartThings deciding what companies’ devices can run locally, it’s the device manufacturer changing their devices’ fingerprints to match a DTH that has been designated to run locally. As I understand it, SmartThings isn’t allowing any “requests” for a particular device in and of itself to run locally.

1 Like

Very helpful response. Thank you for Helping me understand the process.

@Eric_Inovelli @Core_Phx

1 Like

@Core_Phx has the basic idea. It’s not about other companies coming to us, but instead we have started with SmartThings supported DTHs that have a lot of users, and also, have fewer device specific exceptions. There are a lot of people who use more featureful DTHs for some of their color bulbs. However, the more things we start to support, the more likely we are to run into differences between manufacturers (and believe me having a well defined spec such as zigbee does not fix this issue, we deal with many many exceptions to the spec). So, we have tried to encode a “basic” zigbee RGB bulb that should work for the vast majority of bulbs, then people can decide if they are OK using a more bare bones DTH to take advantage of local processing, or if they would like to use the more featured ones but continue to execute in the cloud. Obviously long term I would love to support everything locally, but development has to start somewhere.


I have these Monoprice door/window sensors too. In order for them to process locally, you CAN’T use the Plus version (“Z-Wave Plus Door/Window Sensor”) as the type. You have to use the non-Plus version (“Z-Wave Door/Window Sensor”).

I had to figure that out because someone that wanted to break in can easily cut internet to a house before they break in. Since we’re on the topic, does anyone know why SmartThings can’t use the Plus type for Z-Wave door/window sensors? Is there any plan to add that capability so we get all the features of Z-Wave Plus?

My ST multi sensor is now giving me false notifications. About 5 times a day. And my battery is still reading100%.

That doesn’t explain why ST keeps changing the DT of my Osram RGBW lights to Zigbee RGB DT all on its own though. Luckily the RGB DT shows as a blue button in the app, whereas Osram RGBW DT is a green button. So at least I know when and which lights I have to go into IDE and change back to the right DT again. At least one or 2 lights a day have their DTH randomly changed.

Now explain how it is ST motion sensors are reporting motion in the app, but IDE shows them as offline and last activity 2 days ago?

How about how app and IDE show that when I changed the battery in ST moisture and tripped it to test, that it closed the LeakSmart valve ( as it should), but the valve never closed, shows it sounded the siren, but never did and why 1/2 my lights turned red instead of blue with the SHM leak alarm ? I didn’t realize it had not closed until I went down into the basement to just watch it and open it back up. I pressed open and nothing happened. So I pressed close and the valve closed, pressed open and it re-opened. So open and close worked fine in the app, just not when done by SHM.

How about why on with motion now only works 1/2 the time, and off when motion stops might work 10% of the time. Alexa/Google turn of XXX lights has become the most commonly heard phrase in my house.

On the rare occasion Hue lights actually do turn off with automation, they still only dim to 10% and do not turn completely off even though they show as off in ST app. Which again requires an Alexa/Google turn off XX lights, opening the Hue app or using Hue dimmer to turn them completely off.

How about explaining how it is that when I attempted a repair/replace of an offline ZW switch today it came back successfully replaced. Then immediately disappeared from the list of things in both app and IDE. When I went back and added it again as a new device it was somehow found twice, yet neither one of the new devices in the app would trigger the switch to actually turn on/off.

With having to reboot the hub daily now to get anything to work, I am thinking about just putting the hub on an old mechanical timer to turn off every morning at 4:30, turn on at 4:45 so maybe we will have lights when we get up in the morning.

The worst part is that we had family visiting from all around the country last month and they were so amazed by my house they were all going out and buying ST, Alexa, and GH for their own houses. Of course, they do it right as ST has a complete mental breakdown.

I had an issue like this when I was starting a V2 migration last weekend.

Setup my hub on Thursday to download updates and the like, when it was done I put a few devices on it just get used to unpairing and repairing to make it quicker for the real work on Saturday.

Friday night rolls around my wife and I are watching a movie not on our smartphones and we get an alert that our V2 hub is offline, thinking it might have gotten another update I wait until the move is over, don’t see that the hub is back online, so I go and power cycle it, nothing, do a longer power cycle nothing (the batteries were not in).

So I send Support a ticket. They reply the next day saying the hub requested a DELETION EVENT and that they were able to reverse it but all my things needed to be repaired. Neither my wife and I were using smartthing at all around that time and my wife never used the v2 hub at all.

Given the odd Ghost in the Machine I decided to actually send the deletion event, box it up, and return it. Then repaired everything back to my v1 hub.

So yeah odd things are happening with these hubs.

I just can’t wait for V3 so I can try again since that issue with V2 broke the WAF and she will not let me try again :frowning: I just wanted local processing of hue lights… :cry:

I noticed this towards the end of the beta and reported as a bug. @Zach_Varberg thought it was a cloud issue and logged it.

Add the app showing hub as offline, even though light’s green and it’s online in IDE to the ever growing list of upgrades.


Thanks so much for taking your time to write out such a concise explanation. Very helpful!!

Has there been a small update since 19.17? My hub now shows “last booted” date & time instead of no. of seconds online

Yes, they posted an announcement on Tuesday. Sorry, I am too sleepy to search for the post.