matapan

I'm sure that I've restarted ISY a number of times in the past two months. Perhaps the low battery status was lost when the unit was restarted. That said, I looked at the ISY log for more clues. The motion sensor checked died on 11/4 almost 5am. I searched for any update to a Low Bat node in Excel, but found nothing. Assuming the Low Bat node gets updated, I would assume from looking at the log that there were no Low Battery messages ISY saw on the network all this time. Is this a correct assumption? Or, does ISY and Insteon behave differently? When does the motion sensor actually send a Low Bat indicator update?

Has anyone actually found a workaround or solution to this issue of no low battery indication in ISY? I asked the Insteon support department at Smarthome about this, and they believe there are no issues with the device, even with rev 1.1, and that the problem lies with the ISY software: "[scott] Once again, that is an issue with ISY as far as we can tell. They need to correct the problem in their software." For all three of my motion sensor, I never got a low battery warning. The only indication that the battery was flat was when Dusk/Dawn and Sensor nodes for the 2420M provided no info, with the Low Battery node showing OFF for status.

According to the Help About page, I am using firmware version 3.1.11 on my ISY. After repeatedly clearing the java cache and attempting to run the 3.1.10 applet, I still end up with the same results. No login screen ever appears. How do I collect the relevant trace info to determine root cause here? This is simply not a case of user error, from my perspective. The source of a lot of issues related to upgrades seem to revolve around clearing a cache. Is there a way to automate that process, and eliminate this possibility as the contributor of issues identified? This alone would seem to contribute to a lot of unnessary calls.

Still getting connection errors in Mobilinc when I launch the app. The app appears hung for about 2 minutes before timing out.

Is there any harm in using the applet from 3.1.9 with the firmware 3.1.11? I cannot get the 3.1.10 applet to bring up the login dialog, even after clearing the Java cache.

Does anyone have any best practices they can share with respect to programming to check occupancy, especially when you have pets around? I've got three Insteon v1 motion sensors, plus some X10 ones I've been thinking of deploying. Two issues keep cropping up which roadblock me from moving forward on this idea: - The issue of managing false readings caused by pets. How does one negate or filter out the reality of pets when determining occupancy? Some ideas which have popped in my head (and possibly yours too) include somehow modifying the motion sensor to be more selective about what it sees and when it gets triggered. Maybe you can do this by putting tape over sections of the freznel lens. Or perhaps a careful placement of the motion sensor might achieve the same objective. If this is possible, what are the best practices here? - Making the motion sensor become more discriminating. Pets and wind seem to be issues that can cause lots of false positives. What do people do to get around this and make the sensors more accurate? I know, this is like the previous issue, but more generalized. - The sensor's inherent operation. Motion triggers the sensor, but the sensor does not reset immediately afterwards. There's always a timeout. This makes it hard to use a sensor for checking direction if you have an array of two or more motion sensors to determine where one is headed and to run a program in anticipation of this. Are there some clever ways to use the sensors, as designed in ways that can provide meaningful feedback to a program? That Nest intelligent thermostat coming out soon is intriguing in that respect. Perhaps some of the general ideas about gathering real time occupancy data to better control a thermostat can be used in an ISY setup.

I installed 3.11, first installing 3.10 and applying 3.11. I cleared the Java cache, then tried running the Admin Console applet, assuming there was one available for 3.1.11: http://www.universal-devices.com/99i/3.1.11/. I discovered there wasn't one, so I tried the 3.1.10 applet. The admin console came up, but no login screen. I then tried the 3.1.9 applet. This came up. I tried clearing the Java cache again using the Java Preferences application again. I could not bring up the login screen for the 3.1.10 applet.

