Telegram instant messaging TelegramBot - Empfangen und Senden per FHEM

viegener · 30 November 2020, 23:56:11

Zitat von: htschors am 30 November 2020, 21:33:28
Hallo,

ich habe heute bei der Lösungssuche

Code Auswählen Erweitern
attr global dnsServer 8.8.8.8

gesetzt (in der FHEM Kommandozeile eingegeben), muss aber zugeben, dass ich mich da nicht auskenne. Ich Anfang des Jahres zu Vodafone DSL gewechselt. Vielleicht hat sich da vom Router oder Provider etwas geändert. Aber wie gesagt, da sehe ich aktuell nicht wirklich durch.

Dann lösche den Eintrag mal testweise - wie gesagt Dein Problem liegt bei der Netzwerkverbindung zu Telegram und nicht beim Token oder ssl.
Arbeitshypothese: Der DNSServer 8.8.8.8 gibt eine IPv4-Adresse für telegram zurück und Dein Rechner auf dem FHEM läuft hat nur IPv6 oder umgekehrt?

Wenn es ein raspberry ist auf dem FHEM läuft? Lass doch einfach mal ein ping api.telegram.org auf dem Rechner laufen und poste mal was dabei zurückkommt

stera · 02 Dezember 2020, 19:56:26

Zitat von: viegener am 25 November 2020, 22:26:44
@stera: Das verstehe ich nicht - warum machst Du genau das nicht einfach über Favoriten - Du brauchst dazu kein DOIF.

Schau Dir dochmal im Detail die Favoriten an - damit sind nicht nur die Menus möglich sondern auch solche Shortcuts - darin können auch werte verwendet werden.

Zum Beispiel so:

Code Auswählen Erweitern
/test[Test info]=set yourbotname msg @[yourbotname :msgChatId] {( <some perl code> )} ;

Das funktioniert natürlich auch gut. Hatte nun aber schon vor einiger Zeit mit DOIF andere Dinge so geregelt und finde es persönlich etwas übersichtlicher.

htschors · 04 Dezember 2020, 17:22:39

Hallo viegener,

Ja, FHEM läuft bei mir auf dem Raspberry. Ich habe den Eintrag entfernt. Aber es bleibt im state=failed mit der Fehlermeldung

Code Auswählen

PollingLastError: NonBlockingGet: returned api.telegram.org: Das Netzwerk ist nicht erreichbar (101)

Der Ping funktioniert allerdings:

Code Auswählen

64 bytes from 149.154.167.220: icmp_seq=1 ttl=53 time=22.2 ms
64 bytes from 149.154.167.220: icmp_seq=2 ttl=53 time=22.0 ms
64 bytes from 149.154.167.220: icmp_seq=3 ttl=53 time=22.0 ms
64 bytes from 149.154.167.220: icmp_seq=4 ttl=53 time=22.4 ms
64 bytes from 149.154.167.220: icmp_seq=5 ttl=53 time=22.1 ms
64 bytes from 149.154.167.220: icmp_seq=6 ttl=53 time=22.1 ms
64 bytes from 149.154.167.220: icmp_seq=7 ttl=53 time=22.5 ms

Hast du noch Ideen, was ich noch prüfen kann?

viegener · 04 Dezember 2020, 23:23:33

Zitat von: htschors am 04 Dezember 2020, 17:22:39
Hallo viegener,

Ja, FHEM läuft bei mir auf dem Raspberry. Ich habe den Eintrag entfernt. Aber es bleibt im state=failed mit der Fehlermeldung
Code Auswählen Erweitern
PollingLastError: NonBlockingGet: returned api.telegram.org: Das Netzwerk ist nicht erreichbar (101)

Der Ping funktioniert allerdings:

Code Auswählen Erweitern
64 bytes from 149.154.167.220: icmp_seq=1 ttl=53 time=22.2 ms 64 bytes from 149.154.167.220: icmp_seq=2 ttl=53 time=22.0 ms 64 bytes from 149.154.167.220: icmp_seq=3 ttl=53 time=22.0 ms 64 bytes from 149.154.167.220: icmp_seq=4 ttl=53 time=22.4 ms 64 bytes from 149.154.167.220: icmp_seq=5 ttl=53 time=22.1 ms 64 bytes from 149.154.167.220: icmp_seq=6 ttl=53 time=22.1 ms 64 bytes from 149.154.167.220: icmp_seq=7 ttl=53 time=22.5 ms

