Telegram instant messaging TelegramBot - Empfangen und Senden per FHEM

Begonnen von viegener, 20 Juni 2015, 18:59:41

Vorheriges Thema - Nächstes Thema

jmike

Danke für eure Antworten.

Zitat von: MadMax-FHEM am 15 September 2019, 11:45:35
...Dort einfach deinen Router/Gateway/... eintragen.

Das Attribut dnsServer hatte ich nicht gesetzt. War mir auch nicht bewusst, dass das einen Einfluss auf nonblocking hat.
Hat aber leider nicht geholfen. Die Ursache sieht mir auch eher nach SSL handshake aus.


Zitat von: viegener am 15 September 2019, 11:59:06
... Das Symptom habe ich auch auf meiner Installation - Bei mir manchmal jede Stunde...

- Polling steht auf 20 Sekunden
- FHEM, TelegramBot Modul, httpUtils ist aktuell
- auch Net::SSLeay, IO::Socket::SSL, LWP::UserAgent und LWP::Protocol::https
- fork bzw. memory Probleme habe ich keine

Frage:  sind es bei Dir auch 44 Sekunden delay? Auch mit dem gleichen SSL Fehler?

Ich habe noch 2 weitere FHEM Instanzen im Zugriff, eine davon zeigt den gleichen Fehler:
Readings:
2019-09-15 12:16:31   PollingLastError NonBlockingGet: returned <hidden>: Can't connect(2) to https://api.telegram.org:443:  SSL wants a read first


Ist aber eine komplett andere Installation. Also OS, FHEM, TelegramBot, SSL-* usw.



Danke euch!

DS_Starter

Hallo zusammen,

seit kurzem, vielleicht 2-3 Tagen habe ich das schon von jmike beschriebene Problem dass FHEM minutenlang einfriert und dann


2019.09.16 19:51:11.492 4: HttpUtils: <hidden>: Can't connect(2) to https://api.telegram.org:443:  SSL wants a read first
2019.09.16 19:51:11.492 5: TelegramBot_Callback teleBot: called from Polling
2019.09.16 19:51:11.492 5: TelegramBot_Callback teleBot: polling returned result? <undef>


bringt. Ich habe 3 Instanzen, 2 davon laufen mit teleBot und genau bei diesen zeigt sich das Problem. Ist aber erst seit kurzem. Bin mir natürlich nicht sicher ob es Ursache oder Wirkung ist.
Jetzt habe ich mal das Polling auf einer der beiden abgeschaltet, ich versende ohnehin nur. Mal sehen ob es einen Unterschied macht.

Cannot fork habe ich nicht, zumindest nicht in dem relevanten Zeitraum. Der Speicherverbrauch ist auch mit 600 M moderat.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Frank_Huber

Jetzt wo ich das lese...
Ich wundere mch auch seit paar Tagen dass fhem gefühlt 1x am Tag  für paar Minuten einfriert.
Hab es noch nicht genauer untersucht. Aber hab auf jeder Instanz den TelegramBot...

Gesendet von meinem S60 mit Tapatalk


DS_Starter

Der Dienst schein momentan ziemliche Probleme zu haben:


2019-09-16 21:12:32 PollingErrCount 57
2019-09-16 21:12:32 PollingLastError NonBlockingGet timed out on read from <hidden> after 605s


Der Pollingtimeout steht auf 180s. Bisher war mit dieser Einstellung PollingErrCount meist "0"
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Frank_Huber

Bestätigt :
PollingErrCount

16

2019-09-16 21:15:47

PollingLastError

NonBlockingGet: returned api.telegram.org: Die Wartezeit f�r die Verbindung ist abgelaufen (110)

2019-09-16 21:15:47



Gesendet von meinem S60 mit Tapatalk


DS_Starter

Eben ist die Instanz mit dem noch laufenden Polling wieder für 6 Minuten ausgestiegen.

Wieder kam die Meldung:

2019.09.16 22:31:45.913 4: HttpUtils: : Can't connect(2) to https://api.telegram.org:443: SSL wants a read first
2019.09.16 22:31:45.913 5: TelegramBot_Callback teleBot: called from Polling
2019.09.16 22:31:45.913 5: TelegramBot_Callback teleBot: polling returned result?