Installed 3.1.11 after first installing 3.1.10. Used the link for the applet to version 3.1.10, since there was no 3.1.11 version. The app window came up, but no login screen. Ran the link to the 3.1.9 applet. Login screen appeared. I was able to login successfully. Cleared the Java cache after upgrading the firmware, before running the applet. Deleted the Java cache files again before attempting to run the 3.1.10 applet. Again, no login screen. Only the 3.1.9 applet worked. The Admin UI Help/About reported 3.1.11 was installed. Any suggestions?

Thanks for sharing, evilpete. I'm curious to find out how these bulbs fare over time. The GE CFL's I use did not produce line noise initially, but after 6 months, they generated enough noise to block communication with the Switchlinc Relay they were connected to. There are 4 lamps in the circuit. Replacing the Switchlinc Relay with a Dual Band Keypadlinc relay solved the problem. It would be nice to work with low wattage bulbs that don't create a lot of issues with Insteon.

A useful feature enhancement, if cost effective would be to provide a visual indicator on each Insteon device which would provide immediate, intuitive, and simple feedback to the user when a device has marginal communication with the controller. A diagnostic mode providing the equivalent of a "toner" device would also be useful for the end user to quickly determine which devices are on a circuit. Yes, I'm taking wide brushstrokes here with implementation assumptions of how things work under the cover. Until these sorts of things are addressed, Insteon will remain a hobbyist or bleeding edge adopter type of technology. The user scenarios of the average homeowner still haven't been taken into account, even if a 100% reliable network isn't really a practical day to day goal.

Given the noise issues with CFLs, it sounds like LED's are the way to go if you're going to continue using Insteon. Does anyone have any extensive and low level knowledge about LED's and how well they work or don't work with an Insteon setup when the LED's are used in large quantities? Specifcally: Do LED loads appear as real loads to an Insteon device like a Lamplinc or Appliancelinc? I plugged in some Christmas tree lights last year into an Appliancelinc, it would toggle on when a command was sent, but immediately turn itself off. This characteristic was standard for a number of Appliancelinc units I had around. Plugging in a normal load connected to an incadescent bulb did not cause the Insteon device to behave unexpectedly. Do ramp rates and lighting levels work well with LED's as they do with incandescents? How much noise do LED's produce over time? As a CFL bulb ages, it produces more and more noise. I have the Smarthome recommended GE CFL's. They worked fine initially, but now produce loads of noise on the circuit.

Does anyone have any guidelines on what constitutes a "good" network? How much time should the all device query process take with ISY under ideal conditions, for each device? Are there people here running in the "ideal conditions" category, where they don't get sporadic "Cannot Communicate with ", or have responders to scenes that don't always respond to the scene command. No negatives here. Just wondering if anyone has reached the ideal, 100% reliable configuration. I have some v35 Switchlincs. Since there are 12 of them, I'm mulling over whether biting the bullet and paying the cost for replacing that many switches (god, that's a lot of money!) will resolve my own seemingly random network issues.

Being that this is the reality, I go back to the original question: Is there a way to keep the Keypadlinc button state tied to the success or failure of the scene command? If the keypadlinc is toggled on to initiate a scene, and the scene fails, is there a way to turn off the keypadlinc button to reflect final state?

Thanks for the explanation LeeG. To summarize, I think what you are saying is: 1. All commands generated by key or paddle presses initiates a scene group message. 2. The scene group message actually consists of two messages. One that is broadcast to the entire network, and another that requires an acknowledge from each responder in the scene. 3. If two group messages are sent together in rapid sequence, only the second one will be completed. The first one is aborted. If this is the case, my understanding is that only a single group message can actually be sent reliably on the network. Multiple group messages broadcast at the same time will not be reliable. Is there a way to force the Keypadlinc button state to match the actual acknowledgement state of the group scene command. In other words, can you programmatically ensure the button state matches the success or failure of the group scene command being processed? I hate the fact that the Keypadlinc button states can so easily be out of sync with the scene state. There must be a better way to keep button states in sync with the state of a group scene message acknowledgement.