Hast du noch Ideen, was ich noch prüfen kann?

Ich kann erstmal nur wiederholen, dass es nicht auf ein Problme mit Bot oder SSL deutet. Die Meldung kommt eher auf der Netzwerkebene.

Ein paar weitere Fragen:
- Ist der ping auf dem FHEM-Rechner auf dem telegram nicht geht ausgefürt (auch mit dem fhem benutzer)?
- Hast Du nach dem Löschen des Eintrags FHEM neugestartet

Eine interessante Frage wäre nich, was liefert:

Code Auswählen

{ my $p = `ping -c 3 api.telegram.org`;; return $p }

als FHEM Befehl eingegeben?

htschors · 07 Dezember 2020, 19:57:57

Hallo viegener,

ja, ich denke auch dass das Problem auf Netzwerkebene ist.

Code Auswählen

{ my $p = `ping -c 3 api.telegram.org`;; return $p }
liefert

Code Auswählen

PING api.telegram.org (149.154.167.220) 56(84) bytes of data.
64 bytes from 149.154.167.220: icmp_seq=1 ttl=53 time=21.9 ms
64 bytes from 149.154.167.220: icmp_seq=2 ttl=53 time=22.1 ms
64 bytes from 149.154.167.220: icmp_seq=3 ttl=53 time=21.7 ms

--- api.telegram.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 21.765/21.944/22.114/0.222 ms

Hilft dir/uns das weiter?

Zu deinen anderen beiden Fragen:
- Ist der ping auf dem FHEM-Rechner auf dem telegram nicht geht ausgefürt (auch mit dem fhem benutzer)? Nein, hatte den Nutzer "pi" per SSL Verbindung genommen. Mit deinem perl script als FHEM Befehl siehst du aber auch dass der Ping mit dem FHEM Nutzer auch funktioniert, oder?
- Hast Du nach dem Löschen des Eintrags FHEM neugestartet: Ja, habe ich gemacht. FHEM mit 'shutdown restart' und auch noch mal per SSL 'reboot'.

Woran könnte es noch liegen, wenn der Ping funktioniert?

viegener · 10 Dezember 2020, 21:36:09

Zitat von: htschors am 07 Dezember 2020, 19:57:57
Hallo viegener,

ja, ich denke auch dass das Problem auf Netzwerkebene ist.

Code Auswählen Erweitern
{ my $p = `ping -c 3 api.telegram.org`;; return $p }
liefert
Code Auswählen Erweitern
PING api.telegram.org (149.154.167.220) 56(84) bytes of data. 64 bytes from 149.154.167.220: icmp_seq=1 ttl=53 time=21.9 ms 64 bytes from 149.154.167.220: icmp_seq=2 ttl=53 time=22.1 ms 64 bytes from 149.154.167.220: icmp_seq=3 ttl=53 time=21.7 ms --- api.telegram.org ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 21.765/21.944/22.114/0.222 ms
Hilft dir/uns das weiter?

Zu deinen anderen beiden Fragen:
- Ist der ping auf dem FHEM-Rechner auf dem telegram nicht geht ausgefürt (auch mit dem fhem benutzer)? Nein, hatte den Nutzer "pi" per SSL Verbindung genommen. Mit deinem perl script als FHEM Befehl siehst du aber auch dass der Ping mit dem FHEM Nutzer auch funktioniert, oder?
- Hast Du nach dem Löschen des Eintrags FHEM neugestartet: Ja, habe ich gemacht. FHEM mit 'shutdown restart' und auch noch mal per SSL 'reboot'.

Woran könnte es noch liegen, wenn der Ping funktioniert?

Wenn der ping geht liegt es womöglich irgendwo in perl/fhem auf Deiner Installation. Vielleicht nochmal ein weiterer Versuch:

Was ergibt sich bei folgendem:

Code Auswählen

{ HttpUtils_gethostbyname({timeout=>4}, "api.telegram.org", 1, sub(){my($h,$e,$a)=@_;; Log 1, $e ? "TESTX - ERR:$e": ("TESTX - IP:".ip2str($a)) }) }

Das Ergebnis findet isch im FHEM logfile mit dem Präfix "TESTX"

htschors · 12 Dezember 2020, 11:09:34

