Child SmartApp/Device Install Limits

Announcements
1

tl;dr - The platform update scheduled for the week of April 17, 2017, will include limits to the maximum number of child Devices or SmartApps (or a combination of) that SmartApps or Device Handlers may have. This limit will be a maximum of 500 children.

SmartApps and Device Handlers may themselves have child SmartApps or child Devices. For example, Smart Lighting consists of a parent SmartApp (the SmartApp you install from the marketplace), and each Lighting Automation is an instance of a child SmartApp. Every different Lighting Automation you create in Smart Lighting is creating a new instance of the child SmartApp.

Similarly, SmartApps may create child Devices; this is a common pattern used for LAN- or Cloud-Connected Devices, where the Connect or Service Manager SmartApp discovers and creates the child devices. The new Composite Devices feature allows Device Handlers to spawn child devices as well.

The next platform update will introduce a limit on the number of children each installed SmartApp or Device Handler may have. These limits will be put in place to prevent scenarios where a rogue SmartApp or Device Handler creates an unbounded number of children, causing a poor user experience and unnecessary platform strain.

The details follow.

What

Each installed SmartApp will be limited to having a combined maximum of 500 child SmartApps and Devices.

Each installed Device Handler will be limited to have a maximum of 500 child Devices.

(These limits apply to the total number of children the parent has, regardless of the specific type of the child SmartApp or Device.)

When

We will introduce this limit in the next platform deploy, currently scheduled for the week of April 17, 2017 (the exact date of the deploy is subject to change based on regular ongoing regression testing). We will follow up on this thread when the deploy is complete.

End-user impact

In the highly unlikely event that an end-user attempts to exceed the limit, for example by creating 501 Lighting Automations in Smart Lighting, an error will occur in the mobile app. Our analysis of current child installation data shows this to be an extremely unlikely scenario.

Developer impact

The limit of 500 is one that is extremely unlikely to be encountered through any non-error scenario, and thus typically does not require any coding workaround by the developer. More likely it could be reached if there is some faulty looping logic to create child SmartApps or Devices. A SizeLimitExceededException will be thrown if attempting to add more than 500 children.

If you would like to know the number of children a SmartApp or Device Handler has, you can do the following:

For a SmartApp:

def childrenCount = getChildApps().size() + getChildDevices().size()
log.debug "This installed app has $childrenCount children"

For a Device Handler:

def childrenCount = getChildDevices().size()
log.debug "This installed device has $childrenCount child devices"

Future limit adjustments

The limit of 500 is being put in place to prevent runaway SmartApps or Device Handlers that create an unbounded number of children, typically inadvertently. We will be monitoring child install data, as well as an analysis of platform performance as the number of children grow.

If our analysis shows that a further reduction to the limit is necessary to increase platform performance or reliability, the limit may be reduced in the future. Any future decrease in the limit will be communicated two weeks prior to the reduction, unless an unforeseen and severe platform performance or reliability issue necessitates an immediate reduction (this is not expected!).

Please let us know if you have any questions, thank you!

10 Likes
2

@Jim - Thanks for this information, seems reasonable. Just want to validate something.

There will be a total of 500 allowed child devices overall, not 500 devices for wemo, 500 devices for x, 500 devices for y… Right?

Same goes for SmartApps. 500 total, not 500 SmartLighting, 500 CoRE, …

Seems like limiting the children of a parent to 500 would solve the rogue app / device issue versus making it across all devices / smartapps.

Did I read this wrong?

Also, do you plan to add an exception to be caught?

3

Good question - the limit applies to each installed instance of a SmartApp or Device Handler. So, for example, Smart Lighting may have 500 Lighting Automation child apps, and an app like CoRE could also have 500 child apps per install. I’ve updated the post to try and make that clearer.

2 Likes
4

Perfect, thanks.

5

Off-topic, but …

Can anything be done to just slightly extend the 20-Seconds SmartApp execution timeout? :pray:

ActionTiles is unusual in that it subscribes to potentially hundreds of devices / capabilities. For just a few “power-users”, we are running up against the timeout limit just for simple initialization of these. Once they are authorized, there’s no further problems… until they need to add or remove a Thing.

3 Likes
6

Off-topic, Terry,

this is how webCoRE collects all info (list of capabilities, list of attributes AND their value, list of commands) about all selected devices (and it does it in usually less than 1-2 seconds for 100+ devices):

private Map listAvailableDevices(raw = false) {
    def devices = [:]
    for (devs in settings.findAll{ it.key.startsWith("dev:") }) {
        for(dev in devs.value) {
            def devId = hashId(dev.id);
            if (!devices[devId]) {
                if (raw) {
                    devices[devId] = dev
                } else {
                    devices[devId] = [n: dev.getDisplayName(), cn: dev.getCapabilities()*.name, a: dev.getSupportedAttributes().unique{ it.getName() }.collect{def x = [n: it.getName(), t: it.getDataType(), o: it.getValues()]; try {x.v = dev.currentValue(x.n);} catch(all) {}; x}, c: dev.getSupportedCommands().unique{ it.getName() }.collect{[n: it.getName(), p: it.getArguments()]}]
                }
            }
        }
    }
    return devices
}

The raw is used for different things, it returns an actual List of _DeviceWrapper_s, ignore it. But I found it much better to read in bulk and process in javascript. The hashId is a function I wrote to replace the real device Ids with md5 hashes, for safety purposes.

@tgauchat

2 Likes
7

Thanks… I passed this along to @625alex for us to consider and see if it is applicable to our “ActionTiles (Connect)” SmartApp functionality. We still need to subscribe() to device Events though…

Well… Let’s take this private or to a new Topic. … Where the heck did the “Reply As New Topic” button go?

8

I would agree, could this be extended to 30 seconds? Some times heavy device manipulations logic (e.g. turning on 20+ devices) and with the platform loaded once in a while it would time out.

2 Likes
9

Just to follow up, the update with this change has been deployed to all shards. The developer documentation has also been updated with this limit. You can find it in the Rate Limiting documentation, which was also restructured for readability.

Thanks!

2 Likes
10

@tgauchat
I assume this is old news for you by now, but since I didn’t see any other response to the question…

978Ă—363 63.2 KB

3 Likes
11

Nope… I had yet to find it.

I think minimal design has gone way too far!

2 Likes