Add an optional closure parameter to input(...) for narrowing

[WesMC]

The input(...) facility for selecting devices (typically by capability) would benefit from a new optional closure parameter that reduces the number of items that would otherwise be presented to a client.

Example 1 - Solicit Switches Constrained to one Room

ArrayList<LinkedHashMap> rooms = app.getRooms() 
List<Map<Integer, String>> roomPicklist = rooms.sort{ it.name }.collect{ [(it.id): it.name] }
input(
  name: 'roomId',
  type: 'enum',
  title: 'Select one room',
  submitOnChange: true,
  required: true,
  multiple: false,
  options: roomPicklist
)
input(
  name: 'devices',
  type: 'capability.switch',
  title: " ... "
  submitOnChange: true,
  required: true,
  multiple: true,
  closure: { it.getRoomId() == settings.roomId}
)

Example 2 - Solicit Switches Constrained on a Device Type Substring

input(
  name: 'devices',
  type: 'capability.switch',
  title: " ... "
  submitOnChange: true,
  required: true,
  multiple: true,
  closure: { ! it.type.contains("Lutron") }  // Assumes devices will eventually know their type.
)

See also the discussion in Are APIs available to Custom App Developers for leveraging Rooms and the Devices therein?

[bravenel]

I'm not able to tell exactly what you're wanting to do that can't already be done, at least with respect to devices in rooms. Could you explain what you want that you can't do?

[WesMC]

Currently ...

1. input(...) cannot present devices that have a capability AND are in a specific room(s).
2. input(...) cannot present devices that have a capability AND satisfy some device type constraint (e.g., includes the string 'Lutron', 'zwave', ...).

A closure parameter would allow custom app developers to narrow a list of initial devices (identified by capability or whatever) BEFORE they are presented to a client .

The closure would be constrained to using properties/methods available on the devices.

The advantage of a closure is that it would support relatively arbitrary narrowing - e.g., devices in a specific room, with a specific substring in the device type field, both, etc.

[garyjmilne]

As Wes said we are not able to have users pick devices via Input from a list that is filtered to only devices in a specified room.

However, I noticed tonight that in Room Lighting that a user picks a room and a list is generated containing the appropriate device list.

My guess is you are able to do this because built in apps are trusted and can see all devices without the need for user authorization first. Because you can see all devices, you can use the room attribute to create a filtered list.

What we are asking for is the ability to specify a room name as a filter to the device picker dialog and be able to provide similar capabilities to the built in apps.

This would be very helpful for a project I’m working on.

Gary.