Device settings disappears when I use preferenceType: number

Developer Programs Support
1

Found an odd issue, I am working on an Edge driver and wanted a setting to be able to be a decimal value. I believe the way to do that is preferenceType: number in the profile.

Every time I change it from integer to number then the “Settings” option disappears from the … menu at the top of the device page. No errors when I publish or in the logs (logcat).

ST mobile app on iOS 1.7.9.16

One of the other drivers in the package is already using the number type so I am surprised no one has complained about yet. I don’t have that device connected to my ST hub at the moment to test it.

Anyone else seen this issue or know if I might be doing something wrong?

It works like this below with integer type, but wont allow decimal input. If I change to ‘number’ the Settings menu is gone.

  - name: "tempOffsetHW"
    title: "Temperature Offset (Hardware)"
    description: "Default: 0=No Offset (°F); Set the temperature reporting offset. Refer to documentation for more details. Expert users only."
    required: false
    preferenceType: integer
    definition:
      minimum: -10.0
      maximum: 10.0
      default: 0

I also just tested with min/max as whole numbers, no decimal, sill same issue.

2

Looks good to me, but try again with default: 1.0 and again with a shorter (one, two words) description.

Who knows…?

1 Like
3

I figured out if I change the name then it works, but if I change it back to the name I had it when it was originally an integer it goes back to not working. So must be something cached with the type breaking it, going to try removing the device and adding it back again with the original name.

4

Something cached or a duplicate entry in your profile. I had it once when I copy and pasted an entry from temperature to humidity.

You could also try the name tempHWOffset, because tempOffset (and humidityOffset) is reserved for an explicit default (try it!) and who knows how the parser works…

2 Likes
5

Deleting the device and adding it back again did the trick. Now its working using the original name I set it up with and type number now.

1 Like
6

That happens with custom capabilities too, if you create a capability with an attribute of a certain type and then decide to change the type it will break and you better create a new capability (or a new attribute).

2 Likes
7

I everyone. I tried to replicate the first issue of changing a preference’s data type which made the “Settings” option disappear, but I was unsuccessful. In case it happens again, please report it before changing anything so we can investigate it further.

About this comment, @mocelet:

Can you elaborate on what “it will break” means?
We got another report about the driver not “syncing” with the latest version of a custom capability (new attribute/commands, etc. meaning we get an error in the logs when trying to use the new config in our driver) and, here I shared the feedback from the engineering team to clarify some things about this behavior:

8

Unfortunately I can’t because I don’t remember the details, but I’m familiar with things not working or displaying as expected when you keep the name but change the type.

When I make a mistake in an attribute type of a custom capability (I try to stay away from them to be honest because testing changes can take some time), instead of trying to change the type I just create a new attribute or a new command with a new name and the correct type.