From: Gregg L. <gr...@li...> - 2008-03-13 00:27:35
|
Quoting David Satterfield (3/12/08 6:23 PM): >> I have a bathroom light that has automation logic to turn it on once the >> bathroom door is opened and/or when the bathroom motion detector shows >> motion. If a user turns off the light, then they need a period of time >> to "blank out" all automation while they exit the bathroom. The tracked >> automation may (and, almost certainly will) suggest that the light >> should be turned back on. But, the user will want it off because they >> turned it off and is existing the room. Actually, I've personally >> exited, then come back in (even briefly), manually turned the light back >> on and then back off--all w/i the manual off period. I still want the >> light off--no matter what. That is what the absence of the "auto" >> property gives me. > This use case is very pertinent to me. I have the same basic issue, but > I thought that the act of turning the light "off" would reset the manual > time, (in your example, manual would be called 3 times, once for the > first "off", once for the "on, and once for the second "off) That does not occur auto-magically by Light_Item. It would have to be your own code. > so even if > "auto" were not set, you would get the effect you are describing. No. > Are > you suggesting that additional calls to the manual() method have no > effect if manual mode is already on? No. I would suggest that you just "don't do that". Here's the snippet of user code that I use: if ($bathroom_light_item->state_now) { if (ref $bathroom_light_item->get_set_by && $bathroom_light_item->get_set_by eq $bathroom_light && !($bathroom_light_item->manual)) { # set manual on delay for 1200secs = 20 minutes and off delay for 15 secs $bathroom_light_item->manual($bathroom_light,'1200:auto',15);. } } Note that I guard against repeat calls to manual while it is already invoked. All of my personal use cases avoid it. However, I can see a time when I may need to change that--like if a timer is exceptionally long and circumstances change. > I think if the manual() call just > reset the manual time. you wouldn't want to use "auto". Does a manual() > call get ignored if manual mode is already on? No--the timers and values are reset. This is very desirable from a library standpoint. If you don't want the reset, then simply avoid it altogether (as I have done). >> FWIW: I've been testing the above since this weekend and it seems to be >> working just fine. > > I'd be interested in trying it out... Before I commit code, I did want to make sure that there was clear understanding on a couple of key points: The use of "auto" as a property to each timer value is determined by the value of the Light_Item state at the point that the timer expires. So, if the Light_Item instance is ON and you then set manual (in the way of the various examples) and you then turn the light off so that the Light_Item instance now also tracks to off, then the Light_Item instance will not revert to auto track since the auto property is associated with an ON state. This is important because the timer value is associated with the state at the *beginning* whereas the auto value is associated with teh state at the *end*. Since manual light tracking occurs, it is possible for these states to be different. If you're ok w/ the above, then I'll commit the new additions. If you're not, then I'll need to rework the logic to allow your needs as well as my own (since the behavior as described reflects what I believe to be most necessary/useful). Gregg |