multimon (der Vorgänger des monitord) auf Raspberry Pi

[Schrolli]

Na dann melde ich mich auch mal kurz aus dem Urlaub ;-)

Wegen den 6 stelligen RICs müsste eben mal geklärt werden, ob das nur führende 0en Betrifft, oder generell 6stellig geht. Da kann man das Vadlidation RegEX ja recht schnell umstricken...

Und zum Web Frontend:
Das wurde mal angefangen zum testen, da jetzt aber derzeit große Änderungen an BOSWatch selbst laufen, lag das erst mal auf Eis. Eine Pocsag Anzeige wurde bisher noch gar nicht im Frontend implementiert.
Aber das wird dann wohl die nächste Baustelle sein, wenn die größten Bugs aus dem Aktuellen Dev Stand raus sind.

Grüße aus Prag - Basti

[Smith]

Hey,

Wegen den 6 stelligen RICs müsste eben mal geklärt werden, ob das nur führende 0en Betrifft, oder generell 6stellig geht. Da kann man das Vadlidation RegEX ja recht schnell umstricken...

RICs müssen definitv 7-Stellig sein, wie JHC schon schrieb. Das einzige was auftreten kann, sind führende Nullen.
Die ersten 3 Stellen sind zur Identifizierung des LK in der BRD, soweit ich weiß.
Also muss der RegEx dementsprechend angepasst werden. Ich hab da aber ehrlich gesagt nicht dran gedacht.... :)

@JHC:
Es sieht so aus als wäre es auch so das Multimon die führende Null rauswirft. Es muss also auch die Plausibilitätskontrolle (ric==7) angepasst werden oder es schreibt wer einen Pull-Req. an Elias :)

Grüße aus Prag - Basti

Grüße aus den Niederlanden! :-)

[JHC]

Moin Smith,

Es sieht so aus als wäre es auch so das Multimon die führende Null rauswirft. Es muss also auch die Plausibilitätskontrolle (ric==7) angepasst werden oder es schreibt wer einen Pull-Req. an Elias

Ich habe im Quellcode von multimon-ng keinen Abschnitt gefunden, der dafür sorgt, dass eine führende Null ausgegeben wird. Ich habe nur Längenprüfungen 1-7 gesehen und die Ausgabeformatierung auf 7 Zeichen Platz, rechtsbündig. Das passt soweit zum geposteten Bild mit " 123456". Entweder Dekodierungsfehler oder der RIC war wirklich 0123456 und multimon-ng lässt irgendwo in der Typkonventierng die null fallen.
Ich habe es mir mal erlaubt Elias eine eMail zu schreiben, mal schauen ob er darauf reagiert.

Grüße
Jens

PS: Leider habe ich keine offiziellen RIC-Struktur-Dokumente gefunden, die das vorgeben...

[Smith]

Ich habe im Quellcode von multimon-ng keinen Abschnitt gefunden, der dafür sorgt, dass eine führende Null ausgegeben wird. Ich habe nur Längenprüfungen 1-7 gesehen und die Ausgabeformatierung auf 7 Zeichen Platz, rechtsbündig. Das passt soweit zum geposteten Bild mit " 123456". Entweder Dekodierungsfehler oder der RIC war wirklich 0123456 und multimon-ng lässt irgendwo in der Typkonventierng die null fallen.

Ich gehe davon aus, das dies der Fall ist. Ich habe mir zwar den Quelltext nicht angeschaut, aber es wird so sein.

Die RIC wird dann von boswatch aktuell nicht mehr aufgefüllt. Ich hatte das damals so geschrieben.

.replace(" ", "").zfill(7)

Ich denke damit sollte der Fehler dann behoben sein.
Mit der Filterung der Range, welche dann nach diesem Schritt ausgeführt wird, sollte dann auch Fehldekodierungen nicht mehr vorhanden sein.
Eingang -> RIC auf 7 Stellen -> RIC in Range? -> weitere Ausführung.

Ich habe es mir mal erlaubt Elias eine eMail zu schreiben, mal schauen ob er darauf reagiert.

Bin gespannt, was er dazu sagt. :-)

PS: Leider habe ich keine offiziellen RIC-Struktur-Dokumente gefunden, die das vorgeben...

Naja, offizielle Doku kenne ich auch nicht. Aber schonmal einen DME mit 6 Stellen versucht zu programmieren? Lässt das Programm nicht zu :-)

[JHC]

Hi Smith,

Die RIC wird dann von boswatch aktuell nicht mehr aufgefüllt. Ich hatte das damals so geschrieben.

.replace(" ", "").zfill(7)

Ich denke damit sollte der Fehler dann behoben sein.

