Piston not triggering


#1

I’m almost certain this is a simple mistake I’ve made but can anyone please guide me on why this Piston isn’t triggering?


#2

Force it to subscribe to Outlet 3… right now it’s just waiting for time… you can tell by the orange bolt.

Select the device, click the cog icon (wheel), Always subscribe under Subscription Method.


#3

Umm ok I’ve done that so will test it later but I don’t quite get what I’m changing and what exactly does subscribing mean? And even if it is just waiting for time, shouldn’t that work because as soon as the specified time is reached it should kick off the Piston…


#4

Subscribing means the piston will watch for events from the device. In your first picture example, the orange bolt on the gutter indicates the piston is waiting for that 930pm time only.

Actually, now that I looked at it some more, it will not fire because you will have 2 triggers which will never happen.

Edit: Let me try rearranging it on my end.


#5

Hmm I’ll wait for your rework. I don’t understand why my two conditions won’t fire…


#6

You could try something like this. It’s untested but should work.


#7

This is what I came up with, you can import it or edit your original. My version has shortened time for testing and also I dont have Contacts enabled.

You can edit yours so that all of the Tasks are in sequence in that one group.


#8

This is how I was going to structure it as well. You might need to change the TCP to never cancel. You’ll find this setting by clicking on the with and then clicking the cog icon.

The reason for this is due to the long wait. Eventually the piston state will revert back to false (because it is no longer 9:30:00 pm and the switch is no longer on) and this will cancel any pending tasks. Usually happens within 30 seconds after firing.

@freddyq


#9

Thanks @eibyer for the restructured code, I decided to import yours rather than mess with my original. The only bit I don’t get in your code is why the ‘Turn off’ and second ‘Send notification’ tasks have “(only while )” next to them, i.e. is that deliberate for a reason I don’t understand or do I really need to make those “only while Home”? The reason have the location mode condition is because I don’t want this piston clashing with one I have for simulating lights when we are away - although thinking about it now that light simulation piston has a condition to only run if SHM and location are Away so I don’t think a clash could happen anyway…

@c1arkbar I didn’t know much about TCP until I just read about it, I think I half understand the concept. In my example, the reason I need to say never cancel tasks is because in the time between 21:30 and 22:15 the state of the light might change (by us physically pressing the switch) which would break the piston out of it’s logic and therefore mean it won’t run to the end?

Also, can someone please explain why my original logic wouldn’t run but the new one will? I think I have a gap in my knowledge about triggers and conditions…

Oh and also, given I just want to make sure this piston only runs when we are home, wouldn’t it be cleaner to add a condition in the “if” statement at the top to say “location mode is Home” and then remove all the “while home” statements further down?


#10

Not so much by you changing the light switch. As long as at 9:30 pm exactly that light switch is on then your piston will evaluate as true and will begin to execute your actions.

However after it is no longer 9:30 pm then the piston state will now be false. What happens is then any remaining actions will be canceled. This usually happens shortly after executing because even 1 second after execution the piston is no longer true.

Changing the TCP to never cancel is basically saying if these conditions are true then run ALL these actions regardless of the conditions changing back to false.

This one and the old one are almost identical. The actions are just cleaned up.

That would make it easier if you were to change or add anything down the line.


#11

Ahh I got it - TCP another thing that will prove useful to know.

So can I just check, the reason my original piston didn’t run is because after it hit 9:30:01 the piston state became false and it didn’t follow through with the action of switching off the light or notifying me? And presumably that 1 second wasn’t long enough for the actions to execute?


#12

It should have executed anything up until a wait. I mentioned the 1 second as an example of why it would change to false.

No one can really know much or answer why it wasn’t working without guessing since there were no logs attached. There was a template for this category that was created to get as much information into the first post as possible. This gets answers faster for the user asking questions because we don’t have to ask for the info then wait for each other to get back on.


#13

OK fair enough - I’ll remember to enable logging on pistons i think there are issues with in future.

Thanks!


#14

The (only while) is just a cosmetic bug that gets left behind when you remove all the Mode conditions. I removed your Home mode for testing yesterday.


#15

Ah right - that was my suspicion so thanks for confirming. I will ignore it.