Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(atemschutz): umluftabhängige Filtergeräte lassen sich nicht überwachen — Konzept zu klären

Abierto
  • ¿Algo no está bien?
#428 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend, desktop, mobile

Línea de trabajo

Start with the referenced AtemschutzTrupp.cs, ScbaView.axaml, ScbaViewModel.cs, AtemschutzSection.cs, and SystemAlarmService.cs, then review #398/#418 because their trupp-type work is a stated prerequisite. The existing IsTimeAlarm and MaxDurationMinutes are identified as the time-monitoring foundation. First resolve the open product and safety questions; done means an agreed scope and specification, not an implementation defined by this issue.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement question

Rückmeldung aus der Praxis

Atemschutz: Filter auch integrieren - Wie müssen wir mal klären

Inzwischen präzisiert: es geht um Filtermasken ohne Pressluft, also
umluftabhängigen Atemschutz. Wie das im Lagebuch aussehen soll, ist noch offen —
dieses Issue sammelt deshalb, was feststeht, was im Code im Weg steht und was
zu entscheiden ist. Es ist ausdrücklich keine fertige Spezifikation.

Worum es fachlich geht

Die Atemschutzüberwachung der App kennt heute genau eine Sorte Gerät: das
umluftunabhängige Isoliergerät, den Pressluftatmer. Daran hängt alles —
Einstiegsdruck, Rückzugsdruck, Druckabfrage, bar.

Das umluftabhängige Filtergerät ist etwas anderes: Vollmaske plus Filter,
die Atemluft kommt aus der Umgebung und wird durch den Filter gereinigt. Keine
Flasche, kein Manometer, kein Druck.

Filter sind typ- und klassenabhängig und farblich gekennzeichnet:

Typ Farbe Gegen
A braun organische Gase und Dämpfe, Siedepunkt über 65 °C
B grau anorganische Gase und Dämpfe
E gelb Schwefeldioxid, saure Gase
K grün Ammoniak und organische Ammoniakderivate
CO schwarz Kohlenmonoxid
P weiß Partikel (P1/P2/P3)
Reaktor orange radioaktives Iod

Dazu Kombinationsfilter (A2B2E2K2-P3 und ähnlich) und die Filterklassen 1 bis 3,
die die zulässige Schadstoffkonzentration bestimmen — grob 0,1 / 0,5 / 1,0 Vol.-%.

Einsatzgrundsätze — sie bestimmen, was eine Überwachung führen muss

Nach FwDV 7 darf ein Filtergerät nur eingesetzt werden, wenn

  • genügend Sauerstoff vorhanden ist (mindestens 17 Vol.-%),
  • Schadstoff und Konzentration bekannt sind und zum Filter passen,
  • nicht in Behältern, Gruben, Kanälen oder engen Räumen gearbeitet wird,
  • und nicht im Innenangriff bei einem Brand — Kohlenmonoxid und unbekannte
    Pyrolyseprodukte schließen das aus.

Der für die Software entscheidende Unterschied zum Pressluftatmer:

Ein Filter hat kein Warngerät.

Beim PA sagt das Manometer, wann Schluss ist. Beim Filter merkt der Träger den
Durchbruch an Geruch, Geschmack oder Reizung — und das ist dann das
Rückzugskriterium. Es gibt keinen Messwert, den die Überwachung abfragen könnte.
Was sie führen kann, ist die Zeit.

Typische Lagen — das ist kein Randfall

  • Nachlösch- und Aufräumarbeiten im Freien
  • Tierseuchenbekämpfung
  • bekannter Gefahrstoff im Freien, etwa Ammoniakaustritt am Kühlhaus
  • Ölschaden, Lösemittel
  • Kontaminationsschutz im Strahlenschutzeinsatz

Was im Code im Weg steht

grep -riE "filtergerät|filtermaske|pressluftatmer|umluftabhängig|vollmaske"
über src/, docs/, tests/ und die README → null Treffer. Es gibt dazu
nichts, und die vorhandene Überwachung ist durchgehend druckbasiert:

Stelle Was passiert
AtemschutzTrupp.Register (AtemschutzTrupp.cs:138) if (entryPressure <= 0) throw … "Einstiegsdruck muss größer als 0 sein." — ein Filtertrupp ist damit überhaupt nicht anlegbar
IsPressureAlarm (:328) LatestPressure <= ReturnPressureBar — ohne Druck sinnlos
NextControlDueAt, IsControlDue, PressureControlIntervalMinutes die gesamte Druckabfrage-Schleife
ScbaView.axaml:92 Feld EINSTIEGSDRUCK, NumericUpDown Minimum="1" — Pflichteingabe
ScbaView.axaml:182, :211-220 Spalte DRUCK, Eingabefeld und Knopf DRUCK
ScbaViewModel.cs:128 StatusDisplay kennt den Zustand "Druckabfrage"
ScbaViewModel.cs:446-448 AlarmReason → "Rückzugsdruck erreicht ({bar} bar)"
AtemschutzSection.cs:10 PDF-Spalten "Druck Start" und "Druck akt."
SystemAlarmService.cs:33 Sprachansage voice-druckabfrage.wav

