Or I can do it via scenes with delayed actions to turn it off 1 min later and conditions would be night only and XBMC not playing.
@RexBeckett, how log does it normally take for a response from micasaverde? I have also noticed that even thought the time and date are correct in the UI, when I use the automation tab to see when a scene ran last the date is 29 days ahead
Sent from my iPhone
how log does it normally take for a response from micasaverde?That varies a lot. If you haven't had a response after a week, try an email to support@getvera.com
I have also noticed that even thought the time and date are correct in the UI, when I use the automation tab to see when a scene ran last the date is 29 days aheadAre you sure Vera's date and time is set correctly? Note that the time shown on the UI comes from your PC not Vera. You can see Vera's date and time by looking at the latest LuaUPnP.log entries. See [url=http://wiki.micasaverde.com/index.php/Logs]Logs[/url].
Vera time gets set via your network when it reboots (through power-cycle or SETUP → Net & Wifi → Reboot). If your network is not running when Vera reboots, the time will not be set correctly.
Debugging Lua code in scenes can be very frustrating. When something doesn’t work as you expected, you need to be able to see which parts of your code are being executed and, often, the value of key variables. Vera provides luup.log(…) to help with this but it is not always easy to find your log entries in LuaUPnP.log with all the other activity there.
kwikLog is a simple function that logs your messages, with a time stamp, to a standalone file. The file may be viewed from a browser by entering /kwikLog.txt. A browser page refresh will show you the latest entries.
You can use kwikLog in several ways:
[ul][li]Add it to your scene Lua (above where you call it from your code)[/li]
[li]Add it before code you run in Test Luup code (Lua)[/li]
[li]Add it to Startup Lua so that you can use it from any scene[/li][/ul]
If you add it to Startup Lua (APPS → Develop Apps → Edit Startup Lua), remove the word local from the first line.
local function kwikLog(message, clear)
local socket = require("socket")
local time = socket.gettime() or os.time()
local tms = string.format(".%03d ",math.floor (1000 * (time % 1)))
local stamp = os.date("%d %b %Y %T",math.floor(time)) .. tms
local mode = "a+"
if clear then mode = "w+" end
local file = io.open("/www/kwikLog.txt", mode)
file:write(stamp .. (message or "") .. "\n")
file:close()
end
kwikLog has two arguments: The string you wish to log and, optionally, true if you want to clear the log file. If the second argument is missing or false, log messages are appended to the existing file. You can place calls to kwikLog anywhere in your code so you can see what is happening. For example:
kwikLog("SuperScene started",true)
local status = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",123)
if status == "1" then kwikLog("Light is already on!") end
local level = luup.variable_get("urn:upnp-org:serviceId:Dimming1","LoadLevelStatus",123)
kwikLog("Dim level is " .. level)
if (status == "0") and (tonumber(level) > 0) then kwikLog("This can't happen...") end
etc.
Several users have recently had problems with Sunset and Sunrise triggers due to incorrect location information. As a quick demonstration of kwikLog, paste the following code into APPS → Develop Apps → Test Luup code (Lua) and click GO.
[code]local function kwikLog(message, clear)
local socket = require(“socket”)
local time = socket.gettime() or os.time()
local tms = string.format(“.%03d “,math.floor (1000 * (time % 1)))
local stamp = os.date(”%d %b %Y %T”,math.floor(time)) … tms
local mode = “a+”
if clear then mode = “w+” end
local file = io.open(“/www/kwikLog.txt”, mode)
file:write(stamp … (message or “”) … “\n”)
file:close()
end
kwikLog(“Timezone: " … luup.timezone … " hours”)
kwikLog(“City: " … luup.city)
kwikLog(“Latitude: " … luup.latitude … " degrees”)
kwikLog(“Longitude: " … luup.longitude … " degrees”)
local srtime = os.date(”%c",luup.sunrise())
kwikLog(“Next Sunrise: " … srtime)
local sstime = os.date(”%c",luup.sunset())
kwikLog("Next Sunset: " … sstime)
[/code]
Enter /kwikLog.txt in a browser window to see if your location data is correct. Replace with the IP address of your Vera (without the <>).
Okay so this is pretty strange. I entered the code you supplied to retrieve the time zone and such from my veralite and it returned the following:
06 Mar 2014 21:27:45.025 Timezone: -5 hours
06 Mar 2014 21:27:45.027 City: Swartz Creek
06 Mar 2014 21:27:45.028 Latitude: 42.9382 degrees
06 Mar 2014 21:27:45.030 Longitude: -83.8244 degrees
06 Mar 2014 21:27:45.031 Next Sunrise: Fri Mar 7 07:01:09 2014
06 Mar 2014 21:27:45.033 Next Sunset: Fri Mar 7 18:32:04 2014
Shortly after I pulled the above information, I triggered the scene we have been fooling with and this is information from the log:
06 03/06/14 21:36:12.513 Device_Variable::m_szValue_set device: 39 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Tripped was: 0 now: 1 #hooks: 5 upnp: 0 v:0xb9a730/NONE duplicate:0 <0x2bab9680>
07 03/06/14 21:36:12.514 Event::Evaluate 16 Front Door Light On scene Front Door Light On is true users:(null) allow:1 <0x2bab9680>
08 03/06/14 21:36:12.514 Scene::RunScene running 66 Front Door Light On <0x2bab9680>
50 03/06/14 21:36:12.514 luup_log:0: Scene Debug: Light is off. <0x2bab9680>
50 03/06/14 21:36:12.515 luup_log:0: Scene Debug: startTime = 2332; currentTime = 2136; endTime = 2359 <0x2bab9680>
50 03/06/14 21:36:12.515 luup_log:0: Scene Debug: Skipping actions. <0x2bab9680>
08 03/06/14 21:36:12.516 JobHandler_LuaUPnP::HandleActionRequest device: 61 service: urn:richardgreen:serviceId:VeraAlert1 action: DeviceNotification <0x2bab9680>
08 03/06/14 21:36:12.517 JobHandler_LuaUPnP::HandleActionRequest argument DeviceID=39 <0x2bab9680>
08 03/06/14 21:36:12.517 JobHandler_LuaUPnP::HandleActionRequest argument Description=%20Front%20Door%20is%20tripped <0x2bab9680>
08 03/06/14 21:36:12.517 JobHandler_LuaUPnP::HandleActionRequest argument Name=Front%20Door%20Open <0x2bab9680>
08 03/06/14 21:36:12.517 JobHandler_LuaUPnP::HandleActionRequest argument Service=urn:micasaverde-com:serviceId:SecuritySensor1 <0x2bab9680>
08 03/06/14 21:36:12.518 JobHandler_LuaUPnP::HandleActionRequest argument Variables=Tripped <0x2bab9680>
08 03/06/14 21:36:12.518 JobHandler_LuaUPnP::HandleActionRequest argument Msg=Front%20Door%20-%20Open <0x2bab9680>
08 03/06/14 21:36:12.518 JobHandler_LuaUPnP::HandleActionRequest argument SceneID=88 <0x2bab9680>
08 03/06/14 21:36:12.518 JobHandler_LuaUPnP::HandleActionRequest argument Recipients=kiethr <0x2bab9680>
07 03/06/14 21:36:12.520 Event::Evaluate 20 Front Door Open scene Front Door Open is true users:408711 allow:1 <0x2bab9680>
08 03/06/14 21:36:12.521 Scene::RunScene running 88 Front Door Open <0x2bab9680>
07 03/06/14 21:36:12.521 Event::Evaluate 21 Front Door Open scene Front Door Open is false repeat 0/-1 <0x2bab9680>
07 03/06/14 21:36:12.521 Event::Evaluate 22 Front Door Closed scene Front Door Closed is false repeat 0/-1 <0x2bab9680>
50 03/06/14 21:36:12.524 luup_log:61: VeraAlert:61:SendAlert:Msg:Front Door - Open <0x2b385000>
50 03/06/14 21:36:12.525 luup_log:61: VeraAlert:61:ExpandRecipients:Checking:kiethr <0x2b385000>
50 03/06/14 21:36:12.525 luup_log:61: VeraAlert:61:ExpandRecipients:Adding User Specified Profile:Pushover <0x2b385000>
50 03/06/14 21:36:12.526 luup_log:61: VeraAlert:61:SendAlert:Sending to:Pushover <0x2b385000>
50 03/06/14 21:36:12.527 luup_log:61: VeraAlert:61:PushoverSend:Body:message=Front%20Door%20%2D%20Open&token=axG7NEfje7aHi9z7JqkJNya5K9HGhx&user=8Sw8F92HNwX3sxWYqpwh9CMUrRW5XR&priority=1&sound=intermission&title=Vera%20Alerts <0x2b385000>50 03/06/14 21:36:19.131 luup_log:56: VGinfo: Calling main loop with lul_device: 56 <0x2ceb9680>
50 03/06/14 21:36:19.131 luup_log:56: VGinitPhase: VacationGhost is disabled, sleep and start over <0x2ceb9680>
06 03/06/14 21:36:19.149 Device_Variable::m_szValue_set device: 56 service: urn:upnp-org:serviceId:VGhost1 variable: State was: 0 now: 0 #hooks: 0 upnp: 0 v:0xbf5828/NONE duplicate:1 <0x2ceb9680>
02 03/06/14 21:36:20.101 LOG_CHECK_MEMORY_LEAK pMem start 0x1218000 now 0x1270000 last 0x1256000 leaked 360448 <0x2bab9680>
02 03/06/14 21:36:24.103 ZW_Send_Data node 40 USING ROUTE 18.0.0.0 <0x2beb9680>
04 03/06/14 21:36:24.254 ^C
root@MiOS_35007455:/tmp/log/cmh#
root@MiOS_35007455:/tmp/log/cmh#
It still says sunset is way later than what it is. Tech support tried getting into my box last night however there was an internet outage that prevented them from doing so (just my luck). I think they will try again tonight from the email I received from them. Ill keep you posted.
Yes that is odd. It looks as though it is not correcting sunset for your timezone. If it works in Test Luup, it should work in a scene. Just to complete the picture, add the following at the start of your scene LUUP so all the info is in one place:
luup.log("Timezone: " .. luup.timezone .. " hours")
luup.log("City: " .. luup.city)
luup.log("Latitude: " .. luup.latitude)
luup.log("Longitude: " .. luup.longitude)
local srtime = os.date("%c",luup.sunrise())
luup.log("Sunrise: " .. srtime)
local sstime = os.date("%c",luup.sunset())
luup.log("Sunset: " .. sstime)
[quote=“RexBeckett, post:2, topic:178331”]We often want to allow or block scenes depending on the state of a Z-Wave switch (E.g. a light is on) or a VirtualSwitch (e.g. Home/Away). The VirtualSwitch (VS) plugin is very useful as a means of controlling scenes. You can create several different VS devices to signify various states of your home. E.g. Home/Away, OnVacation, HaveGuests, etc. VS devices can be set manually through the UI, by scenes or with other plugins.
Testing the state of a switch is essentially the same whether it is real or virtual but the serviceID must match the type of switch being tested.
Z-Wave Switch:
local dID = 66 -- Device ID of your Z-Wave Switch
local allow = true -- true runs scene if switch is on, false blocks it
local status = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1","Status",dID)
return ((status == "1") == allow)
Virtual Switch:
local dID = 32 -- Device ID of your VirtualSwitch
local allow = true -- true runs scene if switch is on, false blocks it
local status = luup.variable_get("urn:upnp-org:serviceId:VSwitch1","Status",dID)
return ((status == "1") == allow)
Coming next: Time[/quote]
Trying to adapt this for a multiswitch. Any thoughts?
Multi switch ID = 175
Desired switch = Status2
local dID = 175 – Device ID of your VirtualSwitch
local allow = true – true runs scene if switch is on, false blocks it
local status = luup.variable_get(“urn:upnp-org:serviceId:VSwitch1”,“Status2”,175)
return ((status2 == “1”) == allow)
I have tried several different combinations and not been able to get one to pass Luup test.
Trying to adapt this for a multiswitch. Any thoughts?
You need to change the Service ID to the one used by MultiSwitch:
local dID = 175 -- Device ID of your MultiSwitch
local allow = true -- true runs scene if switch is on, false blocks it
local status = luup.variable_get("urn:dcineco-com:serviceId:MSwitch1","Status2",175)
return ((status2 == "1") == allow)
Here is what tech support had to say:
I checked your unit and it seems that the timezone for your location is setup properly. Please note that the timezone you are able to see in the logs is in UTC format, what?s why you are seeing there 23:24, but after applying your timezone, which is GMT-4, it is 19:24.
If you know for sure that the luup code is written properly, you can also try to use luup.is_night() instead of luup.sunset() and let me know how it goes.
so i am going to change that part of the code and see what happens.
Sent from my iPad using Tapatalk HD
[quote=“RexBeckett, post:68, topic:178331”]
Trying to adapt this for a multiswitch. Any thoughts?
You need to change the Service ID to the one used by MultiSwitch:
local dID = 175 -- Device ID of your MultiSwitch
local allow = true -- true runs scene if switch is on, false blocks it
local status = luup.variable_get("urn:dcineco-com:serviceId:MSwitch1","Status2",175)
return ((status2 == "1") == allow) [/quote]
Thanks but still no success when trying it in the test Luup code area.
Here is the data from the switch file:
Name: MultiSwitch
Device_type: urn:schemas-dcineco-com:device:MSwitch175:1
device_file: D_MSwitch175.xml
id: 175
Variables:
Status1
Status2
Status3
Status4
Status5
Status6
Status7
Status8
I missed spotting your typo in the last line. You are reading the value of Status2 into variable status but using variable status2 in the return statement which does not exist so will return nil. Try this:
local dID = 175 -- Device ID of your MultiSwitch
local allow = true -- true runs scene if switch is on, false blocks it
local status = luup.variable_get("urn:dcineco-com:serviceId:MSwitch1","Status2",dID)
return ((status == "1") == allow)
Edit: I have added the code for MultiSwitch to the examples for Z-Wave and Virtual switches.
I am in the process of committing to using Vera3 for a $2M+ house. I have been uncertain whether to proceed being doubtful whether certain functionality was possible because of Mios’s poor, disorganized and inconsistent documentation, until I found RexBeckett. His examples are clear and sufficiently detailed to answer most of my concerns. After reading RexBeckett’s work, which skillfully and completely illuminates LUUP plugins even for a na?ve user, LUUP itself seems to be a fairly straight forward and easily mastered language, mostly a C derivative I would say.
For example, in the case of the Kicklog function he explains “Enter /kwikLog.txt in a browser window to see if your location data is correct. Replace with the IP address of your Vera (without the <>)”. Notice the careful disambiguating of what “” is in his syntax. Mios should really be paying Rex.
None of this is to suggest that online support is not good. They are responsive and generally knowledgeable, but one question at a time to them is a very resource consuming approach–on both sides.
Incidentally, I wrote my first program in 1963, I know half a dozen programming languages, including the infamous SAS macro language. The first program you write in any language is always the toughest. That is why one or two careful and complete examples in the main documentation would have been most helpful, but a single reference to RexBeckett’s forum page would have been much more.
Hi @RexBeckett,
Since you pointed me here, I hope it’s ok to ask questions here about delayed actions. If not, please just point me in the right direction.
I think I understand that a function is global, so I need to either define variables within the function, or be very careful with naming global vars. I also read somewhere it’s not wise to question your code, but I’m missing something in the following:
[code]local dID = 66
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=1 },dID)
luup.call_delay(“delayOff”,10,dID)
function delayOff(dev)
local devno = tonumber(dev)
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=0},devno)
end[/code]
What is (dev) ? The 66 started as dID, and within the function, it’s devno, but I’m lost with dev. I hope I caught you in a typo, but I’m not betting on it… :-[
I’ve written a solution for keeping a light on for some period past the “no motion” signal, if it’s re-tripped during the delay period that seems to work well. Right now I’m using the brute force method (mostly not using variables) but am passing the DELAY as the single variable until I figure out your encoding them into a string or table.
To turn the light on, I have an empty scene with a trigger on sensor 45 TRIPPED and this in the scene LUUP
[code]local SENSOR = 45 – The door/window sensor device number
local Garage = 16 – the Garage Light device number
local SES_SID = “urn:micasaverde-com:serviceId:SecuritySensor1”
local SWITCH_SID = “urn:upnp-org:serviceId:SwitchPower1”
local status = luup.variable_get(SWITCH_SID,“Status”,Garage)
if (status == "0") then -- Don't keep turning it on if it's already on.
luup.call_action(SWITCH_SID,"SetTarget",{newTargetValue="1" },Garage)
end[/code]
Then to turn it off, another empty scene with a trigger for sensor 45 NOT TRIPPED, and this in the scene LUUP.
[code]local SENSOR = 45 – The door/window sensor device number
local Garage = 16 – the Garage Light device number
local DELAY = 15 – Seconds for testing with a door sensor
local SES_SID = “urn:micasaverde-com:serviceId:SecuritySensor1”
local SWP1_SID = “urn:upnp-org:serviceId:SwitchPower1”
luup.call_delay( “checkLastTrip”, DELAY, DELAY)
– Turn off the light only when it’s not tripped and the DELAY time is expired.
function checkLastTrip()
local DelayTime = tonumber(DELAY)
local tripped = luup.variable_get( “urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, 45) or “0”
local lastTrip = luup.variable_get( “urn:micasaverde-com:serviceId:SecuritySensor1”, “LastTrip”, 45) or os.time()
if (tripped == “0” and (os.time() - lastTrip >= DelayTime)) then
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{newTargetValue=“0” },16)
end
end
[/code]
It works, and doesn’t seem to tie up the system with loops that don’t end, but it just doesn’t seem good form to use empty scenes, but I can’t make it work any other way. Any suggestions or warnings or improvements that you can offer would be much appreciated.
Mike
I also read somewhere it's not wise to question your code, but I'm missing something in the following:
What is (dev) ? The 66 started as dID, and within the function, it's devno, but I'm lost with dev. I hope I caught you in a typo, but I'm not betting on it... :-[You're being very cautious, @ilikelife, but I don't bite. ;D
The third parameter in luup.call_delay(callback, delay, parameter) is a string that is passed to the callback function when the delay expires. I simply use this parameter to pass the device ID that should be turned off. I called the argument dev in the definition of the callback function delayOff. Remember that it must be a string so I converted the string in dev to a number in devno. See: no magic, no typos…
it just doesn't seem good form to use empty scenesEmpty scenes don't really cost anything but if it bothers you, use a single scene and put your code on individual triggers.
It works...I'm surprised if it continues to work reliably because there are a few problems with it:
Your global checkLastTrip function is referring to the local variable DELAY. This may not exist if it has been garbage-collected by the time the callback happens. Either define it inside checkLastTrip or pass it as the string parameter. When you pass a string through luup.call_delay(…), the callback function needs to define the receiving arguments as in my example.
The values returned by luup.variable_get(…) are strings. To avoid problems, use tonumber(…) to convert them before using them in calculations or comparisons.
You probably don’t remember, but in another thread you were walking someone through solving his problem, and he questioned your code. Your response was was a feigned indignant reply something like “Now you’re questioning MY code?” I enjoyed that exchange, but was not seriously worried
luup.call_delay("delayOff",10,dID)function delayOff(dev)
So the device number (66) declared as dID gets passed as the 3rd variable. But does it then get named “dev” because it’s in the one variable position in the function named?
I see the conversion to numeric devno, that gets used in the CALL_ACTION line.
I was attempting to both use and pass the value in DELAY with my
luup.call_delay( "checkLastTrip", DELAY, DELAY)
But think I missed bringing it in.
function checkLastTrip()
Should have been
function checkLastTrip(NameGoesHere)Followed by
local DelayTime = tonumber(NameGoesHere)Is that correct?
And, yes, you are correct that it blew up shortly after I posted.
Do I need to keep my function names unique (checkLastTripSensor45) ? And if the functions are unique, do I have a problem with the local tripped and lastTripped within the functions if when I have this delay running on different sensors at once?
Maybe that’s why everyone else uses plugins, huh?
You probably don't remember...I had already surmised that this was the reason for your comment. Chris and I have many exchanges...
So the device number (66) declared as dID gets passed as the 3rd variable. But does it then get named "dev" because it's in the one variable position in the function named?Exactly.
Should have been Quote function checkLastTrip(NameGoesHere) Followed by Quote local DelayTime = tonumber(NameGoesHere) Is that correct?Precisely.
Do I need to keep my function names unique (checkLastTripSensor45) ? And if the functions are unique, do I have a problem with the local tripped and lastTripped within the functions if when I have this delay running on different sensors at once?As all global functions and variables in your scene code share the same environment along with Startup Lua, you can get contention. Using unique names for global items will avoid this. It is OK to have multiple copies of the same (identical) function defined. The last one loaded gets to live. Problems occur when functions share the same name but are not identical...
Variables defined as local within a function get created when it is called. Each caller gets its own copy of the variables.
Maybe that's why everyone else uses plugins, huh?Plugins are great if there is one that does exactly what you want and you can afford the memory load. Plugins like PLEG can handle a massive amount of logic in one instance, of course. PLEG can now do just about anything a scene can do but I still like to use a few lines of Lua for simple tasks.
Thank you so much for taking the time and having the patience to help me with this. My first (new) question is: other than bothering you each time I run into problems, is there a good reference book that covers the Vera/LUUP part of this? I’ve got the Programming in Lua book (3rd edition) from Lua.org and it helps. (It might help even more if I would spend some time studying it, instead of plowing forward with my live system, but this is more fun.) ;D I’ve used the Wiki pages, and this forum is very helpful, but is there a reference to the device and action commands in LUUP that are not covered in Lua? BTW, am I correct in saying the “LUUP” part is specific and proprietary to Vera / Mi Casa Verde?
The “new and improved” code seems to work without contention. It may be overkill, but I’m renaming everything, because I’m still not clear on what’s global and local. I’m only really using DELAY46, but I left the other variables for my reference.
[code]local Motion46 = 46 – The kitchen motion sensor device number
local KitchenLights = 10 – the Kitchen Lights device number
local DELAY46 = 1200 – Seconds = 20 minutes
local SES_SID = “urn:micasaverde-com:serviceId:SecuritySensor1”
local SWP1_SID = “urn:upnp-org:serviceId:SwitchPower1”
luup.call_delay( “checkLastTrip46”, DELAY46, DELAY46)
– Turn off the light only when it’s not tripped and the DELAY time is expired.
function checkLastTrip46(DELAY46)
local DelayTime46 = tonumber(DELAY46)
local tripped = luup.variable_get( “urn:micasaverde-com:serviceId:SecuritySensor1”, “Tripped”, 46) or “0”
local lastTrip = luup.variable_get( “urn:micasaverde-com:serviceId:SecuritySensor1”, “LastTrip”, 46) or os.time()
if (tripped == “0” and (os.time() - lastTrip >= DelayTime46)) then
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{newTargetValue=“0” },10)
end
end[/code]
The last one loaded gets to live.
Say I have the kitchen and garage lights on Schlage RS200 motion sensors with a fixed 4 minute “On time”. I want the kitchen lights to stay on for 20 minutes past the last detected motion. With the garage lights, 6 minutes seems about right.
If both scenes call checkLastTrip but 1 has a DelayTime of 20 minutes, and the other of 6, what happens when the garage scene fires while the kitchen has been running for a few minutes?
Again, thanks for helping me. I feel dense with this sometimes, but it keeps me out of the pool hall.
Mike
...is there a reference to the device and action commands in LUUP that are not covered in Lua?The only reference that I know is [url=http://wiki.micasaverde.com/index.php/Luup_Lua_extensions]Luup Extensions[/url]. It isn't big on explanation so you must be prepared to experiment a little. LuaTest is your friend. ;)
BTW, am I correct in saying the "LUUP" part is specific and proprietary to Vera / Mi Casa Verde?Yes. luup is a library of functions and variables that is predefined in Vera's Lua environment. It does not exist in normal (non-Vera) Lua environments. This is why there is no detailed documentation out there.
I'm still not clear on what's global and local.You might understand it a little more if you read the first couple of chapters of your book. ::) I'll give you a clue, though: if the definition does not start with [b]local[/b], it isn't! This also means that if you don't define a variable before you stick something in it, it is intrinsically global... You really need to understand variable [i]scope[/i] before this makes sense. Hit that book. :D
If both scenes call checkLastTrip but 1 has a DelayTime of 20 minutes, and the other of 6, what happens when the garage scene fires while the kitchen has been running for a few minutes?Right now your [b]checkLastTrip[/b] function is hard-coded for a specific light so you would not want to call it from both scenes. You can have a single function that works for any device provided you pass the device number as part of the string argument. I show a couple of ways to do this in [url=http://forum.micasaverde.com/index.php/topic,18679.msg154756.html#msg154756]Delayed Actions[/url]. If you write a general-purpose function, you could place it in [b]Startup Lua[/b] and call it from any scene.
Hit the books, huh? 
Like I haven’t heard that before. But just one more before homework. I get that my checkLastTrip is hard coded now. I saw your instructions on passing multiple vars, and I’ll try that soon. What I’m asking is, IF I pass device, delay and other variables to a function named checkLastTrip, there could be multiple instances of that function with different (local) vars like tripped, lastTripped and DelayTime. When you said
The last one loaded gets to live.
Does that mean my other light stays on?
Right after typing that, I think I heard someone saying
You really need to understand variable scope before this makes sense. Hit that book.
I’ll post again in a week or two. :). Thanks again.