Benachrichtung per E-Mail mit Sammelalarm

Hallo

Folgende Aufgabenstellung habe ich: ein Funktionsträger soll bei der Alarmierung bestimmter Stichworte eine E-Mail inkl. Angabe der alarmierten Einheiten bekommen.
Bisher löste ich das ganze über einen Sammelalarm mit dem 'sammel' Parameter. Erkennung der Stichworte mittels Whitelist, Alarmtext-Plugin gebastelt, fertig.
Nun habe ich aber seit einiger Zeit das Problem dass der Alarmtext jeder Einheit aneinandergereiht wird, auch wenn er gleich ist. Das nervt und produziert viel zu viel unnötigen Text. Wie kann ich das verhindern?

Beispiel: 3 Einheiten alarmiert, Mail sieht dann so aus:
Text: Stichwort Adresse Stadt Text; Stichwort Adresse Stadt Text; Stichwort Adresse Stadt Text;
Einheiten: 1; 2; 3

Wir nutzen einen Boss 925 mit dme-input plugin.

Hat jemand eine Idee?
Danke

Guten Tag,

im Sammelalarm unter %SA% sollten doppelte Alarmtexte eigentlich vermieden werden. D.h. beim Zusammenstellen wird überprüft, ob der Text bereits beinhaltet ist.

Ist der Text exakt identisch oder gibt es hier kleine Unterschiede?

Kann das Problem bestätigen.
Habe es vor Monaten schon mal im Forum angesprochen aber keine Reaktion darauf...

Habe es mit zwei Mails gelöst. Die erste ist an eine RIC gekoppelt, die immer ausgelöst wird. Diese versendet den Alarmtext an die entsprechenden Stellen als Info. Der Sammelalarm verteilt danach nur noch in einer weiteren Mail die alarmierten Gruppen.

Zitat:

---

Zitat von Helfo

Ist der Text exakt identisch oder gibt es hier kleine Unterschiede?

---

Der Text ist exakt identisch, kommt direkt vom Melder per seriellem Port.
Das komische ist dass es mit einer älteren FE-Version ja funktionierte, seit der Umstellung auf die neue Version aber nicht mehr :-/

Hi

Gibts denn wirklich garkeine Lösung für das Problem?

Wir vermuten einen Softwarefehler. Sobald der behoben ist, geht die Änderung in die aktuelle Beta mit ein.

Gesendet via Mobile App

Das ist mal ein Wort. Danke!

Zitat:

---

Zitat von firEmergency

Wir vermuten einen Softwarefehler. Sobald der behoben ist, geht die Änderung in die aktuelle Beta mit ein...

---

Ist es wirklich ein Softwarefehler? Logisch nachvollziehbar ist das Phänomen ja. Ein Sammelalarm hat als Texte auch die gesammelten Texte der "Sammelgruppe".

Werden dann identische Texte, welche doppelt vorkommen, einfach unterdrückt?

Also wir untersuchen es noch.
Aber prinzipiell ist es ja nicht notwendig, den exakt selben Text nochmal im Sammelalarm zu haben.

Richtig...
Wäre super, wenn das umgesetzt wird.

Also es sollte immer noch funktionieren, wie auch in den Vorgängerversionen.

Die Voraussetzung ist eben der komplett identische Nachrichtentext. Ist ein Leerzeichen mehr o.Ä. dann fügt er den neuen Inhalt hinzu..

Zitat:

---

Zitat von Helfo

Also es sollte immer noch funktionieren, wie auch in den Vorgängerversionen.

Die Voraussetzung ist eben der komplett identische Nachrichtentext. Ist ein Leerzeichen mehr o.Ä. dann fügt er den neuen Inhalt hinzu..

---

Habe das Problem jetzt mal erforscht. Wenn ich es richtig gesehen habe, dann werden die globalen Ersetzungen nach dem Hinzufügen zum Sammelalarm abgearbeitet. Wäre die Reihenfolge anders, dann wäre ein Trimmen des Textes möglich und man könnte die Unterscheidungsmerkmale entfernen.
Da beim Input über das DME-Plugin der Text aber nie identisch sein kann (sonst wäre ja keine Unterscheidung mehr möglich) wird es in dieser Konstellation nicht funktionieren.
Ist mein Gedankengang richtig oder bin ich auf dem Holzweg?

