Good Day folks!
I'm hoping Thom, posde, phenigma, or anyone else who's familiar with the guts of LMCE can sanity check and provide some advice on what I'm thinking below...
I'm working on my ISY driver, and getting to the parts where it will create devices in LMCE based on what exists in the ISY. The idea is that the ISY "owns" the devices that are linked to it (Insteon for now, possibly UPB and Zwave in future versions of the driver and hardware), and it will inform LMCE about the devices and their configuration. Generally, that is easy and works presently in my driver. The way the ISY works is that there is a Java-based management console that is used to configure and administrate the system, and add and mange connected devices. The API and subscription channel are used to interact with and monitor/react to events from the ISY, for integration into Home Automation systems. Most things are fairly straight forward to implement from the LMCE point of view. There are a few devices/features I'm not quite certain as to the best way to implement them, which is why I'm asking for advice.
The first is Insteon keypads (Dimmer or relay switched). There are 6 and 8 button models; the 6 button has an 'on' and an 'off' button (which appears as one load control switch remotely), and 4 other buttons. The 8 button model has one load control button, and 7 other buttons. The other buttons can be triggers for Insteon scenes (which I'll get to next), or can be cross-linked to other switches. For example, I have a 6 button KeypadLinc in my breakfast nook, that is linked to the switches in the kitchen and family room. Now, I could create a device template for it, but I think I could simply use the generic Light Switch on/off and Light Switch dimmable templates, and use the configuration field to store the required information. Here's the part I'm not sure about. The "other" buttons are a part of the switch, but are not controlling the parent switches load (unless they are part of a scene involving the parent switch). Is is possible to create child devices of a generic light switch, and would it be a good ideal? Or should they be treated as peers and grouped or related somehow?
Insteon Scenes are my next challenge; basically, they are a pre-programmed into the various devices which comprise the scene (using a scene identifier, level, and ramp rate), and then are triggered by the scene broadcast message. The nice thing about scenes is that they happen simultaneously (all member devices respond to the broadcast message directly), and being programmed into the target devices, they work even if the automation controller goes down. Scenes triggered via the protocol have an on/off capability, and a relative dim/bright capability (in which all scene members will brighten or dim as the scene button is held, relative to their scene levels). The thing is, a scene can't be queried directly; it's just a broadcast message on the Insteon network. Scene members have to be queried directly for their status (and that's covered already in the subscription channel in the driver). So, I'm wondering if I should create a device template for an "Insteon Scene", which has a data field consisting of the members of that scene? Or would an LMCE group work? If an LMCE group would work, can I generate and modify them using LMCE events? Or should just use a generic light switch for a scene, and handle it all in my driver using the configuration field information?
The last thing I'm wondering about is the ISY concept of "folders". The ISY has a feature (not Insteon specific) that allows you to group related items (by room, by function, whatever). A device/scene/program can be assigned to only one folder. Would that capability translate directly to an LMCE group? If I were to use groups for ISY folders, are there any problems or gotchas with doing that? Can I create/modify groups using LMCE events?
The ISY also has "programs" and "variables" which are used on the controller for conditional if/then/else type events and automation. Those are all visibly exposed via API's and the subscription channel for event status updates. I'm not even looking at dealing with them right now, is this version of the driver. I'll look at those later when the driver is mature and stable for production usage, but if anyone has thoughts on those, I'd be happy to hear them!
Thanks for your time!
/Mike
