Pistons with waits failing [TCP piston state change]

#21

I’m seeing the same, was testing time scheduled and waits to compare between webCoRE and SmartRules but everything was running on time.

#22

The piston I posted above is still not working correctly. Same exact issue as before.

#23
#24

Thanks. I think there’s either a different problem happening now or something wrong with the piston itself then. I created a new piston with a simple wait and it’s working. The one posted above still has the same problem. The glaring issue I see is the trace log that says its requesting a wake up, but there’s no info log that shows it’s setting up a scheduled job. See post 11 for screenshots. Quick Facts also shows Never for next scheduled.

I tried duplicating the piston, same issue. Also tried recreating from scratch, also same issue.

#25

Dug a little deeper. It’s specific to the TCP Cancel on Piston State Change. If I remove that setting from my switch block tasks, the waits work correctly.

Piston snapshot:

image
image.png1178×971 60 KB

TEP and TCP Set:
image
image.png802×918 20.5 KB

Trace shows wake up requested, info does not show a scheduled job, task after wait never executes:
image
image.png875×1187 62.8 KB

Gutter timer is positive/red:
image
image.png905×299 19.6 KB

Quick facts shows no next schedule:
image

Now if I leave TEP set as-is and remove TCP:

image
image.png699×1097 22.8 KB

Trace shows wake up requested, info shows a scheduled job now:
image
image.png861×1066 52.9 KB

Quick facts shows a next schedule:
image
Set State task after the wait executes:
image
image.png1023×272 20.3 KB

So…the question is, is there a problem with my logic in the piston, or is this a bug?

#26

@ipaterson any thoughts on my last post?

#28

I’d suggest its your use of 'changes to inactive ’ instead of ‘is inactive’

‘Changes to’ only remains true for about 20 seconds after changing, after which it reverts to false waiting for the next change to occur. Piston reverting to false will cancel your 60 second waits.

Try using ‘is inactive’ as this will only get cancelled if the device changes again.

#29

I’ll give that a shot when I get home later. Looking at the logs though, is it normal for the trace log to show that it’s requesting a wake up, but the info log to not show setting up a scheduled job? What was concerning to me was that it looked like the tasks after the wait were never scheduled in the first place, rather than being scheduled and subsequently canceled. That’s why I was asking if it was possibly a bug.

#30

I don’t thing waits have ever been listed as a scheduled job… that’s more for timers and the like.

If you go back to the main dashboard you should however see a countdown timer next to the piston, counting down from 60.

#31

They do show as a scheduled job, see the working and non-working screenshots I posted above.

#32

Not sure then… there is nothing obviously wrong with your logic, beyond my recommendation to use ‘IS’ instead of ‘CHANGES TO’… that should fix the wait not firing.

Perhaps the schedule not showing on the list is related to the fact that it is not guaranteed to happen when cancel is turned on.

#34

I changed it to “is inactive” instead of “changes to inactive” and it’s still behaving the exact same way. I’m fairly confident that TCP is not working as intended. It’s been awhile since I’ve been active in the forums, is there an official way to open a bug report, or is it just a thread here on the forum?

#35

This topic has a great discussion so I’ll just move it to the bug reports category and add a note about TCP to the title

#36

Thank you. Does anyone have any input on this issue?

#37

I plan to take a look at the TCP code later but have remained busy helping those who lost access to pistons or the dashboard after last week’s ST issues.