[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)

this is the older version. the new one has a code of rgix2.

I based it on rgix2 but I see I messed things up a little when moved something around. I’ll redo it.

ok. you can import it using the orange button and using that code.

That what’s called condition traversal optimization and can be disabled for the piston. In an AND group, if any condition is found to be false, the rest is aborted as the result is already know as false. Similarly, for an OR group, if a condition is found to be true, the result is known to be true and the remaining conditions are skipped.

I know this is probably very simple, but how do I retrieve the state of a device, such as a thermostat, to where it would show in a push message and/or the piston state?

For example, “Current state of thermostat is cooling 72 degrees” or something along those lines.

There are a bunch of examples here

You could use a global variable to essentially pause the piston (only close the door if variable is true), then set the variable to false when you press the button.

what am I doing wrong here, the state says always True, and runs every 10 minutes
what I want is the light to not come on if illumination is below a level and to come on if above with motion
and switch off after 10 minutes, for 2 modes, then I want the same but for a night time setting of 5%

@ady624 makes sense. in the example that condition is an AND group. the first two conditions were TRUE so why were the remaining conditions aborted? if you look at the trace the remaining 2 conditions were not evaluated apparently, at least the trace does not have an indication that it was evaluated.

thank you.

It may be that a trace point is missing. Any full level logs?

@Robbie try this …

logs. where line 44 in image is condition #16. now puzzled why does the trace marks it green if it evaluated false per the logs?

6/21/2017, 4:29:37 PM +759ms
+2ms ╔Received event [Room Sensor].motion = inactive with a delay of 258ms
+382ms ║RunTime Analysis CS > 69ms > PS > 129ms > PE > 185ms > CE
+394ms ║Runtime (42943 bytes) successfully initialized in 129ms (v0.2.0c7.20170621) (390ms)
+395ms ║╔Execution stage started
+418ms ║║Comparison off is off = true (3ms)
+420ms ║║Condition #72 evaluated true (14ms)
+430ms ║║Comparison inactive changes_to active = false (1ms)
+432ms ║║Cancelling condition #41’s schedules…
+433ms ║║Condition #41 evaluated false (12ms)
+435ms ║║Condition group #1 evaluated false (state did not change) (30ms)
+459ms ║║Comparison on is on = true (3ms)
+462ms ║║Condition #73 evaluated true (24ms)
+474ms ║║Comparison inactive stays inactive = true (3ms)
+478ms ║║Adding a timed trigger schedule for condition 16
+481ms ║║Condition #16 evaluated false (18ms)
+483ms ║║Condition group #65 evaluated false (state did not change) (46ms)
+495ms ║║Condition #70 evaluated false (11ms)
+497ms ║║Condition group #66 evaluated false (state did not change) (12ms)
+508ms ║║Condition #71 evaluated false (10ms)
+510ms ║║Condition group #67 evaluated false (state did not change) (11ms)
+524ms ║║Condition #19 evaluated false (10ms)
+526ms ║║Condition group #47 evaluated false (state did not change) (11ms)
+537ms ║║Condition #57 evaluated false (10ms)
+543ms ║║Comparison :ee17d13c1af7dc867c099da184fa1c02: changes_to :ee17d13c1af7dc867c099da184fa1c02: = false (1ms)
+545ms ║║Condition #27 evaluated false (7ms)
+547ms ║║Condition group #55 evaluated false (state did not change) (20ms)
+551ms ║╚Execution stage complete. (157ms)
+554ms ║Setting up scheduled job for Wed, Jun 21 2017 @ 4:39:38 PM PDT (in 599.926s)
+573ms ╚Event processed successfully (574ms)

I have to redo the whole trace part to include timers - it was built way before timers were added and is a bit structurally incompatible. Do not worry much about it, the red line is more trustworthy.

ok. jfyi: when the timer does go off as part of a clause like that the timer condition itself does not get marked green in the trace. thanks.

what variable I check if the intrusion detected or smoke detected status? or what events I subscribe to?

try this

“temp: " format(”%.1f", round([Sensor : temperature], 1)) " degrees"

It would appear these pistons break even if I don’t update my side of the code. So, anytime there’s code updates pushed it’s breaking pistons that trigger on time of day. Anyone else experience this?

@ady624 - thoughts?

Does webCoRE have the “Save Event Value on True” ability that CoRE had?

My last piston I’d like to replace was a simple one that sends a notification everytime a door opens and another when it closes. (Basement door with kids).

In CoRE I saved the device list to a variable and the event value to a second one. Then I could have one push action {door} {state}.

I can get there with extra code…but trying to minimize and learn.

Yes, while editing the condition, click on the cog (gear icon) and you’ll see the option to Store the list of matching devices to variable. Also, non-matching.

I saw that but could find the event value on true option.

I think I got it figured from another example earlier in this thread. Basically I can send a notification like this
The {$currentEventDevice} is {[$currentEventDevice:contact]}