Recent Tile Bugs (2.14.0)

Apps & Clients iOS
1

tl;dr

We are confident that the recent tile-related bugs have been fixed, and a production deploy went out this morning (Feb. 5, 2018).

Tile Bugs

Recently, there have been app crashes, “Something’s Wrong” messages popping up, and a series of visual bugs. These bugs are all related and the solution to the crashes caused the visual bugs. For reference, here are a few of the threads that I’ve been watching.

History of the Tiles framework

To help understand how such a widespread series of bugs happened, it’s important to understand the history of the Tiles framework. In the early Kickstarter days, we built Tiles to be flexible and extendable above all else. We knew the framework would need to change a lot and that these changes would have to happen quickly. Given the size and complexity of the platform we were building, the number of developers we had building it, and the variety of devices we had to support, we built the most flexible framework that we could. This allowed mobile developers to make changes to a DeviceType Handler and have those changes immediately reflected in the JSON they were working with. This cut out the need for a cloud developer to change code, and more importantly, removed the need for a deployment.

With a flexible Tiles framework in place, we started building proof of concepts and features. These features were built with convention over configuration, and as more features were added, conventions changed. As years passed and hundreds of iterations happened, certain pieces of Tiles would be changed, repurposed, or deprecated, but rarely removed. This ultimately lead to a lot of bloated and brittle code. Small changes in one spot could cause bugs in seemingly unrelated places. This is, in my opinion, a direct result of our early startup days where we were moving so fast that we couldn’t afford to take the time to harden this piece of the platform. Over time, the iterations slowed and the framework had mostly matured so we started planning where we wanted to take the Tiles framework and how to clean it up.

Direction of the Tiles framework

The next version of Tiles will be driven by capabilities, meaning some devices won’t even need to define Tiles. Some devices won’t even need a DeviceType Handler. A large percentage of DeviceType Handlers have identical tile definitions. This is a direct result of years of refinement and working toward a more consistent UI. Unfortunately, it’s also a result of a lot of copy/paste which makes supporting and updating DeviceType Handlers really difficult.

What caused all those bugs?

Rather than changing the massively complex Tiles framework, we added an adapter layer on top of it that can handle generating capability-based Tiles if the DeviceType Handler does not supply them. In order to do this, we built strongly-typed Tile definitions so that we could accurately generate Tiles when we needed to. The first Tiles to go through this layer were Scenes when they were introduced. It was a new feature and therefore a low-risk introduction to this layer. After that, we started passing SmartApp and Routine Tiles through since they are less complex than device Tiles. Slowly and methodically, we worked our way up to devices.

For the most part, the adapter layer worked well with device tiles. Nothing major came out of our testing, but when the change made it to the App Store builds, we started seeing a lot of crashes and “Something’s wrong” messages. These were a result of errors while parsing Tiles defined in custom DeviceType Handlers. The first iteration of the adapter layer was meant to be a straight pass-through with no changes to the data, but constraining types inherently changed invalid data. For example, strings were no longer being allowed in fields that are meant to be numbers (which is what caused this issue).

We were able to isolate most of the errors and made changes to the parsing logic in this adapter layer in order to stop the crashes. We did this knowing that it could cause visual oddities in the app, but would ultimately stop the crashes. It worked, but caused some weird rendering issues.

We have been working very hard over the weekend and I’m confident that we fixed most, if not all of the Tile-related bugs that were introduced in version 2.14.0. We were able to fix these bugs because they were ultimately cloud issues and not mobile issues. We deployed these changes to production this morning (Feb 5).

How will we prevent this in the future?

This is the topic of the week. We have a lot of thoughts about this, and we’ll be meeting to discuss them in detail. This will greatly inform how we move forward.

Thank you

This community is amazing. Several of you found workarounds to the crashes before we could even get the fix to production. You pointed out a lot of rendering issues that helped us isolate and verify fixes for. Your discussions are what make me confident that most, if not all of the bugs will be fixed with our next deployment. Thank you.

