Seite 12 von 21 ErsteErste 123456789101112131415161718192021 LetzteLetzte
Ergebnis 166 bis 180 von 301

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

  1. #166
    Registriert seit
    01.10.2011
    Beiträge
    94
    okay. Ich baue es nachher für den Rest auch ein. Hast ja recht.

    Zum start-Script: aktuell lasse ich hier beim Reboot das Script inkl. Aufruf über die rc.local ausführen. läuft quasi direkt nach dem init.
    wenn ich es noch schaffe heute, baue ich das start-Script. Allerdings werde ich mir nicht die Arbeit machen und die Argument-Übergabe einbauen. Es kann dann jeder seine BOSWatch Zeile einfügen und dann einfach mit ./boswatch.sh start etc. Zum laufen bringen. ;-)

    Was aber heute noch kommt ist die Funktion im py Script welche die -p Übergabe ermöglicht.
    Geändert von Smith (17.05.2015 um 09:33 Uhr) Grund: Option -p

  2. #167
    Registriert seit
    18.03.2015
    Beiträge
    67
    Zitat Zitat von Smith Beitrag anzeigen
    Was aber heute noch kommt ist die Funktion im py Script welche die -p Übergabe ermöglicht.
    Ist doch schon drin? 'boswatch.py -e PPM' gibt den Error in PPM an...

    Code:
    -e ERROR, --error ERROR   |   Frequency-Error of your Device in PPM

    EDIT:
    BTW... Sobald Smith seine getesteten Änderungen eingebaut hat, werde ich beginnen den Code zu strukturieren. Also trennen in einzelne Dateien. Denn so langsam wird es unübersichtlich und der Code wiederholt sich eh ständig, wieso also nicht Funktionen erstellen die immer genutzt werden...
    Am sinnvollsten wäre es wohl, das ganze als eine Art Plugin System aufzubauen.
    Geändert von Schrolli (17.05.2015 um 11:29 Uhr)

  3. #168
    Registriert seit
    03.03.2015
    Beiträge
    45
    Moin, moin,

    Zitat Zitat von Smith Beitrag anzeigen
    okay. Ich baue es nachher für den Rest auch ein. Hast ja recht.
    So war das jetzt auch nicht gemeint. ;-)
    Ich meinte, dass es nur so einen BosMon-Eingang gibt, so dass man nicht mehrere Konfigurationen (ini) für die verschiedenen Dienste benötigt. (Annahme: keine verschiedenen BosMon-Server)

    Testen kann ich allerdings nur POCSAG, die anderen Dienste nutze ich hier nicht.

    Zitat Zitat von Schrolli
    Als trennen in einzelne Dateien. Denn so langsam wird es unübersichtlich und der Code wiederholt sich eh ständig, wieso also nicht Funktionen erstellen die immer genutzt werden...
    Das klingt gut. Für den BosMon-Teil sind -wie bereits erwähnt - die Aufruf-Parameter je Dienst allerdings unterschiedlich. Entweder die Parameter einzelnd oder das params-Objekt übergeben.

    Zitat Zitat von Smith Beitrag anzeigen
    Zum start-Script: aktuell lasse ich hier beim Reboot das Script inkl. Aufruf über die rc.local ausführen. läuft quasi direkt nach dem init.
    Hast Du mal ein Bsp? Dann würde ich das bei mir auch mal einbauen...

    Zitat Zitat von Smith Beitrag anzeigen
    wenn ich es noch schaffe heute, baue ich das start-Script. Allerdings werde ich mir nicht die Arbeit machen und die Argument-Übergabe einbauen. Es kann dann jeder seine BOSWatch Zeile einfügen und dann einfach mit ./boswatch.sh start etc. Zum laufen bringen. ;-)
    Anpassungen wären für mich okay, spätestens den Pfad zum Verzeichnis muss auch jeder angeben (oder das install-Skript mit erledigen).

    Grüße
    Jens

  4. #169
    Registriert seit
    01.10.2011
    Beiträge
    94
    Zitat Zitat von Schrolli Beitrag anzeigen
    Ist doch schon drin? 'boswatch.py -e PPM' gibt den Error in PPM an...

    Code:
    -e ERROR, --error ERROR   |   Frequency-Error of your Device in PPM
    ja, als ich mir die Kommandos nochmal angeschaut habe viel es mir auch auf.
    Ich bin mit dem -e von boswatch und -p vom sdr durcheinander gekommen zwischen den Fahrten hier... :-)

    Und wie ich bereits per PN schrieb, ich bin auch für das auslagern in einzelene Dateien. ;)
    der Import eines Modules Verzeichnis ist ja in Py ohne weiteres möglich.
    Die Routine dazu schreibst dann du :-D

  5. #170
    Registriert seit
    18.03.2015
    Beiträge
    67
    Zitat Zitat von Smith Beitrag anzeigen
    ja, als ich mir die Kommandos nochmal angeschaut habe viel es mir auch auf.
    Ich bin mit dem -e von boswatch und -p vom sdr durcheinander gekommen zwischen den Fahrten hier... :-)

    Und wie ich bereits per PN schrieb, ich bin auch für das auslagern in einzelene Dateien. ;)
    der Import eines Modules Verzeichnis ist ja in Py ohne weiteres möglich.
    Die Routine dazu schreibst dann du :-D
    Augen auf im "Verkehr" ;-)

    Und zum auslagern... NA TOLL xD muss ich mich mal einlesen.. aber wird schon :-D :-)

    BTW falls es jmd interssiert, ich komm grade vom Feuerwehr Fest und nein, heute bin ich nicht mehr in der Lage was zu "coden" :-D

  6. #171
    Registriert seit
    03.03.2015
    Beiträge
    45
    Hallo Basti,

    Zitat Zitat von Schrolli Beitrag anzeigen
    Und zum auslagern... NA TOLL xD muss ich mich mal einlesen.. aber wird schon :-D :-)
    So als alter Softwareentwickler würde ich sagen: Erst in Funktionen auslagern, dann darüber Gedanken machen, wie man die Funktionen in eigene Dateien auslagert. ;)

    Grüße
    Jens

  7. #172
    Registriert seit
    18.03.2015
    Beiträge
    67
    Zitat Zitat von JHC Beitrag anzeigen
    Hallo Basti,


    So als alter Softwareentwickler würde ich sagen: Erst in Funktionen auslagern, dann darüber Gedanken machen, wie man die Funktionen in eigene Dateien auslagert. ;)

    Grüße
    Jens
    Also ich als "alter Software Entwickler" würde da sagen:
    Python bietet ne Top Möglichkeit Code auszulagern in Module und Pakete, und die per Import einzubinden. Man müsste nur eine Daten Schnittstelle definieren...

  8. #173
    Registriert seit
    01.10.2011
    Beiträge
    94
    Und ich als Anfänger sage:
    globale Funktionen benötigen dann klar definierte vari. für Datenein- und -ausgang.
    nicht mehr poc_id und zvei_id sondern id. ;)

  9. #174
    Registriert seit
    18.03.2015
    Beiträge
    67
    Zitat Zitat von Smith Beitrag anzeigen
    Und ich als Anfänger sage:
    globale Funktionen benötigen dann klar definierte vari. für Datenein- und -ausgang.
    nicht mehr poc_id und zvei_id sondern id. ;)
    Jupp, genau das meinte ich mit der definierten Schnittstelle...
    Wenn ein Alarm ausgelöst wird, muss ein definierter Datensatz an die Module übergeben werden. Und jedes Modul macht dann dementsprechend was es eben machen soll (jenachdem ob FMS ZVEI oder POC).

  10. #175
    Registriert seit
    01.10.2011
    Beiträge
    94
    naja, was ist immer gleich?
    typ = POC1200, FMS, ZVEI
    id = RIC, ZVEI-Code, FMS-Code
    data = poc_text, ZVEI-Festtext (z.B.: Alarm), FMS-Status
    sub_id = poc_sub, ZVEI-Festtext (0), FMS-Festtext (0)
    time = klar oder?

    Wenn wir alle Ausgaben in diese 5 vars bringen sind wir denke ich durch?
    Es muss ja nicht alles dann von den Modulen genutzt werden.
    Aber ausgeben seitens der Decoder-Routine sollte man alles.
    Entsprechend jetzt kann dann jedes Modul schauen ob was für ihn was dabei ist und es verarbeiten.
    Oder denke ich falsch?

    Edit:
    das gefällt mir eigentlich immer mehr. Wenn wir für den Ordner "module" quasi ein wildcard import und diese feste Datenstruktur einbauen, dann kann einfach jeder mal eben ein Modul bauen und veröffentlichen.
    Und das Pflegen der Daten ist noch einfacher, ich muss für POC1200, 512, FMS, etc. alles mehrfach ändern. Bei der Modulversion reicht es einmal. Solange ich definiere, dass ich es für den jeweiligen Typ ausführen will (im Modul halt)...
    Außerdem wäre das Error-Management sinniger, ich kann beim try/ex. auch direkt die Fehlermeldung generieren und weiß welcher Bereich gerade aus den Fugen springt. Sei es mySQL (okay, zeigt er jetzt auch an) oder mein firEmergency-Block oder was auch immer.
    Geändert von Smith (17.05.2015 um 23:43 Uhr)

  11. #176
    Registriert seit
    18.03.2015
    Beiträge
    67
    Genau da will ich hin Smith.
    Es soll vorallem so laufen, das die Daten einfach rausgehauen werden. Und zwar wie du sagtest "Wildcard" an alle. Man muss also um ein neues Modul zu nutzen nix am Hauptcode ändern müssen, sondern einfach in den Module Ordner sein neues Modul reinkopieren.

    Natürlich muss man wie du schon begonnen hast, eine Daten Schnittstelle fest definieren und diese dokumentieren. und schon wird es zum Kinderspiel alle möglichen Module zu nutzen.

    Die boswatch.py soll im Prinzip nur die Daten annehmen. Auf Plausibilität checken, double check bzw alles was eben vorher zum filtern Sinn macht und dann einfach an die Module verteilen. Was die dann damit machen, Wayne ;-)

    Nur wie man die Daten sauber an beliebig viele Module verteilt ... ?
    Geändert von Schrolli (18.05.2015 um 08:49 Uhr)

  12. #177
    Registriert seit
    03.03.2015
    Beiträge
    45
    Wollt Ihr wirklich den Aufwand treiben und das so generisch bauen?

    In Funktionen/Module auslagern ist das eine, das ganze auch noch generisch....
    Da muss man dann Helfermethoden haben...

    Ich glaube bei Bedarf den if-Zweif in der Hauptdatei zu erweitern ist da einfacher.
    Muss sich dann aber auf wenig Code beschränken:
    Code:
    if useMethode: #hier evtl. sogar den get.config-Aufruf, wenn einmalig
       doMethode(typ, id, sub, msg)
    Geändert von JHC (18.05.2015 um 09:10 Uhr)

  13. #178
    Registriert seit
    18.03.2015
    Beiträge
    67
    steh ich auf dem Schlauch, oder liese sich das ganz simpelst so umsetzen?
    https://lkubuntu.wordpress.com/2012/...on-plugin-api/

    Und im Prinzip immer an die run() Funktion den definierten Satz an Argumenten übergeben...

  14. #179
    Registriert seit
    03.03.2015
    Beiträge
    45
    Ja,klingt so...

    Das Programm führt aber immer alle Plugins aus.
    Eine Konfigurationsmöglichkeit müsste man noch einbauen.

  15. #180
    Registriert seit
    18.03.2015
    Beiträge
    67
    Zitat Zitat von JHC Beitrag anzeigen
    Ja,klingt so...

    Das Programm führt aber immer alle Plugins aus.
    Eine Konfigurationsmöglichkeit müsste man noch einbauen.
    Für die config der einzelnen Plugins kann man das dann auch fest in die Python Datei am Anfang als constanten einbauen. Da sollte man den Aufwand eines Config Parsers evtl vermeiden. Keep it simple ;-) Und da kann man ja dann auch angeben, ob das Modul überhaupt aktiv sein soll. Das bisschen Rechenaufwand zum "sinnlosen" Einbinden des Moduls sollte kein Problem sein.

    Oder man legt nur die config sowie andere Initialisierungen in die __init__.py und macht dann für den eigentlichen Modul Code eine Datei die importiert wird. Man muss die Einstigesdatei ja nicht zwingend __init__.py nennen - siehe pluginloader.py da kann mans ja angeben

    Schaut mal in den Dev-Branch / plugin_test
    pluginloader.py enthält die Funktionen zum load/reload der Plugins
    und die plugin_test.py ruft jede sekunde die Plugins auf.

    das schöne an imp.load_module ist, dass schon geladene Module einfach nur neu geladen werden. Also äquivalent zu reload(). man könnte die Plugins also während Boswatch läuft verändern. Die werden bei jedem Aufruf sowieso nachgeladen :-)
    Geändert von Schrolli (18.05.2015 um 10:15 Uhr)

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •