- Posted on
Wed Nov 21, 2007 3:57 pm
-
dduff617
offline
-
- Posts: 661
- Joined: Jul 05, 2006
- Location: Massachusetts, USA
i would suggest separate fields for describing the control and the load.
for example, sometimes it makes sense to describe an insteon device by where the switch is located (e.g. "left switch in box at top of level 2-3 stairs"). other times it makes sense to describe it in terms of the actual real-world device or circuit that is being controlled (e.g. "level 2 hallway lights"). in the latter case, i would want to see in some cases multiple devices grouped together that control the same circuit.
perhaps this is pushing it a bit far, but i would suggest the following are probably common enough to justify having them as (optional) metadata:
floor
indicates what floor the device is located on. for some houses, it might make more sense to use "areas" instead of floors.
examples:
0
1
2
Mezannine
Roof Deck
Basement
Cabana
Garage
Attic
West Wing
Guest House
switch location
examples:
top of stairs
near south entrance
right of sink
none (i.e., for lamplinc, appliancelinc, inline-linc modules)
switch position
(optional) which switch location for banks of multiple switches.
examples:
left
right
center
1
2
3
4
5
6
load description
examples:
tv room cans
bathroom floor heat
front sprinklers
office floor lamp
guest bathroom fan
basement air cleaner
dehumidifier
none (i.e., for keypadlinc not controlling a local device)
group
groups are sort of like keywords. a device could be in one or more groups. groups could be turned on/off or dimmed with a single indigo command. examples:
emergency lights
security lights
appliances
air circulation
outside lights
inside lights
basement lights
bedroom lights
what good is any of this? i.e., why is this useful?
a) when laying out floor plans, or for grouping things in web pages and such, it is often useful to group items by floor (or area). some of the standard pre-defined web pages ("basic pages" and "mini pages") could exploit this data to present logical groupings of modules instead of just a long flat list. as it stands now, i have to try to be clever by using device names to encode metadata, i.e. by putting the floor (0,1,2,3) as the first character of the name.
b) currently, i have many pairs of insteon devices where one device controls the load and the other device is just a "slave" switch in a virtual 3-way circuit. indigo gives me NO WAY currently to associate these pairs, which is kind of a pain, particularly because whenever i change the state of these devices from within indigo, i really want to always keep them "in sync". so having a way to sort by "load description" would at least group multiple devices which are used to control the same load together. a problem with this approach is that this is not a fully general solution in the case of keypads, which can potentially control several devices. hopefully this will get better when indigo gets around to grokking link among modules. then we should be able to see a particular insteon device and then see the list of controllers which are linked to it.
c) regarding groups... action groups are a step in this direction, but why why why for example, do i have to define separate action groups to turn a group of related modules ON and another action group to turn the same set of modules OFF? (and another to DIM, etc.) this creates painful maintenance bookkeeping tasks in indigo which should not be necessary and discourages me from doing more control and scripting within indigo because it just feels "wrong". i would like to see the ability to control a group as a fundamental primitive in indigo that shows up in the interface for defining actions - i.e., instead of "control light / appliance", it could just say "control light / appliance /group". in applescript, group names could be used in most places that module names are used currently. the semantics are (obviously) to act on each item in the group the same as if it were listed individually. perhaps this will be come less useful when link management arrives?
d) importantly, additional metadata like this doesn't need to get in anyone's way. much or all of it is optional (just as the "description" field now is optional). one feature, i think that would make sense would be to use the standard cocoa quasi-convention of providing a columns submenu of the view menu that allows different columns to be toggled, so for example if a particular user doesn't want to characterize what floor his modules are on, he won't even see this field in the interface.