@Helfo: Du hast vom Parameter %SA% gesprochen. Dieser beinhaltet ja nur die Einheiten.
Werden also nur die Einheiten auf die einmaligkeit geprüft?
Mein Problem ist (und ich denke auch das vom TE), dass der Alarmtext (message) nicht verwendet werden kann da hier die Alarmtexte aneinander gekettet werden.
Hier habe ich ja ein Beitrag davor schon meine Vermutung geäußert...

Im Changelog zur Version 1.5.9. steht "Fehler im Sammelalarm behoben" - ist damit der Fehler der Alarmtextvervielfältigung gemeint oder was wurde genau geändert?

Mit der Beta 1.5.8 gab es einen Fehler, wodurch der SA gar nicht mehr ging.
Mit deinem Problem hat es nichts zu tun.

Hatte es aber heute auch nochmal getestet. Zwei Alarmierungen. Beide als Alarmtext "Test". Im SA kam als Alarmtext nur einmal "Test" (nicht doppelt).
Bitte wenn möglich mit der beta testen. Wenn es nicht geht, bitte Logs posten oder schicken (DEBUG level).

Gesendet via Mobile App

Zitat:

---

Zitat von firEmergency

...
Hatte es aber heute auch nochmal getestet. Zwei Alarmierungen. Beide als Alarmtext "Test". Im SA kam als Alarmtext nur einmal "Test" (nicht doppelt). ...

---

Meine Posts schon gelesen? Ist mein Gedankengang denn richtig?

So, habe grade mal getestet, hier ein Log auf debug-level mit Textersetzung:

Code:

---

