-
-
Notifications
You must be signed in to change notification settings - Fork 24
Telegram-Plugin Refactor #134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
6b54965 to
80c6c76
Compare
|
Servus, Hinsichtlich des soft limits von Telegram (ca. 30 Nachrichten pro Gruppe) und um da keinen Alarm zu übersehen habe ich eine Warteschlange eingefügt. Ansonsten verzicht auf eine externe Abhängigkeit Würde dann #107 lösen. Hab das Plugin bei mir auf meinem Pi am laufen und funktioniert zumindest mit ZVEI soweit. Allerdings habe ich noch keine "Maximallastsituation" gehabt wie z.B. bei Probealarmen, wo die Warteschleife sicher greifen muss. Schaut mal bitte, wie es euch so gefällt. Basiert auch auf @janspeller seiner Variante damals (Koordinatenhandling etc). |
22bda44 to
d141b68
Compare
|
inzwischen hab ich mal eine Überlast-Situation erreicht. Im Log steht dann: DATUM UHRZEIT - Thread-1 (_worker_loop) telegram _send_to_telegram [WARNING ] Rate Limit erreicht – warte 19 Sekunden. |
476a488 to
5455685
Compare
|
@KoenigMjr Testest du hier noch, oder bist du inzwischen der Meinung das ist stabil so wie es jetzt ist? |
|
Für mich ist es stabil! Läuft seit ein paar Wochen ohne Probleme, allerdings nur mit ZVEI und ohne die Koordinaten. |
Durch Einbau einer Warteschlange kein Datenverlust bei belegter API (Sendelimit ca. 30 Nachrichten/min, gibt aber Soft-Limit) Exponentielles Backoff mit Maximalgrenze Retry-Zähler mit Abbruch bei zu vielen Fehlversuchen Kein Wiederholen bei permanenten Fehlern (400/401) dynamische Zeitanpassung bei 429 Fehlern Fehlerrobustheit verbessert hinsichtlich Connection Error neues Plugin ohne telegram-bot * Timeout (timeout=10), * HTTP-Fehlerprüfung (raise_for_status()), * Retry-Logik (3 Versuche mit wachsender Wartezeit), * Sauberem Logging mit logger statt print). send_location aus altem Skript übernommen und angepasst
update zur neuen Telegram Version *in Konfiguration hinzugefügt:* Startup_message max_retries initial_delay max_delay *gelöscht:* queue *im Beispiel:* Startup_message hinzugefügt
5455685 to
523329a
Compare
|
@janspeller hast du die Möglichkeit, das irgendwie zu testen? |
Schrolli91
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - @KoenigMjr bisher alles stabil bei dir? Dann merge ich ...
|
ja, läuft bei mir gut und durchgängig ohne Probleme :) |
Neue Features
Die externe Abhängigkeit python-telegram-bot wurde entfernt. Stattdessen erfolgt die Kommunikation mit der Telegram Bot API direkt über requests.
Eingebaute Wiederholungslogik bei temporären Fehlern (z. B. Netzwerkprobleme oder Rate Limits).
Unterstützt retry_after-Werte von Telegram.
Ein Worker-Thread verarbeitet eine Nachrichtenwarteschlange, um nicht-blockierend mehrere Nachrichten zu senden.
Unterstützt sendLocation analog zu bisherigen Funktionalitäten.
Konfigurierbare Parameter
Entfernt
Änderungen an Plugin-Struktur