Scene Build

   I have recently decided to phase out Insteon's management software now that I have the link and scene management pretty-much working in MH. However, the way scenes were handled in HouseLinc left me wanting for an easier way in MH. Here's what I mean... if I have 2 3-way Insteon devices that are also controllable with a button on 2 keypadlincs, that's 5 devices that are each controllers and responders of the other remaining 4 devices. 5*4=20, so that's 20 SCENE_MEMBER entries:

```
    SCENE_MEMBER, dev2, dev1, 100%, 0s
    SCENE_MEMBER, dev3, dev1, 100%, 2s
    SCENE_MEMBER, dev4, dev1, 100%, 0s
    SCENE_MEMBER, dev5, dev1, 30%, 0s
    SCENE_MEMBER, dev1, dev2, 80%, 0s
    SCENE_MEMBER, dev3, dev2, 100%, 2s
    SCENE_MEMBER, dev4, dev2, 100%, 0s
    SCENE_MEMBER, dev5, dev2, 30%, 0s
    SCENE_MEMBER, dev1, dev3, 80%, 0s
    SCENE_MEMBER, dev2, dev3, 100%, 0s
    SCENE_MEMBER, dev4, dev3, 100%, 0s
    SCENE_MEMBER, dev5, dev3, 30%, 0s
    SCENE_MEMBER, dev1, dev4, 80%, 0s
    SCENE_MEMBER, dev2, dev4, 100%, 0s
    SCENE_MEMBER, dev3, dev4, 100%, 2s
    SCENE_MEMBER, dev5, dev4, 30%, 0s
    SCENE_MEMBER, dev1, dev5, 80%, 0s
    SCENE_MEMBER, dev2, dev5, 100%, 0s
    SCENE_MEMBER, dev3, dev5, 100%, 2s
    SCENE_MEMBER, dev4, dev5, 100%, 0s
```

   If you add one more device, that's 5 more entries... If you want to adjust the ramp_rate or on_level of a device in the scene, you have to make that adjustment for each controller in the scene. What about adding a motion sensor that triggers the scene? You have to keep in mind that it's not a responder, and that decreases the number, since it only needs controller entries. You have to think about all of these multiple links every time you edit the scene, and this can make it rather tedious to maintain. As such, I was shying away from using MH to establish links, since with so many permeations to keep track of, there was a high probability of a mistake that I'd have to troubleshoot later.

   HouseLinc has you name the scene, then check off controller and responder for each member of the scene - it builds the links for you. So much simpler! So, I took it upon myself to get MH to mimic this behavior over the weekend. I came up with SCENE_BUILD (a name/tag that I leave open for suggestions). To use it, pick an unique arbitrary scene name, then add all devices to it with a 1 or 0 to make it a controller, responder or both, along with the on level and ramp rate:

```
    #             name,   device, cont, resp, on_lev, ramp_rate
    SCENE_BUILD, scene1, dev1,   1,    1,    80%,    0s
    SCENE_BUILD, scene1, dev2,   1,    1,    100%,   0s
    SCENE_BUILD, scene1, dev3,   1,    1,    100%,   2s
    SCENE_BUILD, scene1, dev4,   1,    1,    100%,   0s
    SCENE_BUILD, scene1, dev5,   1,    1,    30%,    0s
    #INSTEON_ICONTROLLER, A0, scene1, All_Lights|Kitchen
```


   The nice thing is we have the exact same results of the 20-line config with a simple 5 (or 6) line config instead. What a difference! Much easier to see at a glance what this scene does, and easier to edit because of that! If you want to make it a PLM scene, just add an ICONTROLLER entry (commented in the example) with the same scene name, and it's done for you.

   All of the links are created in the Insteon.mhp file, just as it is now. However, there is one difference in my implementation. The scenes are collected through the reading of the MHT file, then once all the objects exist, all permeations of the links are found and written to the MHP file. The advantage to this is that you can place scene entries along with the definition of the devices being controlled, even if the controlling devices are defined later in the file. With the SCENE_MEMBER method, all objects must be defined above the scenes they exist in, which sometimes means the scenes have to be defined much further down the file than the devices. I like the way this allows me to keep my MHT file more organized. Thoughts?