Zitat von: viegener am 10 Dezember 2020, 21:36:09
Wenn der ping geht liegt es womöglich irgendwo in perl/fhem auf Deiner Installation. Vielleicht nochmal ein weiterer Versuch:

Was ergibt sich bei folgendem:

Code Auswählen Erweitern
{ HttpUtils_gethostbyname({timeout=>4}, "api.telegram.org", 1, sub(){my($h,$e,$a)=@_;; Log 1, $e ? "TESTX - ERR:$e": ("TESTX - IP:".ip2str($a)) }) }

Das Ergebnis findet isch im FHEM logfile mit dem Präfix "TESTX"

Hallo und danke erst mal für den weiteren Vorschlag. Ich denke wir nähern uns dem Problem?

Ich habe die folgende Ausgabe im Logfile:

Code Auswählen

TESTX - IP:[2001:67c:4e8:f004::9]

Was sagt uns das?

viegener · 13 Dezember 2020, 12:35:54

Zitat von: htschors am 12 Dezember 2020, 11:09:34
Hallo und danke erst mal für den weiteren Vorschlag. Ich denke wir nähern uns dem Problem?

Ich habe die folgende Ausgabe im Logfile:
Code Auswählen Erweitern
TESTX - IP:[2001:67c:4e8:f004::9]

Was sagt uns das?

OK, die Namensauflösung in FHEM bekommt eine IPV6-Adresse zurück (während Linux eine IPv4-Adresse bekommt, die auf erreicht werden kann). Wenn FHEM versucht diese Adresse zu erreichen kommt vermutlich Deine Anfangsmeldung zurück, das passt.

Also müssen wir versuchen FHEM die IPV6-Namensauflösung abzugewöhnen.

Hast Du das attribut: "useInet6" in global auf 1 gesetzt?
Wenn ja - bitte setze es auf 0

htschors · 14 Dezember 2020, 20:25:50

Zitat von: viegener am 13 Dezember 2020, 12:35:54
OK, die Namensauflösung in FHEM bekommt eine IPV6-Adresse zurück (während Linux eine IPv4-Adresse bekommt, die auf erreicht werden kann). Wenn FHEM versucht diese Adresse zu erreichen kommt vermutlich Deine Anfangsmeldung zurück, das passt.

Also müssen wir versuchen FHEM die IPV6-Namensauflösung abzugewöhnen.

Hast Du das attribut: "useInet6" in global auf 1 gesetzt?
Wenn ja - bitte setze es auf 0

Ja, das war es. Ich habe das Attribut auf 0 gesetzt und jetzt kann er die Adresse auflösen. Aber jetzt hab ich den SSL Fehler. Obwohl ich alles aktualisiert habe :/

Code Auswählen

NonBlockingGet: returned <hidden>: Can't connect(2) to https://api.telegram.org:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

viegener · 14 Dezember 2020, 22:33:07

Zitat von: htschors am 14 Dezember 2020, 20:25:50
Ja, das war es. Ich habe das Attribut auf 0 gesetzt und jetzt kann er die Adresse auflösen. Aber jetzt hab ich den SSL Fehler. Obwohl ich alles aktualisiert habe :/
Code Auswählen Erweitern
NonBlockingGet: returned <hidden>: Can't connect(2) to https://api.telegram.org:443: SSL connect attempt failed error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Dann vermute ich es ist nicht alles aktualisiert insbesondere in perl - also müsstest Du nochmal hier im Thread zurückblättern und versuchen selber herauszufinden, wo es vielleicht nicht aktuell ist.

Versuche doch mal alle Schritte im Detail nachzuvollziehen

rcmcronny · 15 Dezember 2020, 07:07:55

@htschors

Was für ein OS ist denn drauf, wenn es kein aktuelles ist, dann wird es daran liegen. Bei nem Linux kannst Du per SSH Shell mal ein lsb_release -a machen, vielleicht weiss man dann ja schon mehr. Ich habe nun nicht alles gelesen, denke aber Du hast nen Pi mit nem alten OS (Debian 8 oder älter sogar ? ).

Wenn das rauskommt, gibts nur 2 Möglichkeiten:

1. Entweder ein Dist Upgrade nach Debian 9 -> dann 10 (VORHER: Backup Image der SDCard ziehen !!!)
2. Ein neues Image auf ne neue SD Card machen und FHEM neu aufbauen aus einem Backup, dann kannste direkt per SDCard tausch testen. Wenn es läuft, kannst Du die alte SDCard für was anderes nutzen. Das hätte den Vorteil, das Du gleich die SDCard mal erneuert hast und natürlich das System mal frisch drauf hast, ohne Altlasten.

