KeithM

Hi Michel, I would agree with you, the bits are immaterial. But that's not really the point. The issue is that Chrome is well along their well-documented road to phasing out Java support, and the most recent release of Chrome (Version 42.0.2311.90 m), will no longer support the UDI ISY Java interface plugin. Doesn't matter what update or bit version of Java you try (I'm up to date at Version 8 Update 45 (32 bit)). So users should forget using the Chrome route to access ISY in future, and shouldn't waste time trying to troubleshoot what is in fact a documented new Chrome "feature", and not a bug somewhere. I'm surprised and puzzled that this issue is not more widely documented and addressed here and elsewhere. This issue will certainly become more prominent in the very near future as people are updating their version of Chrome and hitting this unexpected issue, as stusviews experience further confirms.

I have the same problem with Chrome on multiple computers no longer being unable to access Java plugins for multiple applications including ISY. This issue appeared following making recent updates to my system (the new ISY994i Series Firmware v4.2.30, Windows 7 x64 updates, Chrome update, etc). Now using the most recent version of Chrome Version 42.0.2311.90 m, and Java Version 8 Update 45 (32 bit). I have the same problem with no longer being able to access my Foscam IP cameras via java plugins on Chrome. I spent some hours trying to figure this out given that a number of things had all been changed at once, and found little surprisingly little reference to this issue until I stumbled across the links below. It would appear that Chrome is phasing out Java support as per the attached article, and we can no longer readily use Chrome with java plugins. http://arstechnica.com/information-technology/2015/04/chrome-starts-pushing-java-off-the-web-by-disabling-plugins/ http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html Internet Explorer (11.0.9600.xxxx) works fine to access ISY and Foscam etc via Java (using Java Version 8 Update 45 (32 bit)), but not Chrome. Pretty clear that Chrome can no longer be readily used for ISY admin console access, or for other Java-based interfaces like to Foscam. Don't fuss over whether you have 32 bit or 64 bit Java - sorry but that is irrelevant to this issue. Read the releases. It will be interesting to see what approach UD, Foscam, and others take with respect to future use of Java. Hope this helps others avoid undue frustration and wasted time.

Hi Stu and Lee, thanks for the quick replies, very helpful! I am interleaving my comments/further questions into your responses. 1) Control is when you want an action to occur at the time a specified device sends a signal. Status is when you want the action to occur only if the device is already in the specified state. Ok, got it. Lee your further elaboration and examples clarified the differences for me. 2) Responding means that the device is connected and functional. OK thanks - I am assuming that this "responding" status is based upon some sort of periodic status checking. That being said, with the moisture sensor I know that it has a built-in daily heart-beat function that one needs to use in a program to essentially accomplish the same thing - i.e. to periodically ensure that the moisture sensor is operational, in range, etc. I am a bit puzzled that this is needed if in fact there is also this "responding" status which presumably is somehow accomplishing somewhat the same thing. Are the specifics around the "responding" status documented somewhere, and under what circumstances would one use it? 3) Dusk.Dawn is always available. How are you checking for the status? When I look at the device on the Admin Console main page left column, and look at the three elements listed for the motion sensor (sensor, dusk.dawn, low bat), in the right hand column where it displays the details for that node/subnode, such as current state, membership, etc - there is a current state (On/Off) for motion, current state for low bat, but the dusk/dawn current state is blank. It is this same way for all the motion sensors (and all of which have dusk/dawn motion triggering disabled). So since the current state for dusk.dawn is blank, with no status shown, I assumed it is not usable. Am I mistaken? 4) On only sends a signal, hence a blink, at the end of the countdown if motion is detected. On/Off sends a signal each time motion is detected, even before the countdown. So if I interpret Stu's description correctly, both modes make use of the countdown timer, but in different fashion. The sequence in detail for the two modes is: On only mode: Motion occurs, countdown starts. More motion during the countdown period has no effect. At end of countdown then On signal is sent. No Off signal ever sent. If my interpretation of your description is correct, it is different that I would have expected, It would seem to make more sense for the On signal to be sent at the start of the countdown period, rather than the end? On/Off mode: Motion occurs, On signal sent, countdown starts. If more motion occurs during countdown period, then more On signals sent (and does countdown period restart?). At end of countdown then Off signal is sent. 5) The first press put the MS into linking mode. The second press (rapid blinking) put the device into unlinking mode. Got it, so what I thought was a problem was just normal operation, good to know. 6) What you are calling communication mode is actually linking mode. Only one device can be linked at a time, although several devices can be linked sequentially by the ISY, unless they're battery powered. Got it, thanks. So other than the ongoing communications reporting from RF devices in response to detected events, is all other traffic initiated by the OP by pressing the Set button (such as to update devices etc) referred to as "linking mode", and there is no other non-linking mode of RF communication by battery devices to ISY? 7) In the Administrative Console, click on ISY for a sortable list. Got it, thanks. Would be nice to be able to somehow print that out and/or export it into a file for documentation/reference.

