SmartThings Community

Security Issue with a Fifteen Exterior Door Church

If you’re using my device handler, the code is somewhat complex and there’s probably some contact related code that will break the handler if changed so I recommend changing one of the other capabilities in the DTH, like Water Sensor.

Replace “Water Sensor” with “Lock”.

Replace “waterSensor” with “lock”.

Replace “wet” with “unlocked”

Replace “dry” with “locked”

Add lines below like @tgauchat suggested:

void lock() { }

void unlock() { }
1 Like

Yeah, I’m stuck…

I’m pretty sure I got all the substitutions all set (actually I created new lines to account for Lock, lock, locked, and unlocked; didn’t touch water, wet, dry, etc.) . In both the SmartThings app and ActionTiles I’m able to select “lock” from the list of choices when configuring. Furthermore, they both have appropriate status text and icons. However, ActionTiles does change the state from ‘locked’ to 'unlocked and visa versa when you bump the tile. I am lost as to where I should put the “void lock() { }” and “void unlock() { }” lines. I know it’s doesn’t matter in my case, I can just set “Tile Security” to “View Only”, but I’m a curious guy. Point me in the right direction?

Again, thank you guys for all the help, outstanding!

Null lock & unlock methods are not sufficient.

You need to add those methods and include a sendEvent(...) of the current state of the Lock to tell ActionTiles to reset the state of the Thing.

Not at PC at moment, but I might be able to provide code snip later.

So you’ve tested that physically opening and closing the contact causes the device to change state in the SmartThings mobile app as expected?

It sounds like ActionTiles is immediately changing the tile based on the assumption that it worked instead of waiting for the device to create the event which is something it shouldn’t be doing.

I’m not sure how often ActionTiles refreshes the screen, but it’s possible that ActionTiles changed it temporarily and it would have switched back to the correct state as soon as the screen refreshed.

If that’s not the case you could probably force it to change back to the correct state by creating a duplicate event of the current state in the lock and unlock commands, but that shouldn’t be necessary.

If it’s working as expected in “View Only”, leave it like that and don’t worry about it.

Sorry, no. Should have mentioned that the hub is sitting at my home until I get it’s permanent place at the church settled. The only GoControl contact sensor I have is permanently mounted on one of the doors; it’s a conundrum. I have a temporary place to put the hub for testing, which was not possible today. I’ll actually fully test the SmartThings mobile app tomorrow. So, hopefully the lines of code I put in are correct.

Okay, thanks. I’ll update after I fully test it tomorrow.

While off Topic, this is a great observation that’s worth a little discussion…

The SmartThings App actually behaves exactly in this manner (ie, immediately changing the Tile State when tapped rather than waiting for the Thing and SmartThings Cloud infrastructure to report/confirm it’s new State)… with one difference in some DTHs:

It is not done universally or consistently (but still pretty common): Many SmartThing DTHs have hardcoded a transitional State that is local to the UI only.

Easiest to just give an example:

Tapping an Unlocked Lock in SmartThings App transitions the Tile immediately to “Locking”, rather than “Locked”. That latter state is eventually reached when the physical Lock sends its updated State to the SmartThings Cloud (vis the Hub).

99% of the time, the transitional state is so momentary, the user never notices it, especially for Switches that say “Turning On” or “Turning Off”. Furthermore, these transitional states are not documented as valid in the SmartThings Developer API / Capabilities except for some specific types like Garage Door (Opening, Closing).

So ActionTiles chose not to implement transitional states unless they are in the official Capability Definition, due to (a) the minimal proportionate value of this, and (b) the overhead at the front end of deciding how long to leave Tiles in a transitional state before having to determine and set to the genuine state. That’s non-trivial complexity.

(I don’t actually know offhand how long the SmartThings App will stall on a transitional State. This is important, because there has to be a predictable result when the user taps a Tile that is in a transitional State: e.g., if Tile says “Locking” should tapping send another “lock” Command attempt, or should it send “unlock”, or neither?)

In ActionTiles, we have implemented the transitional mode for Garage Door and perhaps we will consider it for certain critical Thing types that take time to transition, like Lock, in the future.

Back to this Topic:

The solution I proposed is to put the obligation in the DTH to respond immediately with a sendEvent asserting the accurate closed/open (ahem; locked/unlocked) state, by leveraging the ability to do this with only a couple lines of code in the fake Command methods.

Fun stuff! :slight_smile:

That’s not correct. The default behavior of the SmartThings App is to display no visual feedback when the tile is tapped.

The optional “nextState” attribute has to be specified in order for it to immediately change to another state.

You’re correct that many DTHs use that attribute and they also use transitional states and in those cases the developer has already decided how the tile should act when tapped while in transition.

I agree that trying to implement custom transitional states for each capability isn’t worth it, but using the same generic transitional state for all tiles wouldn’t be difficult.

