An interesting thing happened on my way to... awake

[Macguyver]

So I have a wake-up routing set up in Rule Machine, it is pretty simple. At 0600, two shelly Dimmer-2 devices built into two table lamps, a small Tiffany lamp and one I call the "Trophy lamp" . They begin a slow ramp-up to 100% over 10 minutes, by 1 sec intervals. It has been working great for some time now.
With sunrise coming later, and these HOT NorCal valley days sapping our vitality, my wife and decided to sleep in this morning. Well, the Tiffany lamp is positioned such that it shines right on my wife in bed, so she (such a clever bird) unplugged the lamp before the trigger even fired it off.
Fast-forward to 0645, I got up and started the coffee, and noticed the Trophy lamp was not as bright as it should be. At 45 minutes after the trigger, with the 10-minute ramp, it was only at 26%!! It was still ramping up, but VERRRRY slowly. By 0802, it finally reached 100%.
In looking at the logs, I see where every other line was "Exception when sending: No route to host (Host unreachable). Please check your device settings." which I would expect to see since the Tiffany lamp with the Shelly inside it was not plugged in. What I didn't expect was the entire rule to be so bogged down by that.

I assume this is expected behavior, but I sure didn't see it coming!

Just thought Id share this as it may be relative to someone playing around with rules and scenes, where they have test devices which my get disconnected.

Automate on!!

[bertabcd1234]

Interesting finding. What driver are you using? The built-in one? This could be a matter of it using synchronous vs. asynchronous HTTP calls, though that's just me guessing as to why a "delay" (lack of response) with one might caused a chain of problems down the line. Not something an end user can address, but might be interesting to know.

Anyway, if that's the case, It may not be the rule itself getting "bogged down"; you'd need action logs from the rule to show what it's doing when in order to see if that's really where the slowdown was. But excessive errors (or failed synchronous HTTP calls with relatively long timeouts) may cause some hub-wide problems. App Stats and Device Stats, both under Logs, could point to likely culprits.

Interesting findings, in any case! Just some ideas as to where the issue might be if you're curious to explore.

[FriedCheese2006]

@Macguyver

Trophy lamp

Is it a major award shaped like a leg?

[Macguyver]

Not like this....

[FriedCheese2006]

That's arguably even better than a leg lamp.

[danabw]

Jamon!