Here’s what I tried:
- Create new piston with emojis
- Edit an existing piston with emojis
- Edit the same piston to add emojis
Thanks!
@SrLANGuy if you try it do please let me know if it works … just so i know for my own pistons:
If contact sensor contact changes to open
and
location mode is Arrived
Thanks!
Thanks CHRIS, here’s the full log! I had to open the door twice for the piston to trigger my actions:
6/6/2017 7:15:57 PM +485ms
+2ms
╔Received event [Front Door].contact = open with a delay of 486ms
+141ms
║RunTime Analysis CS > 20ms > PS > 65ms > PE > 56ms > CE
+152ms
║Runtime (31488 bytes) successfully initialized in 65ms (v0.1.0b7.20170603) (150ms)
+153ms
║╔Execution stage started
+170ms
║║Comparison :1ff7a931b4db2dd0264e0d11640b0457: is :1ff7a931b4db2dd0264e0d11640b0457: = true (3ms)
+172ms
║║Condition #12 evaluated true (10ms)
+174ms
║║Condition group #null evaluated true (state did not change) (12ms)
+187ms
║║Comparison open changes_to open = true (1ms)
+189ms
║║Cancelling condition #11’s schedules…
+191ms
║║Condition #11 evaluated true (12ms)
+192ms
║║Cancelling condition #2’s schedules…
+194ms
║║Condition group #2 evaluated true (state changed) (16ms)
+198ms
║║Cancelling statement #3’s schedules…
+208ms
║║Skipped execution of physical command [Computer].on([]) because it would make no change to the device. (3ms)
+209ms
║║Executed [Computer].on (5ms)
+237ms
║║Executed physical command [Kitchen Light].on() (23ms)
+238ms
║║Executed [Kitchen Light].on (25ms)
+315ms
║║Executed physical command [Watch TiVo [Harmony Activity]].on() (73ms)
+316ms
║║Executed [Watch TiVo [Harmony Activity]].on (75ms)
+321ms
║║Cancelling statement #5’s schedules…
+362ms
║║Executed virtual command setLocationMode (37ms)
+415ms
║║Comparison 1496794557853 is_between 1496798640000 … 1496745420000 = false (8ms)
+418ms
║║Condition #10 evaluated false (51ms)
+419ms
║║Condition group #7 evaluated false (state did not change) (53ms)
+424ms
║╚Execution stage complete. (271ms)
+433ms
╚Event processed successfully (432ms)
6/6/2017 7:15:38 PM +464ms
+1ms
╔Received event [Front Door].contact = closed with a delay of 392ms
+149ms
║RunTime Analysis CS > 22ms > PS > 70ms > PE > 58ms > CE
+161ms
║Runtime (31488 bytes) successfully initialized in 70ms (v0.1.0b7.20170603) (159ms)
+162ms
║╔Execution stage started
+178ms
║║Comparison :1ff7a931b4db2dd0264e0d11640b0457: is :1ff7a931b4db2dd0264e0d11640b0457: = true (3ms)
+181ms
║║Condition #12 evaluated true (9ms)
+182ms
║║Condition group #null evaluated true (state did not change) (12ms)
+194ms
║║Comparison closed changes_to open = false (1ms)
+196ms
║║Condition #11 evaluated false (10ms)
+198ms
║║Condition group #2 evaluated false (state did not change) (13ms)
+202ms
║╚Execution stage complete. (39ms)
+212ms
╚Event processed successfully (213ms)
6/6/2017 7:15:18 PM +461ms
+1ms
╔Received event [Front Door].contact = open with a delay of 444ms
+124ms
║RunTime Analysis CS > 17ms > PS > 55ms > PE > 52ms > CE
+133ms
║Runtime (31481 bytes) successfully initialized in 55ms (v0.1.0b7.20170603) (131ms)
+135ms
║╔Execution stage started
+151ms
║║Comparison :1ff7a931b4db2dd0264e0d11640b0457: is :1ff7a931b4db2dd0264e0d11640b0457: = true (3ms)
+153ms
║║Cancelling condition #12’s schedules…
+155ms
║║Condition #12 evaluated true (11ms)
+156ms
║║Cancelling condition #null’s schedules…
+157ms
║║Condition group #null evaluated true (state changed) (15ms)
+169ms
║║Comparison open changes_to open = false (1ms)
+171ms
║║Cancelling condition #11’s schedules…
+173ms
║║Condition #11 evaluated false (11ms)
+175ms
║║Cancelling condition #2’s schedules…
+176ms
║║Condition group #2 evaluated false (state changed) (15ms)
+180ms
║╚Execution stage complete. (46ms)
+190ms
╚Event processed successfully (190ms)
@stevehweb remove the lights are off from the until clause and insert an if check after loopcounter++ and if all the lights are off then break.
You can have multiple IF statements. No need to hack away like in CoRE. So use your else’s when you need to but don’t feel like that’s the only way too
Ah, good idea @bangali, thanks, I’ll do that. @ady624, is this expected behavior that devices in the until clause subscribe to events rather than act as conditions? I’d like to understand this going forward - thanks in advance!
thanks. need more beta testers?
sure. btw, funny part is if you have one device then it’s a condition but if there are multiple devices in the until clause it becomes a trigger.
With some help from the awesome @anon36505037 I’ve finally completed my multiple sensor temperature averaging Piston
it uses: (the = xyz is to follow along in my narrative below)
1: Virtual Temperature Sensor = Dimmer 12
2: Temperature sensors
1) Iris button = Keypad 4
1) Gocontrol Motion sensor = Motion Sensor 6
variables:
input_temp_A = A
input_temp_B = B
avg_temp = C
It does:
* every hour on the :55, refreshes both sensors, then:
-OR-
* if either temperature sensor value changes, set variable A or B to temp sensor A or B value
* if variable A or B changes anytime, OR variable A or B stay unchanged for 30min, set variable C to (avg of A+B)
* when variable C changes, wait 5 sec, “setTemperature” on Virtual Temp Sensor to value of variable C
For some reason, the first time you open your door, you get this:
The second time your door opens, you get this:
I have no idea why this should be false the first time you open your door 
. I imported your piston and it works first time and every time I opened my test door — I couldn’t get it to fail. I originally thought that there may be lag in the piston’s restriction (Arrived mode), but your logs say otherwise. But, there was a state change due to the change to the Arrived mode:
The only things I can think to do at the moment is duplicate your piston (or restore with the import code) and see if anything changes. You can also make the “Location mode is Arrived” part of the top-level IF block condition, instead of a piston restriction, and see what that does.
Also, use the presets for sunset and sunrise for your “Time is between” condition, in the imbedded IF block — {$sunset} and {$sunrise} are the current day’s sunset and sunrise. This isn’t part of the original problem, but thought I’d mention it just the same.
Have you tried using “is open” instead of “changes to open”? Changes to requires an initial cycle to register the state as “closed”, although after that they should behave the same. The condition “is open” has less overhead though, so it’s probably the better choice in your case.
1 Like
That bug has been resolved
1 Like
I’m not quite sure what the difference in programmatically between using the Else If and separate If statements, but that resolved the issue, thank you!
My piston fires but only completes 2/3 steps. Logging has not explained why (at least not to me).
Its a simple piston. Sense motion, turn light on, wait 3 min, turn off.
The logging shows everything up to the Wait, but then nothing. I have just been manually turning the light off when i notice it still on. I’m assuming that I should see the OFF command if it actually happens. I turned it off at 1:30 am this morning manually.
Thanks!
6/6/2017, 10:40:54 PM +678ms
+2ms ╔Received event [Front Door].motion = active with a delay of 164ms
+272ms ║RunTime Analysis CS > 41ms > PS > 148ms > PE > 83ms > CE
+284ms ║Runtime (30837 bytes) successfully initialized in 148ms (v0.1.0b7.20170603) (281ms)
+286ms ║╔Execution stage started
+303ms ║║Comparison active changes_to active = true (1ms)
+305ms ║║Cancelling condition #7’s schedules…
+306ms ║║Condition #7 evaluated true (11ms)
+308ms ║║Cancelling condition #1’s schedules…
+309ms ║║Condition group #1 evaluated true (state changed) (13ms)
+323ms ║║Comparison 10 is_less_than_or_equal_to 1000 = true (3ms)
+325ms ║║Cancelling condition #6’s schedules…
+327ms ║║Condition #6 evaluated true (14ms)
+328ms ║║Cancelling condition #2’s schedules…
+329ms ║║Condition group #2 evaluated true (state changed) (18ms)
+330ms ║║Cancelling statement #2’s schedules…
+391ms ║║Executed physical command [LGT Porch C].setLevel([50]) (53ms)
+393ms ║║Executed [LGT Porch C].setLevel (55ms)
+399ms ║║Executed virtual command [LGT Porch C].wait (1ms)
+401ms ║║Requesting a wake up for Tue, Jun 6 2017 @ 10:43:55 PM MDT (in 180.0s)
+410ms ║╚Execution stage complete. (125ms)
+413ms ║Setting up scheduled job for Tue, Jun 6 2017 @ 10:43:55 PM MDT (in 179.99s)
+466ms ╚Event processed successfully (466ms)
Try moving your lux restriction into your IF statement.
IF
Motion Sensor is active
AND
Temp Sensor Lux Is Below …
WITH
…
DO
…
Are you sure the motion stays active for the three minutes? Disable TCP on the with block, set it to never cancel
1 Like
Ahhh…it definitely does not stay active that long. I forget now that TCP is on by default.
Thanks
I’m trying to convert a piston from CoRE to webCoRE and it’s not working as expected. I have 3 motion sensors in a long hallway which each cover a unique area. I want it so that if all of the motion detects have not see any motion in the last 3 minutes then it should turn off the lights.
@rontalley provided great advice last month which is here: CoRE - Get peer assistance here with setting up Pistons . I followed that and it has been working great under CoRE.
Now I’ve tried to recreate this under webCoRE, but the problem is that it turns the lights off after 3 minutes even if one of the motions see more movement before then. It’s like the Cancel on Piston State Change is not working, but as you can see from the webCoRE piston below, I do have that option set.
The way it works in CoRE, which is how I want it to work, is that you can move around as much as you want and the timer will not go out until its been 3 minutes with no motion. With this webCoRE piston, it turns the light out after 3 minutes of first seeing the motion, regardless of how many times it sees motion. IOW it doesn’t reset the timer back to waiting another 3 minutes from the last point which it saw motion.
What am I doing wrong? Thank you!
Instead of “are inactive” try “changes to inactive”.
Here’s my piston that turns my Garage lights on and off based on motion from two sensors. You could just use the second half if you only want to turn lights off.
