Wait for expression with timeout runs twice: on expression true and timeout over

C-7 hub running 2.3.1.142

@bravenel

Here is my rule with unexpected behavior:

and here is a portion of log with abnormal (I think) behavior:

Wait for expression with timeout starts at 02:56:36.930 pm

Expression became true well before the timeout expires at 16 02:56:45.479 pm
and is trying to finish actions.
However at 02:56:46.959 pm timeout expired and lines after "wait for expression ..."
statement are executing again.

I think rule should/must not be doing this.

What I am missing?

I will look into it.

Thank you.

To have it more exciting I am using "Wait for expression with timeout"
statement left and right in many my rules.
But this is very first time I noticed this behavior and I am very surprised
to see it.

Two things: You aren't on latest release, and this doesn't look like Rule 5.1. This is likely an old problem subsequently fixed. See the current log of this:

No, all my rules are 100% and only 5.1 rules:

You aren't on latest release
Yes, I am happy with 2.3.1.142 release and on purpose.
My golden rule is : Do not fix whatever is not broken.
Frankly, I don't really need anything from latest releases.
It looks like many things became broken in every new release.
Well, this is kind of normal and expected for the very complex
development process.
Finally latest release 2.3.3.140 seems stable enough.
Maybe I will try to upgrade my hub to this latest release
but only if I absolutely have to.

And as I mentioned, I am using the statement in question
virtually in all my rules but never stepped into any problem with it.
The rule what misbehaved is only few days old.
I made significant changes to this rule and new version looks
like running as expected (still will need to test all corners).
Just in case here is an modified one (still using these statements in question:

There have been dozens of bug fixes since then, including, evidently, this one. 2.3.3.140 is final 2.3.3 release; 2.3.4 is in beta.

But why I stepped into a problem only now if this is/was known bug?
This sounds a bit strange.

Well,
You are saying I absolutely have to update my hub to the latest release?
OK, I have an unboxed C-7
It looks like it is time to start using it.
I have/had a plan for a long time to redo many of my rules
but was lazy to start this effort.
I will move all my devices one-by-one to a new hub
and recreate many rules (if not all) from scratch.
Clean start is always a very good idea but unfortunately
very time consuming.

To be clear though you don't have to migrate to a new hub to get on the latest software release.

In fact, I would suggest you don't. Upgrade your existing hub to the newest software release and make sure it works the way you want first.

I imagine you would be rather annoyed if you spent all the time migrating hubs, and still had the exact same issue on the new hub...

I don't remember. You could read the release notes, although when I find a bug that no one has reported, it often just gets fixed instead of going into the notes. All I know for sure about this particular bug is that it is fixed 2.3.3.140.

Yes, I know this.
But many of my rules better to be re-designed.
The main reason is - maintainability.

Hubitat does not allow to group nicely all related rules.
For instance, ISY994 (local Insteon controller) had a folders for rules.
Furthermore, the entire folder could have a conditions
when to run rules inside the folder.
For some reason creating something similar is a BIG deal for the HE.
The work around is to create suffixes. But this way
names become well to long or not really informative.
Keeping all logic in one huge rule also is not a right way.
Splitting logic into smaller rules immediately creates
naming for grouping problem.

Easy replacement of a child devices is impossible.
Work around for this is to create a Virtual Device
and mimic real device to this virtual instance.
This is a bit annoying to create but immediately pays
for itself as soon as you need to swap any child device.
Plus makes much easier to debug rules with child devices.

And of course, something else I cannot remember ...

Not really, simply not at the top of the priorities list. Glad to see you like the hub so much! :crazy_face:

See these notes:

I clearly understand yours point.
But not having this option creates a BIG mess for the nicely organizing
rules and as a result - maintainability.

Yes, C-7 is my main workhorse. All local controls is an absolute must for the Home Automation.
Before HE I had Insteon/ISY automation in my former house.
And X10 before Insteon.
This also was 100% local,

I am desperately trying to get rid of anything cloud based.
As of today only Vertical Blinds for bedroom balcony sliding door relays on Tuya Cloud
and Window Shade in living room relays on Alexa.
All Switchbot Curtins (5 of them) already on local control thanks to Home Assistance
integration.
Ecobee Thermostat unfortunately cloud based but all my integration is On/Off
based on Balcony Doors status.
And Delta Fauset is also relays on cloud but integration is to make sure
water is running when Garbage Disposal turns on.
The rest is all 100% local thanks to the HE!

And BIG Thank you for the info on latest releases!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.