Thanks @ady624. I played with this thing for 2 days. How simple. I already did one earlier with disabling automatic piston state.
[DEPRECATED Thread: visit community.webcore.co for assistance] webCoRE - Piston Design Help (ask your fellow members for assistance)
So I did try the install of webcore. Again following the referenced manual, all 5 parts installed, one after the other, enabled Oauth, then tried to load it on the mobile device as described - no luck. The published apps are available, however, I can load the webcore app, at the 1st screen I don’t do any input (no input fileds are showing) and press “Next”. The app then erors out with "Oops! Looks like you need to double check some inputs."
Then I went and installed it to the location via the simulator, and this time it seems to show on both sides (IDE/Simulator as well as the on the mobile device). However, the access to the dashboard on the mobile device fails after I enter the password and I can see in the SmarTthings IDE log a message that the token is invalid. Any ideas?
Mobile: Windows Phone 10 /Edge
Desktop: Ubuntu 16.4/Chome
When using triggers, if the triggers are within nested if statements and not at the top level, does that cause any issues in the trigger firing? Like so …
Adrian did get it to work for someone. I remember reading about it. He had him go in and manually change something in the webcore code. It had something to do with a required tag on a set of text.
Those are still technically top level unless all of that is nested in another IF that you cut out.
The problem you are referencing would be like this
If front door contact changes to open
If any other trigger thing happens
This will never fire because the likely hood of those two events is on the same grounds of shuffling a deck of cards into any order that had ever occurred before. https://youtu.be/T69cguFzZ_w
@c1arkbar thanks, yes copied the wrong example. please see revised example in the post above.
That should work but best practice is to use that as a restriction instead
Unfortunately @Amo1 you’re beating a dead horse. ST is no longer supporting the WP app and that app is the worst of the three (Android, iOS, WP). It has an issue with all the “required: true” on paragraphs, so you could go through the webCoRE code and look for all
paragraph and delete their required: true (you will have to delete a comma as well). Then save it and publish and try again. It may let you finish the installation, luckily you won’t need it much after that. I have a feeling once installed, it works (the settings part have required paragraphs which only makes them red - but the WP app takes that required literally, even though there is NO possible input from the user)
Is there a bug in Webcore? For some reason the part highlighted in yellow will not trigger and I have no idea why. Could it be this particular if statement has a bug - if time happens daily at 15 minutes past sunset. Because all the other statements in here are working as expected. The part highlighted in yellow are supposed to trigger Wemo switches which work fine.
I am moving my pistons from CoRe to webCoRe and have a question.
I want a routine to trigger when either me or my wife come home but I dont want it to trigger if one of us is already home. On CoRe I had the option to turn on only if piston state changes. Can anyone tell me where that function is in webCoRe?
I have been looking for days and cant figure it out. Thanks.
Click “with” for your actions and then click the cog at the bottom of that window that cog you will be able to pull down options for cancel on condition state change. (you should get a green C on your actions). A green circle with a C.
I had the same problem you are having so here’s my piston to fix it.
Thank you, I found it. Do you know what the difference between condition state change and piston state change is? Is it just looking at one part vs the entire piston?
the cancel on piston state change option should be used in conjunction with custom piston states. Disable the automatic piston state in the piston settings (click on its name in the editor) and then use the Set piston state task in different branches of your logic to set it to different things - see how other users use that in crazy ways
I can tell you that cancel on piston state change did not help me. I had to change it to cancel on condition state change and that worked.
Gotcha. I’m completly new to the programming language so this has been a slow learning process for me. The “on the surface” stuff makes sense to me but the deeper things still baffle.
Why are you using time triggers inside while loops? Try changing the whiles to ifs, or better yet, use timers, this is what they are designed for. While is designed to repeat the designated actions as long as a comparison statement is true.
@c1arkbar Thank you for confirming. On that, if I am executing a series of tasks each with the same restriction vs using a if check as above, is there a processing efficiency difference?
while loops should not have triggers in their condition - that trigger prevents the loop from ever repeating because the trigger won’t be true the second time around. Also, loops should have a wait in them to prevent infinite loops.
Use IFs, not whiles…
OK, thanks - I can try that I guess I am just wondering why all these statements work except the one I have highlighted. I guess the way I implemented it is not reliable but it does work mostly except for one of the repeat statements so that seems like a bug still.