I’ve setup an automation that checks my external IP for changes (using myip sensor).
It emails me with my new external IP if it changes. (I know, I have dynamic DNS but this helps me for other reasons).
Sometimes, when the net goes down (5G internet) the IP changes state to “unavalable”. I want to add a condition NOT to trigger the event when this happens.
So under my “When” section, I add an “And if” section but I’m stumped with the syntax.
I start with “Entity” - myip (which is the sensor).
Then I’m stuck. Is it the attribute field or the state field I want?, and if its state, then the only choices are unknown or unavailable. I assume I want unavailable? is that the sensor being “unavailable” or is it the sensor value = unavailable? Bit confusing as I simply want to check the state of the sensor = “unavailable”
Finally how do I make it a “not” condition - I just can’t see how?
alias: IP Change email
description: Email Roger with new IP when external IP changes
triggers:
- trigger: state
entity_id:
- sensor.myip
attribute: ip_addresses
conditions: []
actions:
- action: notify.email_roger_gmail
metadata: {}
data:
message: "New Public IP : {{ states(\"sensor.myip\") }}"
title: New External IP Address
alias: IP Change email
description: Email Roger with new IP when external IP changes
triggers:
- trigger: state
entity_id:
- sensor.myip
attribute: ip_addresses
conditions:
- condition: not
conditions:
- condition: state
entity_id: sensor.myip
state: unavailable
actions:
- action: notify.email_roger_gmail
metadata: {}
data:
message: "New Public IP : {{ states(\"sensor.myip\") }}"
title: New External IP Address
alias: IP Change email
description: Email Roger with new IP when external IP changes
triggers:
- trigger: state
entity_id:
- sensor.myip
attribute: ip_addresses
from: "On"
to: "Off"
Meaning, it would only trigger when it goes from “On” to “Off” , and thus changing to/from “unavailable” would not trigger
btw - still mystified how to do this in the GUI… Your code (thanks!) has created an
“And if”
Then an equals sign with a line trhough it and then “Test if condition does not match”.
Then teh actual condition is “Confirm myip is Unavailable”.
Sorry if this comes across as pedantic, but can you confirm this actually works? (I do have situations where it would be ideal if it did).
I thought if you set any of from, to, not_from, or not_to, the trigger “fires on any matching state change, but not if only an attribute changed” (quoting the documentation).
Maybe I’ve misread the OP, but isn’t an attribute change what is at stake here?
Hi - it works perfectly. I havea 5G router 4 stories up in an attic, and for reliability, it has a timer plug that power cycles it every morning at 7am. If I ever need to access it due to a problem, I need its external IP, and that vanishes from my main router when it has a problem… so… now, with the script I marked as the solution, every morning I get the email:
New Public IP : 94.196.xxx.63
This means I can easily access the router to administer it in case of emergency.
The “problem”, was that if there was a serious outage, the router would reboot but failt to get an IP at all - and get an email:
New Public IP : Unavailable
Which was just a touch pointless.
Now I don’t get those emails, just the ones when there is a valid IP.
I don’t want the email simply when the IP “changes” - I want the email when the IP changes to a valid IP address, not “unavailable”.
I think the confusion is the sensor state can be unavailable, and the result of the sensor state can also = “Unavailable” - as in the IP address is unavailable, rather than the sensor state simply being unavailable. Does that make sense?
Thanks! This stuff is very handy. I really prefer using the UI simply because most times I try YAML I end up with formatting errors. It seems very picky in that regard, and this is coming from a casual C & Java programmer
I think aceindies reply does not work. The condition tests for the attribute, not the state itself. But the attribute is never on nor off, so the trigger would never fire. Rofo’s answer is the way to go.
As for what you mention, the docs saying using from or to stops it from reacting to attribute changes, does of course only apply when you test the state. If does not apply when you test an attribute. Then of course, it reacts to changes in the attribute.