Druckbare Version
Hi @All,
wir sind seit geraumer Zeit an einem weiteren Update dran.
Bisher sind folgende Features im Plan:
- Ansteuerung von firmergency.
- Blockauswertung (EA) im Client für POCSAG.
Denke das Update wird allerdings noch ein paar Wochen dauern.
Für weitere (sinnvolle) Vorschläge sind wir übrigens jederzeit zu haben ;-)
Gruß,
Jochen
Hi,Zitat:
Zitat von haehnle
Wie wäre es denn mit einer Textersetzung für POCSAG-Alarme? Dann könnte man endlich frei definierbare Texte, für hinterlegt POCSAG-Melder; einsetzen. Bisher bekommt man ja nur den Alarmtext (wenn nicht verschlüsselt) und das Fahrzeug angezeigt (in Statusübersicht). Ich würde halt gern die Alarmtexte (verschlüsselt) durch freie Texte ersetzten. Wäre das evtl. ähnlich machbar wie bei ZVEI-Alarmen? Hinterlegte ZVEI-Alarme werden nur durch einen freien Text und dem dazugehörigem Fahrzeug in der Übersicht signalisiert.
Gruß
Hi,
hmmmmm, also prinzipiell funktioniert das ja schon mit der Textersetzung von POCSAG
Alarmen wie bei ZVEI. Allerdings nur, wenn gar kein Text mit dem POCSAG Alarm gesendet
wird. Und da fängt dann meiner Meinung nach die Problematik auch schon an, denn wenn
da ein Text anbei ist, wie erkenne ich dann ob das ein Klartext ist oder ein verschlüsselter?
Das wird so nicht wirklich programmierbar sein... oder habe ich was falsch verstanden?
Gruß,
Jochen
Hallo,
ich meinte nicht die Textersetzung im Sinne von Texterkennung und Unterdrückung. Das wäre technisch wahrscheinlich gar nicht realisierbar. Ich meinte eher eine Funktion mit der man alle Texte unterdrücken kann, egal ob nun Klartext oder verschlüsselt. Also quasi nur ein ausblenden des Texte, um dafür dann einen Fixtext anzulegen. Im Moment ist es bei POCSAG nur möglich, ganze Melder mit RIC und Text zu unterdrücken. Die RIC an sich dürfte weiterhin angezeigt werden, nur der Text müsste "weg" bzw. zu ersetzen sein. Ich bin mir nicht sicher, ob sowas technisch realisierbar ist. Meine aber, dass es in einem anderen Programm eine Art Textersetzung gibt. Allerdings kann ich über die Funktion keine Aussage geben, da ich mich bisher nicht damit befasst habe.
Aber mir fällt gerade noch etwas ein, was man vielleicht ins Update übernehmen könnten. Und zwar würde ich es ganz praktisch finden, wenn man die Fahrzeugübersicht (wie sie im Client dargestellt wird) auch auf ein extra Fenster als reine Statusübersicht mit einzelnen Feldern übertragen könnten. So könnte man die reine Statusübersicht auf einen zweiten Bildschirm oder Großbildschirm "verbannen".
Gruß,
Oliver
Hi,
also machbar wäre das schon, allerdings finde ich das nicht wirklich so prickelnd.
Was allerdings die Fahrzeugübersicht angeht, so werde ich das mal mit aufnehmen,
dass diese separat in einer Ansicht liegt und aus dem Hauptclient entfernt wird.
D.h. dass der Client noch die Ansicht für "Es Spricht" und "Sprechwunsch", "Dringender
Sprechwunsch" sowie die Telegrammtabelle enthält.
Gibts da Einsprüche gegen??
Gruß,
Jochen
Ich würde gerne beide Versionen weiter nutzen können :)
nicht auf jedem Computer habe ich Platz für zig Fenster und finde eine Anwendung mit mehren Bereichen optimaler.
Dann habe ich immer noch folgende Punkt offen (weiß nicht obs eh in der ToDo ist, oder wieder "rausgefallen" ist):
Das F2 Problem:
http://www.funkmeldesystem.de/foren/...ad.php?t=41979
Die Aussteueranzeigen:
http://www.funkmeldesystem.de/foren/...ad.php?t=42002
Statusfarben im GPS-Client:
http://www.funkmeldesystem.de/foren/...ad.php?t=41991
und dann noch die Feature-Requests:
Aufnahmekanäle:
http://www.funkmeldesystem.de/foren/...ad.php?t=42054
GPS-Koordinaten in Mail:
http://www.funkmeldesystem.de/foren/...ad.php?t=42152
Initialstati:
http://www.funkmeldesystem.de/foren/...385#post384385
Spontan fällt mir noch ein:
Aufnahme als MP3 anstelle WAV um Platz zu sparen (und Datenvolumen ;))
Und dann die Archivierung:
http://www.funkmeldesystem.de/foren/...ad.php?t=42153
mfg
Amok
Wäre toll wenn auch der Client ohne gui unter Linux laufen würde bzw. der Server auch Aktionen bei bestimmtem POCSAG RIC's triggern kann, aktuell kann man zwar den Server laufen lassen, müsste aber nochmal einen Client starten (der ohne gui unter linux nicht läuft) damit man Alarme triggern kann.
Hi,
die Idee ist ja prinzipiell nicht schlecht, aber der Crusader-Client besitzt eben eine
Oberfläche. Diese auszuschalten würde zwar funktionieren, allerdings würde dass dann
eben heisen, dass du keinerlei Änderungen im Client durchführen kannst... außer wenn
du dich mit den Settings-Dateien auskennst.
Deshalb nehme ich davon erst mal Abstand, würde aber jeden unterstützen, der einen
eigenen ui-losen Crusader-Client schreiben will....
Gruß,
Jochen
Ok, gesagt getan, hab einen in perl geschrieben (mit prowl, sms, mysql support und der möglichkeit RIC's zu filtern) der soweit auch klappt, sobald es eine Alpha gibt post ich das hier ;) Aber danke für die Antwort.
Btw. Ist euch evtl. klar warum der FMS Crusader mit einer Java Exception abschmiert wenn (trotz korrekt geschlossenem Socket) der Client beendet wird und dann wieder versucht zu verbinden ? Desweiteren gibt es dann auch keine Initialdaten mehr und es muss der ganze Crusader neu gestartet werden bevor wieder irgendwas über den tcp Socket kommt.
Es sieht für mich anhand der FIN_WAIT states im netstat so aus als ob er nicht bemerkt dass der Socket zu ist und dann beim senden der Message in eine Exception läuft:
netstat:Code:SocketException gefunden
java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
at java.util.Vector.elementAt(Unknown Source)
at de.FMSCrusader.Server.Server.transferTelegram(Server.java:309)
at de.FMSCrusader.Server.TelegramManager$NewTelegramRunnable.run(TelegramManager.java:161)
at de.FMSCrusader.Server.TelegramManager.setNewTelegram(TelegramManager.java:64)
at de.FMSCrusader.Server.Channel.setNewTelegram(Channel.java:2042)
at de.FMSCrusader.Server.Channel.setPOCSAG(Channel.java:2339)
at de.FMSCrusader.Server.Channel.poccreate(Channel.java:2180)
at de.FMSCrusader.Server.Channel.pocsagbuild(Channel.java:2140)
at de.FMSCrusader.Server.Channel.run(Channel.java:191)
at de.FMSCrusader.Server.TelegramCapture$Capture.run(TelegramCapture.java:582)
at java.lang.Thread.run(Unknown Source)
Code:tcp 0 0 127.0.0.1:53360 127.0.0.1:7778 FIN_WAIT2
tcp6 9 0 127.0.0.1:7778 127.0.0.1:53360 CLOSE_WAIT
EDIT: Dann evtl. die Möglichkeit die Ausgaben des Crusaders, wenn man Ihn per -SNF startet in ein Logfile zu schreiben, bzw. Ihn zu "daemonizen". Aktuell lassen sich relativ schlecht init scripte für den Crusader (Smartserver und normal) schreiben.
EDIT2: Ah, und ist es korrekt so, nach dem connect "PASS:kennwort" für die Authentifizierung zu senden ? Ich hab das Verhalten des original Clients mit tcpdump gesnifft, war mir aber auch nicht zu 100% sicher. Aktuell klappt es so, aber nicht das dies die o.g. Probleme verursacht.
Hi,
@amok, feuermelder: dann bleibt das Client Hauptfenster so, aber es gibt auch kein
Sonderfenster für die ganzen Fahrzeuge! Zweimal im Programm verschwendet unnötig
Resourcen.
@jcmerg: Die Passwortsache ist so wie du beschrieben hast. Ausgaben des Servers kannst
du doch kopieren, oder? Bzw. geht > Dateiname.txt nicht? Bezüglich der Exception habe
ich spontan keine Ahnung, allerdings scheint der Server nicht mitzubekommen, dass die
Verbindung geschlossen wurde.
Gruß,
Jochen
Ja, die Ausgaben kann ich STDOUT in ein File umleiten, ich dachte da an einen "echten" daemon ;)Zitat:
Zitat von haehnle
Zu der Connection, evtl. ein cmd CLOSE o.ä.einbauen ? ... ich kann den Fehler reproduzieren, auch mit dem default client sobald der server unter linux läuft.
Hi jcmerg,
also der Fehler tritt auch unter Linux auf, allerdings ja nur, wenn du dein Skript verwendest
anstatt den default Crusader Client oder?
Gruß,
Jochen
PS: Für nen daemon fehlt mir die Zeit, sorry ;-)
Hi,Zitat:
Zitat von haehnle
Fehler tritt auch mit dem Org. Client unter Linux auf.
Hi,
ich schick dir demnächst mal ne Version wo der Fehler im Server gefixt ist zum Testen, ok?
Schick mir ma ne mail bitte, damit ich deine Adresse habe ;-)
Gruß,
Jochen
OK, Danke ;)Zitat:
Zitat von haehnle
Done ...Zitat:
Schick mir ma ne mail bitte, damit ich deine Adresse habe ;-)
Gruß,
Jochen
Hi,
melde mich Mitte nächster Woche, muss noch intensiv testen!
Gruß,
Jochen
Hi,
also bisher ist folgendes erweitert/gefixt worden:
1. Blockauswertung im Client (EA) mit Zeitstempel und RICangabe.
2. Pluginmöglichkeit für Nachrichtenmanipulation (z.B. entschlüsseln).
3. Externer Prozess für Firmergency integriert.
4. Linker/Rechter Kanal getauscht (Bug).
5. F2 Bug in der Haupttabelle gefixt.
So das wars bisher. Werde mich jetzt mal ans Testen machen ;-)
Gruß,
Jochen
Hallo.
Gibt es schon neues bezüglich Erscheinungsdatum des Updates??
Gruß
Tom
Hi Tom,
dauert noch mind. 2 Wochen. Die letzten Tage waren leider mit anderen Themen
gefüllt.
Gruß,
Jochen
Ich möchte als Featurerequest folgendes wieder aufgreifen:
http://www.funkmeldesystem.de/foren/...ad.php?t=29013
Bei uns im Landkreis findet z. B. jeden Sonntag zwischen 11:30 und 11:45 Uhr, sowie jeden ersten Samstag im Monat zwischen 12:00 und 12:30 Uhr ein Probealarm statt (Melder/Sirene). Es ist also nicht so, dass willkürliche Termine gewählt werden sondern nach einem einfachen Schema sich wiederholen. Aktuell müsste ich also (pro Jahr) 64 einzelne Termine in die Liste eintragen. Das ist mir ehrlich gesagt zu aufwendig und wäre für eine leichtere Verwaltung dankbar.
Auch würde ich mir eine Art Kontrollmöglichkeit wünschen. Ich möchte nicht die Stabilität des Programms anzweifeln, nur Vertrauen ist gut, Kontrolle aber besser ;-) Muss ja auch nicht am Programm liegen, sondern kann ja auch mal sein, dass an der Hardware / Scanner what ever was kaputt geht. Oder einfach nur das Audiokabel versehentlich ausgesteckt war (wie es mir neulich passiert ist -.-).
Für mich persönlich (weiß nicht inwiefern andere das Betrifft) würde es reichen, wenn ich z. B. einen externen Prozess vom Probealarm ausnehmen könnte (z. B. für eine Kontroll-Email - oder gibt es sowas schon, und ich habs nur nicht entdeckt?) oder wenn die Tagestabelle (wegen mir auch die letzten 5 Einträge nur) zu einem festgelegten Zeitpunkt per Email verschickt wird. Da sieht man ja dann Anhand der Einträge wann die letzten Auswertungen waren. Wenn sich diese zwei Tage lang wiederholen, weiß man recht schnell, dass da was Faul ist.
Hi zaertl,
was wertest du denn aus? FMS oder POC?
Deine Anregungen sind alle leider nicht wirklich trivial bzw. sehr implementierintensiv
(zB. Intervalle für Probealarm).
Gruß,
Jochen
Danke für die Rückmeldung.
Ich habe schon fast vermutet, dass sich das nicht so leicht umsetzen lässt. Und für mich alleine rentiert sich das wirklich nicht.
Ich werte nur unsere guten alten analoge 5-Ton-Folgen aus.
Servus Jochen
wäre es rein technisch möglich eine Excel-Exportfunktion in der Viewer einzubauen? Wäre da sehr dankbar darum ;)
Gruß
vloppy
Hi Vloppy,
prinzipiell wäre das machbar als csv Datei, die kannst du importieren.
Habs ma notiert.
Gruß,
Jochen
Jop hervorragend!
"2. Pluginmöglichkeit für Nachrichtenmanipulation (z.B. entschlüsseln)."
Moin, was darf man sich da drunter genau vorstlelen ?
Ein Plugin.dll dei eingebunden werden kann bzw vom Crusader bei Start geladen wird?
Ist dann z.b. möglich Nachrichten Text ausblenden zulassen bei der Übergabe an den Bos2Web Agenten 4.0 ? (Da bei uns im Kreis nun bald IDEA Verschlüsselng kommt, ich die verschlüsselten Textr aber nicht im B2W haben möchte, aber die Ric bzw Alarm angezegt werden sollte)
Hi,
genau. Anstatt ner dll ist das halt nen .class file, welches wie in der Anleitung beschrieben
eben definiert sein muss... da wird dann der Text übergeben und du kannst programmatisch
zurückgeben, was du willst... ganz einfach... da werden dann auch die RICs nicht
manipuliert...
Gruß,
Jochen