I’m talking about features that are needed to pass alpha. Core features like the variable and piston triggers. I will look into backup and restore later, so far no one had any “headless” pistons, right?
I apologize in advance if this has already been reported. Just updated to the latest code but I notice a small UI issue.
-
I click-on “Add a CoRE piston…”
-
By default the Piston Mode is “Basic”
-
But I still see “If, Then & Else”
-
If I open the “Piston Mode” selection and hit “Done” then it displays correctly
Thank you, I know exactly what this is. Up until you change anything in that input, the value of it is null so I manually replace it with the default: Simple. I changed the input’s default but not the implied default value. Will fix.
That seems to be working. Super! I also added a “dimmer changes” and “color temperature changes” triggers for the same virtual switch, and updated the save/load tasks to include level and color temperature, and those work, as well. A couple of questions:
-
What does “Aggregation” mean/affect in the context of the “save state” portion? I had to pick something so I selected “First”, but I had no idea why I had to choose or which was appropriate.
-
Would this also work if I did a “save state to local”? That would seem more straightforward than having to create a variable, and in this case since the scope is limited to this piston, would make sense to the user.
The Dashboard for a Basic piston still shows the “Else” clause, too.
Adrian,
Is it worth looking at the null display when zero is entered for a variable value? Not sure if that could cause issues down the road
Rick
Any chance of the isPhysical switch context making the core CoRE list?
That I took care of, refresh?!
I assume it has to. Not sure yet if it calls for another capability, or add it as a modifier in the condition…
Should be fixed in v0.0.064. If not, 065 - I already fixed it.
If you use several devices for the save, there needs to be a way to combine all values into one. I would not use the state though. For the trigger, find the Save event value on true. Add a variable there, it will be the value of the device that changed. Then use load attribute from that variable on all the lights.
Save to local/global store won’t work because each device will save to/load from its own version of the store. These are the capture/restore.
Any reason with this piston schedules the final else 3 extra times after piston went false at 10:36:14pm. and then executed a 2nd light off command at 10:51.
That is WEIRD. Try using {$time}. Could it be that {$minute} was 0 at that time? I will check to see. Java evaluates 0 to false. Sometimes that helps, sometimes it doesn’t. So I need to use (value != null) instead of (value) when comparing.
Can I create a piston that executes another piston’s actions? Is there a way to execute piston actions when something happens?
I know one of the options is to execute piston. But is there a way to just execute the actions of a piston?
Yes. Illuminance reported several times during your Else wait. Enable Only on piston state change on the Else action - that will fix your problem.
Not that I know of. But you could have a Follow-Up piston with a condition Time is any… and then the THEN actions always get executed…
Any thoughts on this?
Rick
I like this idea. There have been a few times where I wish I could copy a piston so I could try new things without breaking the original.
Later, when you work on the backup and restore features, please consider adding some type of restore as new piston option. If you plan on providing some type of duplicate piston feature then that won’t be necessary. Thanks
{$minute} sometimes not parsed. This was exactly what I thought it was. Fixed in v065.