Task being sent when it shouldn't be

#1

I have a piston as shown below.
As you can see, the off command is sent at different times during the week and at weekends.
In the recently tab I can see that during the week the off command is being sent at 22:45 and 23:00.
This is not causing an issue but I believe that this shouldn’t be happening.
Any ideas?
EDIT:I have command optimisation on but surely this is not the problem. Will have to give it a try.

download (8)
download (8).png1178×855 146 KB

#2

All four conditions are subscribed so any one of them will fire the piston…

Toggling switch 2, changing the mode and the start / end of your time windows will all cause the piston to run and in most cases the else part will be selected.

Chose what you want to be the trigger and unsubscribe the rest.

#3

Nope… no logs :microscope:

#4

As soon as I read your reply it made so much sense. I hadn’t thought this one through had I. :frowning_face:
I changed them all to auto subscribe and that will work.
As for the logs, logging wasn’t turned on, I got the info from the recently tab when I looked to see why the light turned on for no reason. There was no ON command but there was an OFF command.

Thanks again for the pointer (as obvious as it seems now) I would have continued to scratch around with it.

#6

It looks like if command optimization is off the command is sent even though it is not true.
I can see an off command being sent in the logs and also in the recently tab at 23:30 on a Thursday. This shouldn’t happen.
Any ideas @ady624 or @ipaterson?

download (9)
download (9).png1178×851 144 KB

#7

I don’t understand, are you not expecting it to fall through to the else when the condition is false?

#8

With command optimisation disabled, your off command will be sent regardless of wether the switch is already off or not.

The else in your piston will fire whenever the mode and time conditions are NOT met and the event times you are describing match that (piston will evaluate on every mode change and at the start and finish times in your time conditions)

Sounds like it’s behaving normally to me??

#9

The first part becomes false, 9:30 to 22:45.
The second part 9:30 to 23:30 is already false as it only evaluates as true at the weekend.
The time passes 22:45 during the week and the switch turns off as the else is being evaluated. Great working as it should.
Why would it evaluate the else again at 23:30 as the piston has never been true again in the period between 22:45 to 23:30.
It doesn’t send the off command at 23:30 during the week with command optimisation on but it does with it off.
I would have thought it shouldn’t sent it regardless of command optimisation.

#10

Based on the timing I would have to guess that the restrictions are being evaluated at runtime rather than at scheduling time, meaning that the piston would schedule Time is between 09:30:00 and 23:30:00, but only on Sundays, Fridays, or Saturdays to run every day and just evaluate to false on excluded days.

I understand your concern now and also consider that a bug, thank you for the example.

I verified that behavior with a simple piston that schedules a time on Saturday and Sunday only. between and not between schedule for Friday (e.g. Setting up scheduled job for Fri, Dec 15 2017 @ 1:00:00 PM EST (in 8300.396s)) while all other conditions and triggers schedule for Saturday.

#11

Thanks for the reply.
The reason I use command optimisation as off is because some of my switches are stateless so therefore ST does not know if the switches are on or off.
While this is great and means I can physically turn these on and off and ST will ignore these actions, it does introduce this anomaly.
Also thought I was going mad with lights doing strange things and I couldn’t work out why.
Now I know and can act accordingly.
Thanks again.

#12

This was not accurate, the only determination is whether the time (or in the case of between the greater of the two times) is in the future. So now at 12:04 time is before 13:00 would schedule for today regardless of the date restrictions.

There is some code to check the date restrictions but it was disabled on April 19 “Time condition restrictions are now working, added date and date&time conditions, offsets still missing”.

I am going to submit a potential code fix for review, hopefully @ady624 will remember the reason the code was disabled.

#13

Caught me at a good time, this change works for me but I’ll wait for ady to review. This one is a bit tricky since the impact of the bug is quite low, but the impact of screwing up scheduling would be very bad :smile:

#14

I agree the impact is low especially in this use case as it is already off. Like I said I have seen other strange things happening which I just assume are ST playing silly beggars. :smile:
Will follow-up any other anomalies I see.
If the risk is too high to upload a potential fix, then leave well alone. The last thing we want is to introduce problems for the majority of people using this fantastic smartapp.