CoRE - Get peer assistance here with setting up Pistons

Another one stumping me a little because I do not understand the logic decisions to use (if this was a pure programming language I would be good, I thinkā€¦)

What I have: a BASIC If Then scenario

This has actually been working like a charm (yes, there is a reason I had to implement the VAR), until today, when for the first time the Cancel clause kicked in mid-way. Yup, it stopped the piston from executing like it is supposed to do. BUT, it also left my piston ā€œbrokenā€ in as much that the VAR never got set to False againā€¦, and now it has failed to run again because this is set as well

Is there a way to re-initialize a VAR on the fly when the cancel occurs? Does a FALSE, if implemented via a different type of piston, get executed when the Cancel kicks in? (From what I read, no)

Thoughts?

Thanks in advance
J

Why are you using string variables and not boolean? Can we see the if? Note that groovy (and by extension CoRE) is case sensitive. False is not the same as false, just like True is not the same as true.

Youā€™re correct @ady624 re the case of the VARs, I figured that out by trial and error. As mentioned, it does workā€¦ As to the why, readability in ā€œplain English.ā€ Some of these pistons I am doing are proof of concept which I will implement in a more logical fashion in due course.

Sure, here is the IF; didnā€™t include it originally because there is really only 1 logical outcome for the THEN to be executed (and it works).

You may want to separate the last set var into a different action that does not get canceled on piston change (so it runs eventually, use a wait as the first task) or convert that to a simple piston and also set the var to False on the ELSE branch. That will ensure correct recycling.

So youā€™re saying that a CANCEL ON PISTON STATE CHANGE is the equivalent of, and will branch to, a FALSE, aka the the ELSE branch, and execute? Is that true for all pistons, or only the Simple piston?

Thanks, Iā€™ll be checking it outā€¦

J

Well, think about it, for a simple piston that turns true and executes the THEN branch, if the state changes, guess where it goes! To false, of course. And if the evalution is false, the ELSE would then run, no? :wink: when a piston state changes, it cancels all tasks marked to be canceled on piston state change and then it will execute whatever actions are programmed for that new stateā€¦

Canā€™t argue with your logic @ady624, but consider thisā€¦

A cancel can also be interpreted as"stop all further execution (including branching to false) & do nothing", which if one is to read the anecdotal behavior in this and other threads re Core, is implied. As the programmer, you have a unique insight into the code logic, and while I have the ability to read it for myself, dude, I do not have the tenacity! Cudos to you!!!

J

1 Like

Well, only the selected action will be canceled on piston state changeā€¦ this only applies to delayed tasks, since those non-delayed have executed way before any piston state change. But you can mix and match, have actions that cancel and others that do not.

By way of your argument, I would like to make a suggestion for enhancement: When a CANCEL event occurs, can we have the option of writing it to Notification? While live logging is useful, it is difficult to read, and if not actively being monitored, leaves a lot to be desired. The Notification can represent the best of both worlds.

J

so does core SmartApp delete itself regularly and all my Pistons? I had three set up now they are gone :frowning:

There is no ā€œcancelā€ event per se, but when evaluation completes, if the new state is different than the original state before evaluation, a routine is executed that looks for any tasks marked as cancelable. If any is found, it is simply removed so it wonā€™t run anymore. But this ā€œeventā€ happens every time the piston state changes, which would overflow the notification page. Sorry :wink:

No, I donā€™t remember enabling such a featureā€¦ Are you accessing CoRE through the marketplace by any chance? You need to access it via the hamburger menu (lol) > Smart Apps. The hamburger menu is the options menu on the top right: three stacked horizontal lines. Hamburger.

1 Like

So, for stability sake Iā€™ve decided to approach CoRE in a different manner.

For example:

I have 7 presence sensors that come and go throughout the day. I have all of these in one giant piston along with some other things in there that are triggered by arrival/departure.

Iā€™ve not experienced any problems that I had been realizing. This huge piston was set up in a Latching piston. There have been times that the piston did not fire correctly, especially if multiple sensors arrived at once.

So, I broke them up into separate pistons. We will see if that makes a difference.

But, the difference in approach is thisā€¦

I believe that ST has been designed around a one shot type of smartapp. Small, simple, to the point. But, I really do not want several hundred pistons in there for me to go through to find something. So this is what Iā€™ve done.

I now have seven (7) separate installs of CoRE. Iā€™ve been running 5 for a couple of weeks now and Iā€™ve not had a single issue with it.

As you can see each one is a category of piston types. This is strictly for organizational purposes.

For those of you that are using AskAlexa/CoRE integration. AskAlexa will see the pistons in all of the installs of CoRE and vice versa. So, no problems there.

Iā€™ve abandoned the ā€œUltimate Pistonā€ (total failure by the way) for the ā€œUltimate Pistons Set-up with Super Awesome Stabilityā€.

ā€¦ more to come.

3 Likes

