# ALS Alert Screen

Jednostronicowa aplikacja HTML/JS wyświetlająca alarmy maszyn na podstawie
danych WebSocket z LuPort. Przeznaczona do montażu na monitorze halowym
(Chromium na Debianie).

---

## Działanie

Strona utrzymuje **jedno** połączenie WebSocket ze zbiorczym kanałem ALS
nowego systemu (`/ws/als-data/` bez maszyny w adresie) — kanał niesie
aktualizacje wszystkich maszyn, a zaraz po połączeniu serwer wysyła migawkę
ich bieżącego stanu, więc trwający alarm pojawia się na ekranie natychmiast,
także po każdym wznowieniu połączenia.

| Sytuacja | Widok |
|----------|-------|
| Brak maszyny w alarmie | Iframe z infoterminalem ALS |
| Co najmniej jedna maszyna w alarmie | Ekran alarmowy z kartami maszyn |
| Brak łączności z LuPort > 10 s | Pomarańczowy pasek u góry (na obu widokach) |

Alarm jest wykrywany, gdy pole `status` maszyny zawiera słowo **`alarm`**
(bez rozróżnienia wielkości liter), np. `"Alarm - awaria"`, `"ALARM"`.

Pomarańczowy pasek to celowo INNY kolor niż czerwień alarmów: mówi „ekran może
pokazywać nieświeży obraz", a nie „maszyna stoi".

---

## Konfiguracja

Wszystkie parametry na początku sekcji `<script>` w `als_alert_screen.html`:

| Stała | Znaczenie |
|---|---|
| `WS_URL` | adres kanału zbiorczego, np. `ws://luport.local/ws/als-data/` |
| `WS_TOKEN` | token konta `ApiUser` (patrz niżej) |
| `MACHINES` | filtr maszyn pokazywanych na ekranie; `[]` = wszystkie |
| `WATCHDOG_SILENCE_MS` | po jakiej ciszy uznać połączenie za martwe (90 s) |
| `STALE_MS` | po jakim czasie dane maszyny znikają z ekranu (5 min) |
| `OFFLINE_BANNER_AFTER_MS` | po jakim czasie bez łączności pokazać pasek (10 s) |

Oba kluczowe parametry można też nadpisać w adresie strony — wygodne przy
konfiguracji kiosku bez edycji pliku:

```
als_alert_screen.html?ws=ws%3A%2F%2Fluport.local%2Fws%2Fals-data%2F&token=...
```

### Token (wymagany przez nowy system)

Nowy LuPort wymaga uwierzytelnienia WebSocket. Utwórz dedykowane konto:
Django Admin → **Users → Api users** → dodaj `bot-als-alert-screen`
**bez żadnych uprawnień** (sam odbiór strumienia ALS ich nie wymaga — konto
ma minimalny możliwy dostęp). Wygenerowany token wpisz w `WS_TOKEN`.

### Format wiadomości

Strona obsługuje dwa typy ramek — obydwa tak samo (liczy się najnowszy stan):

- `machine_data` — migawka wysyłana przez serwer zaraz po połączeniu,
- `machine_update` — aktualizacje na żywo.

```json
{
  "type": "machine_update",
  "machine": "2.60",
  "data": { "status": "Automatyczny", "orders": ["202605350"], "progress": 25, "...": "..." },
  "timestamp": "2026-07-31T12:00:32"
}
```

---

## Odporność na awarie — dlaczego cron-restart nie jest już potrzebny

1. **Reconnect z wykładniczym odstępem i jitterem** (1 s → 30 s). Odstęp wraca
   do minimum dopiero po 60 s stabilnego połączenia — serwer, który przyjmuje
   i zaraz zrywa (np. zły token), nie jest młócony co sekundę.
