CoRE - Get peer assistance here with setting up Pistons

Why isn’t the first action in my else running here?

Motion just changed to inactive and mode is Home-Day.

Edit: Here is debug captured. @ady624 I think mode restrictions per task aren’t working. Or I’m missing something. The only task that runs in this else is the one that has no mode restrictions (you can just barely see it peeking at the bottom), I’ll post another screenshot. Notice that the false actuates, but it thinks there is only 1 task to execute. There should be 2 or 4 depending on how you count them, not one.

1:51:29 PM: debug ╔═══ Done in 1774ms
1:51:29 PM: trace ║╔══ Task processing took 1412ms
1:51:29 PM: trace ║║░░ Removing any existing ST safety nets
1:51:29 PM: info ║║░░ Executing command: [Thermostat - Family Room].fanAuto() (1027ms)
1:51:28 PM: debug ║║░░ Processing command task [taskId:1, time:1472406688304, idx:3, marker:1472406688318, created:1472406688313, ownerId:6, type:cmd, deviceId:e5f4e588-0605-4958-a77b-5b7d1a0fd0ff]
1:51:28 PM: debug ║║░░ Found 1 task due at this time
1:51:28 PM: trace ║║░░ Installing ST safety net
1:51:28 PM: trace ║║░░ Rescheduling time triggers
1:51:28 PM: trace ║╚══ Processing tasks (v0.2.145.20160822)
1:51:28 PM: trace ║╔══ Event processing took 350ms
1:51:28 PM: info ║║░░ ♦ Simple Piston changed state to false ♦
1:51:28 PM: debug ║║░░ Primary IF block evaluation result is false
1:51:28 PM: debug ║║░░ ♣ Function eval_cond_is_one_of for House's mode [Home-Day] is one of '[Home-Day, Home-Night, House-Sit, Home-Sleep]' returned true
1:51:28 PM: debug ║║░░ ♠ Function eval_cond_is for mZone-Family Room's motion [inactive] is 'active' returned false
1:51:28 PM: debug ║║░░ Event eligibility for the primary IF block is 1 - ELIGIBLE (triggers not required, event is a condition)
1:51:27 PM: trace ║╚══ Processing event motion for device mZone-Family Room with id 94352ab0-7229-42f7-b4f5-52a8c6d5f803, value inactive, generated on Sun Aug 28 17:51:26 UTC 2016, about 1333ms ago (v0.2.145.20160822)
1:51:27 PM: debug ╚═══ Received a primary block device event

Here is the rest of the piston. Mode is Home Day. I will try turning of TOS Action, but think it’s the default, and this isn’t scheduling anything… Help!

ok - i’ve been all over this thread and i am missing something. This is my away piston. Why does it not work?

Personally, I would use a latching piston for this.

I’ve used the TOS global before and never got my piston to work correctly, if I had scheduling in it, like yours. I think the piston is canceling its own scheduling as well.

Try removing the TOS and see if it works then.

1 Like

Ooo, I’m going to be a PIA. Why? Simple should work here, it’s a simple if/else.

I don’t know. Cause.

Cause why? :wink: (as the children around here say).

I’ll try some debug next, something’s not right here. I’d using latching if the conditions were different to hold it true versus holding it false, but in this case it’s very simple. If these conditions, run these actions, else run these actions.

My turn, if anybody can spot an issue…

I have 4 pistons set up identically, and ALL were fully function, except of course, now they stopped working… (It is possible I inadvertently made a change, but I doubt it)

This is the log file… It clearly shows the sensors reporting state, but the send messages simply do not get set… Like I said, it was working for several weeks previously…

Thanks in advance
J

Ok, I think I figured it out. I made a change to my thermostats yesterday. I wanted it to be set to auto mode.

So, in the actions I did this:

 Set thermostat mode
 Mode > auto

This did not work. The mode would not change.

So, I changed it to:

   Set to auto

This time it worked.

Fyi, this is on the Honeywell 8320 wave thermostats.

So, it could just be that the setting is wrong for your thermostat. Has that command worked for you in the past?

Also, this is pretty much a true false type scenario. Why not just use a basic our simple piston and use true/false?

This is definitely a situation in which I would use a latching piston. The door is open or the door is closed, perfect for latching.

I use the latching piston for thinks like this because it has always been very reliable for me… Also very flexible.

But, there may also be an issue with push messages that ST hasn’t mentioned yet.

In the dashboard, does either part turn blue when it’s true? Or is it just staying false?

Try changing it to latching and see if that gets it working again.

