Happens Daily, doesn't

[hatallica]

I like the idea of the work-around. That splits the issue into distinct chunks - latency and failure. The former is the tougher to resolve, but the latter is the more frustrating.

This morning’s routines were complicated by a host of failures - during a 4-minute delay to run the “lights on” piston, the hub went inactive. A reboot seems to have set the world right again (I hear my pool pump priming now, as expected).

[orangebucket]

Interesting log. The 9:05pm wake-up didn’t happen on time so a recovery event was fired which did the required job of scheduling the next run for 10:05pm and keeping the piston going. Then the 9:05pm wake-up arrived two and a half minutes late and seems to have found it wasn’t being expected any more.

[hatallica]

Public Service Announcement (not directly related to “happens daily”) - the action part of the piston doesn’t do what it is intended. I didn’t catch my error due to the time comparison issue.

My overall goal is to set the light level and then turn off. That way, when the wife manually switches a light, she does not get an overly dim setting leftover from an automation. I found that “set level” and “turn off” were in a race condition, and sometimes the device would execute them in the reverse order.

The idea was to make sure that the device acknowledged being at the proper setting, and then send “turn off”. However, that part of the piston ran without delay and failed. I will go back to the drawing board, using the work-around from @WCmore to at least make sure that the trigger performs the actions.

[WCmore]

For the record, there may be something going on at ST’s side…

My hourly piston is as simple as it gets.

… yet I just caught it 9m 19s late.

I was asleep… The house was empty… No devices were on… No other piston runs at that time.

So any latency was definitely not on my end.

[WCmore]

My overall goal is to set the light level and then turn off … I found that “set level” and “turn off” were in a race condition, and sometimes the device would execute them in the reverse order.

I do this with a simple block:

With Dimmer 6
    Set level to 50
    Wait 1 sec
    Turn off
END WITH

---

Pro Tip:

In the evening (before bed), I do the opposite, with a very low number:

With Dimmer 6
    Set level to 5
    Wait 1 sec
    Turn off
END WITH

This sets the light to a low level, so I am not blasted with light during over night bathroom breaks.

[hatallica]

I do this with a simple block:

With Dimmer 6
    Set level to 50
    Wait 1 sec
    Turn off
END WITH

This works well for me in a couple of pistons, but I am escalating wait times up to 30 seconds for others. This part is not a webCoRE issue. In the ST IDE, I can see that a varying delay happens between APP_COMMAND and the DEVICE action. If “set level” takes 1.5 seconds and “turn off” takes 0.5 seconds - as it did this morning - then the race is on.

My evening routine is the opposite. Bathroom light (manual dimmer) stays at the lowest level all night, so my wife doesn’t trip over the dog on the way to the bathroom. The hallway has a cheap, plug-in LED motion light. If I need to turn on any other lights in the middle of the night, then it better be an emergency that requires full brightness!

[WCmore]

wait times up to 30 seconds

If commands are consistently taking longer than one second to respond, there are definitely larger issues at play here…

[hatallica]

The first of 3 pistons that I have which use this basic structure worked as expected. The others failed the time comparison.

I still intend to move the actions outside of the IF/THEN, just didn’t get to it tonight.

[WCmore]

I still intend to move the actions outside of the IF/THEN

Make sure to place at least “something” inside the now empty THEN block.
Preferably something that is not critical, such as:

Log to console = "success"

You may think I’m joking, but I have seen occasions where a totally empty IF caused the piston to rebel…
(almost as if becoming self-aware… “You woke me up for this?!?”)

[hatallica]

All 3 of my evening “happens daily” pistons ran without a hitch last night. In fact, the one with actions outside the if/then block ran twice, since it has two triggers. For now, I will chalk this up to some transient condition.

[WCmore]

the one with actions outside the if/then block ran twice, since it has two triggers

I have not seen your latest version…
Any idea why two triggers are excuting back to back?

[hatallica]

Same triggers as the green shot, just different times for different days. The piston runs at both times, with one evaluating true and the other false. With actions outside of the conditional block, it runs for both.

I was not awake for the second one, but noticed it as an event that my cameras captured overnight. This morning, I just split them into separate pistons.

[WCmore]

piston runs at both times, with one evaluating true and the other false. With actions outside of the conditional block, it runs for both.

Ahh yes… You changed the logic from your first post.

My original advice was because:

(both triggers in your original piston will execute) the THEN block beneath, so you could apply a basic hack, and move the action commands outside of that main IF.

Adding an "unrelated trigger" will break that logic.

(although you could always add extra conditional checks in the lower part of the code)

[hatallica]

(although you could always add extra conditional checks in the lower part of the code)

I expected that it would trigger twice. After having it not execute at all, having an extra execution was an upgrade. I briefly debated adding more conditions, but it is so darn easy to duplicate a piston and delete one line from both versions.

I am still feeling out webCoRE, so this will get built-up and reorganized a few more times yet. All the more reason that I wanted to get this super-basic trigger resolved.

[WCmore]

it is so darn easy to duplicate a piston and delete one line from both versions.

Wise choice. I try to limit each piston to a single trigger, if possible.
(which also allows for much more complex actions)

[hatallica]

Except I realized that both will still trigger … Looks like I will be adding those extra conditions after all.

[hatallica]

Or … I found this little gem:

Using multiple TRIGGERS in single IF

Ahh, then perhaps using the Timer is the solution for those blocks as well… I cannot remember the last time I put a time statement as a trigger in an IF block. I usually do this instead: [temp] (although I may place conditions in the next line or two)

This has an elegant simplicity. I already converted my times global variables, so running tests mid-morning requires only a small tweak. In the ST IDE, I am still seeing devices taking over 1 second to respond to an APP_COMMAND, but that debacle might be a whole separate thread. Final (for now) version below.

[WCmore]

Lookin’ good…

You may already be aware, but two thoughts come to mind:

(1) “Every Day at X” blocks stay in that block. (they do not run top to bottom as most triggers do)

(2) If the global @timeShutdownWeekend ever changes, it will still fire at the old time at least one more time, before correcting itself.

[hatallica]

Was not aware of #1, but that is a good tool to have in the knowledge toolbox.

In the dashboard, I did notice that the countdown times did not make sense until I opened the piston editor and re-saved.

[fieldsjm]

(2) If the global @timeShutdownWeekend ever changes, it will still fire at the old time at least one more time, before correcting itself

I usually add an additional ‘Every Day at x’ block prior to the expected global time so that the piston subscribes to the freshest data. Keeps things running smooth.