Predicate condition is true but system think's it's false

I will update soon and let you know.

I am running Hubitat Elevation® Platform Version 2.2.9.140 Hardware Version Rev C-7. I am having this issue with predicate based on a global Boolean variable. When I set the variable so that predicate is false, the rule does not recognize it.

Before start-stop

If I stop the rule and then restart it, the rule does pick up the predicate state:

This is not just missing text, the rule does not recognize the correct state.

Here is the log:

app:5242021-10-25 08:18:06.739 infoMaster Bedroom Lights event: Predicate Rule now false
----> Stopped and Started Rule
app:5242021-10-25 08:17:51.998 infoMaster Bedroom Lights event: (location) / (Hubitat Name) variable:gbMasterBedMSOn false
----> Set Boolean to false through dashboard

I don't think the actual rule matters as this is all predicate, and the variable change is just not triggering the predicate, but I'll post more if you want.

The red text is perhaps not being updated, but that's just a UI indicator. Look at the Application State in the App Status page for the rule (cog icon). There is a state variable called 'stPrimed'. See if it is false. That's what the rule uses.

I'll check about the UI issue. Sometimes, the red text will not be updated until there is a page refresh, but there could be an update that is missing somewhere.

The stPrimed confirms no change upon variable change. When variable set false:

When Predicate False

After stopping and starting the rule:

After restart

Please show logs of the rule, when you set the variable. This one works for me.

There was a reported bug about this, which has been fixed, but probably not released. Coming today.

1 Like

Great, I'll update when I see the notification.

This issue if fixed in Release 2.2.9.141.

2 Likes

I was having problems with simple predicate conditions working and displaying correctly;
Updated hub to 2.2.9.142 today, but had to "Update Rule" for every 5.1 rule with a predicate for it to now show the correct condition for each predicate. Fingers crossed they work.

It looks like they are working for me now with 2.2.9.143. Thanks!

Edit: spoke too soon. The red text now reflects the predicate variable change (that fooled me), but the hasPredicate still does not get updated until I stop/start the rule. I'm now on 2.2.9.144.

I'm having a similar issue with the Rule Machine predicate condition. I normally have my outside lights operate on a schedule with RM. These have been working fine with Rule-4.0. With the new predicate feature, I removed the old rule and re-created it as a 5.1 rule with the predicate of it not being October 31. The rule worked fine by not running on the 31st, but it also didn't run today, the 1st of November. Looking at the app listing, it said the predicate was still false, but once I went into the rule, it showed as true. I manually turned on the lights, and hopefully the rule will now run properly, at least until next year.

I will look into it. I'm pretty sure I know why it failed. It would work if you turn it around, and do Between November 1 and October 30. It treats the same day in Between Two Dates as a special case, one that I missed when creating the schedules for the Predicate rule to turn off on the second 'date'.

2 Likes

This will be fixed in the next release.

2 Likes

Don't know if this is related, but I have the following rule:

It worked as expected: The switches was off before the rule ran the first time. On 10/31, the switch was toggled to "On". On 11/01, the switch was toggled to "Off". Then this morning, 11/02, the switch was again toggled on, and various rules that control the lights in the front part of the house didn't turn the lights on.

Thanks!

Yeah, that's right. Oct 31 to Oct 31 is an oddball case, because it pretty much has to mean either what you have (in which case, why allow it) or it means from midnight on the 31st until midnight on the 31st -- which is zero time. So two choices: reject it as invalid, or treat it as Oct 31 to Nov 1.

Or, there could be a different condition of just On a Day, which would only take one date.

As a point of reference, for time, if there is a Condition called Time of Day which is one minute, and it is treated the same as Between Two Times where the second time is one minute after the first time. An analogous circumstance.

Adding a condition for On a Day seems unnecessary, given what you have posted.

@motokochan ??

@bravenel were you replying to me? Because I did have "Between October 31 and November 1" as the predicate. I assumed that would be treated as "if it's 10/31 or if it's 11/01." What you posted above seems to suggest that is not the case?

ETA: Would it be better to have a predicate "NOT Between November 2 and October 30".

I do understand that the condition could be changed around to "between Nov 1 and Oct 30", and that might make it easier. However, for cleanliness, having a "this specific day" option isn't bad. It mirrors how humans tend to think. I don't think "I want this to happen between November 1 and October 31", I think "I don't want this to happen on October 31."

It doesn't need to be a unique condition, however. The UI for the date range condition could just be adjusted slightly, like not by requiring the second date for a single day. Maybe even just a checkbox that would disable or hide the second date fields to the browser and enter the same date in the fields for the second date (basically how it works now, but more obvious). Then the condition would just be treated as "from 00:00:00 to 23:59:59" on that specific date.

Ha! This is actually the UI progression that Time of Day went through. It got a toggle to only select a single time, and that meant 'during this minute', and only one time would be entered. In Rule 5.1, for clarity, it was broken into two different conditions: Between Two Times, and Time of Day (the single minute):

That seems to indicate what it means in practice, and not surprisingly that condition is true between 3:33 and 3:34. Interestingly, this means exactly the same thing:

But, herein is a subtle difference between dates and times. Times are not inclusive, but dates are. The single time is a special case, while between 3:33 and 3:34 means between 3:33:00.000 and 3:33:59.999, thus excluding any time on or after 3:34:00.000 from the condition. But for dates, 10/31 to 11/1 means between 12:00:00 on 10/31 to 11:59:59.999 on 11/1 -- encompassing all of both dates.

So, if there was a condition On a Day, it would look like this (ignoring the NOT for this discussion):

And furthermore, it does say this for Between Two Dates:

Which makes me think that what @jabecker reports above is actually a bug, at least as to the 11/02 portion of it, as that rule should not have run on 11/02.

Now, here's the funny part of this whole discussion. In order to get that screenshot just above, with On a Day for October 31, I actually implemented 80% of what is required to fully support such a condition. So, might as well finish that... While I'm at it, I will confirm that the variants all work as they should.

4 Likes