# 2026-11-10

## Mobi 2: Portweiterleitungen wie Mobi 1

Wunsch: Auf Mobi 2 (RUT955 `192.168.55.9`) dieselben Port Forwards wie auf Mobi 1 (`192.168.55.6`).

Mobi 1 (gelesen über die Router-API `/api/firewall/port_forwards/config`): Dulcopool 8787 → `192.168.57.82:80`, Loxone 8777 → `.121:80` (MS0470), Loxone2 8778 → `.122:80` (MSCA47), test 8779 → `.145:80` (isp56a2); alle TCP+UDP, Quelle Zone `openvpn`, Ziel `lan`, Reflection an.

Mobi 2 hat dasselbe LAN `192.168.57.0/24`, aber andere Geräte: Loxone (MAC `50:4F:94…`) auf `.146`, `.203`, `.244`, dazu `.137` (Laptop) und `.152`. Keine Zone `openvpn`; der OpenVPN-Client `rtr` läuft über die Standardzone `vpn`. Zuordnung nach Rückfrage beim Nutzer angelegt (API, Quelle `vpn`, sonst wie Mobi 1):

| Name | Port | Ziel | Test aus dem VPN |
|---|---|---|---|
| Loxone | 8777 | 192.168.57.146:80 | 200, „Webinterface“ |
| Loxone2 | 8778 | 192.168.57.203:80 | 200, „Loxone“ (lighttpd) |
| Loxone3 | 8780 | 192.168.57.244:80 | 200, „Webinterface“ |
| Dulcopool | 8787 | 192.168.57.82:80 | keine Antwort (Gerät nicht vorhanden) |
| test | 8779 | 192.168.57.145:80 | keine Antwort (Gerät nicht vorhanden) |

Teltonika-Standardeinträge auf Mobi 2 (alle aus) unverändert. Mobi 1 nicht verändert.

### Bayrol/Dulcopool an Mobi 2 gesucht

Nutzer erwartet ein Bayrol- oder Dulcopool-Gerät an Mobi 2. SSH auf Mobi 2 (root, Schlüssel vom Nutzer hinterlegt), nur lesend: `ip neigh`/ARP und DHCP-Leases zeigen nur die drei Loxone (`.146`, `.203`, `.244`) als erreichbar, `.137` (Laptop) und `.152` nicht erreichbar, `.82`/`.145` ohne Antwort. Bridge-MAC-Tabelle (`brctl showmacs br-lan`): am Kabelport nur die drei Loxone-MACs. `arp-scan` über 192.168.57/0/1/2/178.0/24, 10.0.0.0/24 und 169.254.0.0/16: nur die Loxone. Ergebnis: Kein weiteres Gerät sendet im LAN von Mobi 2 — aus, nicht gesteckt oder hinter einem anderen Gerät.

Dateien: nur Router Mobi 2; Doku `docs/journal/2026-11-10.md`, `docs/TODO.md`.

## Mobi 2 in der App

Wunsch: Mobi 2 als Anlage anlegen, analog zu Mobi.

Stand vorher: Router sendet bereits `mqtt.0.rtrmobi2.gpsdata` und `.lte`. Skript `gps_mobi2` läuft und schreibt Ort/Koordinaten nach `0_userdata.0.dp-smartsolutions.mobi2`. Skript `bayrol_mobi2` zeigt auf `192.168.55.9:8787`, ist aus; die Wasserpunkte stehen auf dem Anfangswert 0. Port 8787 antwortet nicht (Dulcopool am Container nicht vorhanden).

Angelegt: Container „Mobi 2“, ID 5, Standort Düren, Typ und Ausstattung von Mobi übernommen. Die App liest für ID 5 den Ordner `mobi2` und den Router `rtrmobi2`. Ein fehlender ioBroker-Punkt bricht die Abfrage nicht mehr ab. Geprüft gegen ioBroker: online, letzte Meldung 13:36, Position 50.764595 / 6.480945 (Lendersdorf, Düren), LTE −106 dBm (ein Balken). pH, Chlor, Redox und Temperatur sind 0, Status „Keine Daten“.

