Enhancement Request: Device Notes

Posted on
Sun Oct 07, 2007 8:34 pm
nsosnicki offline
Posts: 168
Joined: Nov 14, 2004
Location: Boston, MA, US

Enhancement Request: Device Notes

Matt, I'd love a way to include additional notes about each device. Free form text, maybe 150 characters or so.

My purpose would be for equipment inventory info (service date, order number, etc.) but I imagine it would be useful for others also.

Posted on
Sun Oct 07, 2007 10:35 pm
matt (support) offline
Site Admin
User avatar
Posts: 21417
Joined: Jan 27, 2003
Location: Texas

Re: Enhancement Request: Device Notes

How about the Device Description edit field (inside the Device dialog)?

Regards,
Matt

Posted on
Sun Oct 07, 2007 11:06 pm
gregjsmith offline
Posts: 946
Joined: Apr 01, 2003
Location: Rio Rancho, NM

(No subject)

How about making the description field a little larger or resizable?

Posted on
Mon Oct 08, 2007 11:30 am
macpro offline
User avatar
Posts: 765
Joined: Dec 29, 2005
Location: Third byte on the right

(No subject)

How about adding another field to the devices to group devices together?
(I'm abusing the Description field for this at the moment.)

Posted on
Mon Oct 08, 2007 1:21 pm
nsosnicki offline
Posts: 168
Joined: Nov 14, 2004
Location: Boston, MA, US

(No subject)

If the description field display was larger (so you could see say 3-4 lines at a time) that would work for this purpose.

However, like Macpro I also use the device description field for creating device groups. So without adding a new field, I am kind of back where I started.

I am currently using a spreadsheet which is fine solution, so in the grand scheme of things (link management, native thermostat controls, "real" group functionality, etc.), this is way at the bottom.

Posted on
Wed Nov 21, 2007 3:57 pm
dduff617 offline
Posts: 661
Joined: Jul 05, 2006
Location: Massachusetts, USA

more metadata ideas

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.

Posted on
Wed Nov 21, 2007 11:26 pm
matt (support) offline
Site Admin
User avatar
Posts: 21417
Joined: Jan 27, 2003
Location: Texas

Re: more metadata ideas

Thanks for the great feedback and suggestions. This won't be making it into 2.5, but I do like the idea of providing more Device meta data capability and the ability to target actions based on that meta data.

Regards,
Matt

Posted on
Sat Dec 08, 2007 4:16 pm
dduff617 offline
Posts: 661
Joined: Jul 05, 2006
Location: Massachusetts, USA

another suggestion for useful metadata

here's another piece of metadata that i should have thought before - it should be obvious to anyone who's ever spent much time installing:

provide the ability to annotate each device with what circuit breaker it is on.

Posted on
Wed Dec 12, 2007 3:31 pm
jdlatimer offline
Posts: 25
Joined: May 05, 2007
Location: Winter Haven, Florida

Edit Device

Matt,

Will setting "Default ON level" and "Default ramp rate" in the Device Edit function (for SwitchLinc V2 dimmers) be upcoming?

I appreciate the software you and your team created; and your quick response to support issues.

I'm currently running off your software:

5 - X10 Motion Detectors
1 - X10 Relay for my garage door opener
8 - LampLincs
4 - ApplianceLincs
25 - SwitchLincs
6 - PalmPad Remotes
1 - EZRain Irrigation Controller

and countless Action Groups, Time/Date Actions and Trigger Actions... Even my wife love the automation.

Indigo, Good Stuff!

Jeff

Posted on
Wed Dec 12, 2007 7:22 pm
matt (support) offline
Site Admin
User avatar
Posts: 21417
Joined: Jan 27, 2003
Location: Texas

Re: Edit Device

Hi Jeff,

The next public beta of 3.0 (coming soon!) will support using Indigo to send Insteon group/scene commands, where multiple modules can be commanded to come on at once with varying ramp rates to specific brightness levels.

Indigo will not be able to support remotely programming of the default ON level or ramp rates in the current SwitchLincs. Their firmwares do not support that capability -- you have to program those settings at the switch itself. Indigo will be able to set those default values to the current KeypadLincs and hopefully to future versions of the SwitchLincs. Unfortunately, the firmware for the switches is not field upgradeable.

Note that are two totally separate features though. All Insteon SwitchLincs will support the new Indigo controlled group/scene commands.

Regards,
Matt

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 6 guests