DME-Überwachung und Version 1.3.0.1

[Stefans123]

Hallo ich habe ein Super Spannendes Problem...

Ich habe festgestellt das man die Zeit nicht mehr hoch setzten kann...

Ich muß die Zeit auf 15000´ms bekommen...

Ich habe den Wert nun mehrfach versucht zu ändern aber denoch ohne Erfolg...

Hat jemand ne Lösung???

[firEmergency]

Ja, wir haben die Zeit intern auf 600ms gesetzt, weil wir festgestellt haben, es reicht für alle.
Anscheinend nicht.

Der DME-Listener aus Version 1.1 hat diese Beschränkung noch nicht. Als einfach diesen verwenden:
- Datei von 1.1 nach 1.3 kopieren: /files/inputPlugins/DMEInput.jar

[Stefans123]

Ja, wir haben die Zeit intern auf 600ms gesetzt, weil wir festgestellt haben, es reicht für alle.
Anscheinend nicht.

Der DME-Listener aus Version 1.1 hat diese Beschränkung noch nicht. Als einfach diesen verwenden:
- Datei von 1.1 nach 1.3 kopieren: /files/inputPlugins/DMEInput.jar

danke für den tip...

wäre es möglich das ich die zeit intern auf 15000 hoch setzen könnte´. dan hätte ich ja auch den vorteil das ich zwei einheiten auswätren könnte...

[pfeiffer]

Moin moin,

ich bin auch bei 10 Sekunden. Bei Alarmierungen mit vielen RIC und Express-Alarm muss die zeit lieber etwas länger gewählt werden.


Bitte die Möglichkeit zur Einstellung wieder einbauen.

Danke

Carsten

[faboi]

Bin ich auch dabei....

@firEmergency-Team:
Oder ihr verwirklicht mein Vorschlag der "intelligenten" Lösung des Problems, indem Ihr solange wartet bis die doppelte Zeit des Empfangen eines Zeichens (Baudrate) verstrichen ist. Somit muss man nur solange warten, wie das Empfangen des Textes wirklich dauert.
Vorausgesetzt der DME liefert alle Texte aneinander.

@Alle:
Wartet ihr zehn Sekunden, weil die Ric's in diesem Zeitabstand eintrudeln oder weil es so lange dauert, bis die Texte an Firemergency übertragen sind?

[DeLocke]

Wird es eine "Stand-Alone" Version der DME-Überwachung geben und am besten noch lauffähig unter Raspberry Pi :-P

[firEmergency]

Wird es eine "Stand-Alone" Version der DME-Überwachung geben und am besten noch lauffähig unter Raspberry Pi :-P

Stand-Alone:
Meinst du komplett ohne firEmergency, oder nur eine Art "Client-Server" Architektur (DME-Plugin auf Pi schickt Alarm an FE auf einem anderen Server)?
Ersteres kann ich verneinen, zweitere Version wäre möglich, allerdings aus Zeitgründen aktuell eher ungünstig.

Raspberry-Pi:
Also wenn die Java Unterstützung auf dem PI entsprechend läuft, müsste FE eigentlich schon funktionieren. Haben wir aber noch nicht selbst getestet.

[faboi]

@firemergency-Team:
Ich habe ein großes Problem mit dem DME-Listener und mehreren Adressen die gleichzeitig ausgewertet sollen:
Wenn man die Zeit bei ein paar hundert Millisekunden lässt, kommen nur die Hälfte Meldungen an (was auch mehr als verständlich ist) bzw. es gibt dann mehrere "Fetzen" der Alarmierung.
Wenn ich jedoch her geh und wie die meisten hier 4000-10000 ms nutze, damit wirklich alles bei FE ankommt, die Auswertung im Programm Probleme bereitet.
--> Die Auswertung der einzelnen Adressen funktioniert ja mittlerweile!

Es funktioniert jedoch nicht mit dem Alarmtext. Denn je nach dem wie der Melder (Hier:Boss 925, was aber für alle Swissphone-Melder gilt) programmiert ist, gibt er die einzelnen Adressen als:

Adresse als Ton   --> CR+LF Fixtext CR+LF NULL
Adresse als Alpha --> CR+LF 18:24 16.03.13 CR+LF 02B CR+LF Fixtext Alarmtext CR+LF NULL

aus.
Siehe http://www.funkmeldesystem.de/foren/...ad.php?t=54814

Das bedeutet: Bei einem Intervall mit 4000 ms bekommt man als Alarmtext eine riesiger String mit beiden oben genannten Optionen (je nach Konfiguration). Eine Weiterverarbeitung dieses Textes ist nicht sinnvoll. Auch können keine Filter (auch nicht mit Regex) angewendet werden, da der String zu Variabel ist.

Nochmal: Das Aufrufen der einzelnen Adressen zu den "Pipelines" funktioniert.

