Questions about a dynamic inputs

🚧 Developers
1

I have a dynamic page in an app that lets me choose devices to integrate with the app's child devices based on capability. It looks like this:
dynamicPage(name: "editMapPage", title: "") {
section("< h1>${currDevice.label}") {
paragraph paragraphText
capList.each { cap ->
input "integrate:$currDevice.deviceNetworkId:$cap", "${capabilityMap[cap]}", title: "$cap devices to integrate", required: false, multiple: true, submitOnChange: true
}
}
}

capList is a list of capabilities the child device has.

I am able to call commands on the selected devices using:
settings["integrate:$currDevice.deviceNetworkId:$cap"].< command name>()

This all works fine.

However, when I try to subscribe to the devices using:
subscribe(settings["integrate:$currDevice.deviceNetworkId:$cap"], integrationHandler)
Nothing happens. I do not get an error nor does the subscription appear on the application's status page. Only when I add an attribute to subscribe to does it actually subscribe.
subscribe(settings["integrate:$currDevice.deviceNetworkId:$cap"], attribute, integrationHandler)

Is there a way to subscribe to every event from the device without setting up a bunch of subscriptions for each attribute? I can set up a subscription for each attribute but I am concerned about overhead.

On a separate but related question, is there a way to remove unwanted devices from settings["integrate:$currDevice.deviceNetworkId:$cap"]? I've seen the Amazon Alexa app do that for unsupported devices. I have tried by building a new list minus the unwanted devices calling updateSetting(..., newList) but the unwanted devices remain in the list.

Also, is there a way to iterate through the application's settings? I would like to set up a clean-up routine when child devices are deleted.

Thanks in advance for any help.

Regards,
Greg

2

There is no overhead. Even when you subscribe to multiple capabilities, you end up with multiple subscriptions. A subscription is simply a flag in the database, with a link to the handler -- it's entirely passive.

Sure, settings is a map. So

settings.each {k,v -> 
   log.debug "it.name=$k, it.value=$v"
}

Each element is a key:value pair, with the setting name and its value.

3

@bravenel - Thank you so much. I tried iterating settings similar to that but clearly I didn't get it right. Your code works like a charm.

Good to know about the subscriptions. I won't worry about it then.

Now I just need to know how to remove/unselect unwanted devices from a "capability.xxx" input since there doesn't seem to be a way to apply a filter to the input selection.

Greg

4

How about just not selecting them in the first place?

5

I suppose the word "unwanted" has the wrong connotation. It's more "devices that won't work right". I already handle the possibility that someone could have chosen one by iterating the device list and skipping the processing of devices it can't handle correctly.

I shall do what I now see the Amazon Alexa App does. Disclose it up front:
" If you include a device that isn't compatible with Alexa it will just be ignored and not sent to Alexa."

6

I have confirmed that the Google Home app does in fact remove unsupported devices when you select one. However, in my test the app started throwing 'unable to convert null to bigdecimal' errors in the log file when that happened until I went back in to the app, brought up the selection (now showing the unsupported devices unselected) and simply clicked update, then done.
If you are unable to recreate this, I can try and give you the line number of the error.