Chris Jahn

Then Set Scene 'Scene: USO A' Off $Test.Temp = $Test.Code $Test.Temp *= 10 $Test.Temp += 1 $Test.Code = $Test.Temp Hi ergodic, The reason you need to use a temporary variable is that each calculation sends out a new event, but I think you are only concerned with the final value. We may be able to change this behavior slightly in the future, but there are no plans to do so at this point. e.g. The following will send 2 events, 1) $Test.Code = 10 2) $Test.Code = 11 Then $Test.Code = 10 $Test.Code += 1 For a temporary variable, you may want to use an integer variable instead of state variable because it does not send out an event when its changed, and it does not start an iteration in the program test/run cycle.

The time setting feature is only in the Totaline/Venstar thermostat adapters v.D4 or higher, it is not currently supported in the Insteon Thermostat or the Insteon Wireless Thermostat. I cannot verify it works for all Totaline/Venstar thermostats, but I suspect it does. FYI, all development was done using a thermostat adapter connected to a 1-day programmable Totaline thermostat (P374-1700)

Hi Gary, This feature was only recently added to the Insteon thermostat adapters and therefore it is likely your adapter does not have the minimum firmware level of v.D4.

It was no trouble at all, I'm happy to hear that you figured out the root cause of the problem.

Hi Lou, This is key because a loss of connection definitely explains the blinking problem, so I'm wondering if your Elk connection has been dropping off more often with the new build. In looking at the code, we weren't always do a query after reconnect, so we'll fix that. Is it possible for you to recreate the problem without the connection dropping?

Hi apostolakisl, Well this one has me stumped, I cannot recreate it at all. Can you please recreate it with the event viewer on max and post the results. I'm wondering if something unrelated is causing this problem somehow.

Hi hbsh01, They mean the same thing, and there should be no differences. The 'Heat'/'Cool' nodes exist so they can be used as controllers in a Insteon scenes.

Ok, while it is flashing yellow, restart the admin console and see if it still flashes yellow. If its still flashing yellow then ISY thinks its still in exit timer mode (indicating a comm problem between ISY and Elk), if its not then its a problem with events being sent to the admin console.

Something is just odd here, I have been blasting my ISY with activity while arming night mode and haven't been able to reproduce this even once. If you restart the Admin Console, is it still blinking yellow? Did you make any changes to your Elk setup?

I do not think it should still be blinking. The blinking means the timer is going, for example, you may have a 30 second exit timer that gives you 30 seconds to leave the area before the alarm is fully armed. I have been unable to reproduce this problem, is there a lot of activity (Insteon, Elk, etc.) around the time these were armed?

Hi apostiolakisl, Can you please try to capture this in the event viewer (max level) to help identify the cause of this problem. Did this happen at ISY startup, or did it just randomly happen sometime after that? If you disable Elk then enable it again, does the status show up correctly?

Hi Steve, When you go to the Thermostats tab under Elk, do you see the temperature values for your thermostats? If so, are you sure the ID you are specifying in your variable is correct?

Hi Steve, Are you referring to the temperatures available on Elk keypads, zones, and thermostats? If so, they are available as shown in the wiki: http://www.universal-devices.com/mwiki/ ... _Variables

Hi Steve, For the first two, you will only see node[14 85 E5 1] if it cannot find the node, therefore make sure your device address is correct. Is it possibly 14.B5.E5 instead of 14.85.E5 ? For the value with all the �����s, I just looked at the code and this is a bug (will be fixed for the next beta drop). The bug occasionally causes a corrupted value to be created if the actual value of ST is either 0 (Off), or 100% (On).

Hi hbsh01, You are correct in that it reports the setpoint status when it changes, but this is unlike buttons for example that send an actual command to a remote device (such as Fast On) when the button is pressed. If we set up heat/cool setpoint as a control, the condition would be true regardless of how that setpoint was changed (manually, or through a scene, or through a program, etc.). We may be able to isolate it some cases, but I'm not sure that we can reliably detect if the setpoint was changed manually at the thermostat or not.