Aber schau erstmal nach dem o.g. Befehl.

Ronny

htschors · 15 Dezember 2020, 14:36:47

Zitat von: rcmcronny am 15 Dezember 2020, 07:07:55
@htschors

Was für ein OS ist denn drauf, wenn es kein aktuelles ist, dann wird es daran liegen. Bei nem Linux kannst Du per SSH Shell mal ein lsb_release -a machen, vielleicht weiss man dann ja schon mehr. Ich habe nun nicht alles gelesen, denke aber Du hast nen Pi mit nem alten OS (Debian 8 oder älter sogar ? ).

Wenn das rauskommt, gibts nur 2 Möglichkeiten:

1. Entweder ein Dist Upgrade nach Debian 9 -> dann 10 (VORHER: Backup Image der SDCard ziehen !!!)
2. Ein neues Image auf ne neue SD Card machen und FHEM neu aufbauen aus einem Backup, dann kannste direkt per SDCard tausch testen. Wenn es läuft, kannst Du die alte SDCard für was anderes nutzen. Das hätte den Vorteil, das Du gleich die SDCard mal erneuert hast und natürlich das System mal frisch drauf hast, ohne Altlasten.

Aber schau erstmal nach dem o.g. Befehl.

Ronny

Hallo Ronny,

danke für den Hinweis. Daran liegt es sicherlich. Ich hatte noch ein auf Debian 8 basiertes OS. Ich habe noch einen Raspberry da und habe darauf ein neues FHEM aufgesetzt. Alles problemlos nur leider stürzt mein alter Raspberry - der mit Debian 8 - ab, wenn ich ein Backup mit FHEM anlegen möchte. Die Backup-Datei, welche bis zum Absturz angelegt wurde ist 22 MB groß und scheinbar nicht komplett, da sie sich auf dem neuen Raspberry (mit Debian 10) nicht einspielen lässt.

Das passt nun nicht mehr zu diesem Thread, aber ich wüsste gern, ob ich ein sauberes Backup ohne FHEM (per SSL) machen kann oder ob es eine andere Möglichkeit gibt, in dem der Raspbi nicht abstürzt. Ich habe es mehrmals versucht, immer mit demselben Ergebnis.

VG, Holger

MadMax-FHEM · 15 Dezember 2020, 14:54:34

Wenn du backup startest, wird dir angezeigt mit welchem Befehl das gemacht wird.

Den einfach per ssh auf der Linux-Console ausführen sollte dann ja eigentlich "dasselbe" machen...

Ansonsten reicht wohl:

Code Auswählen


sudo tar -cf /home/pi/Datum_Backup_fhem.tar /opt/fhem/

http://heinz-otto.blogspot.com/2015/12/backup-und-restore-von-fhem.html

EDIT: und halt schauen was du sonst noch brauchst. Z.B. /opt/fhem/.ssh wenn du per ssh als fhem auf andere Systeme "gehst" oder alexa-fhem nutzt oder auch andere Dinge nat.

Gruß, Joachim

htschors · 17 Dezember 2020, 18:30:03

Hallo Joachim,

vielen Dank für den Hinweis. Da es per SSH auf der Linux-Console dasselbe macht resultiert es leider auch im selben Fehlverhalten. ich versuche es aktuell noch mit einer USB-Festplatte. Da bin ich immerhin schon mal bis 661 MB Dateigröße des backups gekommen, aber beim Restore sagt er EOF. Also ist das Backup auch dabei beim Erstellen der Datei abgestürzt. Ich versuche es heute Nacht noch einmal.

Grüße
Holger

Heatseeker · 14 Februar 2021, 10:31:04

Moin,

ich bin von einem RPI auf andere Hardware unter Debian umgestiegen und soweit klappt nun auch alles bis auf eine komische Sache bei Telegram:

Ich kann Nachrichten Senden, aber das Pollen funktioniert nicht. FHEM hängt sich weg ausser ich schallte das "pollingTimeout = 0", also aus.

Wenn ich pollen einschalte bekomme ich:

Code Auswählen

NonBlockingGet: returned <hidden>: empty answer received

ich konnte mit diesem Code nix im Netz finden.
Jemand eine Idee?

Grüße
Heatseeker