Resetting A Variable Based On Location Mode After Rest Of Script Has Run

ShiveringTimbers · 2020-09-20 18:33:49 UTC

1) Give a description of the problem
I want to reset two boolean variables that are being used to indicate if it is the first time a statement within the piston has run. I am using this to ensure that a group of lights is “set” with colour and brightness the first time motion is detected. If the colour or brightness is manually adjusted then they will return to previous state, not initial “first time” colour/brightness.

2) What is the expected behaviour?
When first picking up motion lights should trigger, if boolean is true, then light colour/brightness should be adjusted then, bolean set to false. At change of location mode, bolean should be “reset” to true for next day.

3) What is happening/not happening?
Script Just appears to be running the Location mode update section (line 69) but not the first set of statetments. If I remove the IF at Line 69 statement the script works fine (but only once,due to the boolean) and works fine with the variable removed.

4) Post a Green Snapshot of the piston

WCmore · 2020-09-20 21:08:24 UTC

Hello, and welcome to the club!

webCoRE is an event based system, and conveniently places lightning bolts in the left margin on any “device’s attributes” that will execute the piston.

As you observed, the only trigger in this piston is on line 75…
So currently, the piston will only run when location mode changes.

Normally, I only recommend a single trigger per piston, but if you really want the piston to run based on “Sensor 6’s motion”, then there needs to be a lightning bolt next to that line.
(likely not visible until the piston is saved)

Just keep in mind that every trigger runs thru the entire piston,
(top to bottom) and executes anything not blocked by conditions…

In other words: At every event, every IF block encountered will run either the THEN or the ELSE block.
(this will cause your lights to flash at many peculiar events)

To elaborate, let’s take a closer look at your structure:

IF A
   and
   B
      Then X
      ELSE Y
END IF

IF C
   Then Z
END IF

IF A, B & C are all true, then we can expect the piston to do X followed by Z…
but there are 7 other scenarios that ELSE brings into the mix:

For the most part, I recommend new users avoid using ELSE blocks for 6 months or so.
(99% of pistons do not need them, and they tend to confuse more than help)
Specifically, notice that “Y” (your lights flashing) happens at most events.

On the few cases where ELSE is “required”, I make sure there is only a single condition attached to it. (not a double, as you have done on lines 23-25)

ShiveringTimbers · 2020-09-21 07:46:25 UTC

Hi WCMore, Thank you very much for the reply,

I have a little knowledge with coding but am self taught so may be making some “schoolboy errors”.

I noted the lightning bolt icon when I saved it, and removing lines 76 -79, creates two new bolts at 23 and 25. Which makes the script work pretty much as intended. Triggering the lights to come on if the motion sensor picks up movement during the right hours.

If I understand what you are saying correctly, even if the trigger is the last line of the script, it will run through from the top?

Lines 54 - 72 are intended to warn someone in our living room that there has been no motion (sat still watching a movie) by flashing a countdown, before line 71 finally turns off all living room lights.

My takeaway from your post is)

I should think about moving the time restrictor (line 25) into the “then” blocks to avoid it being a trigger.

*I was under the impression that the “if” line 23-25 would be treated as one statement

That still leaves me puzzled as A) how I get the reset variables to run, without it being part of the “motion” trigger. B) Why adding a seperate IF removed the triggers from the first IF block.

Sorry if these questions are off or I have missed your point. I have been searching for a template that properly indicates how to run a “reset” on variables but have drawn blank.

Thanks again, and apologies if there are any silly questions / I have completely missed the point.

WCmore · 2020-09-21 17:39:12 UTC

This is normal. When there are no triggers in a piston, then all conditions are treated as triggers.
(nice breakdown here)

Yes. A piston always starts execution from the top…
(Regardless of where the trigger is located in the code)

It is two lines, and two independent checks. (as seen in your Full logs)
If they are both “true”, then 27-53 executes. If either is “false”, then it executes 55-72.

In your case, this happens even with location triggers executing the ELSE block at 55-72.

There is a lot going on here, and normally, I would not recommend a new user attack this project until becoming familiar with the core concepts of webCoRE.

… That being said, here is the general structure that I am thinking of:

IF location mode changes                <-- Trigger
Then 
    Set variable
END IF

IF Sensor 6's motion changes to active  <-- Trigger
Then
    IF Time is between X & Y            <-- Condition
    Then
        Do cool stuff
        IF variable is Z                <-- Condition
        Then 
            Do more stuff
        END IF
    END IF
END IF

