Issue with add hours feature

#1

1) Give a description of the problem
So I have noticed if I use the add hours command in an expression and it sets the time after midnight it doesn’t work properly. Ex) add 3 hours to 10:00pm it should be 1:00am, but it does 12:00am. The rest of my piston then thinks it means 12:00am of the current day, and sets off the notification reminder.

2) What is the expected behaviour?
Press button, set a variable timer for 3 hours from now. Once current time surpasses the 3 hour variable, it triggers a notification to take the dog out.

Works great except when button is pressed after 9pm, then it triggers the reminder immediately upon pressing it.

3) What is happening/not happening?
If time is after 9pm and button is pressed it sets a time for midnight, and then notifies saying take the dog out because it thinks it means midnight of the current day (only sees time not date).

**4) Post a Green Snapshot of the piston!

download~3
download~3.png1178×1102 96.7 KB

5) Attach logs after turning logging level to Full
Sorry didn’t have a chance to record logs. Can upon request

#2

A “time” variable can only store the time… Not the date.

I think you want {NextAlarm} to be “datetime”… (which stores both)

pic

Side Note:

I would highly encourage to not enable parallelism unless absolutely necessary…
(less that 1% of my 450 pistons use that option)

#3

Thank you. I changed the variable to DateTime, as well as the trigger to DateTime. Will test tonight, and report if there are still issues (though I’m fairly sure there won’t be any).

Thanks for the note on parallelism. Still trying to grasp when to use and when to not. From what I understand it is used when the piston could be ran twice at the same time, or one instance started running and another started as well? Please correct me if I am wrong, I’m still learning.

Is there any disadvantage from enabling it and it not being used?

#4

Usually, if a new instance of a piston is fired when one is already running, it will loop for up to ten seconds to give the first one a chance to finish. That’s the ‘semaphore wait’ you might come across. I’ve never seen a wait that isn’t (roughly) ten seconds, which is odd as ten seconds is quite a long time for a piston to run. Regardless of that, it means that generally pistons are executed serially so you can safely work with variables and the like without conflict.

So the delay is often no big deal, but something could have happened in those ten seconds that changes things. For example, if a piston fires because the door is opened, ‘contact changes to open’ will be true even if it happened ten seconds ago. That might just mean a long time turning the light on. Or the door may have already been closed and things have moved on. That is why some people combine e.g. ‘changes to on’ with ‘is on’ in conditions.

And, of course, sometimes you just don’t want to wait so long.

So if the piston could be fired more than once in a short space of time, and being delayed by ten seconds might be an issue, and no harm would be done by running in parallel, then you might choose to enable parallelism.