The links on this sticky are all out of date - would be useful to update this useful summary with the current references. Many thanks, Keith

I am relatively new to Insteon and ISY programming. I have set up a small home automation network based upon the ISY994IRPRO controller, and with a mix of dual band switches and key pads, mini-remotes, moisture detector, etc. I have a reasonable amount of real-time programming experience from the past, and have been largely able to figure out the ISY programming concepts and most details. But it has been a bit of a struggle at times. My perception is that the documentation is at times a bit vague or incomplete, and sometimes it takes trial and error to finally figure things out. (An example would be that you can set up a custom email notification with a subject and blank body with no error message, but then that email will never be sent by a Notification since a blank body is not allowed, but there is no error message not any obvious documentation to that effect). I will note my various such learnings along the way and forward for potential inclusion in a future update of documentation. But I digress - back to the current issue. I have recently added three 2842-222 motion sensors to monitor various indoor and exterior locations and trigger. They do not directly control any responders - all control actions are made through the ISY programming. In some areas the detailed documentation (at least what I can find) is vague or I can't find it, and hence I am looking for some guidance from the forum community. 1) for a motion sensor, what is the difference between checking for a Control versus a Status event? I think that I understand the concept for something like a wall switch, where a manual action (pushing a button) triggers a Control event, whose specifics are related to how the button was pushed (On, Fast On ,etc), and the Status just relates to the current state of the switch (On, Off, etc) and which could have been set by manual action or by a Set command sent by another program. The documentation I have come across explaining the difference between Control and Status is not as detailed and clear as I would hope, particularly with respect to different devices. Can someone provide clarity with respect to motion sensors, and more broadly? I see various program examples posted by other users where some seem to check for Control and others seem to check Status, to accomplish exactly the same thing. 2) what makes a check of Status "Responding" true or false? "Responding" seems to be a state different from Off or On, but I haven't been able to find a definition anywhere. 3) I have set all three motion sensors to pin 5 on (programming enabled), all other pins disabled. Via ISY I have set the device options to 7/24 (ie dusk to dawn off) and to on/off countdown mode. It appears that the Dusk.Dawn event flag is specifically interconnected to the dusk/dawn motion detection option setting. If you want to detect motion 7/24, then the Dusk.Dawn flag is not available for checking. In an idea world it would be nice to be able to determine the dusk/dawn events, independently of the motion detection events, but it appears that this is not currently possible. Is my understanding correct? 4) all three motion sensors appear to correctly trigger on motion detect, and the LED flashes once each time. I am still trying to better understand how the countdown time setting works. Am I correct in that a motion detect flashes the LED and starts the countdown timer, and generates a Control On; and that no further LED flashes or Control On will be generated until the countdown timer has run down to 0? Or are the periods between motion detects and LED flashes independent of the countdown period? It seems pretty clear that at the end of the countdown period a Control Off is generated if the option for on/off (ie an off signal after countdown) is enabled, but the role if any of the countdown is not as clear if the off signal option is disabled. 5) when I put a motion sensor into communications mode by holding down the set button, the LED commences slow flashing after 5 seconds as expected, and normal RF communications can occur. However, when I press the set button again (within the 4 minute window) to turn off the communications mode, the LED commences rapidly flashing, and which continues until I press the set button again, at which point the LED flashing ceases. Is this normal operation for these motion sensors? I thought that the LED rapid flashing meant that there was a communications error? All three motions behave the same way, and I have factory reset them and the PLM, but this same pattern recurs. Maybe I am looking for a problem where there is none, since I only get regular single flashes when they are in normal use, which I take to mean that the communications is fine. 6) it appears that only one motion sensor can be in communications mode at a time. When I put one sensor in communications mode, and then I try to simultaneously put another into communications mode, the communications mode of the first seems to be automatically turned off (LED flashing ceases). This makes sense I guess, and I am assuming that it likely applies to all RF devices, but I didn't come across the documentation describing that. 7) to assist in analyzing communications events I would like to have a table listing all the devices and their addresses, and which I can sort etc. I don't see an easy way to get such a list from the system, and am assuming that I just need to manual build and enter such a table in Excel. Is there any quicker route that I am missing? Thanks in advance for guidance on any of these queries, and apologies if I am overlooking the obvious and/or my terminology is unclear or incorrect. Cheers, Keith