Server-Adresse: das Schema richtet sich nach dem Ziel

Beim Neuverbinden stand "localhost:5173" im Feld, die App meldete "nicht
erreichbar". Ursache war basisUrlNormalisieren(): ohne Schema setzte es
blind https:// davor - womit die eigene Vorlage der App unbrauchbar war,
denn im Feld steht als Beispiel 192.168.1.20:8123, und im Heimnetz gibt
es kein Zertifikat.

Jetzt nach dem Ziel: localhost, 127.x, 10.x, 192.168.x, 172.16-31.x, ::1
und .local/.home.arpa/.localhost bekommen http, alles andere weiter https
(datametric360.de laeuft ueber Cloudflare). Steht ein Schema da, wird
nichts geraten.

Vier Regressionstests, darunter der gemeldete Fall, die Vorlage aus dem
Feld und 172.32.0.1 als Gegenprobe zum privaten Bereich.

Co-Authored-By: Claude Opus 5 <[email protected]>

AGENTS.md

@@ -13,7 +13,8 @@ Debug-Knopf und der HA-Zugang bei den Zugaengen; der Cache-Brecher der Bilder ha
 jetzt am Foto statt am App-Start; dazu ein Audit mit zwei Befunden in der
 Wisch-Zeile und der Auswahlliste der App; der Leerzustand der Karte ist deckend,
 dazu die Rueckfrage vor loeschenden Aktionen als eigenes Blatt statt als
-Browserdialog, `2026.9.4.17`,
+Browserdialog; das geratene Schema der Server-Adresse richtet sich jetzt nach dem
+Ziel, `2026.9.4.18`,
 Abschnitte CC bis CK. Davor: Geraetezeit statt Ankunftszeit - die Wurzel hinter der 3-km-Fahrt:
 das Fahrtfenster stand in Geraetezeit, der Verlauf war nach Ankunftszeit sortiert. Dazu die neun
 Paritaetsbefunde und die verunreinigte Batteriehistorie, `2026.9.4.1`, Abschnitt CB. Davor: Der Regler stellt den Schlaf-Timeout des Dongles, flespi lesend und
@@ -10363,3 +10364,36 @@ nicht** - das haette den eingefuegten Token des Eigentuemers geloescht;
 Abbrechen schliesst das Blatt, die Sitzung bleibt.
 
 Kein `window.confirm` mehr im Quelltext ausser dem dokumentierten Rueckfall.
+
+### Nachtrag (2026.9.4.18): das geratene Schema war falsch herum
+
+Beim Neuverbinden stand „localhost:5173" im Adressfeld, und die App meldete
+„Der Server ist unter dieser Adresse nicht erreichbar". Ursache war nicht die
+Eingabe, sondern `basisUrlNormalisieren()`: fehlte das Schema, setzte es
+**blind `https://`** davor.
+
+Damit war die **eigene Vorlage der App** unbrauchbar - im Eingabefeld steht
+als Beispiel `192.168.1.20:8123`, und genau so eingetippt entstand
+`https://192.168.1.20:8123`. Im Heimnetz gibt es kein Zertifikat, Home
+Assistant spricht dort `http`.
+
+Geraten wird jetzt nach dem Ziel: `localhost`, `127.x`, `10.x`,
+`192.168.x`, `172.16-31.x`, `::1`, `.local`/`.home.arpa`/`.localhost` bekommen
+`http`, alles andere weiterhin `https` - datametric360.de laeuft ueber
+Cloudflare, dort waere `http` ein Rueckschritt. Steht ein Schema da, wird
+nichts geraten.
+
+Vier Regressionstests (`src/api/umgebung.test.ts`), darunter der gemeldete
+Fall und die Vorlage aus dem Eingabefeld; `172.32.0.1` als Gegenprobe, weil
+der private Bereich bei `172.31` endet.
+
+Ohne Entsprechung im Panel, notwendigerweise: es kennt keine Server-Adresse.
+
+**Nebenbefund, nicht reproduzierbar:** unmittelbar nach dem Verbinden zeigte
+die App einmalig „401 Unauthorized" auf einer Datenabfrage, obwohl die
+Pruefung beim Einrichten (`GET /api/`) durchgegangen war. Direkt danach
+gemessen: derselbe gespeicherte Token liefert an beiden Endpunkten **200**,
+und ein Neuladen zeigt die App vollstaendig. Der Verdacht ist ein Rest der
+alten Sitzung im Speicher der Seite (getrennt und ohne Neuladen neu
+verbunden); wiederholt sich das, gehoert die Reihenfolge in `fertig()` ->
+`AngemeldeteApp` -> `DatenAnbieter` genauer angesehen.