Was dagegen schon passt

Die halbe Miete ist bereits da:

// src/LageBuch.Domain/Atemschutz/AtemschutzTrupp.cs:326
public bool IsTimeAlarm(DateTimeOffset now) =>
    (IsActive || IsWithdrawing) && DueAt is { } due && now >= due;

IsTimeAlarm hängt allein an StartTime + MaxDurationMinutes und kennt
keinen Druck. Die Zeitüberwachung — genau das, was ein Filtertrupp braucht —
funktioniert also heute schon vollständig. Und MaxDurationMinutes sitzt je
Trupp, nicht global.

Dazu kommt das Fundament aus #398: der Branch fix/trupp-types-stammdaten
macht aus dem Trupp-Typ eine Stammdatenzeile.

public sealed record TruppType(string Name, int MemberCount, int MaxDurationMinutes)

Dort gehört ein Kennzeichen „umluftabhängig / kein Druck" hin. Dann ist ein
Filtertrupp eine Stammdatenzeile und kein Sonderfall im Code — dieselbe Lösung,
die #398 für CSA- und LPA-Trupp vormacht.

Ansatz (Richtung, nicht Entwurf)

  1. Kennzeichen am TruppType, sobald #398 liegt.
  2. Ist es gesetzt: Einstiegsdruck entfällt, Rückzugsdruck entfällt, Druckabfrage
    entfällt. Überwacht wird über die Einsatzzeit, die es bereits gibt.
  3. Druckfeld, Druckspalte, Druck-Knopf und die Druckabfrage-Ansage je Trupp
    ausblenden, statt einen zweiten Überwachungspfad danebenzustellen.
  4. Im Protokoll (AtemschutzSection) darf bei so einem Trupp kein leeres
    „— bar" stehen, sondern das, was tatsächlich geführt wurde.

Einschätzung aus der Praxis

(Meinung, keine getroffene Entscheidung — bewusst als solche gekennzeichnet.)

Der Filtertrupp gehört in die Überwachung. Wer unter Maske im
Gefahrenbereich ist, gehört auf die Tafel, mit Zeit — auch ohne Flasche. Die
Frage „wer ist noch drin und seit wann" ist beim Filtergerät dieselbe wie beim
Pressluftatmer, und sie ist genau die Frage, für die diese Anwendung gebaut ist.

Die Einsatzgrundsätze gehören als Hinweis hin, nicht als Sperre. Ob der
Sauerstoffgehalt reicht und ob der Filter zum Stoff passt, entscheidet der
Einsatzleiter, nicht das Programm — und zwar mit Informationen, die das Programm
gar nicht hat. Ein Hinweis beim Bereitstellen ist billig und richtig; eine
Blockade wäre falsch. Das ist dieselbe Haltung, die
src/LageBuch.AppLogic/Services/StammdatenCatalogue.cs bereits schriftlich
vertritt: "Nothing here rejects a value. An Einsatz in progress must never be
blocked."

Offene Fragen

Das ist der eigentliche Zweck dieses Issues:

  1. Überwachung oder Kräfte? Filtertrupp in die Atemschutzüberwachung, oder
    reicht ein Eintrag bei den Kräften?
  2. Filtertyp erfassen? Als Freitext, oder als Liste in den Stammdaten? Und
    ist der Typ für die Dokumentation wirklich nötig, oder genügt „Filtergerät"?
  3. Woher kommt die Einsatzzeit? Die Standzeit eines Filters ist
    stoffabhängig, nicht gerätefest — es gibt keine Zahl wie die 30 Minuten beim
    AGT. Vorgabe je Trupp-Typ und im Einsatz änderbar?
  4. Sicherheitstrupp? FwDV 7 knüpft den an den umluftunabhängigen
    Atemschutz. Beim Filtergerät ist die Lage anders — zählt ein Filtertrupp für
    die Regel aus #399 mit, oder nicht?
  5. Angebrochener Filter. Ein geöffneter Filter ist nur begrenzt weiter
    verwendbar. Gehört das nachgehalten, oder ist das Gerätewartung und hat im
    Lagebuch nichts verloren? (Meine Neigung: Gerätewartung.)

Querverweise

  • #398 / #418 — Trupp-Typen aus den Stammdaten. Das Fundament; ohne das
    wird der Filtertrupp ein dritter Magic String.
  • #399 — Sicherheitstrupp, siehe offene Frage 4.
  • #402 — Rückzugsdruck ist eine flache 50-bar-Regel und bar ein Literal statt
    einer Einheit. Wer die Druckannahmen anfasst, berührt beides.
  • #410 — Mehrgasmessung. O₂-Gehalt und Schadstoffkonzentration sind genau die
    Werte, die über die Filterfreigabe entscheiden; die Themen berühren sich.
  • #405 — Portabilitäts-Tracking.
Lenguaje dominante
C#
Estrellas
1
Forks
3
Merge medio
4 h 15 min
PR fusionados (30 d)
181

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CodeForFire/lagebuch

Todos los issues de CodeForFire/lagebuch

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.