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

@ady624 You make me smile :slight_smile: Sometimes it’s so easy.

Yes, that’s what I was looking for…

Thanks for the very great work. It’s really amazing, I love webCoRE!

2 Likes

I have this piston and for the life of me I cannot figure out how to stop the timer from resetting and therefore not turning the light off.
I have tried various combinations of TEP and TCP for the ‘else’ to turn the lights off but it keeps resetting when the illuminanse sensor reports a new lux level.
Here’s the piston.


Here is a pic of the timer that keeps resetting.

EDIT. How about a work round if there is an easier way.

Just don’t use the lux as trigger…and enable TCP for the with…

This is for my LivingRoom with and without TV on …

Edit.
Ah. OK make the light level a restriction.

I just attempted to recreate this on my setup and it works as expected. In this case, “Switch 2” is a momentary button device type. TCP and TEP are at their default settings.

5/3/2017, 12:33:08 PM +746ms
+213ms	║Momentary button was pressed

Edit: Also, don’t get hung up thinking switches vs momentary buttons are vastly different, they’re not. They both have on and off states, and they both generate events when the state changes. webCoRE subscribes to these events, so there shouldn’t be any issues related to things happening “too fast”.

2 Likes

@dkkohler Hmm, I will modify mine now and try again. I’ll post back! Thank you for testing.

Or maybe I found the bug and fixed it last night?! :wink: 09c I think

Thanks @SBDOBRESCU. That did the trick.

1 Like

@ady624 You work fast, huh!? Does this bug fix require a GitHub update to the SmartApp? OR is it behind the scenes stuff?

[EDIT] I tested is using “Changes away from 'off” and it still didn’t work. However, setting it to “…switch is ‘on’” has worked, 3 for 3! I’ll take it :wink:

Thank you @ady624, @c1arkbar and @dkkohler!!

1 Like

So my condition is clearly faulty, even though it should be simple. Can anyone tell me why this isn’t firing? I assume that the piston will check in with each sensor and then determine they are all inactive and then do X.

Edit: The piston started firing when I got home. And has been going off ever since. So any idea why? I didn;t add a Mode to it. Is there a default Mode? @ady624 I couldn’t see one.

This is the log.

5/3/2017, 12:04:01 PM +101ms
+1ms ╔Starting piston… (v0.1.09d.20170503)
+112ms ║╔Subscribing to devices…
+121ms ║║Subscribing to Sensor Bedroom.motion…
+140ms ║║Subscribing to Sensor Computer.motion…
+148ms ║║Subscribing to Sensor Dressing.motion…
+155ms ║║Subscribing to Sensor Kitchen.motion…
+163ms ║║Subscribing to Sensor Living.motion…
+173ms ║╚Finished subscribing (66ms)
+347ms ╚Piston successfully started (347ms)

And this is the log after getting home.

2017-5-3 17:30:06 +318ms
+1ms ╔Received event [Sensor Kitchen].motion = inactive with a delay of 160ms
+498ms ║Runtime successfully initialized (v0.1.09d.20170503) (496ms)
+500ms ║╔Execution stage started
+550ms ║║Comparison inactive is inactive = true (4ms)
+555ms ║║Comparison inactive is inactive = true (3ms)
+560ms ║║Comparison inactive is inactive = true (4ms)
+565ms ║║Comparison inactive is inactive = true (4ms)
+570ms ║║Comparison inactive is inactive = true (4ms)
+574ms ║║Condition #2 evaluated true (61ms)
+576ms ║║Condition group #1 evaluated true (changed) (62ms)
+600ms ║║Executed virtual command [Sensor Bedroom].wait (7ms)
+608ms ║║Requesting a wake up for Wed, May 3 2017 @ 5:31:06 PM MDT (in 60.0s)
+775ms ║╚Execution stage complete. (276ms)
+864ms ║Setting up scheduled job for Wed, May 3 2017 @ 5:31:06 PM MDT (in 59.746s)
+889ms ╚Event processed successfully (888ms)

Correct. I use this type of structure in my system. That way I know it will be caught and then in the end it will be off ready to fire again!

1 Like

@dkkohler @ady624 The action of changing modes does work when using “is on” with the momentary button, however, the piston now seems to always be stuck in the “true” state. See below, this screenshot was taken at 2:33pm, 30 minutes later. According to the webCore dashboard when editing the piston, the switch was in the ‘off’ state.

Not really a question specific to webCoRE but figured I would build webCoRE for more trial run pistons. I want to be able to control the good night routine via Google Home and Alexa. My thought was to have a virtual switch or button that I would then code to in webCoRE. Is that the easiest way? I’d prefer not to have to create any virtual devices since they show up in the devices list in the ST app so any other good ideas are welcome.

You could use IFTTT Maker with webCoRE… without a virtual switch

I have the following piston. At the top it says:
This piston does not subscribe to any events. Unless executed by other means, it will never run on its own.

Will it not run on the time change?

It won’t, your clue to something that will trigger is the orange bolt that shows up on the gray gutter.

That is because system variables can not be subscribed to. Instead create a timer instead of an if. Then add your actions to that.

Just making a guess here, but was your house empty when you first made the piston? Your main condition is checking that all the motion sensors are inactive, but due to the event-driven nature of webCoRE, the piston will only run when an event is generated, i.e. when the state changes on one of your motion sensors. This would explain why it only triggered after you got home, since you started tripping the motion sensors, which then caused events to be generated. Does that make sense?

1 Like

Are we able to compare temperatures? This is what I’m looking to recreate

I changed my piston to a timer. It says it ran at the correct time, but it didn’t run the routine. And now the same message is back on it that it isn’t subscribed to any event. Not sure what I’m doing wrong. Here is the new piston.

Edit: Here is the log entry:
5/4/2017, 5:54:59 AM +105ms
+1ms ╔Received event [Home].time = 1493895300000 with a delay of -896ms
+300ms ╚Event processed successfully (300ms)