matapan

Beyond lighting and power controlled appliances, alot of applications seem to employ some kind of motor that open and closes things. Things like draperies and blinds, windows, vent registers, etc. Never having dealt with motors of this type before, can anyone direct me to a site that has basic info how to set up and use motors for these kinds of applications? There are specific questions I have about motors: - When does one use a stepper motor or a servo motor? Are there specific circumstances one is used over the other? - Beyond a simple manual on/off function, do these motors have any kind of sense when they should turn off by themselves? I was wondering how certain motors will turn off when a limit has been reached (e.g. when a curtain is fully open or closed). Is this mostly done by resistance or by timing? - Motors have a torque spec that is a number. How does one relate this value to a real world application, whether or not it's enough or more than enough torque for the job? - Are there certain pitfalls to watch out for? If it's going to be automated, it should work pretty reliably and have some kind of fail safe, right?

LeeG and BrianH: Thank you for your informative and extremely helpful posts. I could not figure out on my own why the local load could not be controlled from a secondary button. The Insteon device firmware spreadsheet is very useful for those who have any kind of Insteon product less than new!

LeeG: Unfortunately, I don't. The closest thing I have is a dual band Switchlinc relay, which is not a suitable device for this test.

LeeG: I have ISY99 firmware version 3.1.13 and console version 3.1.13.

LeeG: Here is the Event Viewer trace for the following actions: 1. Select Keypadlinc Secondary button (e.g. Button in scene. 2. Adjust the load defined in the Insteon scene to 75% 3. ISY momentarily displays update status dialog. 4. When update status dialog disappears, select another button in scene (e.g. Button A), then select button B. Sun 12/11/2011 09:45:30 AM : [iNST-ACK ] 02 62 07.8D.64 0F 11 BF 06 LTONRR (BF) Sun 12/11/2011 09:45:30 AM : [iNST-SRX ] 02 50 07.8D.64 13.22.2E 2B 11 BF LTONRR (BF) Sun 12/11/2011 09:45:30 AM : [standard-Direct Ack][07.8D.64-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 12/11/2011 09:45:30 AM : [ 7 8D 64 1] ST 191 Sun 12/11/2011 09:45:30 AM : [All ] Writing 1 bytes to devices Sun 12/11/2011 09:45:30 AM : [iNST-ACK ] 02 62 07.8D.64 0F 24 00 06 (00) Sun 12/11/2011 09:45:30 AM : [iNST-SRX ] 02 50 07.8D.64 13.22.2E 2B 24 00 (00) Sun 12/11/2011 09:45:30 AM : [standard-Direct Ack][07.8D.64-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Sun 12/11/2011 09:45:30 AM : [7 8D 64 1 ] Memory : EPROM Refreshed

LeeG: Exactly. The load, Keypadlinc 6 Button is defined with an 85% light level for the Insteon scene associated with button A. Change the focus from button A to button B (or anything, for that matter) after the writes to button A scene have completed. The scene will retain the settings for button all other devices in the scene except the Keypadlinc load, in your example 'Keypadlinc 6 Button'. OberKC: I tried air gapping the Keypadlinc to power cycle it. This didn't allow the Keypadlinc Load definition in a scene to be retained.

I am using the latest ISY firmware version 3.1.13. The Keypadlinc version is 1.3. Firmware version is 29 Simply put, the local Insteon scenes for the Keypadlinc load are not being preserved. Selecting another of the local Insteon scenes, then selecting the one whose light level for the load had been modified results in the light level for the load reverting back to 100%. The updates appear to be written to the device successfully each time the updates are applied.

LeeG: Buttons A, B, C, D- these are the secondary buttons on the Keypadlinc. Local Scene Settings - these are the individual Insteon scenes settings for the individual controllers in the ISY scene. The overall scene has ramp rates and light levels defining it. Each individual controller in the scene can have a different setting. Not sure what the official term for this is. All of the responders retain their On level and ramp rate except the Keypadlinc load, which is also a responder. You can set it, but it always goes back to 100%, instantaneous ramp rate. No button grouping is involved. So, buttons A, B, and C on the Keypadlinc are controllers in an ISY scene in which the Keypadlinc dimmer, Lamplinc, and Appliancelinc are responders. The local Insteon scene for each Keypadlinc button is defined as follows: A: Keypadlinc load: 85% ON level, 2 second ramp rate, Appliancelinc: 100% ON level, 0 second ramp rate, Lamplinc: 85% ON level, 2 second ramp rate B: Keypadlinc load: 5% ON level, 2 second ramp rate, Appliancelinc: 100% ON level, 0 second ramp rate, Lamplinc: 0% ON level, 2 second ramp rate C: Keypadlinc load: 5% ON level, 2 second ramp rate, Appliancelinc: 0% ON level, 0 second ramp rate, Lamplinc: 85% ON level, 2 second ramp rate The problem is that when the Keypadlinc load is set for B or C, it looks like the ON level and ramp rate are set, but if you navigate away from the device, then return to it, the Keypadlinc load is reverts to a 100% ON level, instantaneous ramp rate setting. All the other devices save their ON level and Ramp Rate settings. Why can't I save the ON level for the Keypadlinc load in a scene?

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?