Failed to connect when setting up Uptime Kuma integration

[mploetner]

I had the custom Uptime Kuma integration from HACS running and from one day to another it stopped. I reinstalled it and when I enter my uptime Kuma credentials (ip, port, user etc.) it says „Failed to connect“ I set correctly to ignore SSL and added http:// in front of the IP (as before). Uptime Kuma is running and I can access it via the IP

I also tried to set another Uptime Kuma instance which I was able to integrate and had it running for 2 hour and then the integration stopped working while the Kuma instance itself works flawlessly. Trying to reconnect I get the same error as with the other instance.

[dieuvolkanos]

Same error for me. Also tried with API keys and unable to connect.

[dandek01]

Same error here. This all begin after updating to home assistant 2024.5 This is the log

2024-05-02 21:33:54.032 ERROR (MainThread) [custom_components.uptime_kuma] Request timeout for 'https://uptimekuma.myserver.com/:443/metrics'
2024-05-02 21:34:24.909 ERROR (MainThread) [custom_components.uptime_kuma] Request exception for 'uptimekuma.myserver.com:443/metrics' with - uptimekuma.myserver.com:443/metrics

if i try to open link in browser uptimekuma.myserver.com:443/metrics i cant log in. Username and password is correct. I can log in with https://uptimekuma.myserver.com and i see metrics when I'm log in. I have similar problem with adguard and frigate.

[countrock]

Using the HACS plugin on port 3001. Having the issue of Failed to connect. Even disabled authentication, API or user creds. All have the same issue.

[meichthys]

I have not yet been able to reproduce this on 2024.05.x. My suspicion is that it is related to SSL. I've had lots of reports in the past about authentication failing but they've always been when the user was not using a valid ssl certificate or when ignoring ssl.

I would recommend using SSL since it is trivial to setup these days with tools like NGINXproxymanager that can easily renew certificates (including wildcard certificates which can allow you to use a single certificate for all of your services).

I'm welcome to pull requests that would fix this issue for non-ssl or self-signed ssl users, however It's not something I have time to investigate ATM.

[meichthys]

It's also possible this could be related: https://github.com/meichthys/uptime_kuma/issues/91#issuecomment-1951323299

[dandek01]

I'm using ngnix with letsencrypt in docker. I bought a domain and configured some of the containers to use subdomans like https://uptimekuma.myserver.com/. Certs are renewed automatically every few months. I just use adguard dns rewrite *.myserver.com to point back everything to my local server ip. And this worked for a year or two without any problems. After updating ha 2024.5 first my met.no integration broke down, followed by tuya local, uptime kuma, frigate and adguard. Last three integrations were configured to use ssl and everything worked. The only thing I noticed with uptime kuma is this error in logs

This error originated from a custom integration.

Logger: custom_components.uptime_kuma
Source: custom_components/uptime_kuma/config_flow.py:60
integration: uptime_kuma (documentation, issues)
First occurred: 21:03:07 (2 occurrences)
Last logged: 23:31:36

Request timeout for 'https://uptimekuma.my.com:443/metrics'

If I open that url in browser I cant log in as it is asking for credentials over and over again. The same thing is if I try http address. But this is my username and password for uk. Tried bunch of things that cross my mind and ended up with this. But this is my username and password for uk. I don't know. Maybe it is me but I think that this is somehow related to last update, or maybe my setup, but I still cant set up integrations using ssl to uk, frigate and adguard.

[meichthys]

If you cannot log into uptimekuma using https://uptimekuma.my.com:443/metrics', then it is an uptimekuma issue or perhaps uptimekuma changed its auth mechanism. What version of uptime kuma are you on?

[dandek01]

I'm using ver. 1.23.13 This is my docker-compose file:

  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    environment:
      - TZ=Europe/Zagreb
    volumes:
      - ./uptime-kuma-data:/app/data
      - /run/docker.sock:/run/docker.sock
    ports:
      - 3001:3001  
    restart: always

I can log into dashboard with credentials using both http and https.

[meichthys]

@dandek01 Thanks. That's the version I'm on and essentially the same compose file I'm using. Being able to log into the dashboard doesn't mean much for this integration since the integration uses the /metrics endpoint. Can you log into <your_uptime_kuma_url>/metrics using a private browser window? You should use your username (or no username) along with an uptime-kuma api key for the login information.

[meichthys]

Please also re-review the readme instructions as i have clarified the required credentials and added a troubleshooting section.

[dandek01]

I reviewed my nginx settings. I created access list to allow connections only from my local ips. I removed that from all containers I put it on and now I can access and log in using api on host https://uptimekuma.mysever.com/metrics When I tried to set up integration I got this address

https://uptimekuma.myserver.com/:443/metrics

Note "/" before :433. If I try to open this page in browser I got page not found. My suspicions is on nginx config file for uptime kuma, but I'm not sure. I tied to set it up without "/" at the end but the same thing. It tries to connect to non existent url. This is config file for uk in nginx.