Hi hbsh01, We cannot detect manual changes at the thermostat (such as setpoint up/down for example), therefore there is currently no way of doing that. A Control condition is based on an event originating from the device either manually (e.g. a button press on a KPL) or automatically (e.g calling for cool/heat)

Hi Slalom, This issue is actually caused by Elk sending a steady stream of ready/not ready messages when both Area 1 and a common area is not armed. They are aware of the problem and are currently looking at possible solutions. A suggested work-around is to not use common areas for now, and instead use Isy and/or Elk rules to accomplish the same.

Hi Guys, 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 00.00.04 C7 13 00 LTOFFRR(00) 6:52:25 AM : [standard-Group][05.15.36-->Group=4] Max Hops=3, Hops Left=1 6:52:25 AM : [ 5 15 36 4] DOF 0 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 41 13 04 LTOFFRR(04) 6:52:25 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=1, Hops Left=0 6:52:25 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 42 13 04 LTOFFRR(04) 6:52:25 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=2, Hops Left=0 6:52:26 AM : [iNST-SRX ] 02 50 05.15.36 19.75.34 47 13 04 LTOFFRR(04) 6:52:26 AM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Max Hops=3, Hops Left=1 6:52:26 AM : [iNST-ACK ] 02 62 00.00.10 CF 13 00 06 LTOFFRR(00) 6:52:27 AM : [ 5 15 36 4] ST 0 6:52:27 AM : [iNST-ACK ] 02 62 00.00.14 CF 13 00 06 LTOFFRR(00) 6:52:27 AM : [ 5 15 36 1] DOF 4 I noticed that ISY thinks 'Master Bedroom / Master Keypad' was pressed, but I'm not seeing the traffic that would tell us its been pressed. 6:52:27 AM : [ 5 15 36 1] DOF 4 I'd normally expect to see the following prior to that event ... [iNST-SRX ] 02 50 05.15.36 00.00.01 C7 13 00 LTOFFRR(00) ... but instead we are receiving the cleanup messages but interpreting them incorrectly (i.e. treating the following as DOF for the main button, not button 4 (Button [iNST-SRX ] 02 50 05.15.36 19.75.34 47 13 04 LTOFFRR(04) I'm trying to recreate this problem now. Can you please tell me what the exact device type is for 'Master Bedroom / Master-Cans over Bed L' ?

Hi apostolakisl, Thanks for the update, if this happens every time please do two things: 1. - Turn on the event viewer, and select the highest level of logging (Device communication events). - Reproduce the problem, and post the events you see in the event viewer. 2. - Create a new program with identical conditions, but just increment a variable in the then path (no other actions). - Reproduce the problem, and see if the new program runs the then/else the same as your original program (by watching changes in the variable).

Thanks for the feedback, We are still working on the Elk common areas, and the -60/-40 temperature values shown in the Admin Console.

Here's an alternative solution ... viewtopic.php?f=26&t=5283

Generally its more efficient to use a variable because its all done in memory (RAM), unlike enable/disable of a program which writes a file to the SD card each time.

Hi Barkster, There are many ways to write a blink program depending on the conditions etc. required for it. In your case, you can accomplish this with one program that also guarantees the blinking light will be turned off when it stops blinking. This program will start blinking when A1/On is received, and stops blinking when A1/Off is received. If X10 'A1/On (3)' is Received And X10 'A1/Off (11)' is not Received Then Repeat Every 0 seconds Set 'My Light' Fast On Wait 2 seconds Set 'My Light' Fast Off Wait 2 seconds Else Set 'My Light' Fast Off

Thank you so much!

The problem is that it will use the event that caused the program to run, and in this case, that last event will be an armed up event. You may be able to accomplish what you want by splitting it into two programs, but its going to be tricky. I think you would need the first program to have only armed conditions and a 10 second wait (similiar to what you have), and have a second program stop the first program within 10 seconds if it doesn't actually arm. Aha, of course you could change it to use the actual area, since you know it is 'Williams', assuming 'Williams' is area 1, the variable would be ${elk.area.1.armedState}