I added it as a supported parameter to input in the docs, but a full treatment of what defaultValue supports and under what situations will be part of a larger preferences docs expansion/rewrite.
@Jim here’s another bug - this one with SmartApps:
When using a dynamic variable for input type “time”, if I specify the input qualifier “type” it won’t remember the value that entered by the user.
So e.g.
Case 1:
input "userStartTimeA${i}", "time", title: "Start Time", required: false
Works fine…
Case 2:
Now if I add the qualifier “name” and “type” to the input variables
input name: "userStartTimeA${i}", type: "time", title: "Start Time", required: false
Now it doesn’t work, it won’t remember the value that was inputs the next time I open the SmartApp (iOS, not tried Android yet).
Case 3:
So if I’m using input qualifiers I need to use something like the below to get it to work:
input name: "userStartTimeA${i}", type: "time", title: "Start Time", required: false, defaultValue: settings."userStartTimeA${i}"
This is nuts! Spent the better half of the day debugging this why the input type “time” wasn’t working when I had put qualifiers in.
Is this the expected behavior? What’s the right way to handle this?
tagging @slagle and @jody.albritton to track this issue FYI.
@Jim any update on this? It’s causing unnecessary headache while coding. I need to keep reminding myself NOT to use attributes and it’s just an added frustration debugging it each time.
@Jim any update on this? Ran into it and wasted an hour trying to debug it to realize it’s been a long standing issue.
It’s been almost 3/4th of a year now since it’s been reported.
A reminder:
This doesn’t work:
input name: “externalLockNotify${lock}”, title: “Notify on Lock”, type: “bool”, required: false, submitOnChange: true
and this does:
input “externalLockNotify${lock}”, “bool”, title: “Notify on Lock”, required: false, submitOnChange: true
The only difference being using the “tags” to qualify the inputs name and type
@slagle do you want me to submit a ticket for this?
@vlad @kleneau @slagle I would like to bring this to ST’s attention please, this is another case of about to blow up in your face issues. It’s been almost a year since I reported it. Almost EVERY app I had is using dynamic variables and things are getting VERY sticky with this issue. It’s a very fundamental issue.
This doesn’t work:
input name: “externalLockNotify${lock}”, title: “Notify on Lock”, type: “bool”, required: false, submitOnChange: true
and this does:
input “externalLockNotify${lock}”, “bool”, title: “Notify on Lock”, required: false, submitOnChange: true
The only difference being using the “tags” to qualify the inputs name and type
This is impact not just bool but all types of inputs. Can someone please look into this, if you want me to submit a ticket let me know.
EDIT: If the inputs are NOT in the order name, type then it doesn’t work. If you specify the tags then also it doesn’t work.
I’m bring this back up because it’s beginning to show some very unpredictable behavior when using the name tags, the values aren’t being remembered, submitOnChange isn’t working etc. I don’t understand why adding the tags name and type cause it to break??
Try this as a work around for now. Eng is looking into it.
input name: "externalLockNotify${lock}".toString(), title: "Notify on Lock", type: "bool", required: false, submitOnChange: true
Long story short, there is an issue with passing a GString (default) here. So casting it to a string should work.
Thanks for looking into it.
So it’s not a “tag” issue? ie. When you specify name: and type: it doesn’t work but when you don’t specify it (and just put them in the right order), it works. Curious since wouldn’t it be using GString when no tags are specified?
Well whatever you did it stopped working EVEN without the tags now on Android. Still works on iOS, but Android is dead.
I’m so DAMN frustrated, this is working on iOS but doesn’t work on Android anymore:
input “upper${rule.index}”, “number”, title: “If is below (%)”, description: “1 to 100”, required: true, range: “1…100”, submitOnChange: true
EVEN this doesn’t work on Android:
input “upper${rule.index}”.toString(), “number”, title: “If is below (%)”, description: “1 to 100”, required: true, range: “1…100”, submitOnChange: true
It won’t remember the settings on Android. What did you guys do?
So here is the bug in the ST platform if
rule.index = now()
The above code doesn’t work on Android but works on iOS
if:
rule.index = now() as String
It works on iOS and Android.
Now this is beyond me
The reason that input "upper${rule.index}" works and input name: "upper${rule.index}" doesn’t is that the first variant implicitly casts the value to a String since that’s the type of the first parameter:
def input(String name, String type, Map args=[:])
The second variant just accepts name-value pairs and doesn’t perform that conversion to the GString on any of them, including the name property. We will implement a fix to that problem.
I’m not able to reproduce the rule.index = now() problem on iOS or Android. I can’t think of any reason there would be a difference between casting it to a String or not if it is used in a GString like "upper${rule.index}", but I’m not sure where it is being set and how it is being stored from one page rendering to the next, so that the value is always the same. We’d need a more complete example to look further.
I’ll send you the full code to replicate the issue.