Nicht gesetzt, weil die ioBroker-simple-api keine neuen Punkte anlegt und die Admin-Oberfläche eine Anmeldung verlangt: Warnschwellen und die Influx-Aliase `mobi2_ph`, `mobi2_chlor`, `mobi2_redox`, `mobi2_temp`. Ohne die Aliase bleiben die Verläufe leer. Die lokale Seite ließ sich nicht öffnen (kein Server auf Port 8000, Containerseiten verlangen eine Anmeldung).

Die Datenbank ist die gemeinsame Produktionsdatenbank. Der Container ist damit live sichtbar, der Server-Code kennt die Zuordnung erst nach Deploy und `cache:clear`.

Dateien: `src/Service/ContainerApiService.php`, `src/Service/ContainerSceneCatalog.php`, `src/Controller/ContainerController.php`, `config/swimmonitor/changelog.yaml`, `docs/TODO.md`, `docs/journal/2026-11-10.md`.

## Signage: MOV und weitere Videoformate

Problem: Die Mediathek nahm nur MP4 und MOV an, und auch die nur mit H.264 und AAC. MOV vom Handy ist meist HEVC, dazu fehlen MKV, AVI, WebM und weitere.

Entscheidung: Bekannte Videodateien dürfen hochgeladen werden. Ist das Ergebnis nicht schon MP4/MOV mit H.264 und AAC (oder ohne Ton), wandelt ffmpeg es um. H.264 mit passendem Ton wird nur ins MP4 gepackt, alles andere neu kodiert. Die Bildschirme und die Vorschau bekommen dadurch weiter H.264/AAC.

Geprüft: Ein AVI mit MPEG-4-Video und MP2-Ton wird abgelehnt und kommt als H.264/AAC-MP4 heraus (PHPUnit, 1 Test, 8 Assertions). Die Seite selbst nicht im Browser, lokal läuft kein Server und die Verwaltung verlangt eine Anmeldung.

Auf dem Server bleibt `ffmpeg` nötig; lange Filme laufen in derselben Anfrage (bis 30 Minuten) und können am Proxy-Timeout scheitern.

Dateien: `src/Service/Signage/SignageMediaTranscoder.php`, `src/Service/Signage/SignageMediaProbe.php`, `src/Controller/Signage/SignageMediaController.php`, `public/js/admin/signage-media.js`, `public/js/admin/signage-tour.js`, `templates/signage/media/index.html.twig`, `config/services.yaml`, `config/swimmonitor/changelog.yaml`, `tests/Service/Signage/SignageMediaTranscodeTest.php`, `docs/SYMFONY-INTEGRATION-SIGNAGE-DPOHL.md`, `docs/TODO.md`, `docs/journal/2026-11-10.md`.

## Signage: Standbild zur Zuordnung

Problem: In Mediathek, Playlist und Kalender sind Videos nur am Namen zu unterscheiden. Das eingebettete Video zeigt oft kein Bild, solange die Datei nicht geladen ist.

Entscheidung: ffmpeg schneidet ein JPEG (bis 480 px, etwas nach dem Anfang). Neue Uploads bekommen es sofort, vorhandene beim ersten Abruf. Angezeigt in der Mediathek, in der Playlist-Bibliothek und bei den einzelnen Videos im Gerätekalender. Beim Daraufzeigen läuft das Video weiter.

Geprüft: das Testvideo liefert ein JPEG. Die Seiten nicht im Browser, lokal läuft kein Server und die Verwaltung verlangt eine Anmeldung.

Dateien: `src/Service/Signage/SignageMediaTranscoder.php`, `src/Service/Signage/SignageMediaStorage.php`, `src/Controller/Signage/SignageMediaController.php`, `templates/signage/_macros.html.twig`, `templates/signage/media/index.html.twig`, `templates/signage/playlist/show.html.twig`, `templates/signage/device/show.html.twig`, `public/css/admin/signage.css`, `public/js/admin/signage-core.js`, `public/js/admin/signage-playlist.js`, `tests/Service/Signage/SignageMediaTranscodeTest.php`, `config/swimmonitor/changelog.yaml`, `docs/journal/2026-11-10.md`.