Call action triggered by sensor after delay with cancel option

I want to park my Husqvarna Automower when it starts to rain. To achieve this I’ve implemented a rain sensor which triggers “park mower” action when it starts to rain.
However sometimes I get false alarms, so I was thinking to add a delay before parking mower.
I want to implement something like this:

  • if rain then
    – send push notification to my iphone
    – delay x minutes
    – somewhere put “cancel parking” option … maybe some bool switch or something
    – park the mower if not canceled

Any idea what is the best way to put that scenario together?

As part of the push to your iphone, why not just use a actionable notification that has a cancel option to fire whatever mechanism you create to cancel it. Careful with using delays. If you restart home assistant or re-save the automations (you were editing something) the delay is moot and the automation is cancelled. if that is an issue for you, you could use a timer to count down your delay and then your actionable automation could just call a script to cancel the timer.

rain starts
fire automation to notify phone and start timer for x minutes
if user presses cancel, cancel timer and nothing will happen. <= you’d listen for the event and the automation would cancel the timer.
listen for the timer.finished event. If it ‘finishes’ park your mower.

Thanks for the hint! But I’m not sure if the actionable notifications will work when I’m not connected to my LAN.
I’m using HomeAssistant iOS app when I’m connected to my LAN, but when I’m away from home, I’m connected using browser (https + certificates - unfortunately I can’t get the certs to work with the iOS app, but that’s different story).

So that Action from actionable notification probably opens iOS app and triggers whatever I want. So that probably won’t work on WAN in my case :frowning:

They do

It does need access. So you’d need to fix that.

If you fix your access, you should be able to.

Either way, you don’t need to use a actionable notification. You can use a input_button to do the same thing. Still the timer, still the rest. Frankly, you can also just stop the timer from lovelace.

You should spend the time to fix the access as most of this is trivial through the app.

Sorry for the late reply and thanks for the answers.

I’m not sure if that’s fixable. Certificate should be probably included into HA iOS app.
I’m using Nginx https server and logs shows the following error, when I try to connect with HA iOS app from WAN:

“GET /auth/authorize?response_type=code&client_id=https://home-assistant.io/iOS&redirect_uri=homeassistant://auth-callback HTTP/1.1” 403 118 “-” “Home%20Assistant/2022.358 CFNetwork/1333.0.4 Darwin/21.5.0”

I’ll do some more research about that . Otherwise I’ll try the input_button+timer workaround.

Thanks.

It should work just fine in iOS as long as you have real certs issued by something like letsencypt.

It looks like you’re using Cloudflare. I’d suspect its an issue with your intermediate cert or something like that. Or your HA config allowing trusted_proxies (which needs to include all the CF domains). I previously used cloudflare and it worked fine but was tricky to setup.

I’m not using self-signet certificates, I’m using trusted certificate from the https://sectigo.com
I got the following package of certs from them (my server name is renamed to my_domain_com):

  • Root CA Certificate - AAACertificateServices.crt
  • Intermediate CA Certificate - USERTrustRSAAAACA.crt
  • Intermediate CA Certificate - SectigoRSADomainValidationSecureServerCA.crt
  • Your PositiveSSL Certificate - my_domain_com.crt

And here is my Nginx config.

#user www-data;
worker_processes auto;
pid /usr/local/var/log/nginx/nginx.pid;

events {
  worker_connections 768;
}

http {
  # some HTTP boilerplate
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  server_tokens off;

  include /usr/local/etc/nginx/mime.types;
  default_type application/octet-stream;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;

  access_log /usr/local/var/log/nginx/access.log;
  error_log /usr/local/var/log/nginx/error.log; # debug;

  gzip on;
  gzip_disable "msie6";

  map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
  }

  # server on port 80 for HTTP -> HTTPS redirect
  server {
    listen 80;
    server_name my.domain.com;
    return 301 https://my.domain.com$request_uri;
  }

  # The letsencrypt-secured HTTPS server, which proxies our requests
  server {
    listen 443 ssl;
    server_name my.domain.com;

    ssl_protocols TLSv1.1 TLSv1.2;
    # Server certificate
    ssl_certificate      /Users/myusername/ssl/my_domain_com_chain.crt;
    ssl_certificate_key  /Users/myusername/ssl/genisys_ca_rsa.key;

    # client certificate
    #  As part of the TLS handshake a server will (if configured to require client authentication via X.509 certificates) send a certificate request back to the client. Part of this request is a list of CA certificates which the server trusts. A client is expected to send a client authentication certificate that chains to one of the CA certificates in this list.
    #
    ssl_client_certificate /Users/myusername/ssl/genisys.crt;

    # make verification optional, so we can display a 403 message to those
    # who fail authentication
    ssl_verify_client optional; #on;

    location / {
      # if the client-side certificate failed to authenticate, show a 403
      # message to the client
      if ($ssl_client_verify != SUCCESS) {
        return 403;
      }

      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      # Fix the "It appears that your reverse proxy set up is broken" error.
      proxy_pass          http://127.0.0.1:8123;
      proxy_read_timeout  90;

      # web sockets
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;

      proxy_redirect      http://127.0.0.1:8123 https://my.domain.com;
    }
  }
}

I’ve also noticed that accessing my HA server from the web browser doesn’t always ask me for the certificate - sometimes it just throws me a 403 error… but most of time I get the certificate selection popup and after selecting the certificate it lets me in. Maybe there is a catch in nginx config :frowning:

Edit:
I’ve checked the iOS HA app logs and it looks like it doesn’t select the client certificate from the keystore:

2022-06-16 22:49:50.768 [Info] [main] [Bonjour.swift:34] stop() > 
2022-06-16 22:50:05.158 [Verbose] [main] [OnboardingManualURLViewController.swift:153] connectTapped(_:) > Connect button tapped
2022-06-16 22:50:05.163 [Info] [main] [OnboardingAuth.swift:80] performPreSteps(checkPoint:authDetails:sender:) > beforeAuth
2022-06-16 22:50:05.164 [Verbose] [main] [OnboardingAuthStepConnectivity.swift:20] perform(point:) > 
2022-06-16 22:50:05.495 [Verbose] [main] [OnboardingAuthStepConnectivity.swift:28] perform(point:) > NSURLAuthenticationMethodServerTrust
2022-06-16 22:50:05.513 [Verbose] [main] [OnboardingAuthStepConnectivity.swift:28] perform(point:) > NSURLAuthenticationMethodClientCertificate
2022-06-16 22:50:05.679 [Info] [main] [OnboardingAuthStepConnectivity.swift:53] perform(point:) > failure(Alamofire.AFError.responseValidationFailed(reason: Alamofire.AFError.ResponseValidationFailureReason.unacceptableStatusCode(code: 403)))
2022-06-16 22:50:05.684 [Info] [main] [OnboardingAuth.swift:70] perform(checkPoint:checks:) > OnboardingAuthStepConnectivity: rejected(HomeAssistant.OnboardingAuthError(kind: HomeAssistant.OnboardingAuthError.ErrorKind.clientCertificateRequired(Alamofire.AFError.responseValidationFailed(reason: Alamofire.AFError.ResponseValidationFailureReason.unacceptableStatusCode(code: 403))), data: Optional(146 bytes)))

Ah these are custom CAs. I dont tknow if the app is capable of using a custom CA. I am not sure how this is done on iOS. I use letsencrypt and its a valid CA out of hte box.

I’ve found a post which describes this issue:

It looks like the client certificates aren’t supported.