the code is already use integer.
But, the after I look further. The decimal value is shown only when I hit refresh tile. When the temperature is updating without refresh command, the temperature value is without decimal number
Any idea ?
the code is already use integer.
But, the after I look further. The decimal value is shown only when I hit refresh tile. When the temperature is updating without refresh command, the temperature value is without decimal number
Any idea ?
SmartThings recently changed standard sensor reporting tiles to show the more accurate number, not just the integer. As @chuck_pearce said, I believe right now the only way to change the display format would be through a custom device type.
But in any case, I don’t think it changes how often the value gets reported compared to the previous format. @Tyler ?
So my ongoing Smartthings saga continues. I tried deleting all custom device types as suggested, but one (a virtual dimmer) refuses to uninstall. The error message states that it is use by a device. I eliminated every possible device and smartapp that could be using it but I still get the same error message. Has anyone been able to delete a stubborn device type that won’t go away even when it is not in use?
Meanwhile, my Android app received an upgrade yesterday (1.7.2) but it still crashes when I try to access the Things page. I closed and restarted the app, uninstalled and reinstalled the app and rebooted the hub but none of those things helped. No word yet from Support. Anyone have any ideas or suggestions?
Can you access the “My Devices” page on the Web-IDE?
If not this should fix you:
If you can access “My Devices”, then I am not sure this will help.
Correct, but when the temp value is using 1 digit behind decimal point, the reporting is more often.
For example my Aeon Labs Multisensor, it’s using 1 digit behind decimal point. So the refreshing value on device tile is more often. Because it’s read 25.2 and 25.1 is different.
Is not like my SmartSense open/close sensor that not using decimal number, so it’s only updating when the temperature change is 1 degree.
I guess I am not the only one with this problem as @625alex noted. Thank you for giving me a hand @chuck_pearce
Thank you Mike, I believe I may have figured out the issue now, it appears that the name field may be unique when generating these href menus. Not sure if this was the case prior to 1.7.0 but it now appears this is enforced. Still not working 100% but by making unique names to the menus that has at least gotten me closer. I would say that this code was likely written and working when the names were not required to be unique, essentially written supporting a bug. I am closer to believing that the issue is not with the Android release in this case but more in the fix that was put in 1.7.1-2 causing code that should never have worked in the first place to break.
Also, all credit to SmartAlarm goes to @ethayer I am just trying to resolve this issue.
Okay… I have resolved the issue. Here is what is happening:
Synopsis:
Conclusion:
I have attempted to convert the Double to an integer directly, but it retains the .0 decimal extension. I have used the following code (dirty) to resolve this: params.value.toString().replaceAll(’.0’,’’).toInteger()
There must be a better way to do this rather than going to String and back to Integer but I believe this was the ST developers method to allow passing sensor values containing decimal places and had this unintended change.
Sure you guys are getting sick of me by now…
Testing out the new changes to backgroundColors tiles with decimals. I am getting “Sorry but there is an unexpected error.” in the mobile-UI when I attempt to add options with decimals. If I use integer values I do not get the error but as soon as I use any form of decimal, I have an error thrown. Nothing appears in the web-IDE “Live Logging” console regarding the error.
If for example you take a standard valueTile with the following:
backgroundColors:[
[value: 70, color: "#153591"],
[value: 74, color: "#1e9cbb"],
[value: 76, color: "#90d2a7"],
[value: 77, color: "#44b621"],
[value: 82, color: "#f1d801"],
[value: 85, color: "#d04e00"],
[value: 87, color: "#bc2323"]
]
and modify it to
backgroundColors:[
[value: 70.00, color: "#153591"],
[value: 74.00, color: "#1e9cbb"],
[value: 76.00, color: "#90d2a7"],
[value: 77.00, color: "#44b621"],
[value: 82.00, color: "#f1d801"],
[value: 85.00, color: "#d04e00"],
[value: 87.00, color: "#bc2323"]
]
The error is thrown.
Nope! Unless everything is addressed, I’ll be more worried by an apathetic community than an engaged community!
I’ve passed along this use case to our engineering team. Just to confirm - you are running the latest (1.7.2) release on Android, correct?
Jim, that is correct. 1.7.2 updated last night.
Hi @chuck_pearce,
If the parameter is now a Double, why not using Double.intValue() to get the integer value out of it?
That would be simpler…
My 2 cents.
I will give that a shot, but when I attempted value.toInteger() it did not actually convert to an integer, perhaps Double.intValue() will function differently.
On line 116: “log.debug “roomsSetup> indiceRoom=${indiceRoom}””, are you seeing values like 1.0 and 2.0?
The issue I was seeing was when these values with the decimals are then used to reference settings or an index in an array. It looks like you do use them in that manner, try changing “def indiceRoom=params.number.intValue()” to “def indiceRoom=params.number.toString().replaceAll(’.0’,’’).toInteger()”
It is a nasty fix but the normal castings didn’t work for me.
Also, really like what you wrote there, can’t wait to get some of those vents to make use of all the features. Currently using it to average my temp sensors.
@chuck_pearce, intValue() works, but this is not the problem here.
The href menu structure is wrong somewhere, as I see a blank page before the log.debug statement.
Thnx.
@yvesracine This issue with your app is that several of your dynamic pages aren’t defined in the preferences section.
Namely:
roomsSetup, zoneSetup and scheduledSetup.
Hi @Mike_Maxwell, you were right… Back on track now, I was kind of stuck…But, now the IDE is sooooo slooow… Not, the ideal dev environment…
Thnx!!
Skip the ide, it’s way faster just to publish, open live logging and go from there. I only do devices in the IDE now, since they’re a PITA to update.
This is discussed here. I didn’t verify myself, but I think I read somewhere that they fixed that.
Do you have an ETA on the fix?
Thanks
Alex