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)
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?
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? 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!!!
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.
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
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
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2048
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ā.
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.
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
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
2051
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.
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!