Excessive Piston Logging

#1

I noticed that one of my pistons had a ton of log entries, even though the logging level was set to ‘None’ and the trace option was turned off. I’m not sure if excessive logging can affect performance.

I would expect that nothing should show in a piston log if logging is not enabled. I’m seeing the following message filling up the log: “Piston Execution aborted due to restrictions in effect”. Is there any way to turn this type of logging off, or is there a better way to design it so it doesn’t generate those log entries? Every time there’s motion outside of the time frame it generate a log entry.

Piston basics:
Only when
time is between Time A and Time B
Execute
If Motion Sensor changes to active
Then
Turn on light
End Execute

#2

With logging set to “None”, the only logs written should be:

  • Errors/Warnings/Alerts, and
  • “Log to console” commands

It is important to remember that stopping a log does not stop a piston from running.
(it just makes us oblivious to what is going on behind the scenes)

To get rid of the alert, “Piston Execution aborted due to restrictions in effect”, you can get rid of the restriction. Maybe something like this:

Execute
   IF Motion Sensor changes to active
   Then
      IF Time is between X & Y
      Then
         Turn on light
      END IF
   END IF
END EXECUTE

… but in either case, the piston will still trigger whenever anyone walks past that device. 24 hours a day.

Although, if you use the example above, it will not clutter your log.

#3

I would have thought that having the time restriction first would prevent the piston from executing outside of the specified time range. Interesting that changing the restriction to a condition after the motion triggers the piston would eliminate the log entries. Isn’t the piston still firing upon motion and being cancelled when the time condition isn’t being met?

However, your suggestion has eliminated the ‘piston cancelled’ log entries! Thank you!

#4

Unfortunately no. It will still trigger, and then cancel out when a condition fails.
(one reason why I rarely use restrictions)

I suspect this is true because a piston has to be executed for any code to be processed

One way to look at this:

  • A trigger will execute a piston regardless of any conditions
  • The opposite trigger will also fire everytime_(IE: Motion changing to INactive)_
  • Conditions can cancel or abort the logic flow, but cannot prevent the trigger