First, thanks for fixing these issues over the weekend…good to see us back to normal.
That said, I wonder if we can get similar attention to the following long standing UI inconsistencies between iOS and Android mobile apps (yes, I also sent these into Support@SmartThings.com just now):
Heating at vs. Heating to
Somewhere along the line, the Android multiAttributeThermostat reverted back to being inconsistent with the iOS version in this way (I sent this into support back in 2017 and it was fixed - for a while):
-
Thermostat in Heat mode
- iOS shows “Heating at XX” when thermostat operating state is “idle”, and “Heating to XX” when operating state is “heating”
- Android always says “Heating to XX” no matter “idle” or “heating”
-
Thermostat in Cool mode
- iOS shows “Cooling at XX” when thermostat operating state is “idle”, and “Cooling to XX” when operating state is “cooling”
- Android always says “Cooling to XX” no matter “idle” or “cooling”
-
Thermostat in Auto mode
- iOS shows “Heat/Cool at XX-YY” when operating state is “idle”, and “Heating to XX” or “Cooling to YY” when heating or cooling
- Oddly enough, Android shows “Automatic at XX-YY” when operating state is idle, and “Heating to XX” or “Cooling to YY”, which is almost correct, except that it says “Automatic” instead of “Heat/Cool”. Should be consistent.
Background: I have developed a custom Ecobee thermostat Suite of DTH and SmartApps that uses the above iOS behaviours to accurately display what the target heat/cool setpoint is when the operating stat is heating/cooling, and the “demand setpoint” when the thermostat is idle (the temperature at which the thermostat will actually place a demand for heat or cool). My DTH displays at least 1 digit of decimal precision for both Fahrenheit and Celsius, but since Android displays the same regardless of operating state, the display is counter-intuitive to users.
As I said, this was fixed at one point, but has since reverted.
There are several other inconsistencies between the iOS and Android versions of the thermostat multiAttributeTile, including:
-
When displaying the temperature in between the setpoint up and down arrows:
- If the setpoint is 70.0, iOS displays “70” while Android displays “70.0”
- If the setpoint is 70.5, both will consistently display “70.5”
- I would really like to control what gets displayed here, instead of any “magic rounding” being applied. Perhaps if this was changed to check the “as String” version of the supplied value, and then displaying the “.0” if provided (which won’t be there if I pass an Integer “70” but will be there if I pass a Double “70.0” value)
-
If I pass a label value of “39-60%” to a valueTile on iOS, it will properly display a circle filled with backgroundColors; on Android, it does not display the background color (or, it displays a white background, I can’t quite tell).
-
On iOS, if I provide a label for a standardTile, the text is rendered in ALL-CAPS; on Android it is rendered in the case I specify. Both should render in the specified case, IMHO – but regardless, both should be the same.
-
On iOS, if I provide an icon for a standardTile along with a label, the icon is rendered as-is and the (all caps) text is rendered on top of it; on Android, the icon is resized smaller and the text is displayed under the icon
-
Icons render in a smaller scale on Android than the same icon on iOS, even when there is no label defined.
-
Font sizes on Android and iOS are nowhere near the same; text that fits within an icon on iOS is perhaps 1.5x larger on Android.
-
On iOS, if the text displayed in a valueTile is too large to fit (as is the case on the HEMv2 device that you referenced), it is no longer shrunk to fit - it is instead rendered and clipped behind the edges of the valueTile circle. Not sure what this does on Android. Shrinking the text was great, but that disappeared somewhere over the last 2 years or so. Personally, I would like that feature back, or (better) an attribute that we could specifiy the text size (fontSize: S/M/L/XL or 1/2/3/4).
Finally, an enhancement request:
- We really need a way to specify the Z-order of tiles on tablet devices. The current approach really makes it hard to represent a tiled DTH that makes visual sense on both handheld and tablet devices.
Thank you for your consideration in getting these significant inconsistencies corrected once and for all – having said differences between platforms is really “not good” (technical term 
)
Thanks!
Barry