Algorithm

Having defined the terms I prefer to use, I'd like to look a bit more at groups. A group is a collection of physical devices. It may range in size from a single device, up to the total number of devices in an installation. However, the ISY has no concept of a group; or rather, the ISY's concept of a group is transient at best, being identical to a scene. For example, consider a scene 1 which consists of device 4=80%, device 7=40%, and device 8=100%, and a scene 2 which consists of device 4=20%, device 7=100%, and device 8=55%. These two scenes apply to the identical collection of physical devices, or group. But the ISY does not recognize this or any relation between the two scenes; they are entirely independent. Nor am I suggesting that ISY needs to recognize this relationship (though perhaps in the future someone may request it). However, at least one user did request that ISY maintain the status of a scene (ref. the thread linked to in the first post), and a query (and discussion) as to the concept of scene status ensued; hence my interest and subsequent starting of this thread. At present, ISY does not maintain the status of either a group or a scene, although both can be accomplished by user programs, and examples have been posted. But it seems that it would not be difficult for ISY to maintain such status internally. It could simply maintain, for each scene/group, an internal scene variable and an internal group variable, each of which would be either True or False based on the identical criteria as used in the current user programs (and as defined in the quote at the top of this thread). This would be a convenience for the user, who could reference the status in a program something like this: If Status Scene Lower Level is On Then Some actions Else Other actions and If Status Group Lower Level is Off Then Some actions Else Other actions The first would be true when every member of the defined scene was at its exact preset level, or false otherwise; the second would be true when every member of the scene was off, or false if any member was on. Would this conveniently satisfy all the scene/group status needs expressed so far?

