Dann machst du was falsch. Ich nutze die und habe nur EntitÀten.
Sorry, ich verstehe dich nicht. Die Verwendung von UIX in welchem Code ersetzen? Nur Bahnhof⊠![]()
Wenn du keinen card_mod verwendest, kann ich das gut verstehen:![]()
Nutzt jemand die fold-entity-row?
Hier greifen aktuell nach dem Update keinerlei der card_mod(jetzt uix) Anpassungen mehrâŠ
Habs lösen können, gleicher Owner wie card_mod, auch hier keine Updates mehr. ich habe aber diese Repo gefunden, anscheinend hat sich jemand der Sache angenommen und ein Fork erstellt
Du hast rechtâŠaber als die neuen Trigger freigegeben wurde habe ich einiges durchprobiert, da kamen DeviceIDs raus wodurch ich mir gesagt hab âSchade, danke fĂŒr nichtsâ, zumindest was ich jetzt so probiert habe, da kamen EntitiĂ€ten. Naja, im Zweifel prĂŒfen ![]()
Hattest du nicht card_mod mit uix ersetzt?
Dann hast du doch in der Vergangenheit card_mod genutzt, oder?
Dann steht doch in deinem Dashboards
card_mod:
Das dann mit
uix:
ersetzen
Ach so, okay. Ich dachte tatsÀchlich, das sei eben nicht nötig.
Wird aber auch nicht so hÀufig verwendet hier, deshalb wohl ist mir noch nichts aufgefallen.
Ist auch nicht unbedingt nötig, deshalb schrieb ich ja
das entfernen des http: blocks aus der configuration.yaml hat meine weboberflÀche gekillt - hat jemand eine Idee wie ich per SSH die Zertifikate (subdomain.domain.tld.key & subdomain.domain.tld.pem im Ordner configuration/ssl) wieder hinterlegen kann (oder notfalls zumindest HTTPS deaktivieren kann)?
edit: copied my certs directly into fullchain.pem and privkey.key, didnât help. reverted back to symlinks
lrwxrwxrwx 1 root root 19 Feb 5 2026 fullchain.pem â subdomain.domain.tld.pem
-rw------- 1 root root 227 May 8 20:47 subdomain.domain.tld.key
-rw-râr-- 1 root root 3.6K May 8 20:47 subdomain.domain.tld.pem
lrwxrwxrwx 1 root root 19 Feb 5 2026 privkey.pem â subdomain.domain.tld.key
Normalerweise wird die komplette http Konfiguration in die GUI ĂŒbernommen, inklusive der Pfade fĂŒr die Zertifikate.
Die http Konfiguration ist nach der Migration zugĂ€nglich ĂŒber:
config/.storage/http
GruĂ Osorkon
danke, sieht soweit eigentlich gut aus. nur das Rautezeichen am Ende verwirrt mich.
ist es eventuell ein problem absolut vs relativer pfad?
.storage cat http
{
âversionâ: 2,
âminor_versionâ: 2,
âkeyâ: âhttpâ,
âdataâ: {
âstableâ: {
âssl_certificateâ: â/config/ssl/subdomain.domain.tld.pemâ,
âssl_keyâ: â/config/ssl/subdomain.domain.tld.keyâ,
âlogin_attempts_thresholdâ: -1,
âserver_portâ: 8123,
âssl_profileâ: âmodernâ,
âip_ban_enabledâ: true,
âuse_x_frame_optionsâ: true,
âcors_allowed_originsâ: [
â``https://cast.home-assistant.io``â
],
âcreated_atâ: â2026-08-06T18:47:33.043827+00:00â,
âerrorâ: null,
âerror_messageâ: null
},
âpendingâ: null,
âyaml_migration_doneâ: true
}
}#
Der Ordner SSL ist nicht unter config, sondern im Root, das /config muss weg und heissen deine files wirklich subdomain.domain.tld.xxx ?
Oder hast du manuell einen SSL ordner im config angelegt?
unter TrustedProxies sollte die 127.0.0.1/32 und das DockerNetz stehen, dann kommst du noch per ip:8123 ran
"trusted_proxies": [
"127.0.0.1/32",
"172.30.33.0/24"
],
Bis auf den Pfad zum Zertifikat.
Absoluter Pfad!
Also
/ssl/subdomain.domain.tld.pem
Und nicht
config/ssl/subdomain.domain.tld.pem
GruĂ Osorkon
danke, ist aktuell eine installation auf raspberry 4, soll aber demnĂ€chst auf proxmox wandernâŠ
realpath ha.domain.name.key
/homeassistant/ssl/ha.domain.name.key
danke fĂŒr den tipp, liegt am (relative) pfad - das hat das "autoconvert" dann wohl zerstört, da es zuvor aus der configuration.yaml funktionierte
und nein, meine domain habe ich nur verschleiert, ich nutze nicht wirklich subdomain.domain.tld ![]()
edit: damit klappt verbindung wieder ĂŒber die IP (verschlĂŒsselt), aber noch nicht ĂŒber die domain (weder ver- noch unverschlĂŒsselt) :-/
Dann suche ich ich auch erstmal nicht danach. Ist mir zu viel Arbeit, hab ja (noch) keinen KI-Agenten ![]()
Wer Cloudflared benutzt sollte entweder mit der Umstellung auf den Port 80 noch warten, oder alternativ einen neuen Eintrag fĂŒr seine Domain einrichten und die aktuelle mit einem Zusatz und Punkt vor der Domain stillegen. Anscheinend meldet der Supervisor der Cloudflared-App nach dem Portwechsel weiterhin 8123 (Bug in HA 2026.8 / Supervisor 2026.07.5).
Sonst gab es keine unangenehme Ăberraschungen!
Es gibt ja ĂŒberhaupt keine Notwendigkeit den Port zu Ă€ndern.
Und wenn man es tut, dann ist es ja wohl klar, dass Cloudflare, NPM oder was immer man als Proxy nutzt auf den neuen Port umkonfigurieren muss.
GruĂ Osorkon
Ja, ich verstehe auch nicht, was der Hintergrund ist.
Warum sollte man Ă€ndern? Um HA zu erreichen, ohne den Port an die IP danzusetzen und es AnfĂ€ngern einfacher zu machen? Entwicklerwerkzeuge wurden ja auch umbenannt in â Werkzeuge. Ich denke da soll eine breitere Zielgruppe angesprochen und die BerĂŒhrungsangst genommen werden.
Wenn es denn in der App gehen wĂŒrde!
Das der Port in der App geĂ€ndert werden muss war mir klar! Aber es gibt schon einen Fix dafĂŒr von der Cloudflared App!
Raw-Konfigurationseditor öffnen und dann suchen â ersetzen: http://192.168.178.xx:8123/lovelace/default_view?edit=1
