Dann muss ich da noch was ergänzen.
Ich sehe dann folgende Module (Reihenfolge egal, nur der folgenden Erklärung wegen sortiert):
1) Nachrichten Kanäle definieren
2) Archiv
3) Systemalarme
4) individuelle Nachrichten
unter 1) wie von Sven schon notiert die fixen Parameter eines Transferweges
unter 2) quasi wie der KNX-Busmonitor die Auflistung der abgesetzten Nachrichten Spalten
Zeitstempel / Kanal-ID / Nachrichten_Objekt_ID
Ergebnis aus 3) und 4) / Nachrichten_Objekt_Name / Value
Text
unter 3) Kann man sich Alarmobjekte bauen (Auswahl von Systemobjekten und Definition von Schwellwerten/Triggerbedingungen, A C CT usw,) In dem Alrmobjekt definiert man darüber auch die kritikalitätsstufe des Alarms. Bei Schwellwerten lassen sich bestenfalls auch direkt die verschiedenen Grenzen für blau / grün / gelb / rot mit einmal angeben. Und in einem anderen teil des Schirms baut man dazu auch noch die Nachricht selbst als Nachrichtenobjekt in dem man auch noch einen Nachrichtenkanal verbindet, hier sind auf jeden fall auch die Sendebedingungen zu definieren (A/C/CT/T). Nachrichtentext ist hier fixiert.
Ganz Spannend wäre auf der logischen Schicht zwischen 3) und 4) noch eine Art Eskalation, die aber auch nur Sinnvoll umsetzbar mit einer Quittierung ist. Wenn nach x Auslösungen des Alarmobjektes immer noch der Alarm triggert, dann erweitere den Empfängerkreis. Wäre also eigentlich ein neues Alarm-Objekt was eben mehr Vorbedingungen hat als nur eine Systemwertauswertung, stattdessen noch so eine Art Timer oder Counter des eigentlichen Alarmobjektes wie lang/oft der Zustand durchgehend so anliegt.
Damit hat man im DOS drei neue Objekttypen zur Auswahl:
Systemwert_Objekt (x % genutzte SSD)
Systemalarm_Objekt (Rot 95% SSD Auslastung ja/nein)
Nachrichten-Objekt (Nachrichtentext mit Verbindung an den ausgewählten Nachrichtenkanal)
unter 4) stehen die Optionen von 3) zur Verfügung nur ist es hier etwas komplexer und umfangreicher.
Da man sich nicht nur Systemwertobjekte aussuchen kann sondern eigentlich alles was als Input-Objekt aus dem DOS nutzbar ist (Sensorwerte vom 1-wire, eingehende KNX-Telegramme, Outputs aus Logiken, Modbus Eingänge, MQTT Eingangsobjekte), dazu lassen sich ebenso wieder Schwellwert und Triggerbedingungen definieren. Nimmt man nur Trigger wird quasi 1:1 durchgeleitet ohne ein Alarmobjekt zu kreieren, bzw. das wäre eines mit Bedingung allways.
Dann auch ein freies Feld für die Nachricht wo man eben aus dem Eingangsobjekt selbst als auch aus dem Alarm-Objekt was man sich ggf durch die Schwellwertlogik gebaut hat, einfügen kann, das betrifft die Inhalte als auch die Metadaten der Objekte. Und eigene Prosa natürlich. Als letztes folgt wieder die Zuordnung zu einem/ mehreren Nachrichtenkanälen und fertig ist das.
Auch dies ergibt wieder eigene Objekttypen, diesmal aber nur 2 neue, weil das bei 3) verwendete Systemwertobjekt oder auch eines der System-Alarmobjekte sind eh schon da, welche hier natürlich verwendet werden könnten und eben alles andere aus dem DOS auch verwendet werden kann. Neu ist dann hieraus das
individuelles_Alarm_Objekt
Das Nachrichtenobjekt selbst wäre auch wieder die gleiche Objektkategorie.
Die Aufteilung in Wert- / Alarm- / Nachricht- /Kanal-Objekte ermöglicht es einem sofort auch in allen anderen Editoren diese Objekte zu verwenden. Ein solches Alarmobjekt (1Bit) kann man natürlich auch direkt in einer Logik verwenden, da will ja niemand erst nochmal den SSD-Verbrauch gegen einen Schwellwert halten oder verbindet es mit einem KNX-KO und löst auf dem Bus direkt Aktionen aus oder schiebt so ein Alarm-Objekt auf eine Timeseries für Grafana usw. usw.
Die Nachrichten selbst (bis zu 14byte) lassen sich damit auch noch an ein KNX-KO verbinden und senden (Anzeige Taster) oder oder oder.
Quittierungen sind natürlich für weitere Logiken hilfreich, die Nachrichtenzentrale sehe ich hier aber nur insofern beteiligt wenn man auch Input-Nachrichtenkanäle hat. Da wäre dann die Frage wie kann der TWS eine Whats-app / email usw. Empfangen.
Wenn das irgendwie geht wäre das Menüpunkt
5) Auswertung eigehender Nachrichten die zu Objekten führen.
In der Definition der Alarmobjekte selbst. ließe sich dann als Nebenbedingung auch eine solche Quittung entgegennehmen um erneutes Senden / Eskalieren zu verhindern.
Aber hier kommen direkt neue Aufwändige Überlegungen rein, man hat ne Quittung wegen zu voller SSD. Ok wird nicht mehr alarmiert. Wie lange soll die Quittung gelten? Klar irrelevant wäre sie zu setzen, wenn die Auslastung unter die Schwelle geht. Aber sonst?
Das ist ne Spannende Frage, welche bestimmt kommt wenn man ne Whatsapp-Sperre bekommt wegen Spamverbreitung