johnradams

Unless I am mistaken, the Wait statement avoids the race condition that describe in my write-up, here: http://adamsj.com/isy/ The race condition is a concern is you have lots of devices (I have over 100 devices), and some occasional Insteon network delays due to a large configuration (lots of breaker panels, etc.). Your mileage may vary. I didn't like the flickering keypad button, as it was confusing to use. BTW, I plan to post the write-up to the wiki when any final nits are resolved, such as a clear explanation of why it is "better" to use 2 programs instead of a single program with an Else.

Note that your program as listed herein will always execute either the 'Then' portion or the 'Else' portion. This might cause additional internal activity, overhead, etc. within the ISY (we'll let someone at UDI clarify). If you use a 2nd program, then each program can be structured to only use the 'Then' portion. This means that unless the 'If' expression evaluates to True, then the program essentially does nothing. Which might, or might not, be useful. As you gathered, ISY advised me to use the "two program" method.

I intend to add my content to the wiki Real Soon Now. Until I am set up to edit the wiki, I am happily hacking away on my own.

Thanks for your input. I'm glad this discussion is getting some visibility. As I noted, I was advised by UDI to list the devices, and avoid putting the multi-way scene itself in the Action list. And my experience was that my program worked much better after I listed the devices individually. A forum is a great place to raise questions and issues, but not such a great way to disseminate "known-to-be-good" examples, documentation, etc. I look forward to learning the clear and complete "verdict" on this topic so that it can be documented once and for all (and not documented thousands of times in the forums, each time with a slightly different error, omission, or quirk).

Rand, I got the idea from you and/or Darrell Yes, your statement above is correct, and consistent with point #7 on the web page: http://adamsj.com/isy/programming.htm However, the "full story" is slightly more complicated, and bears explaining. Which is exactly why I created the webpage -- to avoid dozens of minor modifications such as one finds in the forum. It is always nice to have a definitive, and clear, explanation. The warning that I speak of in point #7 refers to the notion of listing devices, instead of referring to a group of devices which are described by a multi-way circuit (aka scene). In other words, if you want to turn off all the lights in a virtual circuit with 3 lights, you want to have 3 separate Off commands in the list of Actions. You should not take the short-cut of simply setting the scene (that manages the multi-way circuit) to Off. If you do send an Off command to a scene, make sure that the devices listed in that scene are only acting as Responders for that scene. I have tweaked the wording in point #7 to clarify this. If the revised language in point #7 is not correct, or is unclear in any way, somebody please speak up!

Chris, Another way of stating this (pls correct if/where I am wrong): when a 'Wait' statement is encountered, the executive suspends execution of the program, and schedules the program to run again after the specified interval. The twist, however, is that the program resumes execution "at the top" (eg, the If is re-evaluated). If the expression evaluates to True, then execution proceeds with the statement immediately following the 'Wait' which was just recently in effect. Question #1: is the previous paragraph correct? Or, instead, when execution resumes after the Wait, does execution begin at the top of the 'Then' instead of just after the previous 'Wait'? Question #2: suppose my program performs a Wait. After the interval completes, will the 'Else' portion of my program execute in the event the 'If" expression evaluates to False? Question #3: is my assertion regarding "the If is re-evaluated" actually an simplified (but often close-to-correct) overstatement? And the proper thing to state is that any change in status to an Insteon device which is referenced in the If will cause the If to be re-evaluated. BTW, which I think is incredibly non-obvious. If I want that behavior, it would seem more natural for the logic to look something like this: while ( some_condition_is_true ) { do_some_stuff(); sleep(x seconds); } Maybe some changes to wording would be useful. If the syntax was 'SleepAndReEvaluateIfUponReEntry' I would find that much clearer . This would also allow for other forms of behavior, such as 'SleepAndContinueExecutingRightHereNoMatterWhat'. I'm not suggesting this exact syntax, though . Thanks for clearing this stuff up.

oberkc, Your point is consistent with my experience! I freely admit that I have pre-conceived notions/expectations about the programming model. And that got me into trouble -- the interesting behavior of the 'Wait' statement was probably the biggest mystery for me. The way that 'Wait' causes re-evaluation has now been added (at my request) to the wiki, where it was conspicuously absent. BTW, if it isn't obvious to you, my tutorial goes well-out-of-the-way to explain a few "real-time" and "multi-tasking" issues. I did this because I presume that most people working with the ISY are not familiar with these concepts. Most people cannot initially grasp the idea that all of their devices might not be in some nice, clean, known state when a program runs. It takes them a little effort, and some examples, for them to understand that their program needs to gracefully handle things in an intermediate state, and/or to handle a "race condition" -- especially between their own programs. For example, people typically assume single-threaded execution, as that is essentially what they see on the screen when editing the program details. They cannot help but unconsciously think "Hey, since I see just this one program on my screen, then I guess this is the only thing happening when my program is running." It's human nature -- unless something else has been explained to you. If any of you want to email your own little tidbits of wisdom, I will (a) be pleased to learn them, and ( will add them to my slowly-growing toolbag of tips 'n tricks. jra [at] adamsj.com

I am using a KeyPadLink button to see if any of my basement lights are on (e.g., someone left some of them on ). If any of the lights are on, the KP button is lit; I can then press the button to turn all of the basement lights off. I can also use the same button to turn all of the lights on. While this is a simple scheme, the programming needs to handle some race conditions. I initially struggled with ISY programming, as I was really thrown by a few quirks of the model (not to mention spotty and sometimes contradicting doc!). When I finally got it sorted out, I documented what I had learned, in hopes that others would be spared some pain. Here's the link; enjoy: http://www.adamsj.com/isy/

I am using a KeyPadLink button to see if any of my basement lights are on (e.g., someone left some of them on ). If any of the lights are on, the KP button is lit; I can then press the button to turn all of the basement lights off. I can also use the same button to turn all of the lights on. While this is a simple scheme, the programming needs to handle some race conditions. I initially struggled with ISY programming, as I was really thrown by a few quirks of the model (not to mention spotty and sometimes contradicting doc!). When I finally got it sorted out, I documented what I had learned, in hopes that others would be spared some pain. Here's the link; enjoy: http://www.adamsj.com/isy/

Here is a recent Topology report: http://adamsj.com/udi/topology.v2.7.15__2010-05-18.10.29.44.html You will see an entry (in bold) for a PLM device with address 0D.D8.82.1 which is marked as "Unsupported Device:3.19". I put part of the line in bold to make it easier to find. Here is a (partial) screenshot of the ISY GUI, sorted by device address: http://adamsj.com/udi/Capture-05-18-00001.png You will see that the mysterious PLM device does not appear in the list of "known devices". It should appear near the cursor. In summary, at least these two "databases" are not properly reconciled. It would seem that this may well explain why performing a "device restore" does not remove the obsolete entries from the device link tables. And may well explain other oddities. I very much like the idea that the ISY software controls and maintains the authoritative list of links. This allows one to backup, manage, review, print, display, and otherwise manipulate the myriad of links in an Insteon network. Without ISY, it would be a nightmare to try and keep track of what is where! If you wish to login to my system, please email me and I will reply with the URL and password. Thanks, john

Well said -- I'm not looking to create work! However, I seem to be facing a disconnect between what I understand is essentially three databases: (a) the set of links found in each and every Insteon device's link tables ( the links found in the PLM © the device names, descriptions, and link knowledge maintained in the ISY application Although I am probably misstating something, what I seem to have encountered is that my ISY software knows about a PLM that is no longer in use on my Insteon network (I used it when I was using HouseLinc2 to try and diagnose comm failures). Links to/from this unused PLM continue to appear in device link tables, even after doing a device restore. The PLM device in question does not appear in the left-hand pane of the UI, but does appear in the Topology report. So my problem seems to be that ISY knows about a device, but is unable to communicate with it. And the philosophy of the ISY software appears to be "don't delete references to a device just because communication is failing". In this case, however, I *know* that the device is no longer in use, and I want to completely remove all knowledge of this device from devices, the PLM, and ISY. I suppose that what I need to be able to do is: (a) delete all references to this device in the ISY software/database, then ( cause all device link tables to reflect this change. Although the abandoned Insteon device in this case happens to be the PLM that I used with HouseLinc2, there may well be other abandoned Insteon devices that I want to purge from the system. In general, what is challenging me is knowing what is in the device link tables, versus what is in the PLM that ISY is using, versus what is "known" to ISY. And making sure that they all reconcile. In a consistent, verifiable, and reproducible fashion. Am I missing something? Thanks.

Unless I am mistaken, the Topology report only lists what ISY knows about, and it is implicitly assumed that the information in the devices matches the information maintained and believed by ISY. Which is a significant issue, raised by you and others: if the actual device links don't match what ISY knows about, then your system will have problems. What I am proposing is a report that lists the link tables in the devices (and, to the extent that the device entries are "known" to ISY, displays the human-friendly device names). Make sense?

Thanks as always, Michel, for listening. I realize that you must have a feature and bug list a mile long. But I respectfully suggest that having the ability to gather all device link data would be very useful, and might save UDI staff -- and customers -- LOTS of debugging. I am very keen on using the current Topology report to review my system. I now realize, of course, that this report describes only what ISY knows about. The topology report is not based on actual device link info -- yet it is the device link info that controls what the devices are actually configured to do. The existing UI function: Tools->Diagnostics->Show Device Links Table is somewhat tedious; it requires GUI interaction for each device, shows only the hex detail, etc. Could you consider at least taking "baby steps" towards a full-blown system-wide Compare function? For example, a very nice baby step would be to simply cycle through all device known to ISY, and read the link tables, and display them something like this: aa.bb.cc (Foyer Dimmer) --------------------------------------------------------------------------- Controllers | Responders --------------------------------------------------------------------------- hex dump device name | hex dump device name --------------------------------------------------------------------------- Wow. Such a report would allow people to review and essentially do a "visual compare" (hey -- the Foyer dimmer is controlling the lamp in the bedroom!?!). And for those that care, the hex dump is right there for diagnostic purposes. Assuming the report is HTML, the table cells could each use their own CSS class, so people could make the hex dump invisible if/as desired. For those who don't realize this, you can tweak the appearance of the existing Topology report by editing the CSS declarations in the HTML file; very handy. The above report would not perform any sort of cross-checking; such cross-checking and what-not can get quite involved as you try to keep everything in memory, etc. It is much easier to simply walk the ISY device list and dump them one at a time. Perhaps the UI could allow the user to do this on a folder basis, so that one can get the details for just one folder that contains devices that are "misbehaving". Especially useful for checking a few devices without having to wait for *all* devices to be queried. It is noted that such a report, might well reveal devices not known to ISY, which is not a problem -- that is in fact a help, and the user could then remove these "orphan" links. Anyway, I am hoping/asserting that a simple "dump" tool would be: (a) a very valuable and useful debugging tool, and ( far simpler to implement than a full-blown link analysis tool that attempts to reconcile all devices by examining all of the link details simultaneously. Based on my understanding of the link table structure, it seems to me that the above report would give anyone pretty much all the information they might ever need to review a system, and confirm that their actual devices match their ISY configuration. I suppose minor (future) enhancements could include further decoding of the hex values, perhaps especially to show the dim rates. And of course, once people start discovering a bunch of orphaned or otherwise bogus links, then your users will want a nice UI function to clear out such links. No rest for the weary, right? Thanks as always for your consideration. MarkJames, your suggestions?

Yes, it would involve a lot of gathering status, then doing a lot of cross-referencing to see what, if anything, is amiss. Somewhat like running fsck or chkdsk, where you determine if the number of references to each disk block is correct, that there are no "orphaned" blocks. etc. As you suggest, it gets quite involved, and might take quite a while to run -- which is why I want the computer to do all of that for me As far as docs, I am suggesting that a longish thread can be properly summarized/edited, and made into a single coherent piece. Much like what you did with the Concept of Operation (hope you don't mind my giving it that title). Didn't you edit it 6 times to get it right? Proves my point. Your piece is MUCH more readable and organized than some long thread with dozens of comments, corrections, etc. Having a single coherent piece saves everyone the trouble of figuring the lengthy thread on their own. Speaking of edits to your doc, you mentioned that the PLM is connected to the ISY via CAT5. While the wire may well be CAT5, I think the communication protocol is RS-232. While a far cry from 10 Mbps Ethernet (or faster), the serial link (19.2 Kbps?) is cleaner and more reliable than Insteon's over-the-wire signaling. Thanks again for your insights. I now have renewed enthusiasm for my Insteon/ISY system!

MarkJames, Thanks for the suggestions. I agree with you that somewhere, somehow my system has gotten slightly munged. I recently changed out about a dozen devices, and it probably happened during this process. I thought I did everything cleanly, but I guess not. I think I have exactly one old X-10 device, which I will eliminate ASAP. I have 2406H devices next to every panel, so I've got this covered. I am guilty of "too many" Access Points (I lost count, but have at least 10, as suggested by SmartHome), and will trim that down a bit. I guess I really only need them at the two places where I am jumping from one building to the next (and which is where we are "jumping" from one electrical system to another, using completely distinct feeds from the local power company). All the above being said, I think that I do need a few "extra" Access Points to ensure good signal transfer between some of the panels which are somewhat electrically distinct. By "somewhat electrically distinct", I refer to panels that are separated by a transfer switch for the generator. What tools are available to track the signal flow in the system, especially across Access Points? Can/should I add Access Points to my ISY configuration? Will their status be reported in the ISY UI? The idea of going through each device, one-at-a-time, and checking the device link tables against the ISY link tables is the kind of thing that computers a good at Folks at DUI, any plans to have the ISY software do this sort of thing? It would a great way to verify that a system is configured as expected. And seems like it could save your customers, and your your tech staff, many hours of debugging. At this point, I have only a few simple programs; I have held off on doing the cool/fun stuff until my system is more reliable. Reliability first, features second. Michel, Thanks as always for listening. I really think that UDI would be well-served by spending X hours on doc, thus answering many questions with a broad brush. And saving 25*X hours in one-on-one support handling. Getting the doc right is a "highly leveraged" activity, and would save UDI staff (as well as your customers!) many hours.