2. **Watchdog martwego połączenia.** Przeglądarka nie wystawia ping/pong do
   JS, więc połączenie zabite bez zamknięcia TCP potrafi wisieć „otwarte"
   w nieskończoność. Na kanale zbiorczym dane płyną praktycznie ciągle
   (35 maszyn × cykl scrapera 30 s) — cisza dłuższa niż 90 s oznacza martwe
   połączenie i wymusza reconnect.
3. **Wygasanie danych.** Dane maszyny starsze niż 5 min znikają z ekranu —
   alarm maszyny usuniętej z widgetu ALS nie wisi w nieskończoność.
4. **Widoczna utrata łączności.** Pasek offline + pasek statusu w rogu.
   Ekran nigdy nie pokazuje po cichu nieświeżego obrazu.

---

## Historia: dlaczego alarmy „przestawały wyskakiwać" (do 2026-07-31)

Poprzednia wersja utrzymywała **35 osobnych połączeń** (po jednym na maszynę)
i miała błąd, który ujawnił się po ukryciu paska statusu: element `#status-bar`
został **zakomentowany w HTML**, ale `refreshStatus()` nadal po niego sięgał.
`TypeError` na `null` przerywał handler `ws.onclose` **przed** zaplanowaniem
reconnectu — każda maszyna po pierwszym zerwaniu połączenia milkła na zawsze.
Maszyny odpadały jedna po drugiej przy każdym czknięciu sieci, a restart
z crona co 2 h maskował problem, zaczynając od zera.

Wnioski utrwalone w obecnym kodzie:

- element statusu **musi istnieć w DOM** (ukrywanie wyłącznie przez CSS),
  a `refreshStatus()` i tak ma osłonę na jego brak,
- brak `ws.onerror` jest celowy — po błędzie przeglądarka i tak wywołuje
  `onclose`, a osobny handler był tylko drugim miejscem, z którego dało się
  rzucić wyjątkiem,
- scenariusz 6 w testach (`test/testy_ekranu.py`) jest bezpośrednim testem
  regresji tego błędu.

Poprawki robione na kiosku w czerwcu (timery świeżości per-maszyna,
ubijanie „zombie" połączeń, jitter reconnectu) szły w dobrą stronę, ale
nieświadomie POGORSZYŁY objaw: watchdog celowo zamykał ciche połączenie,
a każde zamknięcie przechodziło przez ten sam wadliwy `onclose` — czyli
własna obrona uśmiercała maszynę na stałe. Ich sedno (wykrywanie ciszy,
jitter) jest zachowane w obecnej wersji; nakładkowy iframe („iframe
optimalization") również. Zrezygnowano z czyszczenia danych przy rozłączeniu:
alarm nie znika przy 3-sekundowym czknięciu sieci — o niepewności informuje
pomarańczowy pasek, a migawka po reconnexie przywraca prawdę.

**Cron restartujący przeglądarkę co 2 h można usunąć.**

---

## Testy

```bash
python3 test/testy_ekranu.py
# lub na kiosku:
CHROME_BIN=/usr/bin/chromium python3 test/testy_ekranu.py
```

Deterministyczne, bez sieci: skrypt aplikacji jest wycinany z żywego
`als_alert_screen.html`, `window.WebSocket` podmieniany na fałszywkę,
a scenariusz (10 asercji: migawka, aktualizacje, reconnect, baner offline,
watchdog, wygasanie danych) jedzie na wirtualnym czasie Chromium — całość
trwa kilka sekund mimo symulowania ~6 minut.

---

## Tryb debug

Podgląd ekranu alarmowego bez danych i bez połączeń WS:

```
als_alert_screen.html?debug
```

albo w konsoli przeglądarki: `DEBUG_ALARM = true; updateDisplay();`
(powrót: `DEBUG_ALARM = false; updateDisplay();`).

---

## Wymagania

- Chromium/Chrome 105+ (CSS Container Queries, `min()`) — kiosk działa na
  Chromium pod Debianem.
- Dostęp sieciowy do LuPort (WebSocket) oraz infoterminala ALS (iframe).