You go from one extreme to the other!

This is another wild theory based on what I have no idea, but really I am not sure what issue you are trying to solve here. When you say you believe ST was designed for small simple apps - how is your approach here meant to intersect with that theorized design goal and therefore, in theory, work better?

So, my understanding, each piston is itā€™s own app anyway. So outside of organization, I am not sure what you gain from separate CoRE installations. The downside to this, as far as I can tell, is that you cannot have pistons from different containers interact through variables. Which I donā€™t like. You can do it through simple binary communication using virtual switches, but thatā€™s much more limited and complex to execute.

You had instability, you changed CoRE in an attempt to solve it and now you donā€™t have stability issues? The problem there is that while you can correlate them, you donā€™t have causal link. What else changed in the ST backend you have no insight on? Is it simply because you blew away the logic and rebuilt it? State or something else stuck - DB corruptions unknown to you or even ST, etcā€¦

I am afraid weā€™re all left to chase our tails when issues come about around here. There are so many theories, but not much of it can be relied upon IMO. There are just too many dynamics unknown and unknowable to us.

Bless you for testing every possible approach. You are tireless. Perhaps manic. Seek diagnosis.:grin:

3 Likes

I think the key is in number of devices a single Piston reacts to/relies onā€¦

Iā€™ve been trying to simplify so a single sensor that may cause many device actions, is a single piston. Or in some cases a few, like multiple motion sensors in one room just for coverage. The fewer ā€œaction itemsā€ the better response kind of thought process.

My understanding is that means the piston is only looking at that one device to fire off, vs some of my longer button controller replacement pistons where it needs to keep track of multiple devicesā€™ and their actions.

Oh and Iā€™ve set all my power meters to a 15 second monitor period, that noticeably sped things up. ST seems to flat out suck at handling a lot of stuff in a single second, which is hilarious since I deal with 10/100Gb routers dailyā€¦my brain doesnā€™t comprehend thisā€¦Iā€™m guessing it may be a limitation of the Zigbee mesh more than anything.

1 Like

Yes, I agree! I blame my ex wife.

Not another theory and not trying to solve anything. Just streamlining. Yes, I believe it was designed for small efficient apps. Itā€™s well known that smaller apps seem to work better. In RM and in CoRE, the smaller the rule/piston, the faster it is.[quote=ā€œJH1, post:2049, topic:50187ā€]
how is your approach here meant to intersect with that theorized design goal and therefore, in theory, work better?

So, my understanding, each piston is itā€™s own app anyway. So outside of organization, I am not sure what you gain from separate CoRE installations.
[/quote]

My approach here is meant to intersect with this ā€œtheoryā€ in that Iā€™m going for more pistons that do less (in most cases). The multiple installs serve me two purposes: 1) the UI got slow when I hit 30 pistons 2) digging through that long list was annoying.

Multiple installs are for organization and UI ease of use. No other purpose.

Interaction among pistons is not something I do very much of. In rule machine, there was no choice. It was limited in ways that CoRE is not. I use very few variables, actuallyā€¦ I currently do not use any. I also only have one piston that does anything with other pistons. Itā€™s a basic piston that runs several follow up scenarios and it is triggered at mode changed. Iā€™ve designed my system to be very sections and non interdependent. Each device is only used in a single piston, except for a single motion sensor.

Hmmmmm, maybe this explains why I really experience only small amounts of the problem others have so much? ? ?

I definitely phrased that wrong. No, not instability for the systemā€¦ But stability for my OCD. Nothing got blown away. Everything is working good, except for Alexa. Amazon is posing me off.

The main thing here is this. My system has grown huge. 150 devices approx. 35 pistons, 47 AA macros, 5 independent smartapps, 14 smart lighting scenarios, IFTTT, and harmonyā€¦

The thing has grown in spurts. The programming had become jumbled. A couple of days ago I discovered I had a smart lighting rule and two pistons that were doing the exact same thing to my porch lights.

Iā€™m just cleaning house. Thought Iā€™d share my thoughts and ideas. If I say our do something that helps another user, then great. Cause I know I learn from all of yā€™all.

3 Likes

Thanks Rick, this worked after a couple of tries.

No, hamburger menu-SmartApps.

Thank you, that did it!

1 Like

In trying to create a few pistons to get the hang of how this all works. I have one that I started ā€œCoRE Piston1ā€ Now I can not delete / remove it. when I select it to ā€œopenā€ I get the red bar - you are not authorized to performā€¦" trying to select remove does nothing. I have opened this with URL thinking I could delete/ control from PC - doesnā€™t look like you can control/ edit etc web based. Any ideas?
JH1 - I agree that the less complexity per APP/piston seems ā€œeasierā€ ~ at least for me. But of course my simple mind likeā€™s little clean Apps where I can get to what I need in 2 seconds flat, or my OCD says it isnt time efficient. HAHA. Thanks!

And then you donā€™t.