Telegram Messenger - Nachrichten per Shellskript verarbeiten

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Ich hab dein Problem gefunden!
    Du frägst am Anfang mit if ab ob der Sender Joh ist. Ist dies der Fall rutscht das Programm in die Bedingung, da vor den nächsten Abfragen aber ein elif steht werden diese nicht mehr behandelt sofern eine vorherige Bedingung schon erfüllt wurde.
    Du musst also vor die gemeinsame Abrage ein einfaches if setzen, dann könnte es funktionieren. Allerdings wirst du dann zwei Antworten bekommen: "Unbekannter Befehl!" und "Pongelpongelpong..!". Das liegt daran, dass das Programm die erste Bedingung auch erfüllt und die erste Antwort schickt und danach die zweite Bedingung erfüllt wird und die zweite Antwort geschickt wird.
    Lösen kannst du das indem du die gemeinsame Abfrage an den Anfang setzt und dann vor die Einzelabfragen je ein elif setzt.

    Das mit dem "-d" funktioniert außerdem leider nicht.

    LG
    Automatisch zusammengefügt:
    Schon mal vielen Dank für die ausführliche Antwort, aber irgendwo häng ich noch, denn wenn ich nach dem reboot den Status abfrage bekomme ich folgendes Bild:

    :s
    Automatisch zusammengefügt:
    Wenn ich das ganze ohne Port ausführe (benötige ich meines Wissens nicht) dann kommt folgendes Ergebnis:

    Einmal editiert, zuletzt von piro (11. Januar 2017 um 07:58)

  • Telegram Messenger - Nachrichten per Shellskript verarbeiten? Schau mal ob du hier fündig wirst!

  • Ob du den Port brauchst kommt darauf an wie du den Client verwendest. Für den Autostart ist er nicht relevant. In diesem Tutorial wird aber benötigt damit der Telegram Client antworten kann.

    Kanns du den Client so von der Kommandozeile aus starten?

    Code
    /home/pi/tg/bin/telegram-cli -s /home/pi/tg/test3.lua -d -D -E -R -P 54321 -W

    DON'T PANIC!

  • Ich hab das Projekt etwas abgewandelt und auf meine Bedürfnisse angepasst und da brauch ich keinen Port ;)

    Den Client kann ich ganz normal auch mit deinem Befehl von der Kommandozeile aus starten und dann funktioniert alles auch einwandfrei.
    Auch nach
    sudo systemctl start telegram-client.service
    funktioniert alles bestens.

  • Du hast ja sehr viel in Richtung Autostart ausprobiert. Hast du das auch alles wieder rückgängig gemacht? Könnte gut sein dass da noch was dazwischenfunkt.

    Schau auch mal unter /var/log/syslog nach ob da was genaueres steht:

    Code
    sudo cat /var/log/syslog | grep telegram

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (11. Januar 2017 um 16:47)

  • Natürlich hab ich schon viel probiert weil ich ja zum Ziel kommen möchte :shy: aber bis jetzt hat es noch nichts gebracht.

    Ich hab alle Skripte wieder gelöscht bzw verschoben und in rc.local und crontab die Zeilen auskommentiert.
    Wenn ich den genannten Befehl ausführe bekomme ich für jeden Neustart so einen Block:

    Wenn ich das Skript "telegram-client.service" lösche, dann kommt entsprechend kein solcher Block, nach einem reboot, dazu.
    Aber rauslesen kann ich daraus jetzt nicht wirklich viel. :s

  • Nabend...

    ich hab ein ähnliches Problem:

    Bis zu dem Punkt wo Du das script getestet hast bevor du es "enabled" hast, hast bei mir tadellos geklappt...
    Script enabled, sudo reboot, nix telegram... :(

    sudo systemctl -l status telegram-client.service" wirft mir (direkt nach dem neustart) diese Meldung:

    jetzt kommt der Hammer:
    versuche ich es erneut mit "sudo systemctl start telegram-client.service" passiert das:

    Das möge mir doch bitte mal jemand erklären... Startet telegram doch noch zu früh? Fehlt ihm noch etwas was zum Zeitpunkt des starts von Telegram noch nicht durchgeladen war??

    die sudo cat /var/log/syslog | grep telegram schmeisst mir das raus:

    Was da los??

    LG

    Einmal editiert, zuletzt von Tiieto (11. Januar 2017 um 22:09)

  • Das ist ja blöd. Da habt ihr beide ja scheinbar genau das gleiche Problem.
    Ich hätte das nicht gepostet wenn es bei mir nicht so funktionieren würde.

    Hier mal der letzte Teil meiner /var/log/syslog:


    Der beendet sich und startet immer wieder brav. (Der erste Eintrag ist drin weil ich da nochmal was geteset hatte.)

    Um zu testen ob der Client aus irgendeinem Grund nicht doch zu früh gestartet wird könnt ihr den Client ja mal mit einem sleep verzögert starten. So hab ich ihn auch über die /etc/rc.local gestartet bekommen.

    Geht bestimmt auch anders aber ich hab dazu nochmal ein kleines Skript erstellt das nichts weiter macht wie den Client verzögert zu starten:

    Bash
    #!/bin/bash
    
    
    # 2 minuten warten
    sleep 120
    
    
    # telegram client starten
    /home/pi/tg/bin/telegram-cli -s /home/pi/tg/fwd.lua -d -E -R -P 54321 -W

    Das Skript hab ich im telegram Verzeichnis gespeichert
    und ausführbar gemacht:

    Code
    chmod +x /home/pi/tg/start_telegram.sh

    Anschließend die Unit angepasst dass sie nicht mehr den Client direkt startet sondern das Skript:

    Code
    ExecStart=/home/pi/tg/start_telegram.sh

    Dann ein Neustart und wieder mit "sudo systemctl status ..." getestet.

    Achja, Ich hab ganz vergessen dass bisher immer alle Ausgaben auf die Konsole aufgrund des "-D" deaktiviert waren. Hab diesen Parameter im Skript jetzt mal weggelassen und sollte einiges mehr ausgegeben werden über "sudo systemctl status ...".
    Das Ausgaben sollten auch in der /var/log/syslog auftauchen.

    EDIT: Option -d ergänzt.

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (12. Januar 2017 um 09:15)

  • Du startest Telegramm nun nicht mehr als deamon? (startoption "-d" fehlte... )
    Absicht?

    LG
    Automatisch zusammengefügt:
    =(
    Nach sudo reboot & einer ausreichenden Wartezeit von >10 min:

    Einmal editiert, zuletzt von Tiieto (12. Januar 2017 um 09:09)

  • Oh, doch mach ich noch. Das ist wohl irgendwie untergegangen. Gut aufgepasst. Daran sollte der start aber nicht scheitern.

    --
    Gibt's ja nicht :/ Hat er das "sleep" laut "status" nach dem Neustart auch 10 min lang ausgeführt?

    Sieht so aus als hätte er das Skript gar nicht erst gestartet bekommen. Hast du das Skript auch als "pi"(bzw. dem Benutzer unter dem der Client laufen soll) und nicht als root angelegt?

    Code
    ls -la /home/pi/tg/start_telegram.sh 
    -rwxr-xr-x 1 pi pi 175 Jän 11 06:05 /home/pi/tg/start_telegram.sh

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (12. Januar 2017 um 09:26)

  • Öhm, keine Ahnung...

    Ich hab einfach den Raspi rebootet und als er gerade neu gestartet hat ein paar pings via telegram gesendet..
    Wenn alles geklappt hätte, hätte ich nach dem erfolgreichen start von Telegram eine entsprechende Anzahl an "Pongs" bekommen müssen...
    Hatte dann ca 10-15 min was anderes zu tun & erst nach dieser Zeit mein Telefon begutachtet, aber es kam kein Pong...

    LG

  • Also ich hab gerade das mit dem zusätzlichen Skript probiert und es funktioniert! :D :bravo2:
    Es reicht sogar eine Wartezeit von 10 sec aus.
    Vielen Dank dafür! :danke_ATDE:

    Was bei Tiieto noch schief läuft werde ich jetzt noch ein wenig rumprobieren den Fehler nachzustellen, ich geb bescheid sobald ich was gefunden hab. ;)

    Jetzt bleibt mir vorerst nur noch ein Problem, nämlich, dass ich keine Zeilenumbrüche schreiben kann. :s
    Automatisch zusammengefügt:
    Was bekommst du nach dem Befehl

    Code
    grep -i "telegram" /var/log/syslog | tail

    angezigt?

    Einmal editiert, zuletzt von piro (12. Januar 2017 um 16:42)

  • Zeilenumbrüche im gesendeten Text meinst Du??

    Das hab ich gerade eben raus gefunden.. mit "\n"

    Code
    send_text "hier der text \nUnd weiter in der nächsten Zeile..."

    ich glaube das evtl ein Fehler im msg-parser.sh schuld dran sein könnte...
    Das hab ich seid eben auch soweit hingebogen das es so tut wie es soll.. Wenn auch mit kleiner Einschränkung...

    Scripttechnisch funktioniert nun erstmal...
    Was jetzt allerdings nicht klappt ist die Screenshot Funktion...
    da bräuchte ich nochmal hilfe...

    Code
    case $msg in
       "!screenshot")
       export DISPLAY=:0
       scrot -q50 /tmp/screenshot.png
       send_text "send_photo $empf /tmp/screenshot.png"
      ;;

    denke mal das wird an der Funktion "send_text" liegen... die kann ja nur text senden & keine Bilder... - weiss jetzt aber nicht wie ich das umstricken kann / soll / muss...
    Denke mal ne neue Funktion "send_picture" währe da hilfreich... :s

    LG
    Automatisch zusammengefügt:
    Screenshot ist auch gelöst...

    function send_picture hinzugefügt

    Code
    function send_picture() {
    echo "send_photo $user \"$1\"" | $cmd
    }

    und weiter unten im script dann der Aufruf:

    Code
    case $msg in
       "!screenshot")
       export DISPLAY=:0
       scrot -q50 /tmp/screenshot.png
       send_picture "/tmp/screenshot.png"
      ;;
    
    
      esac

    das tut einwandfrei...

    Jetzt quasi "nur" noch das autostartproblem...
    Das versuch ich gleich nochmal.. :D

    LG

    Einmal editiert, zuletzt von Tiieto (12. Januar 2017 um 17:14)

  • Hey Super, dann ist also wikrlich der zu frühe Start das Problem.

    Liegt wohl an dieser Zeile:
    "After=network-online.target"

    Kenn mich damit aber auch viel zu wenig bis gar nicht aus und müsste mich erstmal einlesen und am besten selber testen.
    Beudeutet dass ich euch bei diesem Problem im Moment leider nicht weiterhelfen kann und ihr vorerst auf den Workaround mit dem sleep setzen müsst.
    Ich würd aber sonst einfach mal einen neuen Thread für das Problem mit dem Autostart aufmachen, bin mir fast sicher dass da jemand direkt sagen kann wieso das nicht klappt.

    Zitat

    Öhm, keine Ahnung...


    Prüf das doch mal. Er muss auf jeden Fall das sleep die >10min ausführen.

    Grad das Problem mit dem Screenshot gesehen, gut gemacht. Ich hab im Skript der einfachheit halber nur das send_text() eingebaut. Lässt sich ja wie du gemerkt hast sehr einfach beliebig erweitern. :)


    Und ja, Zeilenumbruch in der Antwort klappt mit einem "\n".

    DON'T PANIC!

  • Dieses

    Code
    "After=network-online.target"

    hört sich so an als müsste er warten bis die Netzwerktreiber geladen sind und das Netzwerk bereit ist..
    Soweit korrekt?

    Wenn ja:
    Wie bekomme ich raus welcher Prozess beim booten als letztes durchgeladen wird?
    Dann könnte man ggf diese Zeile in

    Code
    "After=last_prozess.target"

    umwandeln... Oder? :daumendreh2:

    LG
    Automatisch zusammengefügt:
    Andere Frage:

    Gibt es in der bash eine Zufallsfunktion?
    Ich würde gern bei einem bestimmten Befehl mehrere Antwortmöglichkeiten haben & eine dann per Zufall auswählen & senden...

    LG

    Einmal editiert, zuletzt von Tiieto (12. Januar 2017 um 18:49)

  • Genau, so hatte ich das "network-online.target" auch verstanden.

    Eine von systemd unabhängige Möglichkeit alle laufenden Prozesse seit dem Start anzuzeigen ist "sudo ps aux".

    Mit systemd geht wohl mit: systemd-analyze (nicht selber getestet)
    http://serverfault.com/questions/6173…tree-of-systemd
    https://www.freedesktop.org/software/syste…md-analyze.html

    Also hast du den Autostart per sleep hinbekomen?

    Grad hier noch was interessantes entdeckt:
    https://www.freedesktop.org/wiki/Software/…/NetworkTarget/

    --
    Klar. Google suche nach: "bash zufallszahl"

    DON'T PANIC!

    Einmal editiert, zuletzt von joh.raspi (12. Januar 2017 um 19:07)

  • Hallo

    Probiert doch mal folgendes in der in der Service Unit

    Code
    Requires=network.online.target
    After=network.online.target

    https://wiki.archlinux.org/index.php/Systemd

    Zitat

    [font="sans-serif"]Handling dependencies[/font]
    [font="sans-serif"]With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit A requires the unit B to be running before A is started. In that case add Requires=B and After=B to the [Unit] section of A. If the dependency is optional, add Wants=B and After=B instead. Note that Wants= and Requires= do not imply After=, meaning that if After= is not specified, the two units will be started in parallel. [/font][font="sans-serif"]Dependencies are typically placed on services and not on targets. For example, [/font][font="sans-serif"]network.target is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since [/font]
    [font="sans-serif"]network.target is started anyway.[/font]

    Code
    systemd-analyze plot > something.svg


    Gibt euch in einer schönen Grafik über die Boot Reihenfolge und Zeiten aus.

    Gruß

    Oliver

    Einmal editiert, zuletzt von Steinardo (12. Januar 2017 um 20:24)

  • Durch den tipp von Steinardo und der damit verbundenen Überprüfung des startscriptes hab ich meinen Pi nun soweit, das er telegram automatisch beim hochfahren mitstartet...
    Hatte zusätzlich aber nich nen Fehler im startscript den ich so wohl nicht entdeckt hätte...

    --> pfadangabe zur "start_telegram.sh" war nicht ganz korrekt... Flüchtigkeitsfehler würde ich sagen... :wallbash:

    Nun ja, jetzt tuts ja... :danke_ATDE:

    LG

    Einmal editiert, zuletzt von Tiieto (14. Januar 2017 um 20:47)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!