Please help me understand why this expression doesn't evaluate correctly

#1

1) Give a description of the problem
I have the attached piston. When I do a trace it appears that the expression is not considered when it decides when should be scheduled. Perhaps it is being considered but on the day that it is being considered it is not considering the next day so if it is considering Monday’s schedule on Sunday the day of the week is Sunday and it doesn’t schedule Monday’s schedule at 2:30. It would probably schedule Tuesday’s at 2:30.

2) What is the expected behavior?
For the piston to run Monday at 2:30 and Tuesday through Friday at 3:30.

3) What is happening/not happening?
I just confirmed it because it just ran now. It appears that it is considering the schedule an entire day ahead of time so so when it completed today on Monday and went to schedule it again it sees that it is Monday and it scheduled it to run tomorrow (Tuesday at 2:30). I can obviously fix this by checking the day of the week as Sunday but is there a better way to design this?

4) Post a Green Snapshot of the pistonimage

z4x7w
z4x7w.png1178×564 61.4 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
Logs not necessary.

#2

(dayOfWeekName == ‘Monday’ ? ‘14:30’ : ‘15:30’)

But bear in mind that timers schedule on last run, so you might want to change the condition to Sunday to get the right result.

#3

Thank you for your feedback. Correct, I said I could have fixed it that way in my post. I asked if there was a better way to design this. I’m assuming that if the system goes down or the scheduling is otherwise disabled and re-enabled between Monday 12:00am to Monday 2:30pm then having Sunday in the evaluation will then break the first day again.

Is there not a better way to design this type of piston?

#4

You’re expression was wrong so it would have always scheduled wrong.

You are right to look at Sunday when scheduling for Monday… I was reinforcing that opinion.

WebCoRE has built in recovery every 30 minutes so if a schedule gets lost it soon recovers… but yes… you’d then get the wrong schedule with current setup.

#5

Consider having an extra (blank) timer block, forcing the piston to run at 00:01 every day, just to schedule on the day required.

every day at 00:01
DO
(Blank)

Every day at {(dayOfWeekName == ‘Monday’ ? ‘14:30’ : ‘15:30’)}
DO
stuff

Personally I’ve never seen schedules disappear… problems tend to be devices not reporting or responding to commands at the time the schedule arrives.

#6

This expression doesn’t schedule wrong. There is no $dayOfTheWeekName in my system variables. It is $dayOfWeekName as I have provided. In addition, you are returning strings which have to be converted to time anyway. In general with languages that support dynamic/loosely typed variables if you want less confusion you provide the value in the type you intend it to be converted to, stored in, etc. I would say providing time cast values is safer than providing strings.

I can change it to Sunday but I would prefer to see a better design option if somebody knows one. It doesn’t matter if ST recovers every 30 minutes if it comes back between Monday 12:00am and 2:30pm. For the purposes of this piston this window is small but if this were a different scheduled event that ran only once a month or once a quarter or once a year (I don’t even know if those are possible) this design would be worse off. You can see how the evaluation day should not play into when the scheduled event needs to run.

Is there a design that makes the schedule evaluation completely irrelevant?

#7

Ah, yes. This will be better. Thanks!

#8

Sorry… typo… meant $dayOfWeekName

I was referring to the time() part of your expression… might work but shouldn’t be needed.

#9

One question about this suggestion. I can test this out if you don’t know the answer. With a schedule like this I’m assuming it will run it even on the first day if 12:01 am has passed?

#10

Yes… saving the piston will result in the next available schedule being set.

You can check the next schedules run time at the top of the piston preview page.

#11

This ended up being a very unreliable way because of daylight saving time changes, pausing the piston, and various other reasons. I went away from this approach completely and now I use something like this which seems to work for more scenarios. I thought I would post it in case anybody finds it useful.

download
download.png1178×768 84.3 KB