Gradually turn on lights.

[cw-kid]

This trigger isn't working for me. I am getting a lot of false triggers where its saying my WAN IP address has changed when it hasn't.

Sometimes it's showing a value of

${{ myIP.ip }}

And then the rule fires suggesting the WAN IP has changed when it hasn't.

I need the "changes" trigger to only trigger if its validated more than once or over a period of time, that the actual WAN IP address has changed and its not some blip or problem or slowness with it working out what the WAN IP really is.

[LibraSun]

Good catch. Sounds like some other condition is called for, which either inspects the contents of myIP.ip for a suitable RegEx match (e.g. digits and dots) or verifies that the contained value is not NULL, or at least different from the literal ${{}} you experienced.

[toggledbits]

That non-substituted value means that the expression failed. Check the log. I suspect that the query is failing from time to time, resulting in no data to myIP. That would also be in the log. The query failing will clear myIP, and that would make myIP.ip throw an evaluation error.

This would be a good use for the ?. operator: myIP?.ip will return null if the fetch fails and myIP gets cleared, rather than throwing an error. You can then test for that null.

[cw-kid]

I've changed the rule to use "myIP?.ip" instead that seems to still work OK and my current WAN IP is brought down from the online API request.

As for the false triggering when the query is failing from time to time, I tried setting the trigger "for at least X secs"

Expression Value: ip changes from 11.222.333.444 to (any) for at least 360 secs

However this doesn't seem to work at all. I turned off my VPN and the WAN IP address changed, the rule that checks for the IP worked and the global expression contains the new IP address.

However the other rule that is meant to trigger on expression value changes from specified IP to any other IP / value never fired.

So I am not sure what is the best way to setup this trigger, so it works and doesn't false fire if the expression value goes to null / the http request query didn't happen to work that time.

[LibraSun]

I was going to suggest the ol' "Sustained for __ seconds" trick, so glad you landed upon the same solution. Unclear why something would "stop working" just because of that. Have you checked the Logs? And is the secondary Rule enabled?

[cw-kid]

@librasun If I removed the sustained for X seconds it starts "working" again but I am still getting false triggers though sometimes.

[cw-kid]

Thought I'd try this one instead:

Is this a bug however ? I cannot set that to more than 60 seconds if I put in 360 seconds and save it reverts back to 60 seconds.

[toggledbits]

The changes operator produces a pulsed output (otherwise you would never be notified of two or more changes sequentially). A pulsed output cannot be "sustained", because it only ever lasts 10ms or less.

Since you are testing "changes from expected to anything else", that's really not logically different from "not equal to expected". Use a plain equality/inequality. That will produce a sustained output for which the sustained for restriction can be used.

[cw-kid]

@toggledbits

OK thanks that makes sense.

I will not use "Changes" then in the trigger.

Instead I will try <> NOT expected value (IP address) and use a sustained for X secs.

[toggledbits]

On my end I'll tighten up the UI so that option can't be selected when the changes operator is used.