Why won't my (first, simplest in the world) smartapp work?!

SmartApps & Automations
1

I’ve got a couple of Hue bulbs directly connected to a V2 hub and I decided to mess around with a SmartApp for fun. Well it’s not fun anymore!
My really basic amendment to the ‘big turn off’ app works perfectly through the IDE but does nothing when I run it through iOS.
Have tried lots of things to no avail so I am asking the kind people of the Smartthings community for help.
Here’s the code. There is nothing to it. But it won’t work when deployed… Any suggestions would be very much appreciated.

definition(
name: “Dim the lights”,
namespace: “davydrop”,
author: “davydrop”,
description: “change the light level when the SmartApp is tapped or activated”,
category: “Convenience”,
iconUrl: “https://s3.amazonaws.com/smartapp-icons/Meta/light_outlet.png”,
iconX2Url: “https://s3.amazonaws.com/smartapp-icons/Meta/light_outlet@2x.png”
)

preferences{
section(“When I touch the app, change the level of…”)
input(name: “bulbs1”, type: “capability.switchLevel”, title: “Lights 1”, description: null, multiple: true, required: true, submitOnChange: true)
section(“Choose light effects…”)
input(name: “lightLevel1”, type: “number”, range: “0…99”, title: “Light level 1”, required: true, multiple: true)
}

def installed()
{
subscribe(app, appTouch)
}

def updated()
{
unsubscribe()
subscribe(app, appTouch)
}
def appTouch(evt) {
log.debug "appTouch: $evt"
def newLevel1 = (lightLevel1 as Integer)
log.debug "new value = $newLevel1"
bulbs1?.setLevel(newLevel1)
}

2

Do you get an error in Live Logging when you try to run it from the iOS app?

I don’t know that these would matter, but you shouldn’t need the submitOnChange: true for the bulbs1 input, nor the multiple: true for the integer level. It’s possible that the multiple: true for the lightLevel1 input is passing it as a map instead of a single value, but your log.debug new value should show you if that’s the case.

3

This is new to me :frowning: What do you mean “when I touch the app”? You mean simply touching the app name in the mobile will trigger this event? Like I said, “New to me”

1 Like
4

Really? I guess this is a “hidden gem”, but it’s been around forever.

Wow… It’s not in the Docs, @Jim?

It is super handy for manually kicking off a SmartApp that failed to run on schedule too! (But each such SmartApp needs to subscribe to appTouch).

1 Like
5

Yes, this was the main reason I started messing around with SmartApps. For the things I don’t want on as schedule I just wanted to hit a play button.
Anyway back to trouble shooting my app now (thanks for the suggestions).
Hopefully my next post will indicate success!

1 Like
6

Not that this helps much, but I do have a changeset in progress that adds this. We had to shift our attention but hope to get back to it soon.

1 Like
7

Just to say thanks. Made both changes and it now works. Not sure which one made the difference as I did both at the same time but the map suggestion seems very plausible.

1 Like
8

Could also use some help with a simple app (my first). If working correctly the app would continually toggle a switch every 5min. The code seems to work at first but after about a day it stops and I have to reinstall to get it started again. I haven’t written any kind of code for a very long time so I’m certain I have just missed something obvious. Any help would be greatly appreciated.

preferences {
section(“Select switches to control…”) {
input name: “switches”, type: “capability.switch”, multiple: False
}

}

def installed() {
log.debug "Installed with settings: ${settings}"
runEvery5Minutes(toggleSwitches)

}

def toggleSwitches() {
log.debug "Switching on interval"
if (switches*.currentValue(‘switch’).contains(‘on’)) {
log.debug "toggle: $switches = ${switches*.currentValue(‘switch’)}"
switches.off()
}
else if (switches*.currentValue(‘switch’).contains(‘off’)) {
log.debug "toggle: $switches = ${switches*.currentValue(‘switch’)}"
switches.on()
}
}

9

Doubt there is anything wrong with your code… Looks OK.

But the obvious thing you missed are the half-dozen or more Topics over the past month that show scheduling methods are currently unreliable. They may work very well for some Customers, or some days, and others fail most of the time or inconsistently.

There are some clever workarounds, but might not be the best use of initial learning time…

10

Bummer, I did notice a few such posts but I assumed that issue was quickly resolved given the importance of such functions. Thanks for the response.

1 Like
11

That’s funny… (Crazy laugh…). But seriously… It’s been nearly 18 months, up & down.

1 Like