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!
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2147
Personally, I would use a latching piston for this.
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2148
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.
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.
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…
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
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2156
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.
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! (actually please never do that, enjoy away…)
1 Like
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2160
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.
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.
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:
turn off device
wait 2-3 seconds (will tinker to see what works optimally)
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 :
Turn Off
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?
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