• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
sensor
#1
I'm using a pir sensor (pollin protocol) and when movement is detected it switches to OFF. Except, it will never switch back to on except if I make a rule that switches it back to ON again after x seconds.

Now, if I start the daemon and in the config.json the pollin state is already OFF, then the rule will never be executed to set it back to ON.

There are situations that it 'sticks' to OFF and the rule will never be executed.

Any ideas how to force it always back to ON after x time ?
 
Reply
#2
You could use a rule that lets a generic switch device follow the sensor device with a delay of x seconds . Then in a second rule you can switch both devices back to on whenever both devices are off. For instance like this:
Code:
"rule1": "IF sensor.state IS on OR sensor.state IS off THEN switch DEVICE generic TO sensor.state AFTER 5 SECOND",

"rule2": "IF generic IS off AND sensor.state IS off AND (dt.second % 1) == 0 THEN switch DEVICE generic AND sensor TO on",
 
Reply
#3
The problem is that the rules are only executed if there is a change of state.
The pirsensor only sends a off state when movement is detected. So if the config.json begin state is off when the daemon starts the state never changes so the rule is never executed.

In orher words. A rule only changes the pirsensor.state back to on if it changes from on to off.

Imo the rules should all be executed when daemon starts on initial states.

Any thoughts?
 
Reply
#4
Did you try the rules I proposed? I seems you didn't.

The triggering of the second rule does NOT depend on a device state change as you say, but on a change of the datetime second "dt.second % 1) == 0" and the current state of the sensor device, so it will be executed also if the sensor is off on startup.
 
Reply
#5
You're right, I didnt see the 2nd rule (on my phone correct). Gonna test it as you wrote and will report back the result! Thx for your patience!
 
Reply
#6
assumtion when starting daemon default settings:

generic = on , sensor = on , then rule1 doesnt do anything at startup and rule2 doesnt do anything. This is good as the sensor will send a off state and set things in motion.

generic = on, sensor = off, then rule1 doesnt do anything at startup and rule2 doesnt do anything. This is not good and is my problem. First I depended on the initial sensor state , now I depend on the initial generic state.

generic = off, sensor = off, then rule1 doesnt do anything at startup and rule2 triggers them both to on. This is good.

generic = off, sensor = on, then rule 1 doesnt do anything at startup and rule2 doesnt do anything. This is good as the sensor will send a off state and set things in motion.

If I understand your setup correctly, you want it it check consistently AFTER 5 seconds to set the state back to on. You did this so the rule checks multiple times in case the sensor.state 'hangs' in a off state.

My 'problem' is that I need to set the config.json in a specific state otherwise it will not set things in motion. (In your case you need to set the generic to on initially. In my case I need to do that with the sensor.state before I start the daemon)

Solution would be (in my case) a default-state option for the sensors like the relay uses, or the rules should be initally executed at start daemon.


Tell me if I'm totally wrong Wink
 
Reply
#7
The 5 seconds are just an example and determine how long sensor will stay in the off state. If you wish you can choose a different setting.

But why would generic ever be on and sensor off at startup, unless you do that on purpose?

If the duration of sensor's off state is not important for you, you could also just create one rule that switches sensor to on every second if it is off.

Code:
"rule": "IF sensor.state IS off AND (dt.second % 1) == 0 THEN switch DEVICE sensor TO on",

The main thing is that the rule that is supposed to switch sensor back to on is based on a time event and not on a change of state.
 
Reply
#8
Agree, and I'm gonna use it Wink

Cause I'm testing alot and the pirsensor is in my living room, the change is pretty high that I stop the daemon when the state is off.

Other thing I found is that using ip:5001/config not always shows all rules but I see them parsed when starting the daemon. How come they are not visible in the config?

Code:
"pirResetState": {
                        "rule": "IF (datetime.second % 2) == 0 THEN switch DEVICE PIRSensor TO on",
                        "active": 1
                },


Somehow it get parsed but doesnt work as expected, probably also the reason that it's not visible in the ip:5001/config file.

ÊDIT: found that ip:5001/config?media=all is showing everything (api) ....Still dont understand why the PirResetState rule didnt work.
 
Reply
#9
It seems that you named your datetime device "datetime", but that is a protocol name. Protocol names are not allowed as device names!

Also I would add "PIRSensor.state IS off"at the beginning of the rule, so it wil only be executed if the sensor is off.
 
Reply
#10
When using datetime.second in de config.json it doesnt give an error that it's missing the 'datetime' device (when having dt as device.)

I edited a part of the wiki example page where the device datetime was missing.
I'll adjust the rest later as the examples are not uptodate.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  China Door/Window Sensor markus 1 711 03-15-2018, 09:18 PM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)