Die Instanz ohne Polling läuft unbeeindruckt weiter. Wenn das so bleibt wäre die Ursache meiner Meinung nach gefunden.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Ma_Bo

Dieses Problem hatte ich vor ca. 3 Monaten schon, ich habe auch sehr lange gesucht, bis ich dahinter kam, dass es mit dem TelegramBot zu tun hat...

Zu dem Zeitpunkt hatte ich dann keine weitere Zeit, der Sache genauer auf den Grund zu gehen und habe das Polling auf 0 gestellt, seitdem ist Ruhe, nutze auch nur das versenden von FHEM aus...
Ich hatte vermutet, dass es evtl mit meiner Internetanbindung zu tun hatte, da dort in letzter Zeit auch Probleme waren...

Grüße Marcel
NUC mit FHEM, HM Heizungsthermostate, HM Wandthermostate, Intertechno Funksteckdosen, 10" Tablet als Wanddisplay, KeyMatic, Fensterkontakte, Fensterkontakte umgebaut als Wassermelder und Briefkastenmelder, Aussenthermostat, Anwesenheitssteuerung über Fritz Box, Google Home usw. usw.

DS_Starter

Kurze Rückmeldung. In der Nacht ist die Instanz mit TeleBot Polling wieder mehrfach mit der schon beschriebenen Fehlermeldung hängengeblieben. Freezemon hat diese Mitteilung brav protokolliert.
Die andere Instanz ohne Telegram-Polling ist sauber durchgelaufen. Habe nun auch auf der ersteren Instanz das Polling abgeschaltet, aber die Ursache scheint eindeutig zu sein.

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

jmike

Bei mir tritt es erst seit dem 1.9 auf, wie ist es bei euch?
Ich tippe auf ein oder mehrere Server im Telegram Backend, die ein Problem haben. Je nachdem wo der request landet schlägt es fehlt oder funktioniert.

@viegener, hast du eine Idee warum der Aufruf trotz NonBlockingGet "blockierend"  ist?

Habe mal den botsupport angeschrieben, mal schauen was die sagen.
In der publicgroup zum botTalk war leider nichts zu finden.

Lg

jmike

... könnte sein, dass ich eine Lösung gefunden habe.

Wäre super wenn noch weitere Leute testen könnten und in der FHEM/HttpUtils.pm auf Zeile 500 folgendes einfügen:

$par{SSL_hostname} = '';
(in der Zeile vor "$par{SSL_verify_mode} = 0")

Damit wird in den SSL Optionen der Hostname nicht gesetzt.
Hab das Polling wieder aktiv und seit dem keinen Fehler mehr gesehen.

lg


DS_Starter

Habe die Zeile bei mir auch mal eingefügt und beobachte das Ganze nun wieder mit eingeschalteten Polling auf einer Instanz.
Mal schauen was passiert ...

PS: auch die Instanz auf der ich heute früh das Polling ausgeschaltet habe, ist nun sauber durchgelaufen.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

andies

Zitat von: jmike am 17 September 2019, 14:26:48
Wäre super wenn noch weitere Leute testen könnten und in der FHEM/HttpUtils.pm auf Zeile 500 folgendes einfügen:
Muss man das irgendwie reloaden oder so?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

MadMax-FHEM

Zitat von: andies am 17 September 2019, 20:25:08
Muss man das irgendwie reloaden oder so?

Jep.

Oder shutdown restart von fhem...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

DS_Starter

Moin,

bei mir lief die Instanz mit dem gepatchten HttpUtils die Nacht sauber durch.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

jmike

Bei mir und deren anderen Instanz ist seit der Änderung auch kein Fehler mehr aufgetreten.
Werde das Phänomen noch mal reproduzieren um sicher zu sein.

Eine finale Lösung ist das übrigens nicht. Die Server Name Indication wäre schon gut zu nutzen, abgesehen davon möchte ich meine httpUtils nicht vom repository ,,trennen".
Eventuell gibts einen Weg per config das im TelegramBot Modul (oder sogar Device) zu deaktivieren, nur für die Telegram Domains.

Andernfalls wird hieraus ein Feature request für die httpUtils.

Seitens telegram support gab es leider noch keine Info.

Und ja, ein fhem restart ist nötig, hatte ich vergessen zu erwähnen.