Ein Lösungsansatz wäre aus meiner Sicht, dass CR LF (\r\n) mit ausgewertet wird und als Trennzeichen fungiert. Hier muss dann aber auch der DME-Listener für jede Auswertung zwischen den Zeichen einen Alarm anlegen. Jetzt wird derzeit ein Alarm angelegt (im Server) jedoch alle Fixtexte (Pipelines) gefunden.

Da dies tiefere Eingriffe in die Funktionsweise des Plugins sind ist es natürlich nicht mehr universell einsetzbar für Übergaben über die serielle Schnittstelle. Daher wäre es m.M. nach am besten hier eine Checkbox für die Swissphone-Interpretation der Daten setzen zu können.

Wenn das umgesetzt wird, wäre das Sahnehäubchen, die Begriffe Port-Listener und FMEListener im Log (oder auch im Plugin) auf DME-Listener gleichzuziehen.

Beispiel:
Die Übergaben sind im angehängten Bild ersichtlich.

Wünschenswert:

- Alarm für GF_Nacht (ohne Text)
- Alarm für Gruppe4 (ohne Text)
- Alarm für Kommandant mit Text, Datum und hier 02B
- Alarm für stv_Kommandant mit Text, Datum und hier 03B
- Alarm für ZF_Nacht (ohne Text)

Wobei das übergebene Datum und die Uhrzeit mit persönlich nicht wichtig ist und es steht per Variable in FE zur Verfügung. Dies filtere ich per Regex raus. Jedoch die 02B bzw. die 03B (Adressenindex und Subric vom Melder) ist wichtig, da ich hier die Einsatzart auswerten kann.

Hoffe das ihr das Problem nachvollziehen könnt.
Würde mich über eine Antwort freuen... ;-)

EDIT:
Habe die Steuerzeichen im zweiten Bild nochmal deutlicher dargestellt. Es kann natürlich auch NULL verwendet werden.

[firEmergency]

Es würde dann aber in deinem Beispiel 5 Alarmierungen (für jeden Linebreak eine) generiert werden. Das wäre in Ordnung, oder?

[faboi]

Ja, nur so ist ja eine gezielte Auswertung bzw. Weiterverarbeitung möglich.
Ich denke so war das Plugin auch ausgelegt, dass pro "Nachricht" per serieller Schnittstelle die Überprüfung der entsprechenden Codes ausgeführt wird und dann die entsprechende Pipeline aufgerufen wird.
Hier ist jetzt der Unterschied, das eben länger die Schnittstelle "gepollt" wird und alles in einer "Nachricht" kommt, was dann auf die oben genannte Weise zerpflückt werden soll.

Mir ist wichtig, dass das Plugin nicht auf meine persönlichen Bedürfnisse angepasst wird, sondern allgemein die Auswertung und eben für mehrere, gleichzeitige Adressen optimiert werden soll. ;-)
Daher wäre es gut, wenn andere ihre Erfahrungen damit hier auch noch teilen würden...

[evos]

Kann zwar nicht so vom lesen alles verstehen, aber wenn es ein beta plugin gibt wäre ich bereit es auch zu testen.da ich so leicht gesagt das gleiche Problem habe.

Gesendet von meinem HTC Desire HD A9191 mit Tapatalk 2

[firEmergency]

Ich hab hier eine geänderte Version des Plugins hochgeladen. Die .jar muss nach /files/inputPlugins/

Anschließend muss das Input-Plugin zurückgesetzt werden. Dann gibt es eine neue Checkbox "NUL als neuen Alarm interpretieren". Dort den Haken setzten.

Bitte berichten, ob es funktioniert, da ich es selbst nicht live testen kann.

ACHTUNG
NUR MIT AKTUELLER BETA 1.3.0.8 AUS DEM SHOP NUTZBAR!!!

[faboi]

Also nach dem ersetzen des jar-Files startet der Server nicht mehr richtig. Er bleibt irgendwann stehen.
Error.log im Anhang

[firEmergency]

Oh. Mist.
Hatte ich ganz vergessen.
Man braucht die heute erschienene Beta dafür (1.3.0.8).
Gibts im Shop
Sorry

[faboi]

Okay, läuft soweit jetzt mal im produktiven Umfeld als Test. Kann leider diese Alarme nur sehr schlecht simulieren.
Vlt. finde ich noch ne Möglichkeit.

Bezgl. der Beta kommt beim Startup:

28.03.2013 - 12:16:33.498 DEBUG SysOutOverSLF4JInitialiser - Your logging framework class ch.qos.logback.classic.Logger should not need access to the standard println methods on the console, so you should not need to register a logging system package.
28.03.2013 - 12:16:33.618 INFO  SysOutOverSLF4J - Replaced standard System.out and System.err PrintStreams with SLF4JPrintStreams
28.03.2013 - 12:16:33.648 INFO  SysOutOverSLF4J - Redirected System.out and System.err to SLF4J for this context

Ist vlt. für euch interessant..