matapan

I have a scene that doesn't work as I expect. Can anyone offer any suggestions? The scene consists of a 6 button Keypadlinc carrying a load, an Appliancelinc, and a Lamplinc, called devices A, B, and C respectively. The above 3 devices are responders in a scene: A, B, C Three of the buttons on the Keypadlinc are controllers in the scene: Button1, Button2, Button3 I defined the local control of the scene as follows: Control Button: Button1 Light Level: A - 85%, B - 100%, C - 85% Control Button: Button2 Light Level: A - 5%, B - 100%, C - 0% Control Button: Button3 Light Level: A - 5%, B - 0%, C - 100% I've left the ramp level out for simplification. The load carrying device does not keep its setting for the local scene setting. In each case, A is set, but reverts to 100% if you select a different row, then select the same row again. Is there a reason why I cannot save the local scene setting for the Keypadlinc load device? All the other devices defined in the local scene have their settings preserved. I don't see any external references to the Keypadlinc load device, except in another scene where the device is a responder. I tried restoring the Keypadlinc device to no avail. As a standalone device, the device keeps its light level and ramp rate settings just fine. Is this a bug?

Thank you for the replies! So, programs with no conditions will not run, unless there's a calling program that will reference the appropriate branch. The program with the condition does run, but the folder with the condition and program with no condition within it does not. Makes sense now.

What's the difference between how ISY evaluates a conditional program and a folder with the same condition as the conditional program which also contains a program with no condition? Example Conditional Program: if status 'motion sensor' is on and status 'motion sensor' is not off then set 'lamp' on else set 'lamp' off Example Folder and Null Condition Program: Folder Conditions for 'Occupied' if status 'motion sensor' is on and status 'motion sensor' is not off then allow programs in this folder to run Program: if No conditions then set 'lamp' on else The conditional program behaves differently from the folder with a null condition program. Why?

LeeG, Thanks for your reply. It was worth the effort to replace them. I ran scene tests before and after the v35 Switchlinc replacements. I had a total of 10 of these devices. I would inevitably get some kind of failure running a scene test before. No failures whatsoever after replacement. I wish I knew earlier that these Switchlincs were directly causing the comm errors I was seeing up until now. Maybe the absence of these errors means that my scene commands will work more reliably now.

Interesting. It would be very instructive if someone could explain how ISY variable(s) can be updated externally.

Thanks, wrj0. I get the jist of it. Does your startup program call a series of programs to start watchdog timers desired each time the ISY is restarted?

What is the impact of deleting a motion sensor, or any other battery operated device for that matter that the Admin Console requires you to place in linking mode to complete the delete operation? If one will never see the device again, presumably all the cleanup on the controller/PLM is complete, and the any references in the battery operated device need to be cleaned up. Is this the case? If so, is there any problem deleting the device node in the Admin Console if the device will never be on the network again, and it is not possible to put the device in linking mode to complete the documented step?

Can anyone think of a way in which the scheduled On Off times for a device can be updated dynamically? Can these times be fed to ISY from an external source? Before Example (Pseudocode): At Sunrise - 45 minutes Then Turn On Front Porch Lights After Example: At for a duration of Then Turn on Front Porch Lights and fed to ISY via external source (e.g. email, insteon relay device state, etc.) It would be nice to mimic some of the predictive capabilities of the Nest thermostat by processing the ISY log information from time to time and creating programs that are more elastic and accommodating to the user.

wrj0: Writing a program to check daily for any sensor traffic sounds like a good approach. What does the code for the condition look like?

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?

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.

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?