You may be correct @bamarayne that a latching piston may be better… But I have issues wrapping my head around it. Besides, these pistons were functional! Wonder if @ady624 can weigh in here.

About the only change that has occurred in my environment is me upgrading to the latest Android app version. Now I am not 100% certain [a mind looking for a reason often finds one], and it may be pure co-incidence, but I think the issue may have started happening at that point in time. Besides, is it even possible that the app interface can have a behavioural effect?

J

I honestly don’t know. I updated my so as well but I’ve not had any problems. I’m receiving all of push messages.

Inclined to agree, and, like you, I am receiving all OTHER push messages. Go figure.

J

Something may have changed in the back end that is affecting only certain pistons.

I actually only use basic, simple, and latching pistons. I’ve not found a use for any others.

It has. I just redid my pistons using the same commands, just combined, so I know it’s something amiss here. I believe mode restrictions at action/task level may not be working, or TOS was an issue, waiting to test TOS at the moment.

EDIT: It’s not TOS, just tested. I bet it’s mode restrictions. @ady624 stop enjoying your weekend! :wink: (actually please never do that, enjoy away…)

1 Like

This is mine. I’m not using presence yet, but mine are mode triggered.

Mine worked when they looked like yours (no mode restrictions). I switched to mode restrictions to handle sleep and away in the same piston, and that is where I’ve gone afoul. :confused:

I can make them work again, but I’m lazy and want to help make sure bugs are smashed, or understanding is gained if I’m missing something.

1 Like

I have a basic Add-A-Motor motor on a curtain. It was created for old X10 technology. The way it works is if you give it power it opens the curtain. To close the curtain, you unplug it and wait about 2-3 seconds, then plug it back in. I have it connected to a Z wave plug in module for Appliance. To open the curtain you “turn it on”. To reverse direction (ie close curtain), you “turn it off”, wait about 2-3 seconds then “turn it back on”. To open curtain again, you again, “turn it off”, wait 2-3 seconds until you hear a click, then turn it back on.

Specifically, it needs to:

  1. turn off device
  2. wait 2-3 seconds (will tinker to see what works optimally)
  3. turn on device

So most of the time, the device should be in On state (whether curtain is open or closed).

i started messing with Core and was able to add a piston where:
If device is On, then :

  1. Turn Off
  2. Turn on (delayed)

Now i don’t know what to do with that piston. Can i turn it into a virtual switch? Should i not have used If Then? If so, how would I just make it do Turn Off then Turn On (delayed) w/o If Then?

thanks for helping this newbie.

And this time I caught it changing it! Not sure what to think now.

4:24:10 PM: debug ╔═══ Done in 1804ms
4:24:10 PM: trace ║╔══ Task processing took 1476ms
4:24:10 PM: trace ║║░░ Removing any existing ST safety nets
4:24:10 PM: info ║║░░ Executing command: [Thermostat - Family Room].setCoolingSetpoint([74]) (1156ms)
4:24:09 PM: debug ║║░░ Processing command task [taskId:1, time:1472415848831, idx:1, marker:1472415848864, created:1472415848844, ownerId:2, data:[p:[[d:74, t:decimal, i:0]]], type:cmd, deviceId:e5f4e588-0605-4958-a77b-5b7d1a0fd0ff]
4:24:08 PM: debug ║║░░ Found 3 tasks due at this time
4:24:08 PM: trace ║║░░ Installing ST safety net
4:24:08 PM: trace ║║░░ Rescheduling time triggers
4:24:08 PM: trace ║╚══ Processing tasks (v0.2.145.20160822)
4:24:08 PM: trace ║╔══ Event processing took 327ms
4:24:08 PM: info ║║░░ ♦ Simple Piston changed state to false ♦
4:24:08 PM: debug ║║░░ Primary IF block evaluation result is false
4:24:08 PM: debug ║║░░ ♣ Function eval_cond_is_one_of for House's mode [Home-Day] is one of '[Home-Day, Home-Night, House-Sit, Home-Sleep]' returned true
4:24:08 PM: debug ║║░░ ♠ Function eval_cond_is for mZone-Family Room's motion [inactive] is 'active' returned false
4:24:08 PM: debug ║║░░ Event eligibility for the primary IF block is 1 - ELIGIBLE (triggers not required, event is a condition)
4:24:08 PM: trace ║╚══ Processing event motion for device mZone-Family Room with id 94352ab0-7229-42f7-b4f5-52a8c6d5f803, value inactive, generated on Sun Aug 28 20:24:07 UTC 2016, about 674ms ago (v0.2.145.20160822)
4:24:08 PM: debug ╚═══ Received a primary block device event

What’s going on here?!