How can I extend a motion sensor timer.
Answered
When I use a motion sensor (Vision ZP3102) to control an on/off switch module, and want to delay switching the switch to off after the motion sensor signaled no_motion, how can this be fulfilled?
I have created a rule that turns the switch on when the sensor signals 'motion'. Then I created another rule that is trigged when the sensor signals 'no_motion', that just waited 5 minutes and if the sensor still was in state 'no_motion' it turns off the switch - but it is not working.
I want to turn off the switch if the sensor has been in state 'no_motion' for at least 5 minutes (no 'motion' in the 5 minutes).
I tried to use your stairway timer example, but without any luck - it always turns the switch off after 5 minutes.
The same question
No connection
Real-time notifications may not work
The problem with your rule is that the state of the a sensor doesn't get updated during the execution of a rule. We make a 'snapshot' of all states and variables present on the system at the time of the event and use it for that rule.
The idea was to save us from the concurrent programming troubles. Example of a trouble would be if you had a rule like this:
There would be no guarantee that sensor1 preserved the state between these 2 lines, and we'd have a possibly unpredictable result. So, if you use something like
then the last something will ALWAYS be executed. Also same thing if you use variables.
Somewhere in the process we forgot about 'refresh' puzzles that update the snapshot used by the rule with current states and variables, but we'll add them ASAP.
Meanwhile, something like this should work
That 'when sensor=any' checks if the event was a change of the sensor's state, but doesn't care about the actual state of the sensor. The same thing could be achieved with 'when sensor=motion or sensor=no_motion'...
The problem with your rule is that the state of the a sensor doesn't get updated during the execution of a rule. We make a 'snapshot' of all states and variables present on the system at the time of the event and use it for that rule.
The idea was to save us from the concurrent programming troubles. Example of a trouble would be if you had a rule like this:
There would be no guarantee that sensor1 preserved the state between these 2 lines, and we'd have a possibly unpredictable result. So, if you use something like
then the last something will ALWAYS be executed. Also same thing if you use variables.
Somewhere in the process we forgot about 'refresh' puzzles that update the snapshot used by the rule with current states and variables, but we'll add them ASAP.
Meanwhile, something like this should work
That 'when sensor=any' checks if the event was a change of the sensor's state, but doesn't care about the actual state of the sensor. The same thing could be achieved with 'when sensor=motion or sensor=no_motion'...
The problem with your rule is that the state of the a sensor doesn't get updated during the execution of a rule. We make a 'snapshot' of all states and variables present on the system at the time of the event and use it for that rule.
The idea was to save us from the concurrent programming troubles. Example of a trouble would be if you had a rule like this:
There would be no guarantee that sensor1 preserved the state between these 2 lines, and we'd have a possibly unpredictable result. So, if you use something like
then the last something will ALWAYS be executed. Also same thing if you use variables.
Somewhere in the process we forgot about 'refresh' puzzles that update the snapshot used by the rule with current states and variables, but we'll add them ASAP.
Meanwhile, something like this should work
That 'when sensor=any' checks if the event was a change of the sensor's state, but doesn't care about the actual state of the sensor. The same thing could be achieved with 'when sensor=motion or sensor=no_motion'...
The problem with your rule is that the state of the a sensor doesn't get updated during the execution of a rule. We make a 'snapshot' of all states and variables present on the system at the time of the event and use it for that rule.
The idea was to save us from the concurrent programming troubles. Example of a trouble would be if you had a rule like this:
There would be no guarantee that sensor1 preserved the state between these 2 lines, and we'd have a possibly unpredictable result. So, if you use something like
then the last something will ALWAYS be executed. Also same thing if you use variables.
Somewhere in the process we forgot about 'refresh' puzzles that update the snapshot used by the rule with current states and variables, but we'll add them ASAP.
Meanwhile, something like this should work
That 'when sensor=any' checks if the event was a change of the sensor's state, but doesn't care about the actual state of the sensor. The same thing could be achieved with 'when sensor=motion or sensor=no_motion'...
I have tried the above suggested solution, and it works perfectly, thank you.
Yes, it would be a nice thing to have some kind of a 'Refresh' puzzle, that will update the status of the sensors to be used by subsequent puzzles.
I have tried the above suggested solution, and it works perfectly, thank you.
Yes, it would be a nice thing to have some kind of a 'Refresh' puzzle, that will update the status of the sensors to be used by subsequent puzzles.
I tried to use your stairway timer example
Where did you find this example?
I tried to use your stairway timer example
Where did you find this example?
When do you think this "oversight" (refresh puzzles) will be updated ?
When do you think this "oversight" (refresh puzzles) will be updated ?
since 2 eek the any state doesn't work ? wath is wrong ?
since 2 eek the any state doesn't work ? wath is wrong ?
Replies have been locked on this page!