Change of enum options between install and update of SmartApp, old values are not removed from setting

Developer Programs Writing SmartApps
1

I searched and searched for this topic, but didn’t find an answer, so I’m going to write here instead.

I am in the process of making some updates to the Ecobee (Connect) SmartApp to bring it more up to date and to start adding features into the main devicetype and SmartApp combos.

One of the changes that I was making was splitting up the dynamic settings pages into a more logical flow: authentication --> Select Thermostats --> Select Remote Sensors.

For the Remote Sensors, I only want to show the sensors related to the selected thermostats. This all works great the first time the app is invoked. However, if down the line I want to remove a thermostat I also want to remove the corresponding sensors.

Here is the problem that I’m running into. The input for the sensors selection is enum and the options are generated dynamically based on which thermostats are select. But any sensors that were previously selected the first time through remain in the enum setting even if they are not shown on the UI for the enduser.

Here are the steps:

  1. Install the Ecobee (Connect) app (copy it over or link to the IDE. You also need to create the two device types as well for Ecobee Thermostat and Ecobee Sensors)

  2. Do the OAuth login steps

  3. Select two thermostats from the list

  4. Select some remote sensors (pick at least one from each thermostat)

  5. The app should now be fully installed, it should have created two thermostats and all of your sensors

  6. Now, open the smartapp again to make changes

  7. Click next on the OAuth screen (you should still be authenticated)

  8. On the Thermostats screen, deselect one of the two thermostats (Click Next) (We’ll call this Thermostat2 for this example)

  9. On the Sensors screen you should only see sensors associated with the selected Thermostat from the previous step.

  10. Click Done

At this point, the SmartApp is able to delete the explicitly deselected Thermostat2, however, the sensors that were associated with Thermostat2 were not explicitly deselected as they were never presented to the user, so they are still in the settings variable (settings.ecobeesensors).

How can I remove these sensors from the setting variable? To me, this seems like a bug. If the options were not present on the screen to select, they should not end up in the resulting settings variable.

If you want to look at the full code, it is available in the StrykerSKS-Ecobee3 branch on the SmartThingsPublicCommunity:

GitHub repository of code

In particular, checkout sensorsPage().

Any help would be appreciated.

// StrykerSKS

2

It is sort of a bug, but more accurately it’s just “out of spec” behavior … ie., a use case that wasn’t anticipated.

settings is read-only (I’m pretty certain), but with Dynamic Pages there might be a complicated way to program around the problem.

@slagle or @jody.albritton or one of the superstar developers around here may have various alternatives or more accurate info on this situation…

3

Thanks @tgauchat, yes the settings are read-only (as I discovered both through trial-and-error, and via the documentation). I also played around a bit with the Dynamic Pages to attempt to clear the variable but wasn’t successful finding a combination that worked.

I hear you about the “out of spec” behavior as well, but given that the settings are read-only it still feels like a bug to me. Given that there is a whole section describing the behavior of dynamically created preferences in the documentation (Dynamic Preferences) this feels like something that they should have anticipated. (The main example between the example and my code is that I allow multiple selections.)

Looking forward to hearing from others on a possible workaround.

It isn’t the end-of-the world for now since it is likely a corner case (since people aren’t likely to remove a thermostat from the app very often). Plus, any residual sensors can be manually deleted by the user if needed.

// StrykerSKS

4

Settings are not read only. In fact in one of my recent posts I had to initialize some settings variables as the default are not working.

5

@Lgkahn
Exactly where in your code did you set the settings variables?, as I’ve not had any luck setting them in code in a smart app.

2 Likes
6

i set them in device types not smart apps. but same should apply… i set them in config function which gets called when adding device ie

if (settings.ReportTime == null)
settings.ReportTime = 5
if (settings.WattageChange == null)
settings.WattageChnage = 10;

7

Did you completely remove this app? If not, old settings, and old state variables, hang around. They are harmless, but they won’t go away until the app is uninstalled.

1 Like
8

Yea, this doesn’t work in smart apps, “same should apply”, true, but it doesn’t.

The only way to remove an orphaned input element in an app, is to unset them in the mobile app prior to removing the element from the page…

1 Like
9

Are you using the submitOnChange flag for your dynamic pages? If not, that’s probably your problem.

10

Nope, that’s not the issue.
You have a dynamic enum list, you select something in it.
You go back later, the dynamic list is now changed, the previously selected item is still assigned to the input.
There’s no way to clear it, reset it, null it, other than deselecting any selected items, then moving off the page, or selecting a new item, then unselecting it from the new enum set.

1 Like
11

Ok, I re-read this. (On vacation so doing this in between plans)

Does ecobee surface the sensors as individual devices through the API or are they only put up as a “sub device” of the thermostat?

12

They all end up as individual sensors within Smartthings but they are children of the smart device. From an Ecobee perspective, they belong to the Thermostat. So you have to query for the thermostat information and ask the API to also include the sensors if you want that info.

I can work around this, it just means that I now need to explicitly keep track of which sensors belong to which thermostats, then if we remove one of the thermostats then I’ll just have to programatically remove those sensors. It just would have been a lot easier (and elegant) to use the existing code that was there to remove them.

(I was tearing my hair out trying to figure out why they weren’t being removed!)

1 Like