Yeah there were, long to explain - it was part of a test to figure out the error that surfaced last (running out of compiled space). Removed it, not sure I published the modification…
1 Like
@ady624 If I had a Follow-Up with set to a certain piston in a piston (ex. Core Piston #1) and I rename the Follow-Up piston after the piston is created to “My Piston”, the piston that referred to it still uses the old piston name (Core Piston #1)… any way to refer to it by an object ID instead of the name? Just wondering…
Thanks,
Kevin
Saw the same thing this weekend. Taps also lose the connection.
When I developed that, I had no way to use a key-value list for the options. There apparently is an undocumented way, but it’s a bit too late now. But I am thinking of doing that for the published version - it appears everyone will have to rebuild their pistons 
I honestly hope you are joking …
Not joking. Looking into ways to backup/restore - otherwise, everyone will have to rebuild, it will be a different app once it’s published. Makes sense. So I’d better get backup/restore working…
2 Likes
I have gremlins, this will allow me to exterminate them. Not a bad thing all things considered. Remember folks this is still BETA!
Edit: er…RC, close enough right? NOT FINISHED! There we go…
2 Likes
I expected this. I also expect to only be allowed to install 1 copy of the app.
It is going to be a huge pain, but it will also be an opportunity for me to clean up some of my early pistons that are not as efficient as they could be.
If I had a voting button I’d vote for more features rather than a migration tool. I may not have as many pistons as you. I’m sitting at 28 I think with another 15 or so to build this week. I have been migrating away from most of my other SmartApps.
2 Likes
I guess it is good we can take pictures of the different pistons.
I assumed the final version would make us have a clean slate.
1 Like
will you remain the maintainer or will you hand this to the ST folks?
2 Likes
I have a piston that has stopped executing it’s actions for the past 2 weeks. It’s a simple piston that changes the mode to “Mode Name” Away from “Mode Name” when a virtual switch Everyone Left is on. The Piston State changes to true but the actions don’t run. It I simulate the piston it completes it’s action.
It was working fine a few weeks ago, but I don’t know which build broke it.
Can you repost and show the current mode? It is just below where you cut off.
It was already changed by me simulating the piston. I’ll post the next time we leave and the piston is supposed to run.
Probably need to log the piston in IDE to see what’s happening behind the scenes.
@ady624, I set this up yesterday as testing for someone else, the dashboard showed it cycling through the loop even after the door contact was closed (it did cancel the on/off though). Is that normal? I even added the ‘break’ in the BUTIF but did not work as I expected. Is there a proper way to break out of the loop example?
Thanks!
IF
● sim Door1 contact stays open for 1 minute
THEN...
Cancel on condition or piston state change
Using sim SW1...
► FOR 3 CYCLES DO
► │ Turn off
► │ Wait 10 seconds
► │ Turn on
► LOOP AFTER 30s
BUT IF
● sim Door1 contact changes to closed
THEN...
Using location...
► BREAK
1 Like
The BREAK has absolutely no effect outside of an IF-END, FOR-LOOP, WHILE-LOOP, or a SWITCH-CASE loop. None. It’s designed to jump to the end of such a loop, so if there’s no loop, there’s no jump. Also, the FOR loop is actually scheduled in one go, so the result of your loop, after the piston was evaluated is:
time / action
T+00s Turn off
T+10s Turn on
T+40s Turn off
T+50s Turn on
T+80s Turn off
T+90s Turn on
Note that FOR or LOOP don’t actually make it to the schedule of actions.
When the door closes, the cancel on condition or piston state change should cancel any remaining task.
I have built this code and it does not appear to cancel the remaining tasks - it doesn’t do anything but I can see the counter in the dashboard count through on the rest of the loops.
Well, it may be because of the peculiar case of “stays”. Is the piston evaluated if and when you close the door? Does it turn “false” at that point? (look at logs). If it does, can you please try the “cancel on piston state change” rather than condition or piston? Let me know if that works, it must be a bug then.
I actually already had it setup as cancel on piston state change. I will have to look into the logs later