Note: I did not use ELSE above, but they are all individual elements, so a pro can insert them in the appropriate section.

Also note that with this method, location changes will not run anything buried beneath the trigger:
IF Sensor 6's motion changes to active
(since it immediately returns “false”)

ShiveringTimbers · 2020-09-21 17:47:53 UTC

Thanks again for taking the time to reply, I really do appreciate it,

I will persist by modifying the script to a format similar to yours and see how I get on.

I have it kind of working as it is now (without the reset) which just means If I change the light colour because I need it brighter etc it will change it back the next time it sees movement which is kind of annoying.

If I get it running perfectly I will be sure to post back here so you know your efforts were not in vein.

ShiveringTimbers · 2020-09-21 19:38:37 UTC

WCmore,

I feel I must be making a fundamental error, to keep things simple I have dropped the whole thing back to two simple If-Then statements. But again only the Location mode change is set as a trigger. (see screenshot)

Regardless of if the location mode IF is first, or second the trigger icon follows it, meaning (if I understand right) the sensor will never trigger the routine, only a location mode change.

This issue goes away if I change the location change to a physical switch. I take it this is a limitation that I have overlooked somewhere.

WCmore · 2020-09-21 20:53:45 UTC

Triggers are precise moments in time, and kick off a piston
Conditions are vague windows of time, and control the direction of logic once the piston has already begun.

Every handler is different, but notice how all conditions are near the top, and all triggers are near the bottom:

ShiveringTimbers · 2020-09-21 21:03:16 UTC

That makes sense, I have just changed the second statement to use a trigger (Motion Sensor Motion changes to - Active), instead of the “is active”)

And we are golden! May my head bashing continue

ShiveringTimbers · 2020-09-22 22:11:14 UTC

Hi WCmore,

Thought I would let you know I got the system working how I wanted.

What it achieves…

Sets light temperature and brightness at set times of day automatically
If settings are overridden manually they are respected and restored the next time the lamps come on by sensor trigger (unless a new time period or mode is entered).

I ended up using two scripts to keep the “off” function separate from the colour presets.

I have attached both scripts below in case someone is looking to achieve something similar (although my example works it may not be the best way of doing this) and I am open to feedback on how I could further streamline the pistons.

Piston 1: Sets a variable ensuring the piston does not run more than once per time slot. Also includes the lighting levels that should be used in each time slot.

Piston 2: This takes the colour setting of “bulb 1” in case the group has been overridden manually. It then re-applies those settings on next start up.

Limitations:

I have yet to work out a “nice” way of making it so that if the condition arises that a new preset time window has been hit, that those conditions overide the “last saved” light settings. so far I have found that the 400 milisecond delay has been sufficient, but this may need extending or a better method sorting?.
It does not monitor all bulbs, so if you set some to different levels manually it will only replace all other bulbs with the settings sampled from bulb one.

Many Thanks!

WCmore · 2020-09-22 22:40:18 UTC

It is coming along nicely…

If I was being completely honest, I’d have to mention that both pistons have the same trigger:
IF Sensor 7's motion ...

This means each time someone sneezes, both pistons will try to run at the same instant…
… but one will end firing before the other one. (which one is anyone’s guess)

ShiveringTimbers · 2020-09-23 16:51:14 UTC

I have now condensed this down to one script which works without having to guess which one would fire first.

It is pretty long, but does what I need. Is there any “ettiquete” for shortening things and neatening things up before I repeat this for the rest of my rooms

Thanks for the help once more, I legitimately would not have got it working without your assistance.

WCmore · 2020-09-23 17:12:57 UTC

A few thoughts come to mind…

(1) Each room has a different motion sensor, so those triggers will remain unique

(2) I would use different times in each piston, to prevent multiple pistons from trying to be run simultaneously. (even a 1 min difference is adequate)

(3) I would most definitely NOT use location mode as a trigger in every piston!

(4) I don’t think I’ve mentioned this to you yet, but I would highly consider converting the “ONLY WHEN” blocks into indented IF blocks instead. The former can be a little funky, and will not always do what you want it to.

With regards to #3 above…

I would be tempted to use one piston to keep track of Location mode changes, and update a global variable or Simulated Switch accordingly.

Then, the individual room can check that switch or variable (as a condition, not a trigger), and take the appropriate action.

Pro Tip:

I tend to let a new idea (piston) run for a week or so before I start duplicating it. Even with thousands of pistons under my belt, real life applications often encourage a bit of tweaking a few days down the road.

IMO, It is much better to have a solidly tested piston, before duplicating the logic.