[REPORTED] Input number in device-handler weird behavior

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.

Actually settings description:"10" instead of defaultValue:"10" set 10 as a place holder but never been sent to settings.

The only caveat is even you set another value let’s say 12, the field will always show 10…

Hey @CyrilPeponnet

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.

2 Likes

Thank’s for the followup :slight_smile:

1 Like

Awesome, I thought I was loosing my mind troubleshooting an update to one of my devicetypes. Thx!

1 Like

From ST support

Engineering team seems to have been able to isolate the issue and should be fixed ASAP.

2 Likes

This bug will be fixed when we release version 1.8 of the app. It is in testing and should be released fairly soon, though I can’t give you an official date.

So wait and see…

Any updates on this? How soon is soon? It’s been more than six weeks since this was reported.

Wait for 1.8 to be released.

Yep, waiting for the iOS app to be ready. Lets just say, its ready on our end…

1 Like

So it should hit the AppStore on 1/2 weeks (could be faster or longer)…

Well… I’ve just updated mobile app to version 1.7.4 (1128) released today and the bug IS STILL THERE. How do you explain this? :imp:

Cause 1.7.4 has been out for a month or two? 1.8 isn’t published yet.

Nope. 1.7.4 for iOS was released today. See the date? 7/28/2015.

My bad. Android has been at the version for a month or so, did not realize the iOS version just launched. Guess they are now out of sync.

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.

Trust me… it’s worth the wait.

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.

It is ready :slight_smile: My quote still stands. Wanting to make version 2 of the app the best we can for everyone. So thats the focus. Appreciate your feedback man :smile:

Whatever makes you feel better, man. :smile:

Listen- -
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.

:smile: