Only if store is empty?

#1

During night or ‘gloomy’ periods, this piston controls selected inside and outside lights when my wife and I arrive, or when the doorbell is pressed. It captures the current state of those lights (on/off, brightness), changes them to 100% for 5 minutes and then returns them to their previous state and level. Although this piston kinda works, the “prevent overwriting the current state” (only if store is empty) seems to be ignored. I used this piston in ST and it worked as expected.

When my wife’s and my phones arrive at different times (even though we’re in the same car) as is almost always the case, the second ‘close’ arrival should be ignored since there is already data in the local store. What’s not working correctly is that the second arrival is not ignored and the capture store is overwritten and the piston timer is restarted.

Here’s the piston:

download
download.png1178×1043 131 KB

As you can see below, last night the first presence arrival is overwritten by the second arrival 3.5-ish minutes later:

image
image.png735×307 16.3 KB

#2

I’m not familiar with the capture/restore attributes, but it looks very useful/easy to use if it functions a you expect.

I think your logs are showing what I would expect. The body of your if statement will be executed when the second arrival occurs. If this is working differently than on ST, I wonder if there’s a bug in the capture/restore code?

What do you want to do with the second arrival, ignore it, or extend the 100% period?

#3

It would be good to see full logs for both executions.

#4

I can see that the then block has been run again resulting in the display of the arrival message and I can tell that the time must have been reset to five minutes by the delay before the next execution. I see no evidence for whether the ‘capture attributes’ task did anything or not. Full logs might be diagnostic in that case to show what the restored values are.

As far as I can see the piston is doing what I would expect it to do when the second arrival is less than WaitTime minutes after the first one.

I can see that the ‘capture attributes’ running the second time would not be what you wanted, it is just that there isn’t anything there that shows that happened. Full logs would help for that, and they would also indicate if there are any bootstrapping issues. For example what if the local store wasn’t empty before the first arrival?

#5

With logs trace or higher they should show if they did not capture (the 2nd time).

I just ran my test for this, it passed…

#6

It should certainly run the ‘IF’ again when the second sensor arrives. But, once it checks and finds that the store is not empty, it should not extend the timer - as long as the timer has not already expired from the first presence sensor’s arrival.

#7

It would be of value, but I don’t currently have any because this piston has been running for several years without issue, so I had turned extra logging off. I’ll have to turn it on and test it again. I can recreate the events by using the doorbell and press it twice within a short time.

#8

Agree with the lack of the logs. But as I mentioned to @E_Sch, unfortunately, this piston was running without error for years, so I had turned of the extra logging off and only have the entries from the piston.

This won’t help much due to the lack of extra llog level, but here’s another example from a few days ago with a shorter time between the presence sensor arrivals:

image
image.png712×240 14.9 KB

I’ll increase the log level, test again soon and post the results.

#9

The code would not know the store is empty, and so would run the rest of the if action. If you want to ignore the second arrival, if the first is still being processed, you will need to use a variable to act as a semaphore, and check whether there is an outstanding action being processed.

#10

Again, it would certainly help to have the extra logging.

However, I can tell that the store data was not overwritten because the lights were actually restored to their pre-1st arrival settings. If the stored data had been overwritten, the lights would have stayed on at 100% because that’s the state they were in by the time the 2nd presence sensor arrived. This is absolutely why the ‘only if store is empty’ is used.

Lightbulb moment!
DOH!!!

Looking again at the piston code for the first time in a while, it seems to me now that the piston is acting exactly as I wrote it. There’s nothing in the piston to prevent the second presence sensor arrival from being logged by the piston, and nothing to prevent the timer from resetting to provide an extra [WaitTime} minutes based on the 2nd arrival. Even worse, I wrote it to do exactly that because if I or my wife actually drives to the house slightly behind the other person, I would absolutely want the lights to stay on for them too (for safety and convenience).

So, in short, the piston is running properly AND exactly as it was written and I originally intended it to run. Therefore, I’m an idiot. and old (I am) and forgot all of that.

I apologize for the false alarm and wasting your time. I appreciate everyone’s attempt to assist me.

#11

No problem, you’ve taught me something new, I didnt realise the power & flexibility of the capture/restore attributes statement. I would have coded something way more complex!

It’s worth adding more comments to your code (I still don’t) but often come back to a complex piston and have to work out/remember why i did something a particular way.