I was wondering why myself too. Maybe just wanted to get everything under one piston?
@eric182
I was seeing issues with the global variables not updating. So I tested with locals along side the globals and they updated every time.
I also had used globals before because I had the count reset logic for day, week, month, year in a separate piston which is now integrated into the single piston.
I can add logic in to update those with existing global counts into the local variables.
1 Like
Here’s my Doorbell Notification Piston below. I use global variables for my lighting so you would have to change to your lighting for it to work for you.
Here’s my living room lighting Pistons that goes by the outside illuminance levels from Nest Weather, you can use any weather device for this purpose though. I created global variables for my lights on these pistons so you would have to change those of course if you were going to use these. I execute a separate piston to check if lights needs turned on because I found with the hue lighting, sending turn on commands when light is already turned on even with the command optimizations enabled always changed the color temperature for some reason, probably a bug with the DTH for the Hue bulbs that I use.
Visitor Mode we trigger manually in ST App or with an extra arrival sensor we have. Visitor’s mode also sets my Nest Thermostat to home mode as well.
Morning Lighting Piston:
Daylight Lighting Piston:
Late Afternoon & Evening Lighting Piston:
Visitor’s Mode Piston:
Switch On Check (Hue) Piston:
Set Color Temperature Piston:
4 Likes
I updated my above solar report piston to also report daily peak power (and change from previous day) and using replace() to strip the formatting and newlines from the piston for the notification rather the constructing the text again. It also stores power, energy, daily energy, and daily peak power into fuel streams:
4 Likes
I use a custom DTH I wrote:
5 Likes
Basic piston, but figured I’d share it any way. The key was to put the else if statement with the location mode before the last else if statement. I’m guessing there’s another way to do this with some of the settings in the cog but I can’t figure that out - but the method below does work.
I can see old CoRE habits die hard. If it works it works no need to fix it but you could break all those else ifs into their own ifs.
1 Like
I think I tried that approach last night but it wasn’t getting past the second IF. I’m guessing that’s because I didn’t have the Location Mode IF listed second, it was third and the piston never ran it. It wasn’t until I tried the above method that I also tried putting the Location Mode IF second. Is there benefit to running IF’s instead of Else IF’s?
Hey @ahndee
The Piston works great, the dashboard data is great, the SMS formatting seems to be off. Here is a copy of the piston and my phone message
Thoughts?
Rick
I believe that this is a bug - if you edit the “Send Notification” step and look at the value it evaluates to it is correct.
I alerted @ady624 about this issue In a different thread.
Edit: You have an older version of the piston. in the replace() expression, you should replace \n with \\n
@Ross the location of the IF doesn’t matter ignores you set asynchronous processing (click on each IF, click on the cog icon, under Execution Method change to Asynchronous- donthis on each IF so they can all fire inidpendantly and are not reliant on an IF further up the chain).
Can I also make a suggestion to help you optimise this piston - turn off Command Optimisation (click the piston title, cog, Command Optimisations - Disable). That way if someone changes a light to on/off outside of WebCoRE, WebCoRE doesn’t assume it knows the last state.
One other suggestion for optimising - you have multiple ‘Set level to’ followed by ‘Turn on’. No need for the Turn On - set level does the same thing (see my piston to do a similar job below). Each time your piston effectively is telling you bulbs switch on switch on. Just suggestions for you to ponder
Depending on what @Ross is turning on he might have to use set level first. (But you should test that out to see. Cause more than likely you don’t need the turn on command).
Also since none of his IF statements should be running at the same time because of the time blocks in each if, there is no need for changing to async. That is not holding anything up. Only 1 if should be executing actions at any given time.
Command optimization is s good point. So I do agree with that one.
So as for why ifs versus else ifs. I think it is just proper. We had to use the else IF and when true/false trick in CoRE to be able to create more complex pistons. No longer is this required. I can’t answer why it might not be working without a snapshot of the piston and some logs. But post that in the help thread and either tag me or someone else can help too.
Thank you! I really appreciate the feedback and example.
1 Like
Thanks! I know there are some suggestions in the help thread so I’ll head over there next. 
I’ve been waiting all day to get back to this.
Hi @ahndee,
Didn’t seem to help, unless I didn’t apply the change correctly which is very likely
Do you have an updated Piston that I could import? Might be easier
Rick
1 Like
Been hesitant to switch mines over from CoRE. I see you’ve done the work so I will just copy yours! Looks very similar to what I have in CoRE.
You know what they say about Great Minds
I’ve been modifying it quite frequently to allow different types of notifications I.E flashing lights, push notifications, voice notifications. I will update the public version once I’ve added more testing
Andreas, replace the \\| with | or |
it appears the expression parser is replacing [ and ] with [ and ] respectively, making that \[ be required. I’ll see if I can fix it, even though it may not need fixing. There are certain characters that need escaping at webCoRE level, [ ] { } so those need to be written as [ to begin with.