Closed Schrolli91 closed 8 years ago
wäre dabei... was muss ich tun und was gilt es zu beachten?
Statt den Master-Branch zu ziehen, einfach den Develop Zweig nehmen, BOSWatch installieren und bissl testen ob irgendwas nicht funktioniert wie es sollte ;-)
ok. Dev-Version ist gezogen. Welche Dateien ersetze ich sinnvollerweise zum testen? Reicht es, die BOSWatch.py zu ersetzen oder gibt es auch Änderungen in anderen Dateien? Was hat sich geändert? Gibt es neue Funktionen/Argumente? Ich hätte 2-3 Ideen, die evtl mit einfließen könnten. Es wäre schön, wenn man als Ric-Filter eine csv-Datei angeben könnte. So hält man die die config.ini etwas übersichtlicher. Ich muss tatsächliche einzelne RICS angeben und kann nicht den Start- und Endbereichfilter nutzen. Zudem wäre eine Option schön, dass bei einer leeren Message die Plugins nicht aufgerufen werden. Ich filtere derzeit leere Messages über eine PHP. Schöne wäre es, wenn bei leerer Nachricht gar nicht erst das Plugin gestartet wird. Das ganze läuft bei vielen sicher auf nem Raspberry Pi und eine Schwachstelle sind viele Schreibzugriffe auf die SD. Ich habe momentan die Logfiles daher in den RAM ausgelagert. Vielleicht könnte man noch eine Log-Option machen, dass wirklich nur die Ereignisse geloggt werden, wo auch eine Aktion erfolgte (Plugin gestartet). Meine Logfiles laufen derzeit richtig voll mit "RIC XXXXXXX is not in the allowed list".
Um die Dev-Version sinnvoll zu testen sollte BOSWatch komplett neu aufgesetzt werden, da sich extrem viel geändert hat. Das meiste sollte in der Readme stehen. Die muss unter Umständen auch noch etwas erweitert werden.
Über weitere Ideen können wir später reden, ich würde einfach gerne den Aktuellen Stand soweit stable bekommen.
Btw: Loglevel kann in der config eingestellt werden ;-)
Hallo Schrolli,
ich teste seit ca. 10 Tagen die Develop (POCSAG, mit MySQL Plugin) und kann keine Fehler aufzeigen. Alles läuft flüssig und konstant. :)
Ich habe allerdings ein paar Ideen und hoffe, dass hier wer / evtl. Du (auch, wenn Du wohl gerade viel mit der Ausbildung zu tun hast) helfen kann.
@ThomasF88 Sicher das es der DEV-Branch ist? Über die install.sh bekommt man die Dateien vom Master-Branch. Prüfen kann man das z.B. in der config.ini. Dort muss es Einträge zum NMA Plugin geben. Außerdem ist der DEV-Branch nicht einfach so lauffähig, weil es dort einen Bug gibt, da sich ein Dateiname und der Ort geändert hat.
Ich habe dazu ein Issue geschrieben.
@GonzoBS danke für den Hinweis auf den Bug - habe dein Issue #85 bereits gefixt :-)
Der aktuelle Dev Branch sollte sich zumindest mit diesem Befehl direkt ziehen lassen git clone -b develop https://github.com/Schrolli91/BOSWatch.git
Falls jemand Lust hat, kann er die install.sh
so umbauen, das man wählen kann, ob man die aktuelle Stable, oder die Entwicklerversion laden möchte und das ganze als Pull Request senden. Dann kann auch der dev-Branch mit allen Abhängigkeiten sauber installiert werden.
EDIT:
Ich hab jetzt ganz spontan einfach eine zweite install Datei angelegt, welche den Dev-Branch direkt zieht und installiert. install_dev.sh
Moin!
Ist es denn richtig das wenn ich als Loglevel DEBUG einstelle, in der Shell Ausgabe keine DEBUG Meldungen erscheinen? Die DEBUG Meldungen sehe ich nur in der log-Datei. Das ist im Master noch anders gewesen.
nutze zum starten einfach -v
oder --verbose
um Boswatch etwas komunikativer zu gestalten :smiley: Dann werden alle Ausgaben die ins Logfile geschrieben werden, parallel in die Shell geschireben
Das erste was mir aufgefallen ist: Du hast im Gegensatz zum Master keinen Default-Wert für den Gain angegeben; ich musste etwas suchen, da ewig keine Meldung rein kam ;-) Weiteres teste ich in den nächsten Tagen.
Ich war mal mutig und habe den Dev-Branch als Produktivsystem eingesetzt - inkl Plugins mySQL, E-Mail und JSON-Socket inkl raw-out. Rückmeldungen kommen im Fehlerfall.
@flothi super Danke Ich strebe nämlich dringend ein Release des aktuellen Dev Branch an, da, falls Probleme im aktuellen Master auftreten, quasi nichts mehr gefixt werden kann, da es schon viel zu viele Änderungen gab. Ein Release möchte ich aber auch erst machen wenn das ganze einigermaßen stabil läuft...
@Schrolli91 Ich habe leider nen miserablen 4m-Empfang hier, sodass ich die Funktionalität nicht testen kann - ich probiere mal diverse Antennen etc durch
Sooo - Feedback:
Stabil scheint die Sache zu laufen, die Alarmierungen werden zuverlässig erkannt und dekodiert.
Verwunderlich: Die Umsetzung der E-Mail-Variablen, v.a. der Uhrzeit - anscheinend zieht Python sich irgendwo UTC her, obwohl gemäß date
die richtige Zeit eingestellt ist.
alles klar - danke fürs testen... Das mit der Uhrzeit schau ich mir dann nochmal fix an, woran das liegen kann
Ich vermute einen fehlender Parameter in includes/helper/timeHandler.py - da wars mir aber zu früh noch weiter zu schauen ;-)
Hab in der timeHandler ne Änderung vorgenommen, die hat bei Angabe eines Timestamps diesen tatsächlich bezogen auf UTC umgerechnet.
Bitte nochmal testen jetzt
@Schrolli91 Uhrzeit ist wirkungsvoll gefixt, jetzt schauts gut aus
Super, danke fürs feedback
Nach 7 Tagen Dauerbetrieb und geschätzten 80° hier unterm Dach klappts immer noch einwandfrei - für die POCSAG-Front des Dev-Branch würde ich die Freigabe mitzeichnen ;-)
wenn POCSAG geht, dann sollte FMS und ZVEI auch gehen, da ja im Prinzip die Decoder nicht verändert wurden seit damals.... Und ab den Plugins ist es eh einheitliches Datenformat.... nur das statt ner RIC eben n ZVEI Code drin steht.... Dann strebe ich jetzt mal einfach für nächste Woche n Release an
Hallo zusammen,
falls jemand Lust hat, den aktuellen Dev-Branch ein bisschen auf Herz und Nieren zu testen, würde ich mich über Feedback und Berichte über evtl. auftauchende Probleme freuen.
Wenn das ganze nämlich soweit stabil läuft, würde ich das ganze gerne offiziell in den Master übernehmen.