$currentEventAttribute does not report correctly when attribute is 'time'

#21

Weird.

#22

There is code in webCoRE for scheduled events (timers) to attempt to restore the state when the timer was created.

I appears this code is running, and if the timer ‘was created’ by test, it restores some of the original event state (name, value, description, unit, physical

It also appears it tries to restore $args…

There is code executeEvent:

if(evntName==‘time’ && event.schedule!=null){
srcEvent=event.schedule.evt

I’m guessing the thought process was if you did a wait to resume the wait (ok), but it seems to be using it for any timer - so likely it needs to distinguish a wait during execution (resumable) vs. scheduled run…)

#23

When I came across this thread last night, it was already stupid o’clock. It still kept me awake until the wee small hours. Unfortunately the new app was playing silly beggars today and I never got a chance to revisit it and get the sequencing right in my head.

If you had a piston with e.g. ‘wait 3 seconds’ in it, you’d expect $cEA to be the same before and after the wait as you are still processing the same event. So it doesn’t seen unreasonable for it to persist after e.g. ‘wait 10 minutes’ too. So if the piston is waking up after a wait you have the apparent contradiction that the event attribute is ‘timer’ but the $cEA is still whatever it was when the wait was scheduled.

I guess what we are seeing is the piston being unable to recognise the ‘happens daily’ timer as a new phase of exexcution rather than a wake up timer on the old one. I can’t even decide if that is a bug or not. I couldn’t work out last night if the happens daily time being an expression affected things.

I thing @E_Sch has said the same thing while I am typing.

#24

I know it was a lot to follow in the various tests I did. I tried making the timer fixed (set to a specified time shortly in the future. Still was the same. If I hit ‘test’ first, then when the timer executed, the event still showed as ‘test’ There is no wait in this piston so none of these were waking uppitiest for a wait. They were all executing the ‘happens daily at’ as the first statement in the piston. Also, I tried hitting test and then waiting for multiple cycles of the timer and 'test; persisted as indefinitely as I tested (2-3 cycles). If I don’t hit test after editing, the ‘time’ attribute is reported continuously until either a ‘test’ or ‘execute’ event occurs.

From what @E_Sch said, it appears there is an attempt to restore when waking up from a wait and maybe the ‘happens daily at’ is being treated as a wake up? ‘every’ is completely different and always seems to report properly.