25.10.2013 - 19:00:09.000 INFO  RemoteGUIServer - Führe manuellen Alarm aus
25.10.2013 - 19:00:09.000 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:09.000 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720408953"
25.10.2013 - 19:00:09.000 DEBUG AlarmPool - # Key: "address" with Value: "sammel1"
25.10.2013 - 19:00:09.000 DEBUG AlarmPool - # Key: "message" with Value: "1111111Testsammelalarm"
25.10.2013 - 19:00:09.015 DEBUG AlarmPool - ### Alarm ist Teil eines Sammelalarms
25.10.2013 - 19:00:09.015 INFO  AlarmPool - Neuer eingehender Alarm für "sammel1"
25.10.2013 - 19:00:09.015 INFO  AlarmPool - Alarm ist ein Sammelalarm
25.10.2013 - 19:00:09.015 INFO  AlarmPool - Neuer Sammelalarm eingegangen mit 30000 MilliSekunden Wartezeit gestartet
25.10.2013 - 19:00:09.015 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:00:09.015 WARN  PipelineController - Alarm für sammel1 wird nicht behandelt, da kein zugehöriger Alarmablauf gefunden wurde.
25.10.2013 - 19:00:09.125 DEBUG PipelineController - Server legt sich schlafen!
25.10.2013 - 19:00:14.578 DEBUG GAlertServer - Zu AlarmData hinzu: address - sammel2
25.10.2013 - 19:00:14.593 INFO  RemoteGUIServer - Führe manuellen Alarm aus
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720414578"
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - # Key: "address" with Value: "sammel2"
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - # Key: "message" with Value: "2222222Testsammelalarm"
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - ### Alarm ist Teil eines Sammelalarms
25.10.2013 - 19:00:14.593 INFO  AlarmPool - Neuer eingehender Alarm für "sammel2"
25.10.2013 - 19:00:14.593 INFO  AlarmPool - Alarm ist ein Sammelalarm
25.10.2013 - 19:00:14.593 INFO  AlarmPool - Sammelalarm an bestehenden (SA_sammeltest) hinzugefügt
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:00:14.593 WARN  PipelineController - Alarm für sammel2 wird nicht behandelt, da kein zugehöriger Alarmablauf gefunden wurde.
25.10.2013 - 19:00:14.703 DEBUG PipelineController - Server legt sich schlafen!
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "status" with Value: ""
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720439015"
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "message" with Value: "2222222Testsammelalarm; 1111111Testsammelalarm"
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "function" with Value: ""
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "sammel" with Value: "_sammel2; _sammel1"
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "address" with Value: "SA_sammeltest"
25.10.2013 - 19:00:39.031 INFO  AlarmPool - Neuer eingehender Alarm für "SA_sammeltest"
25.10.2013 - 19:00:39.046 INFO  AlarmPool - Kein Sammelalarm
25.10.2013 - 19:00:39.046 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:00:39.046 DEBUG TextReplacer - Wert nach globaler Ersetzung: Testsammelalarm; Testsammelalarm
25.10.2013 - 19:00:39.046 DEBUG AAOController - Suche nach Alarmstichwort im Feld <message>...
25.10.2013 - 19:00:39.062 INFO  AAOController - Suche nach Stichwort in "Testsammelalarm; Testsammelalarm"
25.10.2013 - 19:00:39.062 DEBUG AAOController - Alarmstichwort-Suche abgeschlossen
25.10.2013 - 19:00:39.062 DEBUG PipelineController - Alarm-ID wird für diesen Alarm nicht erstellt
25.10.2013 - 19:00:39.062 INFO  PipelineController - Pipeline gestartet für SA_sammeltest
25.10.2013 - 19:00:39.062 INFO  Pipeline - Pipeline von Einheit (SA_sammeltest) wurde mit AlarmData () gestartet
25.10.2013 - 19:00:39.078 INFO  PluginController - PluginController mit Plugin prowl.Prowl (Admin0) mit AlarmData ()wurde gestartet
25.10.2013 - 19:00:39.078 DEBUG PluginController - Das GUIElement person-iphone benötigt iphone-Information der Person
25.10.2013 - 19:00:39.078 DEBUG Prowl - Pushdata:
25.10.2013 - 19:00:39.078 DEBUG Prowl - application: sammeltest
25.10.2013 - 19:00:39.078 DEBUG Prowl - event: Einsatzalarmierung
25.10.2013 - 19:00:39.078 DEBUG Prowl - priority: Gering
25.10.2013 - 19:00:39.078 DEBUG Prowl - description: Testsammelalarm; Testsammelalarm
25.10.2013 - 19:00:39.078 DEBUG Prowl - Push für API-Key: xxx
25.10.2013 - 19:00:39.093 DEBUG Prowl - Text: Testsammelalarm; Testsammelalarm
25.10.2013 - 19:00:40.156 INFO  Prowl - Senden an xxx: API call succeeded. 1000 api calls left.
25.10.2013 - 19:00:40.171 DEBUG Prowl - Push erfolgreich!
25.10.2013 - 19:00:40.171 INFO  PluginController - PluginController mit Plugin prowl.Prowl (Admin0) mit AlarmData () nach 1093 ms beendet
25.10.2013 - 19:00:40.218 DEBUG Pipeline - Plugin : Beendet, starte 0 Kinder!
25.10.2013 - 19:00:40.218 DEBUG Pipeline - Erstelle AlarmHistory
25.10.2013 - 19:00:40.218 DEBUG Pipeline - AlarmHistory erfolgreich erstellt. Füge hinzu
25.10.2013 - 19:00:40.218 DEBUG DataManagement - Hinzufügen von AlarmHistory für Admin
25.10.2013 - 19:00:40.218 DEBUG DataManagement - Synchronize Start
25.10.2013 - 19:00:40.218 DEBUG DataManagement - Synchronize Started
25.10.2013 - 19:00:40.218 DEBUG DataManagement - Datum der AlarmHistoryFri Oct 25 00:00:00 CEST 2013
25.10.2013 - 19:00:40.218 DEBUG DataManagement - File einlesen C:\firEmergency\Config\AlarmHistory\History_of_10_25_13.fdb
25.10.2013 - 19:00:40.234 DEBUG DataManagement - History-Count 11
25.10.2013 - 19:00:40.234 DEBUG DataManagement - Existierende AlarmHistory als Backup speichern
25.10.2013 - 19:00:40.234 DEBUG DataManagement - Daten in Datei schreibenC:\firEmergency\Config\AlarmHistory\History_of_10_25_13.fdb
25.10.2013 - 19:00:40.250 DEBUG DataManagement - History erolgreich geschrieben. Backup-Datei löschen
25.10.2013 - 19:00:40.250 DEBUG DataManagement - Synchronize End
25.10.2013 - 19:00:40.250 DEBUG DataManagement - Synchronize Ended
25.10.2013 - 19:00:40.250 DEBUG RemoteGUIServer - Tag zum Speichern: 25.10.2013
25.10.2013 - 19:00:40.250 DEBUG RemoteGUIServer - Speichere Tages-Liste...
25.10.2013 - 19:00:40.250 DEBUG DataManagement - Gewünschte Datei listOfDays.txt
25.10.2013 - 19:00:40.250 DEBUG DataManagement - Speichere Datei: C:\firEmergency\Config\listOfDays.txt
25.10.2013 - 19:00:40.265 DEBUG GStatusController - Neue Alarmierungen sind da
25.10.2013 - 19:00:40.265 DEBUG MainFrame - Aktualisierung der AlarmHistory gestartet
25.10.2013 - 19:00:40.265 DEBUG Launcher - 1 Oberflächen wurden über neue Alarmierungen informiert
25.10.2013 - 19:00:40.265 INFO  Pipeline - Alarmabarbeitung beendet
25.10.2013 - 19:00:40.265 INFO  Pipeline - Pipeline von Einheit (SA_sammeltest) wurde nach 1203 ms beendet. Fehler aufgetreten: Nein
25.10.2013 - 19:00:40.265 DEBUG GStatusController - Neue Alarmierungen sind da
25.10.2013 - 19:00:40.281 DEBUG MainFrame - Überwachung der AlarmHistory läuft bereits
25.10.2013 - 19:00:40.406 DEBUG PipelineController - Server legt sich schlafen!
25.10.2013 - 19:00:43.296 DEBUG DataTable - Hole History für: 1382720439015-SA_sammeltest

