LBS19000303 - Telegram Contact I LBS19000304 - Telegram Receiver I LBS19000645 - Telegram Command Validator

[nektar]

Beobachte seit ein paar Tagen das mein Arbeitsspeicher voll läuft. Ein Reset des Bausteines 19000303 ändert nichts. Nur ein Stoppen des LBS leert den Arbeitsspeicher.
Habe vor kurzen auf 0.6 geupdatet. Kann es damit zusammenhängen?

[ChrisP]

ja den telegram receiver meinte ich... egal jetzt klappts ja wieder

[jonofe]

nach dem reset funktioniert es wieder. danke! kann es am update der lbs liegen?

Update welcher LBS?

Des Telegram Receivers? Eigentlich nicht, denn die Struktur der DB hat sich nicht geändert. Da aber diese DB wohl auch im RAM liegt, ist natürlich ein harter Reboot auch ein Problem.

[ChrisP]

nach dem reset funktioniert es wieder. danke! kann es am update der lbs liegen?

[jonofe]

Kann an einer korrupten Telegram MySQL DB liegen. Dafür gibt es der Reset Eingang E7 beim Telegram Receiver. Sende mal eine 2 auf diesen Eingang, dann wird die DB gelöscht und neu aufgesetzt. Danach sollte es eigentlich funktionieren.

Außerdem solltest du dir mal den Telegram Command Validator (19000645) anschauen... Damit kann man die Validierung von eingehenden Telegramnachrichten vereinfachen.

[ChrisP]

Ich habe vor einiger Zeit einen ersten Test mit dem Telegram Receiver gemacht welcher auch einwandfrei funktionierte.
Gestern wollte ich diesen wieder verwenden was in einer Endlosschleife endete.

Folgendes soll passieren:
Wenn das Wort "BEWEGUNG" einlangt soll ein KO auf 1 geschalten werden (funktioniert) und eine bestätigungsnachricht gesendet werden. Diese wird allerdings unendlich oft gesendet.

Ich muss jetzt nicht einmal mehr etwas an den Bot schicken. Soblad ich die Logik aktiviere geht die Spammerei auch shcon los

[jp2008]

Steht doch in der Hilfe:

Habe ich wohl übersehen bzw. erst jetzt den Bedarf gesehen. DANKE für die schnelle Hilfe!

[jonofe]

Wie sendest du die Icons? Meine Versuche waren bisher nicht erfolgreich...

Steht doch in der Hilfe:

You can use the Bytes (UTF-8) representations of emojis.
For a complete list, see here: http://apps.timwhitlock.info/emoji/tables/unicode

Auf den Link klicken und einfach die Einträge aus der "Bytes (UTF8)" Spalte verwenden.

Screenshot from 2017-05-16 18-12-26.png

[jp2008]

Die "fehlende" Benachrichtigung kann auch gewünscht sein - ich werde es bei meinem Briefkasten jetzt mal damit probieren und dann bei erfolgter Leerung keine gesonderte Benachrichtigung bekommen...

Anbei ein kleines Beispiel.

Wie sendest du die Icons? Meine Versuche waren bisher nicht erfolgreich...

[MrIcemanLE]

Im Update des Telegram Contact LBS v0.8 können nun Textnachrichten geupdated werden.

Vielen Dank für die Umsetzung. Der Chatverlauf sieht jetzt übersichtlicher aus. Anbei ein kleines Beispiel. Einziger Nachteil ist die fehlende Benachrichtigung bei einem Update.

Update.jpg

[jonofe]

Im Update des Telegram Contact LBS v0.8 können nun Textnachrichten geupdated werden. Alle anderen Medien werden für ein Update derzeit nicht unterstützt. Lediglich die Caption (Überschrift) von anderen Medien könnte geupdated werden. Dies ist aber noch nicht implementiert. Wenn es dafür einen Use Case gibt, dann bitte um Feedback.

Das Update von Textnachrichten funktioniert via E4 wie folgt:

1. Textnachricht senden: Text auf E4 geben

2. Textnachricht mit Message-ID XYZ updaten: XYZ|Text auf E4 geben

3. Letzte Textnachricht updaten: |Text auf E4 geben

Ich werde wohl als nächstes das Update von ReplyMarkups einbauen. Damit lassen sich dann die Tastaturen updaten. Das könnte auch interessante Möglichkeiten eröffnen, z.B. Per Telegram Receiver "Status Licht" abfragen. Die Antwort enthält dann eine Tastatur, je nach Status des Lichts, also z.B. "AUS", wenn das Licht an ist. Drückt man dann "AUS", dann wird das Licht ausgeschaltet und man kann die Tastatur auf "EIN" updaten. Dauert aber noch etwas ....

[MrIcemanLE]

