Grizzy Posted March 9, 2015 Posted March 9, 2015 Hello, I had everything running smooth until I had a power loss to my isy. After reset several of my programs using the hidden door sensors were erratic and unpredictable. I suspect the cause was a null value in the sensor field for each door sensor. Once each and every door was opened and closed one time every thing was again ok. Because each sensor was pre-tested they all had either an on / off value, such that when entered in a program they worked fine. Doing a query will not work on the battery device. So how can I write the program to deal with the null condition until the sensor reports to the isy the first time. Here is a partial part of the program as I have it now. If ( Status 'Door 1 Sen (2C.73.62)' is Off Or Status 'Door 2 Sen (32.8E.CE)' is Off Or X10 'A12/On (3)' is Received ) And $i_Alarms_On is not 3 Then Wait 3 seconds Run Program 'Alarm Audible' (Else Path) Disable Program 'Garage M1 Motion' Disable Program 'Garage M2 Motion' Disable Program 'LT Bldg M1 Motion' Disable Program 'Front Driveway Sensor' $i_Alarms_On = 3 $s_Alarms_On = 3 Send Notification to 'Donald' content 'Alarm Disarmed' Set 'X10 Devices / A12 Disarmed' On Set 'X10 Devices / A11 Silence Delayed' Off Set 'X10 Devices / A10 Arm' Off Else - No Actions - (To add one, press 'Action') Thanks Don
stusviews Posted March 9, 2015 Posted March 9, 2015 Writing a program to "Enable Run at Startup" that will "Write Device Updates" for each battery powered device may do what you want.
Jimbo.Automates Posted March 9, 2015 Posted March 9, 2015 The write device updates only works when the device wakes up. I use a state variable to track the status of all my open/close sensors just for this reason. Each time the status changes a program sets the state variable, along with the init to value. Sent from my Nexus 7 using Tapatalk
Xathros Posted March 9, 2015 Posted March 9, 2015 I would suggest the following change to the example program: If ( Control 'Door 1 Sen (2C.73.62)' is Switched Off Or Control 'Door 2 Sen (32.8E.CE)' is Switched Off Or X10 'A12/On (3)' is Received ) And $i_Alarms_On is not 3 Then Wait 3 seconds Run Program 'Alarm Audible' (Else Path) Disable Program 'Garage M1 Motion' Disable Program 'Garage M2 Motion' Disable Program 'LT Bldg M1 Motion' Disable Program 'Front Driveway Sensor' $i_Alarms_On = 3 $s_Alarms_On = 3 Send Notification to 'Donald' content 'Alarm Disarmed' Set 'X10 Devices / A12 Disarmed' On Set 'X10 Devices / A11 Silence Delayed' Off Set 'X10 Devices / A10 Arm' Off Else - No Actions - (To add one, press 'Action') This way it's not based on status but rather door events. This doesn't solve the unknown state after a power cycle but should not be confused by it either. -Xathros
Grizzy Posted March 9, 2015 Author Posted March 9, 2015 Xathros, I tried using control in place of status earlier and if I remember I had problem with it triggering the program and when I changed it to status it worked. This has been awhile back when I first wrote it so I not sure, I just remember I had used control. I am rewriting the code using variables as Jimbo suggested. I do not understand why it will help because the same status program sets a variable rather than running the program ? I would appreciate if someone can explain why the difference and what is actually happening when the program evaluates a NULL. It seems like the command "if Status xxx = On" would evaluate false on a null value ?? I will try using the "Command" rather than "Status" again and see what happens. Thanks all for your ideas. Don
LeeG Posted March 9, 2015 Posted March 9, 2015 (edited) The Variable is never Null. The Variable is set to the Init value when the ISY boots up. The Variable may not be accurate if the door is moved while the ISY is down but the value is never Null. Edited March 9, 2015 by LeeG
Grizzy Posted March 9, 2015 Author Posted March 9, 2015 The Variable is never Null. The Variable is set to the Init value when the ISY boots up. The Variable may not be accurate if the door is moved while the ISY is down but the value is never Null. Ok that makes sense, when the program that sets the variable does see a null, the results maybe unpredictable but the main controlling program always sees a real number and can follow a determined path and not get lost in a loop. Am I thinking correctly ?
LeeG Posted March 10, 2015 Posted March 10, 2015 The Program that is triggered by the change of state of the Sensor and sets the Variable value and Variable Init value should not be triggered until the Hidden Door Sensor actually sends either an On or Off message. Any Program that does something based on the state of the Sensor should check the variable value rather than the Sensor state.
Grizzy Posted March 10, 2015 Author Posted March 10, 2015 The Program that is triggered by the change of state of the Sensor and sets the Variable value and Variable Init value should not be triggered until the Hidden Door Sensor actually sends either an On or Off message. Any Program that does something based on the state of the Sensor should check the variable value rather than the Sensor state. How can I wait to set the variable until each sensor actually reports an on or off ?
Jimbo.Automates Posted March 11, 2015 Posted March 11, 2015 Use if control instead of status like Xathros mentioned in post #4
Recommended Posts