To clarify, the device is a Switchlinc or other device directly controlling a load. If I toggle a scene from a Keypadlinc then immediately toggle a device controlling a load, the Keypadlinc shows the status change, but the devices in the scene don't always respond.

Thanks for the explanation!

Thanks for the details LeeG. What is the proper coding practice then to prevent incorrect state displays on the controller/responder when scene or device status change command is issued immediately after a different scene command is issued? Example: Toggle a device. Immediately toggle a scene. Result: Scene is not activated. The keypad or switchlinc indicator no longer matches the actual scene state. How does one prevent this, programatically or otherwise?

I can reliably turn on and off a group of lights in a scene and toggle another Switchlinc if wait a second or two between paddle or key presses. If I press both paddles or keys in rapid sequence, the scene fails to toggle, even though the keypad button shows the scene was enabled or disabled by its illumination. Is this a case of too much communication going on at once? Or something else?

Now that the Admin Console for ISY-26 is essentially "frozen", would it make any sense to load this as a completely separate app to remove the requirement for clearing the Java cache each time one goes between ISY's? I know this is an edge case for most people - who has two or more ISY's? An installer or maintainer perhaps?

Beyond pointing to the correct URL, is there anything which needs to be done when one has to go between Admin Consoles for ISYs with different firmware versions? I have an ISY-26 running 2.7.15 and an ISY-99 running 3.1.9. Do I need to clear the Java cache going between versions? Thank you.

Interestingly enough, the firewall was blocking the network resource request from ISY. The same request works through Safari. What is the difference between the way a network resource request is made and how a browser makes the same request? Why does this work through the browser, but is blocked otherwise?

I still get sporadic and random "Can't Communicate with " errors in the Admin Console from time to time. I also don't always get all the responders in a scene to respond to a scene command reliably. In researching the issue on the forum, it sounds like v35 Switchlincs are the culprit. Has this been proven definitively? If so, several questions: - Does this affect the dimmer and relay switches? - Is this being treated as a known issue by Smarthome? In other words, are they accommodating people by replacing these switches with equivalents that don't have the firmware issue, even if they're out of the warranty period? - Are there users on this forum who have seen their communication issues resolved, as described above by the replacement of all the v35 switches on their network? I have 12 of these v35 Switchlincs on my Insteon network. After trying various approaches to fix the problem, I'm wondering if replacement will take care of my issues once and for all. It would truly be nice to have a reliable system going.

I've been using an ISY for several years now. I have questions about some features with ISY and Insteon - the primary one being the purpose of scenes. The Admin Console allows one to create a scene for a group of switches/devices. Activate the scene, and the responders in the scene should respond. I get that. What I don't understand is what you do with the individual devices defined in the scene. For example, you can theoretically set a different ramp rate and on level for individual Switchlinc dimmers in a scene. What does that actually mean? If I toggle a paddle in a 3 or 4 way switch circuit, the lights turn on using the ramp rate and on level defined in the scene. This is true regardless of the switch in the scene this was done from. So far, I haven't figured out what the individual device settings are supposed to be used for. Anyone care to comment?

When I had the resource successfully running in 2.8.16, the address used was not localhost but the computer's local IP address. This worked at that time, but no longer. Using the (Test) button at the bottom of the panel in the Admin Console, upon first invocation, I get a "Request Failed" error, with N/A showing in the Resource Response window. From my browser running locally, I can call the same URL and get a response. What is wrong here?

I created a network resource which was created while my ISY was running firmware version 2.8.16. My system became unstable for some reason, and I restored an old backup which didn't contain the resource and then upgraded to firmware version 3.1.9. After recreating the network resource, I found that it would not run the command specified from the Admin Console. I tried the same URL in a browser and verified it works. What is the next step in identifying the problem? The URL looks something like this: http://localhost/~username/script.php?q=run The network resource definition looks like this: GET /~username/script.php?q=run HTTP/1.1 Host: localhost:80 Content-Length: 0 in Raw Text format.