Ich meinte nicht zwei mal die selbe Nachricht sondern eine Art Update. In meinem Fall:

• Ich gebe EDOMI das signal, dass ich das Haus verlasse (Taster) --> Nachricht über Telegram "Abwesenheit starten" (sozusagen Bereitschaft)
• Wenn die PM keine Bewegungen mehr erkennen, geht EDOMI auf den Status "Abwesend" und sendet mir ein Update. Dies wird über den Entropie-LBS geregelt. Es sind also manchmal 5 Minuten später und manchmal 15 Minuten.

Ich wollte eigentlich nur die Anzahl der Nachrichten im Chat-Verlauf reduzieren und in diesem Fall ein Update der vorherigen Nachricht machen.

Denkbar wären aber auch weitere Use-Cases für den Bot zusammen mit dem Receiver:

• anzeigen eines Kamerabildes welches immer aktualisiert wird, bis der Nutzer einen Button (in Telegram) drückt oder eine neue Nachricht eingeht.
• oder eine Fortschrittsanzeige für einen Vorgang, den man gern überwachen möchte

Mein Vorschlag wäre daher ein separater Update-LBS und die Message-ID als zweiter Ausgang in dem bestehenden LBS. So lässt es sich individueller Regeln und der LBS wird nicht so komplex.

[jonofe]

Ich bin noch nicht ganz sicher, ob ich den Use Case genau verstanden habe. Ich versuche es mal mit meinen Worten zu beschreiben:

Wenn kurz nacheinander dieselbe Nachricht an einen Empfänger geschickt wird, dann soll nur eine Nachricht angezeigt werden. Richtig?
Dies könnte man nun auf zwei Arten realisieren:

1. Wenn eine zweite Nachricht innerhalb einer Zeitgrenze (z.B. x Sekunden) am Baustein ankommt mit gleicher Chat-ID, dann wird diese ignoriert.

2. Wenn eine zweite Nachricht innerhalb einer Zeitgrenze (z.B. x Sekunden) am Baustein ankommt mit gleicher Chat-ID, dann wird diese als Update mit der Message-ID der letzten Nachricht geschickt, so dass die letzte Nachricht geupdated wird. Da es ja dieselbe Nachricht ist, wäre inhaltlich erstmal kein Unterschied zu Szenario 1 vorhanden, es sei denn man sieht im Telegram Client, den neuen Timestamp. Da der Timestamp ja auf Minuten-Basis im Client angezeigt wird, wäre Szenario 2 also nur dann wirklich unterschiedlich zu Szenario 1, wenn x entsprechend groß gewählt würde. Wenn wir hier nur von Sekunden sprechen, um Dubletten rauszufiltern, dann wäre Szenario 1 vermutlich ausreichend. Korrekt?

Was ich mir grundsätzlich noch vorstellen könnte, dass man die Message-ID der versendeten Nachricht auf einen Ausgang gibt und diese auch in anderen Use-Cases mit nachgeschalteter Logik verwenden kann, um eine bereits gesendete Message zu updaten. Dazu wäre dann natürlich auch ein Eingang mit dieser Message ID notwendig oder man gibt auf den Text Eingang sowas wie "Message-ID"+"Message" an. Entspricht die Message-ID dann der letzten gesendeten Message, dann wird ein Update gesendet, ansonsten eine neue Message. Damit könnte man dann auch ein Update mit geändertem Inhalt senden.

Fedback?

[MrIcemanLE]

Mir ist noch nicht ganz klar, wie die Entscheidung getroffen wird, ob es ein Update oder eine neue Nachricht wird.

Ich hatte für mich einen eigenständigen LBS gemacht (quick & dirty). Bei der Einarbeitung in deinen LBS (um dir ein Diff erzeugen zu können) ist mir aufgefallen, dass die Unterscheidung und das Triggern wahrscheinlich Punkte sind, über die man etwas mehr nachdenken sollte. Ich habe es erstmal so, dass die MessageID und der Text als Trigger gelten. Aber vielleicht würde sich auch ein Trigger-Eingang anbieten, wenn man einen separaten LBS macht. Mir ist es nicht gelungen, die Idee in deinen LBS einzubauen. Daher hier der abgespeckte und modifizierte LBS für Updates als Anhang.

[jonofe]

Die Frage wäre jetzt, soll ich einen eigenen LBS draus machen, der zu 80-90% aus Code von jonofe besteht oder wollen wir/jonofe das Feature integrieren?

Eigener LBS macht aus meiner Sicht keinen Sinn, dem würde ich auch nicht zustimmen. Du könntest mir ja mal ein Diff der geänderten LBS zusenden und ich schau mir das mal an. Mir ist noch nicht ganz klar, wie die Entscheidung getroffen wird, ob es ein Update oder eine neue Nachricht wird.