---

Der Text wird doppelt in <message> geschrieben obwohl er eigentlich gleich ist. Aber eben erst NACH der Textersetzung.

Und hier ein Sammelalarm ohne Textersetzung:

Code:

---


25.10.2013 - 19:06:13.125 INFO  RemoteGUIServer - Führe manuellen Alarm aus
25.10.2013 - 19:06:13.125 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:13.125 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720773078"
25.10.2013 - 19:06:13.125 DEBUG AlarmPool - # Key: "address" with Value: "sammel1"
25.10.2013 - 19:06:13.125 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"
25.10.2013 - 19:06:13.140 DEBUG AlarmPool - ### Alarm ist Teil eines Sammelalarms
25.10.2013 - 19:06:13.140 INFO  AlarmPool - Neuer eingehender Alarm für "sammel1"
25.10.2013 - 19:06:13.171 INFO  AlarmPool - Alarm ist ein Sammelalarm
25.10.2013 - 19:06:13.171 INFO  AlarmPool - Neuer Sammelalarm eingegangen mit 30000 MilliSekunden Wartezeit gestartet
25.10.2013 - 19:06:13.171 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:06:13.171 WARN  PipelineController - Alarm für sammel1 wird nicht behandelt, da kein zugehöriger Alarmablauf gefunden wurde.
25.10.2013 - 19:06:13.281 DEBUG PipelineController - Server legt sich schlafen!
25.10.2013 - 19:06:16.906 DEBUG GAlertServer - Zu AlarmData hinzu: address - sammel2
25.10.2013 - 19:06:16.921 INFO  RemoteGUIServer - Führe manuellen Alarm aus
25.10.2013 - 19:06:16.921 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:16.921 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720776906"
25.10.2013 - 19:06:16.921 DEBUG AlarmPool - # Key: "address" with Value: "sammel2"
25.10.2013 - 19:06:16.937 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"
25.10.2013 - 19:06:16.937 DEBUG AlarmPool - ### Alarm ist Teil eines Sammelalarms
25.10.2013 - 19:06:16.937 INFO  AlarmPool - Neuer eingehender Alarm für "sammel2"
25.10.2013 - 19:06:16.953 INFO  AlarmPool - Alarm ist ein Sammelalarm
25.10.2013 - 19:06:16.953 INFO  AlarmPool - Sammelalarm an bestehenden (SA_sammeltest) hinzugefügt
25.10.2013 - 19:06:16.953 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:06:17.000 WARN  PipelineController - Alarm für sammel2 wird nicht behandelt, da kein zugehöriger Alarmablauf gefunden wurde.
25.10.2013 - 19:06:17.109 DEBUG PipelineController - Server legt sich schlafen!
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - # Key: "status" with Value: ""
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - # Key: "timestamp" with Value: "1382720803187"
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"
25.10.2013 - 19:06:43.203 DEBUG AlarmPool - # Key: "function" with Value: ""
25.10.2013 - 19:06:43.203 DEBUG AlarmPool - # Key: "sammel" with Value: "_sammel2; _sammel1"
25.10.2013 - 19:06:43.203 DEBUG AlarmPool - # Key: "address" with Value: "SA_sammeltest"
25.10.2013 - 19:06:43.234 INFO  AlarmPool - Neuer eingehender Alarm für "SA_sammeltest"
25.10.2013 - 19:06:43.250 INFO  AlarmPool - Kein Sammelalarm
25.10.2013 - 19:06:43.250 DEBUG AlarmPool - Alarm hinzugefügt und Controller aufgeweckt
25.10.2013 - 19:06:43.281 DEBUG TextReplacer - Wert nach globaler Ersetzung: Testsammelalarm
25.10.2013 - 19:06:43.281 DEBUG AAOController - Suche nach Alarmstichwort im Feld <message>...
25.10.2013 - 19:06:43.281 INFO  AAOController - Suche nach Stichwort in "Testsammelalarm"
25.10.2013 - 19:06:43.296 DEBUG AAOController - Alarmstichwort-Suche abgeschlossen
25.10.2013 - 19:06:43.296 DEBUG PipelineController - Alarm-ID wird für diesen Alarm nicht erstellt
25.10.2013 - 19:06:43.296 INFO  PipelineController - Pipeline gestartet für SA_sammeltest
25.10.2013 - 19:06:43.296 INFO  Pipeline - Pipeline von Einheit (SA_sammeltest) wurde mit AlarmData () gestartet
25.10.2013 - 19:06:43.296 INFO  PluginController - PluginController mit Plugin prowl.Prowl (Admin0) mit AlarmData ()wurde gestartet
25.10.2013 - 19:06:43.296 DEBUG PluginController - Das GUIElement person-iphone benötigt iphone-Information der Person
25.10.2013 - 19:06:43.312 DEBUG Prowl - Pushdata:
25.10.2013 - 19:06:43.312 DEBUG Prowl - application: sammeltest
25.10.2013 - 19:06:43.312 DEBUG Prowl - event: Einsatzalarmierung
25.10.2013 - 19:06:43.312 DEBUG Prowl - priority: Gering
25.10.2013 - 19:06:43.312 DEBUG Prowl - description: Testsammelalarm
25.10.2013 - 19:06:43.328 DEBUG Prowl - Push für API-Key: xxx
25.10.2013 - 19:06:43.328 DEBUG Prowl - Text: Testsammelalarm
25.10.2013 - 19:06:44.656 INFO  Prowl - Senden an xxx: API call succeeded. 1000 api calls left.
25.10.2013 - 19:06:44.656 DEBUG Prowl - Push erfolgreich!
25.10.2013 - 19:06:44.656 INFO  PluginController - PluginController mit Plugin prowl.Prowl (Admin0) mit AlarmData () nach 1360 ms beendet
25.10.2013 - 19:06:44.703 DEBUG Pipeline - Plugin : Beendet, starte 0 Kinder!
25.10.2013 - 19:06:44.703 DEBUG Pipeline - Erstelle AlarmHistory
25.10.2013 - 19:06:44.703 DEBUG Pipeline - AlarmHistory erfolgreich erstellt. Füge hinzu
25.10.2013 - 19:06:44.703 DEBUG DataManagement - Hinzufügen von AlarmHistory für Admin
25.10.2013 - 19:06:44.703 DEBUG DataManagement - Synchronize Start
25.10.2013 - 19:06:44.703 DEBUG DataManagement - Synchronize Started
25.10.2013 - 19:06:44.703 DEBUG DataManagement - Datum der AlarmHistoryFri Oct 25 00:00:00 CEST 2013
25.10.2013 - 19:06:44.703 DEBUG DataManagement - File einlesen C:\firEmergency\Config\AlarmHistory\History_of_10_25_13.fdb
25.10.2013 - 19:06:44.718 DEBUG DataManagement - History-Count 13
25.10.2013 - 19:06:44.718 DEBUG DataManagement - Existierende AlarmHistory als Backup speichern
25.10.2013 - 19:06:44.734 DEBUG DataManagement - Daten in Datei schreibenC:\firEmergency\Config\AlarmHistory\History_of_10_25_13.fdb
25.10.2013 - 19:06:44.734 DEBUG DataManagement - History erolgreich geschrieben. Backup-Datei löschen
25.10.2013 - 19:06:44.734 DEBUG DataManagement - Synchronize End
25.10.2013 - 19:06:44.734 DEBUG DataManagement - Synchronize Ended
25.10.2013 - 19:06:44.734 DEBUG Launcher - 1 Oberflächen wurden über neue Alarmierungen informiert
25.10.2013 - 19:06:44.734 INFO  Pipeline - Alarmabarbeitung beendet
25.10.2013 - 19:06:44.734 INFO  Pipeline - Pipeline von Einheit (SA_sammeltest) wurde nach 1438 ms beendet. Fehler aufgetreten: Nein
25.10.2013 - 19:06:44.750 DEBUG GStatusController - Neue Alarmierungen sind da
25.10.2013 - 19:06:44.750 DEBUG MainFrame - Aktualisierung der AlarmHistory gestartet
25.10.2013 - 19:06:44.921 DEBUG PipelineController - Server legt sich schlafen!