When a tile is tapped while in transition you can reset it to the device’s current attribute value.

It’s not a perfect solution, but it’s better than making the assumption that the command was successful.

Here’s an example that demonstrates why I think the assumption ActionTiles makes is a big problem:

A user locks a door through ActionTiles and the status changes to locked so they go to bed thinking the door is locked. The user wakes up and discovers that there was a problem with the lock and they slept all night with an unlocked door.

A generic transitional state like a spinning circle would have prevented that from happening because when the tile got stuck the user would have investigated and seen that the door was still unlocked.

You can run into the same problem with SmartThings, but a developer can write the DTH in a way that prevents it. There’s nothing a developer can to do prevent that problem from happening in ActionTiles.

Since this isn’t a real device your suggestion would work, but this device can’t perform actions so the simplest solution is to mark it “View Only”.

1 Like

You’re technically right; but I have yet to see a DTH written without a “nextState:” value; and there’s nothing in the “standards” that say the nextState “should” always be a transitional state; so it is not uncommon for Devs to code the expected final state as the nextState (i.e., off directly to on).

I completely agree that this example demonstrates a valid concern / potential issue.

I sorta understand what you are trying to say, but I need to clarify a couple things:

  1. ActionTiles is not a “Development Platform” (unlike SmartThings). So talking about “developers” in this context is meaningless confusing to me.

  2. If transitional states are considered a priority issue by our Customers ( then it is solely our (ActionTiles’s) choice as to whether, how, and when to implement it.

  • But… As noted in this specific Topic, SmartThings DTH developers can implement a workaround by coding an immediate "sendEvent()" in the actual Command methods. I don’t claim this is optimal, but if an ActionTiles customer currently has a particularly critical or sensitive Thing (e.g, a Lock), they could use this workaround as an option, until ActionTiles implements transitional states in the UI, if ever.


I super appreciate the thoughts you have shared @krlaframboise; it gives @625alex and I some helpful perspective.

We have a policy to avoid extensive discussions about ActionTiles in the SmartThings forum or on Facebook (etc.), so this is where we drop off.

Anyone with thoughts, ideas, or concerns about this are encouraged to contact:

Based on the interest level, we usually follow-up with open discussion Topics in our own Feedback Forum, which will then automatically track questions, Votes, refinement ideas, and any/all progress on the issue. We really value the feedback that our Customers share to our official Forum at

Thanks again!

The first 3 switch examples in the tiles section of the documentation don’t include the “nextState” attribute and if you look at the Siren DTHs written by SmartThings you’ll see that they don’t use “nextState” either.

I was referring to developers in the same context that you are in your quote below…

Creating an event from a command will make SmartThings think the device is online even if it’s not so that’s not a viable workaround, but it’s a moot point for the DTH that started this discussion because he can mark the device “View Only” in ActionTiles.

I originally stated that the behavior he was seeing was an issue with ActionTiles and had no intention on having a discussion about it, but you tried to pass it off as being the exact same behavior as SmartThings and I’ve clearly shown that it’s not.

You even confirmed that by stating “I completely agree that this example demonstrates a valid concern / potential issue.”.

I agree that further discussions about how big of an issue that is and whether or not it should be fixed should be done in the ActionTiles forum.

Yeah, maybe I’m not so curious now. :frowning:


As a side note now. The lines I added did work. Didn’t work at first until I notices the defaults in the mobile app settings (also in the DTH, or because of the DTH). “Contact” is the default Status Attribute, and even though I set that to “lock”, I had to set the Unlocked Event as, and Locked Event as contact.closed. After that, the SmartThings app behaved as desired and the ActionTiles app worked exactly as I needed using the Security Setting as “View Only”. Both displayed the text locked and unlocked with appropriate icons. Neither one will change when tapped.


Here’s an update…
Managed to finally place the hub about three weeks ago, It’s not where I originally diagrammed to be, but it’s located just down the hall about 20 feet from original. In place of the hub, I put in an Aeotec Range Extender 6. I’ve only put in two sensors on two of the classroom doors. Unfortunately my Parkinson’s has been getting worse and it takes most of a day to get one completed. I don’t want to fail getting one done and have a door left open for the night, so I’ve been pacing myself.

I also put in a GE light switch in the new construction hallway wall. Unfortunately, they used a metal box and operation was sub-par. So, taking some guidance from other posts here on this forum concerning antenna extending, i opened up the GE switch and extended the antenna.

A metal faced switch in a metal box does not pass much signal.

Two forked security screws in opposite corners to take the the metal front off.

Two more screws to open the plastic box and you’ll find the antenna on top.

Scrape the coating off the end of the antenna, attach the extending wire, reassemble, snake the wire (6 and 3/16 inches past the metal) down a hole outside the metal box, mount it, and a Z-wave repair. Much better overall operation.