23 Likes
2

Thank you for providing this explanation. We are so good in here at second-guessing reasons for problems and typically getting it wrong! We don’t usually get a full explanation like this and I for one appreciate it.

5 Likes
3

Thanks a lot!, not so much for fixing it (of course that’s the main goal) but mostly for this communication and the information and insight.

Many big problems actually become small annoyances once you understand whats happening and know that there is people working to fix it and the fix will eventually come. Also good to get the message across about the huge complexity and size of such a flexible a platform like this one…

I see a lot of “how did this pass QA?” or “do you guys even test before releasing” or “this is a firmware problem, downgrade my hub now!” and even “this is very easy to fix, why haven’t you done it?”… well, when you don’t have a clue of whats happening its easy jump on these kind of questions, reality is things are not so simple…

Kudos for the communication! keep at it…

5 Likes
4

@steve_vlaminck -

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 :blush:)

Thanks!
Barry

3 Likes
5

Ooops - one more major inconsistency between iOS and Android thermostat multiAttributeTile:

  • iOS always displays the little “degrees” circle ( ° ) following temperatures in both the setpoint display between the up and down arrows, and in the bottom center text (“Heating to 69.0°”). Android simply does not display that symbol at all.

IMHO, both should display it for consistency. Since there is no way to specify whether or not to display it (I can’t provide android with the string “69.0°” as a setpoint).

Thanks again for your consideration…

6

Thank you for a very thorough explanation and making sure to get those issues resolved as quickly as possible (on a related note – you guys really seem to like to deploy changes on Fridays…).

Since it is my understanding that tiles are getting worked on, can I ask for a feature enhancement I asked for a couple of years ago again? Being able to add a printf-style formatting string for numerical tiles would be wonderful. This would allow for consistent formatting and remove the need to specify string tiles in order to achieve this instead.

3 Likes
7

Yes, since this UI topic is getting some attention at them moment, I’d like to join in asking that the inconsistencies between the SmartThings mobile app UI on different platforms be resolved.

The differences in the way text is rendered (size, all caps vs lower or mixed-case) and the way custom icons are displayed is particularly maddening. In fact, I see a lot of variations between different screenshots of Android users, so it doesn’t seem that the UI on Android is consistent across different mobile devices.

Having had some experience working with improving community-created device handlers, I can see how it would be a daunting and maddening experience trying to develop more professional SmartApp solutions.

2 Likes
8

As of 1:30pm EST today, it appears that ALL of the described fixes have been reverted to the broken mode we experienced over the weekend.

9

And perhaps coincidentally, the SmartThings Cloud <–> Ecobee Cloud is suffering constant connection timeouts…

10

What about all of the tile rendering issue that remain on iOS?? When will a fix be available for that?

11

It was available earlier today but apparently things have been reverted back to the broken version again… :scream:

1 Like
12

At 11:15am CST we rolled back the deploy, and redeployed at 2:00pm CST.

2 Likes
13

was the rollback possibly tied to the ADT outage?

14

@steve_vlaminck -

To add on what Barry (@storageanarchy) already told, I will attach some pictures of the same problems.

On the following pictures, we can clearly see how the declaration of a tile acts on iOS vs on Android

rectangle_iOS
We see the circle being stretched and the text overlaping the icon.

rectangle_Android
We see a perfect circle and the icon being on the top of the text.

text_traillingZero_iOS
We see the oversized text and the non-trailling zero which I cannot make appear

text_traillingZero_Android
text_traillingZero_Android.PNG518×512 46.4 KB

We see the text (which I find a bit small, but not too bad) and the trailling zero

There’s no way I can make a deviceHandler that works on both devices this way

15

Has anyone heard any updates on this? i’m experiencing the exact same issues with a device handler for a Rheem hot water heater with the eco net wireless connection. I can make the code work well in Android, but several display issues in IOS.

1 Like