[MSR] Native fan capabilty

[vezinpi]

Roger that. Up to this point I was really thinking that It would work like Date/Time.

Thank you.

[vezinpi]

@toggledbits said in [Solved] Local expression evaluation:

Also: it's not correct to compare a time string to another time string. Basically, everything about this expression won't work.

I understand that, as you explained, expression cannot auto evaluate based on time. However when manually trigger, the expression do work as intended with time and all.

I Know that your not in the business of teaching others how to code but does it means that, inside an expression, we should never attempt to perform actions based on time like:

if strftime("%H:%M:%S") < "08:00:00" then
...

Thanks

[tunnus]

If you use Unix epoch format, you can compare two values as they are numbers

[toggledbits]

At best, comparing numbers within strings is considered bad style. As @tunnus says, you're better off using epoch time format in many cases, which we could say more broadly as, there are numeric forms available that will work better (and show good programming discipline/style).

Now, your particular tests can be done in epoch time, but that may not be the best approach, since epoch time is absolute from Jan 1 1970 UTC, and you are really just looking at particular daily events. Within Reactor itself, similar calculations are done in MSM form, or Minutes Since Midnight.

Looking at your "edges" (the points in time where things change), you could set them in MSM form like this:

vFrom1 = 09 * 60 + 25,
vFrom2 = 09 * 60 + 30,
vFrom3 = 09 * 60 + 41,
vTo = 10 * 60 + 55,

You can see I am multiplying the hour by 60 and then adding the minutes, which gives minutes since midnight for each event time.

To get the current time in MSM, you can:

p=dateparts(), vToDay= p.hour * 60 + p.minute,

From there, the rest of your expression should work as you wrote it, but it will now be comparing numbers (MSM):

#Get current house temperature
CurrentHouseTemp = getEntity( "hass>Thermostat2" ).attributes.temperature_sensor.value,

case
  when CurrentHouseTemp <= 19 and vToDay >= vFrom1 && vToDay <= vTo: "true1"   # From1
  when CurrentHouseTemp <= 20 and vToDay >= vFrom2 && vToDay <= vTo: "true2"     # From2
  when CurrentHouseTemp < 26  and vToDay >= vFrom3 && vToDay <= vTo: "true3"  # From3
  else "false"
end

This doesn't change the fact that this expression won't be evaluated periodically on its own. You still need to use an Interval condition to stimulate its re-evaluation.

[vezinpi]

@tunnus @toggledbits Thank you both for all your explanation.

Much appreciated.

[tunnus]

Continuing this discussion, I've noticed that if I have local expressions that contain "getEntity(...)" type of variables, these expressions are evaluated every time entity changes. This happens regardless of triggers.

But if I have the same expressions where "getEntity(...)" is replaced by a global variable / expression (and this global variable contains getEntity-structure), these kind of local expressions are not evaluated even if global variable changes. For clarity, expressions would be evaluated if rule is triggered.

@toggledbits, is this behaviour by design? Using build 25060 on Docker.

[toggledbits]

Try restarting after any edits to rules or expressions. I do this kind of structure a lot and I don't see issues, but I'm always willing to look at any reproducible test case you can give me.

[tunnus]

@toggledbits well I guess the following test cases should either prove my point or prove me wrong

Rule 1: (no real triggers, only comments etc)

local expressions:
TempOutside = getEntity( "..." ).attributes.temperature_sensor.value

---

Rule 2: (no real triggers, only comments etc)

local expressions:
TempOutside = g_TempOutside

(where g_TempOutside = getEntity( "..." ).attributes.temperature_sensor.value)

---

So in my case "Rule 2" -type of local expressions won't be evaluated unless rule is triggered. I'm pretty sure it used to work differently with earlier builds, about a year ago.

[tunnus]

This case is easy to reproduce, only the question is if this happens by design?

("TempOutside" is also a global variable, although its naming is a bit misleading)

[toggledbits]

It's more a reflection of a limitation in the language implementation and integration. It's incredibly hard to get the dependency scan right, and what I really need to do at this point is go back and remake the expression parser specifically for Reactor, rather than using it as a standalone library (which I nonetheless author, but I was trying to keep it isolated). It's a tricky business, and even changing behavior at this point to make it work the way you think it should will probably goof up somebody else's rules and expressions. I'll add it to the wish list. It's definitely an interesting problem that I'd like to tackle, but it's not going to come painlessly.

Workaround for the moment, and I realize it's not great, is to integrate changes conditions for those global variables into the rule's triggers.

[tunnus]

@toggledbits the main thing is that now I know that this behaviour is not a bug and there's a clear alternative (not using global variables when rule does not trigger often enough).

Anyway, MSR is a great software and thanks for your continued support!