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.

First, MarkJames, thank you very much for your excellent write-up. Your "Concept of Operation" makes things much more clear. My setup sound similar to yours: about 100 devices, multiple panels, two buildings, and two completely separate electrical meters -- I rely on the RF of Access Points to bridge the two systems. So here's my question: I am pretty sure that the link information stored in the devices does not exactly match the link information known to ISY. This may be in part due to my earlier use of SmartLinc2. The result is apparent gremlins in my system -- last week, for no apparent reason, and without making any changes that I recall, the lights in my office began blinking every few hours. I recall reading somewhere in the forums about identifying differences between the device link tables and those known to ISY. Is there some way to start some massive "scan" of all devices known to ISY, and (a) compare the device links to what is known to ISY, and ( optionally force the device links to match those in ISY? I like the idea of being able to first review what is going on before having ISY go and "fix" the bad links. BTW, I understand that I will "lose" any useful links that are in the devices, but not known to ISY -- but I don't mind, as I really want my devices to reflect what ISY is managing (and can thus be documented, backed-up, etc.). I have read that these sorts of bogus links in devices account for some degree of unreliability (due to excessive bogus traffic), especially in large systems, so I am hopeful that my system will perform better overall after the cleanup is done. Finally, if anyone from UDI is reading this far, it would be very helpful if someone would expand the ISY documentation to include cleanly written examples, tutorials, etc. I see that the forum and the wiki do include a number of examples. But sometimes an "example" in a forum ends up being a thread, with all sorts of fix, improvements, etc. The history is useful and worthy, but it would be great if a final summary was included in the standard doc (either the PDF, the wiki, or even a sticky part of the forum). For example, the Concept of Operation offered by MarkJames should absolutely be included as some sort of reference material. I wish I had blundered upon it months ago. Not only would it have saved me time, but I would have bugged UDI tech support less. Another example: I asked UDI tech support for help with the programs and KPL configuration so that I could use a KPL to track the status of multiple scenes in a room. The goal is to allow me to turn on/off lights (on a room-by-room basis; each room has several scenes) when the kids leave the lights on downstairs. It took about 10 email exchanges before the kinks got worked out. I assert that the final example should be included in the wiki or forum, as a "supported" or otherwise clearly described example. Requiring your customers to each individually build a knowledge base is too much work, and a waste of people's time and effort. Thanks again to my hero of the day, MarkJames.

CASE CLOSED! Thanks for the feedback. I was too casual in my description; allow me to be more clear. 1. Yes, the ISY has a static IP of 192.168.67.9. My firewall/router maps the external IP of 173.15.208.50 to 192.168.67.50. As you point out, I am using the NAT feature of the Sonic firewall to map the externally-visible/accessible IP to selected internal ("192") IP. The "services" passed through from 173...50 to 192...9 for the ISY are ping,http,https. I use the same scheme for the server that I mentioned in the post; it has a static IP of the form 19.168.67.x which is mapped to the external IP of 173.15.208.52. It also has more services passed through (ftp, and others). As far as "port forwarding", I am mapping the external ports to the same internal ports. This means that I can access the ISY using port 80 and/or 443, without having to remember special port numbers. Things get complicated enough without having lots of port mapping, although I do this in my colo setup when I run short of IPs. Ugh. 2. I now understand (I think!) that "Enable Internet Access" really means "configure UPnP". So, I have disabled that feature on the ISY. Thanks for making that more clear. 3. Thanks for the link on the "port forwarding", although those web pages apply to standard home routers, and not slightly more advanced ones like my SonicWall TZ100. I have faithfully performed the analogous actions, though, by passing through the proper set of services from ...50 to ...9 (as noted above, this set is http on 80, https on 443, and ping/icmp). 4. Thanks for clarification on simultaneous access -- very nice! After writing all of the above, I finally found the missing piece of magic in my NAT configuration, and now everything is working perfectly. Thanks for the help.

Hi, I am running 2.7.13 on my ISY-99i. I am accessing the ISY locally using 192.168.67.9 and this is working fine. I can also ping this lan address and the ISY replies as expected. I am trying to access the ISY remotely (for testing, I "remote desktop" into a remote machine, then open a browser and point it back to this location). Argh, remote access to the ISY99 is not working. I have 5 static IPS at this location, and one is dedicated to the ISY: 173.15.208.50. Therefore, I don't need to do any port mapping, as 80 and 443 aren't "overloaded". I have another server at .52 and am able to ping it, and access via http(80) and https(443). I configured my Sonic firewall to handle the ISY almost exactly like the aforementioned server (the services open for the ISY on .50 are http, https, and ping). I've done this sort of config many times before and generally have no issues. Alas, I am unable to access the ISY via ping, http, or https. One thing that might be a clue is that Help->About reports that the URL for "Internet Access" is "https://0.0.0.0". Is this URL is only set when using UPnP or equivalent? If not, do I need to set it? And if so, how? My questions are: 1. Does the https://0.0.0.0 mean anything? 2. Should I have Internet Access enabled in the ISY via File->Enable....? (I do.) 3. Can the ISY support more than 1 simultaneous session? (Even if it can't, it should still be able to respond to pings). 4. Got any bright ideas? I'm stuck. Thanks in advance for your help.

Someone else on this forum said it nicely: "once I started working with the ISY99, I never looked back." One of the reasons that UDI has such a good product is they listen to customer feedback. I am often amazed by "support teams" that don't recognize useful input when they receive it, and instead focus on defending their existing position. UDI actually listens to its customers, and recognizes a good idea when they hear it. Instead of a canned "we're looking at it" reply, they do something useful. Thank you! In my opinion, Insteon would be far less useful without ISY. Thank you, UDI!

Yes, I just checked and confirmed that I am downloading the correct binary. I also located the 2.6.13 release, but (as you might expect) got the same installation error. Ideas?

I am getting the "Upgrade Failed:Invalid Length" error trying to update from 2.6.8 to 2.6.12. It seems that the amount of data transferred to the ISY-99i varies; typically is perhaps 5% to 15% (just a guess, though). Actually, I first see this error message: "Upgrade Failed :java.io.IOException: An established connection was aborted by the software in your host machine." Then I see the Invalid Length message. I am not running any anti-virus software. I am have disabled the Windows Firewall. I just re-booted my XP SP3 box and it should be pretty clean. Nothing interesting as far as I can tell in the Java Console (I am running Version 6, Update 11). Any help would be appreciated.