---

Hier ist der Text nur einfach vorhanden da eben nichts durch die Textersetzung ersetzt wird und 2 identische Texte zum Sammelalarm hinzugefügt werden.
Passt also zum Gedankengang von faboi

Eigentlich ist es doch ganz klar. Das ist dein ersten Beispiel:

Zitat:

---

25.10.2013 - 19:00:09.000 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:09.000 DEBUG AlarmPool - # Key: "message" with Value: "1111111Testsammelalarm"
...
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:14.593 DEBUG AlarmPool - # Key: "message" with Value: "2222222Testsammelalarm"
...
>> Jetzt kommt der Sammelalarm
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:00:39.015 DEBUG AlarmPool - # Key: "message" with Value: "2222222Testsammelalarm; 1111111Testsammelalarm"

---

Die eingehenden Texte sind doch alles andere als identisch: "1111111Testsammelalarm"<>"2222222Testsammelalarm" . Aus diesem Grund werden Sie im Sammelalarm beide hinzugefügt und es wird ein Text daraus: "2222222Testsammelalarm; 1111111Testsammelalarm"

Beispiel 2:

Zitat:

---

25.10.2013 - 19:06:13.125 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:13.125 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"
...
25.10.2013 - 19:06:16.921 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:16.937 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"
...
>> Jetzt kommt der Sammelalarm
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - ### Neuer Eingegangener Alarm ###
25.10.2013 - 19:06:43.187 DEBUG AlarmPool - # Key: "message" with Value: "Testsammelalarm"