Thanks for the thoughts expressed so far. As some have said, it really is a matter of preference. One can adopt whichever model best suits him. But I think the concept of groups has not really been discussed. Before proceeding, it might be wise to clarify the terms, since the two models seem to differ in their interpretation. It seems to me that even in the C-Bus model, where the term group (because it is a physical group of devices which share a common level for a given scene) is used to represent a member of a scene, the scene itself sill consists of a number of members (groups in C-Bus terminology) which in most cases will be less than all existing groups, and therefore this collection of groups (let's call it a set) that the scene applies to is still a super-set of the scene. In other words, the scene is still a sub-set of the set, just as in the Dali model. Now, I've never used an (expensive) C-Bus lighting system, so don't know whether or not they employ the concept of a 'set'. Nor do I know how granular C-Bus groups can be made. If a group can be made as small as a single device, then the C-Bus Set->Scene(->Group) becomes identical to the Dali Group->Scene(->Device); only the terms differ. Since three levels of reference seem more than are needed (and as the ISY does not employ them in any case), I tend to prefer the terminology used in the Dali model (and eloquently expressed by upstatemike) of Group->Scene, where a Group is a physical set of devices, and a Scene is a defined set of levels/ramp-rates for those devices (of which there may be more than one for a given group).

Bill, yes you are correct. The commands are Start Manual Change and Stop Manual Change. The start command contains a byte which indicates the direction of change. These commands could be put to good use as triggers. However, they don't appear to show up in the Java console; I'm not sure why. Michel/Chris, could Bright and Dim (as ControLinc buttons or as paddle holds) be made to work as triggers in the next version? It would be great if the All On and All Off buttons could also be made to work as triggers, but I seem to recall reading that those ones aren't possible; is that correct?

Which software are you referring to? You mean in the ControLinc? I was looking in the Java console (with DBG 2) and think that what I saw confirms this. I didn't see specific Bright/Dim commands listed, but did see what appeared to be a number which could be the level, after the button was released. However, using the ControLinc, I found that if I pressed and held the Bright or Dim button, then released it, all was as above. But, if I quickly pressed and released Bright or Dim (the same way one would do with one of the numbered buttons), then there appeared to be a level change of about 3% (in the ISY console), but after which further Bright or Dim button presses (even if held) would have no further effect until the On or Off button was pushed.

I thought this had been previously discussed, but couldn't turn it up in a search. Is there any way to trigger on a Bright or Dim command, such as when pushing the Bright/Dim buttons of a ControLinc, or when holding/releasing a SwitchLinc paddle?

Toward the end of this thread, there was a brief discussion of the difference between a group and a scene, where it was posited that "A scene has only 1 defined state, TRUE (when each member is at the exact setting defined by the scene) and all other states are considered FALSE. A group has only one defined state, FALSE, (when all members are off) and all other states are considered TRUE. [upstatemike]" Finding the discussion very interesting, I've done a little searching for information on these concepts. One lighting manufacturer's (Dali) manual considered a scene to be a specific set of preset levels (and optionally, ramp rates) for a defined group. In other words, a group is a physical grouping of devices, and a scene is one particular set of levels for a group. There may be many presets (scenes) for a given group. So a scene is actually a sub-set of a group. This definition works well with the one presented above. Another manufacturer's (C-Bus) manual seemed to indicate somewhat the reverse, where a group is a physical group of lights (kitchen group, dining group, etc.), and a scene is a set of preset levels for a set of predefined groups (kitchen group to 100%, dining group to 64%, etc.), thus making a scene a super-set of groups. This same manual does, however, state that a scene indicator should be on when the scene is set, but off when any member is at variance with the preset, thus concurring with the thought expressed by upstatemike in the thread linked above. There were many sites which talked about the Dali components, but the number of discrete descriptions seemed to be about evenly divided between the two (super-set or sub-set) views. Still, the noise-to-signal level was high, and in digging even those out of the search results, I've only scratched the surface. It is, I think, a subject which would make for interesting discussion. What are some of your thoughts?

Agree completely with the thoughts expressed in the various posts in this thread. And also agree with Mark's: Yesterday I received my new V572RF32 and set it up. Unfortunately, it displayed some problems, and I described them in an e-mail to WGL last evening. Today an e-mail reply was waiting for me. Based on my report, they had verified the problems, fixed the firmware, and sent me an RMA number! So, here's a virtual beer for WGL, as well as UDI!

No worries! I received your e-mail regarding not being found on the list, and I went and registered again. Hopefully this time it will "take" .

Hi Rand. While I agree with the remainder of your post, I didn't get the Thank You note you mentioned. I'm feeling so left out! Am I the only one?

Chris, thanks so much for the good news, and for your continued support and improvement of the X-10 capabilities of ISY!

Whenever a program runs, it is either set True ('Then' path) or False ('Else' path), therefore you can use any conditions in your 'If' to set a program to True or False. You can use Actions to explicitly set flags as well; create an empty program named 'Flag 1', and in other programs use the 'Program' 'Run' 'Flag 1' action to set 'Flag 1' true, and use 'Program' 'Run Else' 'Flag 1' to set Program 'Flag 1' false. Super! Thanks, Chris, that's exactly what I was looking for.

In all the examples above, the conditions which control the Flag program are all time events. Is there any action statement one can place in a separate program [without actually turning some Insteon device on/off] which would cause a Flag program to change state?

Clarence, thank you! Flags ala your programs will alleviate a lot of problem areas, pending the introduction of genuine variables. Well done!

Well, if the status indicates the the last button press On or Off (kind of a simulated Load, as you commented), I imagine someone will find a way to make good use of that information. I don't see it as a bug.

Thanks for the information, Mark and Michel. My DHCP addresses never seem to change, even when the computer is switched off for the night and back on. But I think I might try changing my network to static addresses anyway, when I find the time.

Will do.

Hi Michel. I had JRE 1.6.0_02 until about a week ago, when it notified me of an available update, and I updated to JRE 1.6.0_03-b05. So, I guess the problem must have been a. cached version of applet. Though recycling the ISY didn't help, the problem disappeared after turning the computer off for the night, then back on today. So far, it appears to be working correctly.

Now that I can access ISY with 2.4.10, and since I don't like to have UPnP enabled, I've added a link to my bookmarks which goes to http:/192.169.x.y:z/0/p (there is a slash missing so it isn't a clickable link in the forum) so that I don't have to go to the UDI Support page every time, or in case the Internet connection is down. Is this an acceptable way to access ISY?

Yesterday I tried powering off the ISY for 60 seconds and back on, but that didn't help. Perhaps it was powering off the computer and back on that did it?

Hi Mark. I already have the IP address and port number, and it doesn't appear to have changed with the upgrade from 2.4 to 2.4.10. But, today it appears to be working. I wonder whether they made any changes to the web link to get it going?

Hi Mark, thanks for that information. That must be the culprit, as I've been logging on from the page you pointed to. I don't have UPnP enabled, and therefore don't have My Lighting in My Network Places. Is there any workaround? If not, I guess I have to wait for 2.5 to be officially released--will it then allow logging on without UPnP?

After upgrading to 2.4.10, I can no longer log on to the ISY. I get the logon dialog box, enter 'admin' and 'admin' (I have yet to change them), and press 'OK'. The dialog box goes away, but a moment later it come back. I enter the id/password over and over until finally I get a dialog box which says "Socket open failed java.lang.NullPointerException". I press 'OK' and get another dialog box which says "Not Implemented". There was also another dialog box which disappeared too quickly to read, but it said something to the effect of "Maximum Security Sessions". Sometimes, it appears that I have logged in, but there is a red exclamation-mark icon beside 'Network' and beside 'Configuration'. Also, the 'File' menu is the only one which is enabled. The 'Link Management', 'Tools', and 'Help' menu, and all the toolbar buttons, are grayed out. How can I get back into ISY?

Sorry for the late input. In the X-10 world, the 'group' (housecode) is designated by a letter, and the 'unit' by a number, thus making them easy to distinguish; the 'control' is usually written as a word, but internally represented by a number. I agree with Chris that the control code is needed for debugging. But, the English word is easier for the user to understand, so I would prefer something like this: If ( X10 'A1/On (3)' is Received Or X10 'A2/On (3)' is Received Or Control 'Keypad' is switched On ) And X10 'A1/Off (11)' is not Received And X10 'A2/Off (11)' is not Received And Control 'Keypad' is not switched Fast On Then Send X10 'C4/On (3)' Set '0A.B9.44.1' On Else Set '0A.B9.44.1' Off Send X10 'C4/Off (11)'

You know, that's a real sore spot! I've had a lot of difficulty with Smarthome (Hey, I think Digger can relate to that). I had been placing items in my basket over the last week, and was just waiting on an e-mail communication to decide about one more item. So, I went last night to the Smarthome site, and tried to check out with the items already in the basket. I entered the discount code, which it accepted, and showed the appropriate discount. But when I got to the actual checkout, it kept giving me an error and wouldn't let me proceed. This has nothing to do with using a discount code; it's an error I've seen on their site before. I tried calling, but naturally they were already closed. Oh well, my fault I suppose, for leaving it so late in the evening! But I do know the code worked, and others have confirmed that. So I hope everyone else who tried was able to get a nice 20% discount! Anyway, it may take a little longer, but I'm hopeful of there being an ISY in my future .

Well, I've been an Ocelot user for many years (am I the only one here? ), but haven't yet used an ISY. I do look forward to it, though, and will certainly be able to provide a lot more comparison information when I have. ISY and Ocelot are, I think, not so much competitors as complementary, so I'd really like to approach it from that perspective. I think they would make an excellent combination.