
LeeG
Members-
Posts
12943 -
Joined
-
Last visited
Everything posted by LeeG
-
The Program will trigger on each Motion On message. If using Occupancy mode or a short timeout value (less than 3 minutes random) and motion continues to be sensed the 'LvngRmRec' light will remain On and no email will be sent. Once the motion On messages stop flowing for 3 minutes random the 'LvngRmRec' will turn Off and a notification will be sent.
-
Actually the worst of the possible problems do not exist. The motion sensor is working and the ISY is hearing the motion sensor messages. From the Admin Console issue a Fast On to the Loft light. Since the Program Fast On is not working I expect the Admin Console Fast On to also not work unless a Program change was made and a Save was not done. You can remove all the Jumpers except 5. Jumper 1 reduces the motion sensor sensitivity when in place (both pins). Not normally done unless a pet or trees/wind is causing false motion messages.
-
captfisk When Jumper 5 is in place (both pins) only Jumper 1 (sensitivity) has any affect. Jumpers 2,3,4 and the pots are not used when Jumper 5 is in place. Does the Motion Sensor - Sensor node reflect On/Off status as motion is detected? Assuming Off commands have not been suppressed the Sensor node should be On for at least 30 seconds. That is the minimum programmatic timeout value. The Program looks correct. Lee
-
wharris Use the Admin Console and send a Fast Off command to a specific InLineLinc with Sense (not using a Scene). Does the specific InLineLinc with Sense react to the Fast Off and no longer turn On in response to motion? Lee
-
I don't think the problem is a failure to run the Program. The symptom is much more consistent with an intermittent powerline communication issue with the pool location.
-
There is an ISY User Guide which can be downloaded and printed if hard copy is preferred. Define an ISY Scene. Add the KPL button to the Scene as a Controller Add the Switch to the Scene as a Controller When the ISY is done the KPL button and Switch will be cross-linked such that either can turn the load On/Off and both will reflect the On/Off status. Functionally equivalent to using the Set button method to cross-link the KPL button and Switch. Do not use the Set button method to establish links. Besides being able to use either the KPL button or Switch, the Scene name can be used in an ISY Program to turn the Scene On/Off. Also by selecting the Scene name in the Admin Console the Scene can be turned On/Off Note that the ip addresses you refer to are actually Insteon device addresses, not ip addresses.
-
Afraid so. The MorningLinc is linked to the lock set using Set button linking. The ISY cannot do that because of the security between the MorningLinc and the lock set. Then the MorningLinc is added to the ISY, using the "keep existing links" option to prevent destroying the Set button link between the MorningLinc and the lock set. Wiki indicates the ISY cannot control the MorningLinc/lock set if the Set button link is deleted. The Wiki does not specifically state the solution but I would assume the MorningLinc has to be linked to the lock set again using the Set button. Delete the MorningLinc from the ISY before doing the Set button link as Delete erases the MorningLinc link database. After the manual Set button link, add the MorningLinc to the ISY using the "keep existing links" option.
-
When the MorningLinc was added again, was the keep existing links optiion used?
-
raydoc A KeypadLinc button can be assigned to the Scene by doing a right click on the KPL button node and select Add to Scene ... A popup will display listing the Scenes. Select the Scene and either add it to the Scene as a Controller or Responder. If added as a Controller it will also be added as a Responder automatically (if node has responder capability). Lee
-
dstrohl Are the Programs Enabled (Enable column shows On)? Do either of the Programs show Not Saved in the Activity column? Is the time shown across the top left of the Admin Console screen correct? Is the Program in a Folder which has Conditions? Under the Program | Details screen right click on the Program name, select Copy to Clipboard and post Program Lee
-
That is correct. There is no guarantee the Program started at 12:00:00 will complete before the Program started at 12:00:01. They run independently.
-
First problem resolved. Run the Event Viewer and press the KeypadLinc button that is expected to trigger the Program, post the event log.
-
There are threads that have higher priority than User Program threads. For example, when Insteon device message traffic enters the picture. Without that a long running Program clause could block other Program execution. Once the currently executing user Program thread has been interrupted by a higher priority thread, how the OS dispatches the lower priority interrupted threads will not be predictable from an individual Program perspective. When Program A “Runs†Program B each Program runs independently on their own thread. A “Call Program B†is the term often given to a thread transferring instruction execution to another Program/subroutine, continuing at the same task/thread level. The only way Program A and Program B can be serialized is to have a "Wait on Program B to complete" or “Wait on Program B to post an event Program A is waiting on†function. That function does not exist at the user Program level. This is standard multi tasking stuff. It applies to every multi tasking OS I have worked with over 40+ years. Nothing unique to the ISY Programming model. An event driven multi thread model is essential with automation. It would certainly make Programming concepts easier if things were linier but that model cannot work in a world based on device button/paddle presses and time specific events.
-
I would not assume the clause of a called Program will run to completion before the calling Program continues. From the UDI Wiki … “Within the Then or Else clause of a program, statements are executed from top to bottom in the order in which they occur. When a statement calls another program, the called program begins executing, and the calling program immediately continues execution with the next statement in sequence--it does not wait for the called program to complete before continuing.†The tasking of an OS is unpredictable in real life. The various threads in the ISY OS that have priority will change the execution order of that simple test. Without a specific task wait on another task capability Program execution will vary.
-
I have no explanation for what you are describing. For a Restore Device to work but not show status changes, very odd. There are some basic things to try, unplug the PLM for 60 seconds, reboot the ISY, clear the Java cache, be sure the PLM is not plugged into a surge suppressor strip or UPS. After rebooting the ISY click on My Lighting to display a summary of all the devices. Do any show On/Off status? If they do does the status change when a button/paddle is pressed for that device. For a device to indicate a status change valid link records must exist in the device and the PLM. The Restore Device would have rewritten the link records in the device and the PLM for that particular device. Even if the other PLM link records had been erased the one device should be working. A shot in the dark would be to factory reset the PLM (not the ISY) and do a File | Restore Modem {PLM}.
-
What do the ramp rates show for the various devices?
-
Suggest picking one device and doing a Restore Device to see if that restores communication from the device to the ISY. With none of the devices showing status changes there may an issue with a firewall that is blocking device status changes from reaching the Admin Console. Do you know if the Admin Console ever showed device status changes.
-
buzzhazzard Run Tools | Diagnostics | Event Viewer with Device communications events selected (important). Press the KPL button and see if there are Insteon messages generated in the Event Viewer window. If no messages are seen there are likely communication problems between that KPL and the ISY PLM. If there are messages generated please post the messages. Lee
-
Something is blocking the push of device status/information from the ISY. Perhaps something with the firewall.
-
The I/O Linc Relay status will normally always be On. The ISY indicates the last command sent to the Relay which is normally On. The timer in the I/O Linc turns the Relay Off after the defined time when in any of the Momentary modes but the I/O Linc does not notify any of the linked devices of that action. Thus the Relay is Off but the ISY indicates On reflecting the last sent command. The Relay status cannot be used in ISY Programs as a result. The I/O Linc Sensor should reflect whether the door is Open or Closed. The Sensor can indicate On or Off with door open. Depends on whether using the NO or NC portion of the magnetic switch and whether the I/O Linc Trigger Reverse option is set.
-
There was a time when both 32 and 64 bit Java install was required. Don't know if it still applies. Also does the Vista PC have the same trust level at the router the laptop does.
-
dstrohl Look at the Programs | Summary tab and see what the Last Run Time column shows for the two Programs. That will show if the Programs have been Triggered. Lee
-
CJVann The device interface supports setting the beep duration, the current device firmware seems to ignore the beep duration for now. It opens the door for possible device support at a later date. I suspect rather than chase the unknown UDI would prefer to use the interface as spec’d and let the device firmware evolve as it will. It is similar to beep itself. Devices that do support beep, some of the older firmware levels do not support beep at all. Rather than chase the beep feature the ISY sets it and those devices with later firmware react to it. Lee
-
CJVann The devices produce a chirp rather than a beep. Duration has no perceptible impact. Backlight LED Off/On levels are interrelated. There is always a minimum relative difference between Off and On levels regardless of values defined. As the Off level increases so does the On level to maintain the minimum difference between Off and On. The device firmware maintains this relationship regardless of the Off/On levels. Although the On level can be set lower than the Off level the device firmware will maintain a relative Off/On level Lee
-
gakran If the post was not a finger check and the ISY is at 2.8.6 move to 2.8.16. It looks like a Program is running in a loop. A Scene is repeatly being turned On. Sat 09/03/2011 05:19:28 PM : [iNST-ACK ] 02 62 00.00.10 CF 11 00 06 LTONRR (00) This is interferring with the update. Disable all the Programs and see if that helps. Lee