# ------------------------------------------------------------
# uptimekuma.myserver.com
# ------------------------------------------------------------

map $scheme $hsts_header {
    https   "max-age=63072000; preload";
}

server {
  set $forward_scheme http;
  set $server         "192.168.31.103";
  set $port           3001;

  listen 80;
listen [::]:80;

listen 443 ssl http2;
listen [::]:443 ssl http2;

  server_name uptimekuma.myserver.com;

  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /etc/letsencrypt/live/npm-20/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/npm-20/privkey.pem;

# Asset Caching
  include conf.d/include/assets.conf;

  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security $hsts_header always;

    # Force SSL
    include conf.d/include/force-ssl.conf;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;

  access_log /data/logs/proxy-host-11_access.log proxy;
  error_log /data/logs/proxy-host-11_error.log warn;

  location / {

  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security $hsts_header always;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    
    # Proxy!
    include conf.d/include/proxy.conf;
  }

  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

This config is generated using nginx webui.

[meichthys]

That config looks pretty good to me. You could try turning off some of the additional options like HSTS, Caching, Exploit blocking, etc to see if that helps, but i suspect not.

The extra / in https://uptimekuma.myserver.com/:443/metrics is concerning though, I just can't reproduce it even if i wipe my config and re-configure. It does seem like some kind of reverse proxy issue, but i don't see anything wrong with your config.

[dandek01]

I tied to turn on/off additional options, restore it from backup, rebuild image. Nothing. The only thing I didnt try is to delete container, it's image, local files, pull it from docker hub and reconfigure everything from scratch.

[meichthys]

If you can login using the metrics endpoint on a private browser window using your uptimekuma api key, then there's nothing wrong with Uptimekuma, and it would have to be with either your network, the integration, or homeassistant.

[dandek01]

I think that problem is the same for uptime kuma, frigate and adguard integration connecting them over ssl. If I want to connect frigate over ssl I get timeout error fetching https://frigate.myserver.com/api/stats but I can access it in the browser private mode. But I dont know what the problem is.

[meichthys]

I use the adguard and uptimekuma integrations with ssl and haven't had any issues (I'm also using nginx proxy with almost identical configurations as you showed), so I'm not really sure how to help.

[meichthys]

Can you confirm you are using the latest version of the uptimekuma hacs integration?

[dandek01]

No. I tried to add uptime kuma from hacs repository but ha wont let me add it as this integration is already built in home assistant.

[meichthys]

I'm referring to the integration in HACS, not the UptimeKuma HomeAssistant AddOn.

If you're using the HomeAssistant UptimeKuma Addon, there have been lots of reported issues with it. See here for some details: https://github.com/meichthys/uptime_kuma/issues/91

[dandek01]

Oh sorry gave you wrong info. Was working on something else. Yes, I have integration v.2.30 from HACS.

[dieuvolkanos]

After many try this configuration working for me.

Create an API Key on Kuma

[Uptime Kuma Integration] Host: http://192.168.0.200 port: 3001 Username: Username (by default is admin) Password: API Key Verify SSL Certificate: Check

[dandek01]

I tried and it created integration. I just used homeassistant.local. I doesnt make much sense to me. I have glances integration that is using https and it is working, no problem.

[meichthys]

I tried and it created integration. I just used homeassistant.local. I doesnt make much sense to me.

In your case you need to use homeassistant.local because you are running the Home Assistant uptime kuma add-on inside of Home Assistant itself.

[dandek01]

I'm not running addon, I'm running uptime kuma in docker container. And everything else for that matter. I can stop homeassistant container and uptime kuma is.. up with all 47 monitors. I mostly use it to check zigbee devices availability. Everything is reported online even if homeassistant is stopped.

[meichthys]

Then in that case I have no clue. There is some weird networking issue I suppose.HomeAssistant.local Couldn't possibly work if Uptime Kuma is not even running on that machine.

[dandek01]

Everything is running on the same machine. 31 container. I use https on local network. I know it is wired unnecessary etc. but this is how I set things up. Was just checking containers and glances container is running in network mode host and I can connect integration using ssl. Others like frigate, adguard or uptime kuma have mapped ports and this is a bridge mode if I got docker networking correctly. As this was working fine before I presume that something has been changed in home assistant that this isn't working anymore. But I will have to use host on some of this containers to test things out.

[dandek01]

I solve it. The problem was dns settings on my debian machine. Probably years back I set up 1.1.1.1 nameserver. When I done curl -v https://frigate.myserver.com it tried to access it over my public ip, but containers can't be accessed over the net. And that was the reason I coudn't set up integrations using mysubdomain over ssl. I use adguard as local dns but I totally forgot on system dns settings. I set up frigate and uptime kuma integrations to work with ssl, still struggling with adguard over ssl.

[meichthys]

Thanks for following up 👍