---

Hier sind beide Texte identisch. Deswegen wird dann zum Sammelalarm der Text nur einmal hinzugefügt.

Und ja:
Die globale Textersetzung findet erst nach (!) dieser ganzen Überprüfung statt.

Zitat:

---

Zitat von firEmergency

...
Und ja:
Die globale Textersetzung findet erst nach (!) dieser ganzen Überprüfung statt.

---

Das ist schade, denn so kann man es nicht mit dem DME-Input benutzen, da hier ja ein eindeutiges Unterscheidungsmerkmal pro Text beinhaltet sein muss.

Zitat:

---

Zitat von firEmergency

Eigentlich ist es doch ganz klar. Das ist dein ersten Beispiel:



Die eingehenden Texte sind doch alles andere als identisch

---

Ja eben. Und genau so kommen sie vom DME-Input Plugin an.

Die große Frage ist: warum ging es früher und jetzt nicht mehr?

Und: gibts irgend eine Möglichkeit die Verdoppelung zu unterbinden?

Wenn es früher ging, war das Glück oder ein Fehler.
So wie es jetzt ist, verhält es sich auf jede Fall richtig.
Das einzige was wir von unserer Seite aus schauen könnten, wäre ob wir die Textersetzung vorziehen könnten.
Da müsste ich aber erst nachschauen ob das geht.

Gesendet via Mobile App

Zitat:

---

Zitat von firEmergency

Wenn es früher ging, war das Glück oder ein Fehler.
So wie es jetzt ist, verhält es sich auf jede Fall richtig.
Das einzige was wir von unserer Seite aus schauen könnten, wäre ob wir die Textersetzung vorziehen könnten.
Da müsste ich aber erst nachschauen ob das geht.

Gesendet via Mobile App

---

ok, danke.
Evtl müssen wir den Umweg über eine separate Auswertung der RIC wählen und den DME nur noch für den Expressalarm-Text verwenden.
Dann kommt der Text nämlich nur noch einmal und es kann sich auch nichts verdoppeln...

Zitat:

---

Zitat von firEmergency

....
Das einzige was wir von unserer Seite aus schauen könnten, wäre ob wir die Textersetzung vorziehen könnten.
Da müsste ich aber erst nachschauen ob das geht.
...

---

Das hört sich gut an... ;-)