Just to let you know guys that I have open a bug request to ST support for the following issue:
When using a number input type with a default value like this:
input(name:"testNumber", type:"number", title: "type number not working fine", defaultValue: "10")
First time you open the preference panel and press Done it will store the default value shown in the field.
Second time when you load the preference pane the text field is empy.
IF you press done here, this will erase the previous value.
Here are the log related to updated() callback
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:24 PM PDT: debug testEnum is:Red
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:24 PM PDT: debug testNumber is:null
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:24 PM PDT: debug Done button has been pressed <—Second time I opened the preference panel and press Done. I will ERASE the type num values
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:17 PM PDT: debug testEnum is:Red
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:17 PM PDT: debug testNumber is:10
4c5f1ad3-4da2-4635-80ee-6bab200ec11c 2:58:17 PM PDT: debug Done button has been pressed <—First time I opened the preference panel and press Done. I will store default values
This should show the default value if no value is set and the current value of settings.XXXX otherwise.
If you want to try here is the reduction based on simple device.
Note that it’s works fine for enum input type.
@Riley escalated the issue to developers. I’ll keep you in touch.
I worked on this with Riley. What we found is this works fine in the android app but not the iOS app for some reason. As you mentioned already we’ve got the right players involved. Updates forthcoming.
This one was already in the pipeline before the fix was dev complete. But now we are so close to a new UX that we are focusing on that. We aren’t focusing on new releases on the old UX. We are truly focussing on making the new UX right for you all. Bugs, experience, usage, etc. Plus making sure we have it in time to get through the iOS revision process. Not the answer I want to give but I can tell you… it’s fixed, the app is just not ready for public consumption yet.
Is this a joke? How can I trust you if you said a week ago (and I quote):
Lets just say, its ready on our end.
I see the same pattern in another thread where your colleague said a week ago that a certain fix would be released “today” and there’s no sign of it a week later. Makes me wonder if there’s a new corporate policy at SmartThings to mislead their customers.
We’re as transparent with the community as possible. Deadlines are missed at times. That’s the nature of software development PLUS our transparency. He is correct in which it is ready on our end. We do want version 2 of our app to be a better experience.
I don’t get you, Geko. We get faulted for not talking, and we get faulted for providing our projections. Surely, you’ve been in software development with tons of moving parts.