Hallo,
wir haben einen digitalen FME der uns via serieller Verbindung die Alarmmeldung übertragen könnte.
Ist es vorgesehen solch einen Alarmeingang umzusetzen?
Grüße,
Tobias
Hi Tobias,
das klingt interessant! Fällt die Alarmmeldung einfach im Klartext aus der seriellen Schnittstelle oder braucht man eine Software vom Hersteller, um da ranzukommen?
Die Alarmmeldung muss dann wahrscheinlich noch in Stichwort, Adresse usw. zerlegt werden, aber das sollte ja machbar sein.
Viele Grüße,
Andreas
Hallo Andreas,
wir hängen direkt an der seriellen Schnittstelle, d.h. die Alarmmeldung kommt im Klartext rein und müsste dann nach entsprechenden Trennzeichen geparsed werden.
Für die serielle Schnittstelle müsste Baudrate etc. einstellbar sein.
Ist so etwas möglich?
Das ist auf jeden Fall machbar.
Einen Mechanismus zur Textzerlegung gibt es grundsätzlich schon, zur Verarbeitung der Alarmfaxe. Das kann hier dann einfach wiederverwendet werden. Könntest du mir die Ausgabe der seriellen Schnittstelle – um die sensiblen Angaben bereinigt – zukommen lassen?
Interessant wird es dann bei der seriellen Schnittstelle. Bisher ist vieles darauf ausgelegt, auf einem Raspberry Pi oder zumindest auf Linux zu laufen. Wäre das bei euch auch der Fall oder arbeitet ihr mit Windows? Nur damit ich weiß, was ich primär testen bzw. dokumentieren muss.
Bzgl. des Hostsystem sind wir flexibel. Aktuell laufen Windows-Maschinen da wir noch eine weitere SW betreiben.
Gerne kann ich einen Raspberry aufsetzen, vermutlich dann mit USB-to-Serial Adapter. Wenn das System allerdings auf einem Windows-PC laufen würde, wäre es für einen schnellen Test besser.
Ich versuche die Ausgabe mal aufzuzeichnen. Bei unserer Einsatzhäufigkeit kann es aber sein, dass es einige Tage/Wochen dauert…
Gibt es bereits ein Konzept zum Einlesen von seriellen Texten?
Falls nein, könnte man überlegen, ob man (evtl mit einem externen Tool) den seriellen Input in eine Datei schreiben lässt und die Datei dann über eure Texterkennung laufen lässt. Könnt ihr auch direkt Textdateien parsen?
Dann könnte ich mich selber um das Parsen der Texte kümmern.
Das Einlesen von einer seriellen Schnittstelle müsste erst eingebaut werden. Wenn du die Möglichkeit hast, die Ausgabe selbst abzufangen, zu verarbeiten und weiterzuleiten wäre das im Zweifel die schnellere Lösung.
Bisher werden in der Überwachung von Ordnern auf neue Dateien nur PDFs berücksichtigt. Grundsätzlich kann man das auch auf Textdateien ausweiten, dann stellt sich aber immer noch die Frage nach der Zerlegung des Texts. Im Moment gibt es nur die Möglichkeit, aus mitgelieferten Textzerlegungen auszuwählen. Das Format eines Alarmfaxes betrifft ja immer gleich ganze Städte und Landkreise, da sollen alle gleichermaßen von Anpassungen profitieren.
Wenn du mit APIs und JSON hantieren kannst / willst, könntest du auch einfach einen Einsatz anlegen und die Felder selbst ausfüllen. Nachdem die Doku an der Stelle noch nicht vollständig ist, kann ich dir hier gerne noch weitere Details liefern, wenn das eine Option für dich ist.
Hallo,
das einlesen der seriellen Schnittstelle mit Node.js habe ich hin bekommen. Wenn du mir noch verraten könntest welche Felder ist befüllen muss (z.B. Alarmstichwort, Einsatzort etc) dann würde ich ein node.js skript schreiben, welches das alles schon parst und aufbereitet. Du müsstest das dann nur noch in euer System übernehmen.
Leider verstehe ich zuwenig von Feathers. und euerem Projekt so dass ich das nicht selber hin bekomme.
Grüße,
Tobias
Klasse! Also ein Einsatz könnte folgendermaßen aussehen:
let incidentData = {
"reason": "Straße überschwemmt", // Einsatzgrund bzw. Schlagwort
"keyword": "THL 2", // Stichwort
"description": "Wasserrohrbruch im Kreuzungsbereich", // Freitext der Leitstelle
"location": {
"rawText": "Musterstadt, Einbahnstraße 5 a" // Adresse als Freitext
}
}
Keines der Felder oben ist ein Pflichtfeld und kann leer oder weggelassen werden, falls es dazu keine Angabe gibt. Es gäbe auch noch mehr Felder, aber die sind entweder aktuell nicht wichtig, oder sie werden mit Standardwerten gefüllt. So wird z. B. als Alarmzeit (time) die aktuelle Uhrzeit angenommen.
Bekommst du auch den ausgelösten RIC zu sehen?
Leider nein. Der Melder ist auf einen eigenen „Informations-RIC“ programmiert. Dieser wird von der Leitstelle nur bei echtem Alarm mit alarmiert (also nicht bei Problealarm oder ähnlichen).
Ich versuche mich gerade in euer Projekt und Node.js einzuarbeiten. Als C-Entwickler ein riesen Spass! 
Ah okay, aber das passt ja auch. Zur Not müsste man das eben zeitbasiert unterscheiden, eine Funktion die für die analogen Melder eh noch eingebaut werden muss.
Das glaube ich 
Wenn dir irgendwo Doku fehlt, sag gerne Bescheid. Ich werde gleich mal noch die READMEs vom Hub aktualisieren, wie man eine Entwicklungsversion ans Laufen bekommt.
Ja, eine Doku wäre super!
Wie gesagt ich werde die nächste Alarmierung aufzeichnen. Ich hoffe dann einen eindeutigen Delimitter zu finden um das parsen zu vereinfachen. Sonst müsste man tatsächlich mit timeouts arbeiten.
So, ich habe mal die READMEs von Hub und Display etwas aufgemöbelt. Also vor allem die in den Unterordnern für server, console usw.
Und es gibt natürlich auch noch https://docs.alarmdisplay.org/
Die Seite kriegt demnächst auch mal ein Update, das bezieht sich alles noch auf die letzt veröffentlichte Beta-Version. Deshalb möchte ich da jetzt bald eine neue schnüren und auch die Docker-Images veröffentlichen, dann passt das wieder zusammen.
Ich habe jetzt mal einen Service zum Auslesen der seriellen Konsole angelegt. Das klappt auch schon ganz gut.
Ich habe jetzt nur ein Problem mit der Datenbank.
Aktuell hat die Tabelle ‚hub_textanalysis‘ einen Fremdschlüssel auf die watchedFolderID in der Tabelle „hub_watched_folders“.
Jetzt musste ich eine neue Tabelle für die Konfiguration der seriellen Ports anlegen. Diese müsste ich jetzt auch über die ID auf die Textanalysenkonfiguration in der Tabelle ‚hub_textanalysis‘ damit ich weiß welche Textanalysekonfiguration ich für den Pagereingang her nehmen muss.
Hast du eine Idee wie man das umsetzen könnte?
Ah, ja so ein ähnliches Problem hatte ich neulich auch, bzw. habe dann gleich versucht, es zu vermeiden. Da ging es um die Druckaufträge für neue Dateien (Tabelle hub_print_tasks).
Da es später auch andere Quellen für Druckaufträge geben soll, gibt es jetzt keine feste Bindung an die watchedFolderId, sondern stattdessen zwei Spalten: event und sourceId. Das event bezeichnet das Ereignis, das den Druckauftrag auslöst (bisher nur ‚found_file‘) und sourceId die ID der Instanz, die das Event auslöst (für ‚found_file‘ die ID eines überwachten Ordners). Dadurch wird das ganze etwas entkoppelter.
Auf dieses Schema sollte die textanalysis-Tabelle auch noch umgestellt werden, um weitere Quellen zu ermöglichen. Ich hatte da primär Emails im Sinn, aber hierfür passt das natürlich auch schon.
OK, verstanden. Dann versuche ich das so einzubauen…
Das wäre super. Und wenn’s wo hakt, gerne fragen.
Noch ein Tipp: Die Skripte für die DB-Migration wurden bei mir im Entwicklungsmodus (npm run dev) immer ignoriert. Mein Workaround war da, die Anwendung einmal zu bauen (npm run compile) und aus dem lib-Ordner zu starten.
Das funktioniert schon ganz gut. Ich habe alles umgestellt und das Anlegen eines Einsatze aus dem seriellen Monitor funktioniert auch schon.
Jetzt fehlt mir tatsächlich nur doch ein Log unseres Pagers damit ich die Texterkennung einstellen kann. Wir hatten zwar zwischenzeitlich schon Einsätze aber irgendwie kam am Pager nix raus. Da bin ich gerade mit der Leitstelle dran. Ich hoffe bis Freitag ist das Problem gelöst.
Dann müssten wir noch die console überarbeiten damit man den pager auch konfigurieren kann.
Soll ich dir meine Änderungen bzgl. serieller Eingang schon mal als PullRequest schicken? Dann könntest du vorab schonmal checken und Feedback geben…
Coole Sache 
Ich habe jetzt erst mal nur wegen der Datenbank draufgeschaut und kommentiert, über den Rest lese ich später noch drüber.
Ich bin dann schon mal gespannt auf die Pager-Ausgabe. Ich glaube, dass die Textanalyse noch ein Mini-Update braucht, um direkt ab dem ersten Zeichen Angaben extrahieren zu können. Bisher wird immer erst nach dem Beginn der ersten section gesucht, und alles davor weggeworfen. Für das Alarmfax ist das sinnvoll, hier wohl eher nicht. Aber das sollte kein Drama sein, und das kann ich schon mal vorbereiten.
Folgendes Problem:
Obwohl ich alle Referenzen zu watchedFolderID in der textanalysis entfernt habe bekomme ich noch folgende Fehlermeldung:
[2021-04-01T07:39:22.524] [ERROR] default - Unhandled Rejection at: Promise Promise {
GeneralError: Unknown column ‚watchedFolderId‘ in ‚field list‘
at new GeneralError (C:\Users\tobiby\source\repos\hub\server\node_modules@feathersjs\errors\lib\index.js:177:17)
at exports.errorHandler (C:\Users\tobiby\source\repos\hub\server\node_modules\feathers-sequelize\lib\utils.js:29:20)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at Object.onNewSerialAlarm (C:\Users\tobiby\source\repos\hub\server\src\services\textanalysis\textanalysis.class.ts:31:30) {
type: ‚FeathersError‘,
Gibt es noch einen versteckten Index oder ähnliches wo er sich noch die „alten“ Spalten der Tabelle merkt?