Ich sehe das nicht als "Fehler" in BOSWatch, wenn RICs eigentlich 7-Stellig sind sollte. Eigentlich dürfte BOSWatch die RIC nur von links beginnend auffüllen, ein Leerzeichen rechts von der Zahl oder zwischen den Ziffern wäre ein echter Fehler.

Naja, offizielle Doku kenne ich auch nicht. Aber schonmal einen DME mit 6 Stellen versucht zu programmieren? Lässt das Programm nicht zu :-)

Da wir hier nur RICs > 1xxxxxxx haben, hat sich mir das Problem mit 0xxxxxx noch nicht gestellt.

Grüße
Jens

[Smith]

Ich denke du weißt was ich meine.
das zfill ist schon der passende Weg um eine von multimon nicht übergebene führende Null wieder hinzu zufügen.
Damit sollten wir auch für Landkreise in denen es mit 00 beginnt gewapnet sein. Auch wenn es nur 9 sein können ;)
Ich wollte auch nur darauf hinaus, das ich damals in meinem Script und in der ersten Phase von BosWatch aus diesem Grund das zfill eingesetzt habe.

Und damit wäre dann das "Problem", welches kein Fehler ist, erledigt :-)

[Schrolli]

Ich denke du weißt was ich meine.
das zfill ist schon der passende Weg um eine von multimon nicht übergebene führende Null wieder hinzu zufügen.
Damit sollten wir auch für Landkreise in denen es mit 00 beginnt gewapnet sein. Auch wenn es nur 9 sein können ;)
Ich wollte auch nur darauf hinaus, das ich damals in meinem Script und in der ersten Phase von BosWatch aus diesem Grund das zfill eingesetzt habe.

Und damit wäre dann das "Problem", welches kein Fehler ist, erledigt :-)

Falls ich das damals entfernt/nicht übernommen habe tuts mir leid. Habe das vermutlich als Unnütz angenommen, da sowas ja eigentlich nicht vorkommen kann/darf ^^
Aber ist ja schnell wieder eingebaut...

Grüße

[JHC]

Moin, moin,

das "multimon-ng"-Problem mit den RICs habe ich gefixed.
Sollte jetzt wieder funktionieren.

Weiterhin habe ich
- das firEmergency-Plugin von Smith
- und ein eMail-Plugin
dem develop-Branch hinzugefügt.

Grüße
Jens

[Schrolli]

Super... :-)

Wenn jemand das mal noch kurz testen könnte? Oder ist schon alles auf den ersten Blick Bugfrei? Dann würde ich am Wochenende endlich mal wieder in den Master mergen :-)

"noch" Grüße aus Prag ^^

[joki]

Hallo zusammen,
kam die letzten Tage leider nicht zum testen, heute hab ich die aktuelle Boswatch mal mit install.sh drübergebügelt.

Leider laufen bei mir immer noch die Fehler mit den 6-stelligen Rics auf :-(
Dachte da wäre dran gearbeitet/gelöst worden, oder war das nur im Developer-Branch.

Gruß Jörg

[JHC]

Hallo Jörg,

Habe eben nochmal im Repository nachgeschaut, der Bug ist dort behoben.
Hat er bei Dir nicht den aktuellen Code gezogen?
Oder das Problem ist noch etwas ganz anderes.

Bitte schicke mir mal das log als pm.

Grüße
Jens

[joki]

Hallo zusammen,
es funktioniert alles wunderbar, die Emailfunktion, die Auschlussliste, die Description-Liste, das einzige was im Moment noch nicht so super funktioniert ist die Unterdrückung der Wiederholungen, aber evtl. muss ich da nur mal die Zeit ein wenig hochsetzen.
Ansonsten: super!
Dankeschön.

[JHC]

Moin, moin,

die BOSWatch Version im develop-Zweig kann jetzt auch als Dienst ausgeführt werden.
Installation muss manuell erfolgen, die Beschreibung findet ihr in service/README.md

Gerne testen und Fehler melden.

Grüße,
Jens

[Schrolli]

Aktuell steuern wir auf ein Release 2.0 zu
Letzte kleine Fehler werden noch behoben, und dann wird nochmal eine Runde getestet.

Grüße

[joki]

Hallo zusammen,
ich habe da ein Problem mit dem versenden von Emails, d.h. es wird nur an die erste Adresse in der Zeile verschickt, ich habe schon diverse Alternativen ausprobiert, allerdings ohne Erfolg.

Das hab ich bisher gemacht:

1. to = user@irgendwo, user2@woanders
2. to = user@irgendwo,user2@woanders
3. to = user@irgendwo; user2@woanders
4. to = user@irgendwo;user2@woanders

der erste user@irgendwo bekommt die Email, alles was dahinter steht wird ignoriert :-(

Jemand ne Idee dazu?

Gruß Jörg