Unofficial thread for compatibility

[cw-kid]

OK done - I also restarted MSR and did a hard refresh.

[toggledbits]

And the rule?

[cw-kid]

It still says "null"

[toggledbits]

OK. In RouterMemoryFree expression remove all of the (\\d+) strings so that the middle/second argument to match() is just "Mem:" by itself (no spaces or other data). Restart and hard refresh. Then re-check.

[cw-kid]

Like this ?

match( RouterMemoryResponse, "Mem:")

[toggledbits]

Yes, that's fine.

[cw-kid]

It now says -

Last value: (string) "Mem:"

And the test rule trigger -

[toggledbits]

OK. So your pattern isn't matching, it seems is actually the problem. You may have some special characters or strange spacing in your pattern that I cannot see in the screen shots. There could also be a tab or other non-space character that looks like a space coming back in the shell command output.

Try using this expression for RouterMemoryFree:

match( RouterMemoryResponse, "Mem: (\\d+) (\\d+) (\\d+)", 3 )

[cw-kid]

It appeared to evaluate as it flashed green, Value is null however.

This is what is in the "RouterMemoryResponse"

Last value: (string) " total used free shared buffers cached\nMem: 426020 330068 95952 3488 0 37716\n-/+ buffers/cache: 292352 133668\nSwap: 0 0 0\n"

[toggledbits]

OK. Try changing all of the spaces to \\s* like this:

match( RouterMemoryResponse, "Mem:\\s*(\\d+)\\s*(\\d+)\\s*(\\d+)", 3 )

[cw-kid]

@toggledbits That seems to work.

[toggledbits]

OK. So your router must be returning some space-looking character that isn't space in the string somewhere. That's fine... the \\s means match anything that looks like a space. That's your path forward.

[cw-kid]

Great thanks. I just need to know how to use a Global Expression in my rule now?

As using a value like ${{ RouterMemoryFree }} only seems to work if the expression is a local expression within the rule.

[cw-kid]

The Global Expressions look like this now. I have the used and free memory values OK.

[cw-kid]

Seems I can just do them as Local Expressions after all instead of Global ones.

[toggledbits]

If you are only going to push them out in the same Reaction to other places, that's fine. You don't be able to use them in conditions, though.

[cw-kid]

Yes that's right, info only

The routers CPU temp and WIFI chip temps however I am using those in another rules trigger to warn me if its getting hot. so those had to be Global Expressions.

[toggledbits]

Oh... wait though... rule-based expressions evaluate a bit differently from global.

As global expressions, when "Response" changes, it triggers an immediate update/re-evaluation of Free and Used, as was happening in our troubleshooting.

When you move them to rule-based however, expressions in rules are only evaluated when the rule's trigger conditions are checked. That means the interval will cause Response to get fetched and updated, but Free and Used as local variables will not be updated immediately after... they will not update until the next time the interval triggers an evaluation of the rule, so each response will not have its new values posted until the interval period lapses. Do you understand what I'm on about here? I think you should be able to observe this behavior in the rule status.

[cw-kid]

Yes I understand what you just said.

But back to my other question then, is it possible to use a Global Expression value in a rules action with a value like ${{ RouterMemoryFree }} but for the Global Expression rather than any local one.

[toggledbits]

Sure, use it just like you've shown. As long as there is not a local variable with the same name, it will find/choose the global variable.