matapan

OberKC: I was actually think more along the lines of a motion sensor, not a contact sensor for a door, for the same reasons you cited. The closest I've been able to come to is trying to find a countdown period which eliminates the false readings but which isn't too long so as to be energy inefficient, then adding a manual override condition in the form of a third program which just checks to see if the circuit was manually turned off or not and adding the logic to the other two programs accordingly. I'm curious if anyone has found better occupancy check that more closely follows the user's intent and optimizes energy savings without becoming a detriment to the equipment being controlled (minimize on/off cycles as much as possible).

What are the functional differences between the Insteon and X10 motion sensors, beyond the communication reliability aspect of these devices? There's the fact that Insteon motion sensors have a state that can be readily checked, whereas the X10 device does not. But one can accommodate state checking by creating a simple program as a retainer for the X10 motion sensor's state: Motion Sensor On State Check: If X10 'A1/On (3) is received Then Run Program 'A1 Motion Sensor State' (Then Path) Else -- No Actions -- Motion Sensor Off State Check: If X10 'A1/Off (11) is received Then Run Program 'A1 Motion Sensor State' (Else Path) Else -- No Actions -- A1 Motion Sensor State: If -- No Condition -- Then -- No Actions -- Else -- No Actions -- The status of the program 'A1 Motion Sensor State' tracks the motion sensor state - True means the motion was sensed, false means no motion. I know, more work just to track the state of a motion sensor, but the cost differential is pretty big - if you deploy lots of sensors, that's a lot of money. Any real functional advantages of using the Insteon motion sensor?

The general objective is to qualify occupancy, to discriminate between a quick in and out of a room vs. true occupancy in the fastest way possible. "Buffering" checks using a motion sensor on entry and exit seems to be one approach. Not sure if there are any better ways. I've coded the exit check in two programs: Program Test1: If Status 'Sensor' is On and 'Target Device Controlled' is Off Then Set 'Target Device Controlled' On Else -- No Actions -- Program Test2: If Status 'Sensor' is Off and Program 'Test1' is False Then Wait Set 'Target Device Controlled' Off Same kind of program for entry check, but that's not optimal; for lights, that might be okay, since most people turn a paddle on by themselves manually. For climate control, a buffered entry check isn't optimal because it takes a while for the temp to adjust, and the shorter the wait time, the better. I'm wondering what a better entry check might be, to discriminate between a quick in and out of a room and a true occupancy scenario.

Thank you LeeG for the explanation regarding program evaluation and when they occur. I am still trying to wrap my head around event programming, especially evaluations and preventing infinite loops. In a different example, say you want to check on a change of state several times before committing a device state change - taking multiple state samples. In pseudocode, I imagine the logic would work like this: if is ON then turn on else wait 1 minute check the if the is still OFF then turn OFF So, in ISY, is this best done in 3 programs, where the first program sets the target device on if the trigger device is on, with the else clause passing off to another program, which evaluates the previous program state, along with the trigger device state, etc? Or, is there a better way? As a debugging aid, is there a good way to get the program summary page to refresh automatically when program states change?

LeeG: Here's one program that runs through the Then path, but evaluates to False on the summary page. It's my garage door opener program: If Status 'Garage -Sensor' is On And Control 'Keypadlinc Garage Door Button' is Switched On Then Set 'Garage - Relay' On Wait 5 seconds Set Garage -Relay Query Else - No Actions - I know the program runs through the Then path because the relay is energized and the garage door opens. Based on what I read in the Wiki, I think the program should evaluate to 'True' after execution. It does show up as False through in the Summary.

According to the Wiki's Condition page: "The program state is set to True when the program enters the Then path and False when it enters the Else path. Folder conditions can be set based on the program state. This state is also reported in the Status column in the program summary table." I have some programs that are evaluated and run the Then path, yet their status shows as "False". I am running firmware version 3.1.14. Is there anything which would contribute to the program state being evaluated as "False" when it did run through the Then path in the program?

What are the amperage requirements for the Venstar thermostat? I found a 24VAC AC adapter supplying 1.25 amps. Is this a suitable supply?

I have a 7 day programmable Venstar thermostat with the Insteon adapter installed. Is it possible to query for the program settings for Morning, Day, Evening and Night and use this as part of the logic in a program?

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?