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

[starwarsfan]

Wenn wir schon dabei sind: Es wäre besser, die LBS-Nummern im Titel auch jeweils ausschreiben, da man dann danach suchen kann.

[Robby]

Mein wichtigster LBS in Edomi...
...wenn´s klingelt und wenn die Frau nach Haus kommt---->>> bloß nach Haus fahren, es gibt Essen

Vielleicht sollte man das Thema umbenennen in

LBS19000(303I304I645) - Telegram Contakt I Telegram Receiver I Command Validator

umbenennen

In der Hilfe steht:

The out A1 is set to 1, if the message specified on A4 was received from a ChatID which is specified on A3.

sollte das nicht E4 und E3 heißen?

[starwarsfan]

Die dritte Variante wird in EDOMI Kreisen auch starwarsfan Validierung genannt.

Viel Spaß damit....

ROFL, ich fühle mich geehrt.

Coole Sache, vielen Dank für den Umbau.

[jonofe]

Erweiterung des Telegram Validators um einen Validation Level (E5).

1. Wenn E5 = 0 (default), dann werden die Ausgänge A1 (=1) und A2 (=ChatID) nur gesetzt, wenn eine korrekte Nachricht von korrekter ChatID empfangen wurde.
2. Wenn E5 = 1, wie bei 1. und zusätzlich werden die Ausgänge A1 und A2 auch gesetzt, wenn eine korrekte Nachricht von falscher ChatID empfangen wurde. A1 wird dann natürlich auf 0 gesetzt und A2 auf die empfangene ChatID.
3. Wenn E5 = 2, wie bei 2. und zusätzlich dann werden die Ausgänge A1 und A2 auch bei falscher Nachricht gesetzt. A1 auf 0, A2 auf die ChatID des Senders. D.h. A1 und A2 werden bei jedem ankommenden Telegram gesetzt.

Der Timestamp A3 wird nur gesetzt, wenn ein Telegram korrekt validiert werden konnte, d.h. Text und ChatID waren korrekt.
Die dritte Variante wird in EDOMI Kreisen auch starwarsfan Validierung genannt.

Viel Spaß damit....

[jonofe]

Update des Telegram Command Validators mit Timestamp Ausgang ist nun verfügbar.

Mir war übrigens in meiner Logik aufgefallen, dass die o.g. Änderung, d.h. Setzen der Ausgänge A1/A2 auf bei invalider Chat-ID, dazu führte, dass meine Logik nicht mehr funktionierte. Ich habe nämlich den Ausgang Chat-ID A2 dazu verwendet, bei bestimmten Nachrichten, eine Antwort an den Absender zu senden. Bislang war es ja so, dass ein Setzen von A2 implizit eine valide ChatID war. Jetzt kann es auch eine invalide ChatID sein. Dadurch muss man nun einen Wertauslöser hinten dranhängen, A1 als Trigger, A2 als Wert, dann ist der Ausgang des Wertauslösers dann eine validierte ChatID.

starwarsfan : Auf Basis dieses Verhaltens, werde ich ggf. dein gewünschtes Feature doch über einen Eingang konfigurierbar machen, d.h. ob man auch die Signalisierung von invaliden Telegrammen möchte. Würde dann dreistufig sein:

0 => Update A1(1) / A2(ChatID) nur bei valid (default) (also nur wenn Message und ChatID korrekt)
1 => Update A1(0) / A2(ChatID) bei auch bei invalid ChatID (also immer wenn korrekte Message empfangen wurde)
2 => Update A1(0)/ A2)ChatID) auch bei invalid message (also immer)

Bzgl. des RAM Problems ist mir eben aufgefallen, dass Telegram "long-polling" unterstützt. Dies kann ggf. das RAM Problem deutlich entschärfen. Bin gerade dabei dies zu testen. Falls es erfolgreich ist, gibts es bald ein Update des Receivers.

[jonofe]

Hi Yves,

ich habe es mit dem stündlichen KO verbunden. Das sollte eigentlich reichen.
Habe schon überlegt, ob ich es automatisieren soll. D.h. regelmäßig die RAM Auslastung monitoren und wenn >50% dann ein Reset mit einer bestimmten Totzeit danach.

Inzwischen gibt es auch eine andere PHP Library für Telegram, allerdings müsste die zunächst wieder backportet werden auf PHP 5.3. Hab ich im Moment leider wenig Zeit für.

[starwarsfan]

Hallo André,

wie ist Deine Erfahrung mit dem Reset-Eingang des Receiver-Baustein 19000304? Seitdem ich den Baustein in Betrieb habe, blendet mir Edomi RAM-Warnungen ein und das Memory des Systems wird mit 94% Auslastung angezeigt. Der Output von htop direkt auf dem System sieht so aus:

2016-12-02_19000304_Memory.png

Aktuell habe ich E6 mit dem System-KO 20 belegt, um täglich einen Reset zu machen. Das ist offenbar zu wenig. Wie hast Du bzw. wie haben andere das bei sich eingerichtet?

[starwarsfan]

Hallo André

Ich habe zumindest die Erfahrung gemacht, dass gleichzeitiges Setzen von vielen Ausgängen wahrnehmbar ist. ggf. sind ja noch viel mehr DB Zugriffe vonnöten, außderdem die entsprechende Logik, die dahinter hängt. Und wir sprechen hier ja auch nicht von DB Servern, wenn ich mir so die Beliebtheit des S900 für ca. 25€ anschaue.

Naja, wenn man Gravitationswellen mit einem Rechner mit der Performance eines Raspi berechnen will, dann dauert's eben etwas...

Ausgänge zu setzen um in der Liveansicht zu debuggen halte ich auch nicht für sinnvoll.
Wenn du es unbedingt haben möchtest, musst du ja auch nur zwei Zeillen einfügen.

Joa, das ist klar. Ich schraube nur ungern an anderen LBSen herum, da das bei allfälligen Updates nur in immer mehr Arbeit ausartet und eigene Erweiterungen ja durchaus auch für andere User interessant sein könnten.

Was ich mir vorstellen könnte, wäre ein Ausgang A3 mit einem Timestamp, wann zuletzt die Ausgänge A1/A2 gesetzt wurden, d.h. wann zuletzt der korrekte Text empfangen wurde.

Sounds like a plan! Gute Idee, +1 von mir.

[gaert]

mySQL ist isoliert betrachtet sicher "schnell genug" für ein paar 1000 Operationen - das "Nadelöhr" ist eher PHP, bzw. die Kombination aus beiden: Beim Setzen von z.B. 40 Ausgängen werden prinzipbedingt auch 40 einzelne Updates per PHP auf die DB getriggert. Das Ganze wird sich im Millisekunden-Bereich abspielen, aber in Summa mit anderen Logiken etc. kann da natürlich einiges zusammenkommen. Leichte Latenzen (im Subsekunden-Bereich) sind aber m.E. auch kein Drama, denn das "Hauptnadelöhr" ist grundsätzlich das unglaublich schnelle KNX...

[jonofe]

Ich habe zumindest die Erfahrung gemacht, dass gleichzeitiges Setzen von vielen Ausgängen wahrnehmbar ist. ggf. sind ja noch viel mehr DB Zugriffe vonnöten, außderdem die entsprechende Logik, die dahinter hängt. Und wir sprechen hier ja auch nicht von DB Servern, wenn ich mir so die Beliebtheit des S900 für ca. 25€ anschaue.

Ausgänge zu setzen um in der Liveansicht zu debuggen halte ich auch nicht für sinnvoll.
Wenn du es unbedingt haben möchtest, musst du ja auch nur zwei Zeillen einfügen.

Was ich mir vorstellen könnte, wäre ein Ausgang A3 mit einem Timestamp, wann zuletzt die Ausgänge A1/A2 gesetzt wurden, d.h. wann zuletzt der korrekte Text empfangen wurde.

[starwarsfan]

Hi

alles andere würde ggf. zu hoher Last führen, wenn du z.B. 20 Befehle definierst, dann würde bei jedem Telegramm 40 DB Schreiboperationen ausgeführt, da 40 Ausgänge gesetzt werden. Das würe ich definitiv nicht empfehlen.

Du machst Dir Sorgen wegen 40 DB-Zugriffen? Ernsthaft jetzt? Also wenn wir von 4000 oder 40000 reden würden, wäre ich bei Dir aber meinst Du wirklich, dass die paar Operationen das System so runterziehen? Wenn dem tatsächlich so ist, bin ich extrem enttäuscht von MySQL.

Das letzte Telegram siehst du immer am Telegram Receiver.

Joa, das ist klar.

Und wieso sollte man auf z.B. bei Telegram "Licht aus" in einem Baustein "Rolläden hoch" ein Invalid empfangen. Verstehe den Anwendungsfall nicht.

Bsp. "Licht an" ist valide, aber nicht für einen Instanz mit "Rolläden hoch". Der Telegramtext sollte doch zunächst mal festlegen ob es für den LBS relevant ist. Wenn nicht relevant, dann ist er auch nicht invalid.

Ja eben. Wenn nicht valide, dann den Ausgang zurücksetzen auf 0. Wenn das wirklich ein Performance-Issue ist, kann das ja wie erwähnt auch optional aktivierbar sein.

Aber wie auch immer, ich fänd's im Moment hauptsächlich in der Live-View sehr praktisch, da dort beim Arbeiten mit den Logiken die Übersicht verloren geht. Aktuell muss man erst mit der Maus auf den Receiver gehen, damit im Tooltip die gesamte Meldung sichtbar wird. Dann muss man prüfen, ob und was der entsprechende LBS gemacht hat, da ja quasi alle Ausgänge auf 1 stehen nach ein paar Versuchen.

[jonofe]

alles andere würde ggf. zu hoher Last führen, wenn du z.B. 20 Befehle definierst, dann würde bei jedem Telegramm 40 DB Schreiboperationen ausgeführt, da 40 Ausgänge gesetzt werden. Das würe ich definitiv nicht empfehlen.
Das letzte Telegram siehst du immer am Telegram Receiver. Und wieso sollte man auf z.B. bei Telegram "Licht aus" in einem Baustein "Rolläden hoch" ein Invalid empfangen. Verstehe den Anwendungsfall nicht.

Bsp. "Licht an" ist valide, aber nicht für einen Instanz mit "Rolläden hoch". Der Telegramtext sollte doch zunächst mal festlegen ob es für den LBS relevant ist. Wenn nicht relevant, dann ist er auch nicht invalid.

[starwarsfan]

Hi

Willst du nur eine 0, wenn der Befehl korrekt und die ChatId falsch ist?

Nein, wenn eines von beiden falsch ist.

ansonsten wird es schwierig, da der LBS ja eigentlich so designed ist, dass es je Befehl und ChatID(s) einen LBS gibt. Und jeder LBS empfängt alle Nachrichten.
Wenn auch bei falscher Nachricht eine 0 gesendet wird, dann wäre dies natürlich sehr oft der Fall.

Und ist das ein Problem? Es ist klar, dass jeder Befehl "seinen" LBS hat. Genau deshalb wäre es ja gut, wenn die Ausgänge bei einem nicht validen Befehl zurückgesetzt werden. Ob man dann darauf auch wirklich reagiert, ist ja jedem Anwender dann selbst überlassen.

Ich würde also die Übereinstimmung der Nachricht mal als notwendige Bedingung betrachten, dass der Baustein seine Ausgänge setzt. Und wenn die ChatID stimmt, dann wird der Ausgang A1 auf 1 gesetzt und wenn sie nicht stimmt dann auf 0. In beiden Fällen wird die ChatId des Senders auf A2 gesetzt. Okay?

Hm, das macht für mich keinen Sinn, da es mir nicht darauf ankommt ob die Chat-ID stimmt, sondern eben ob der Befehl valide ist oder nicht. Damit "sieht" man auch einfach, welcher Befehl der letzte ausgeführte Befehl ist.

[jonofe]

HAbe es gerade mal ungetestet als v0.3 hochgeladen. Bitte Feedback, ob es wie oben beschrieben funktioniert.

[jonofe]

Willst du nur eine 0, wenn der Befehl korrekt und die ChatId falsch ist?
ansonsten wird es schwierig, da der LBS ja eigentlich so designed ist, dass es je Befehl und ChatID(s) einen LBS gibt. Und jeder LBS empfängt alle Nachrichten.
Wenn auch bei falscher Nachricht eine 0 gesendet wird, dann wäre dies natürlich sehr oft der Fall. Da jede Instanz bei jeder ankommenden Nachricht getriggert wird.
Ich würde also die Übereinstimmung der Nachricht mal als notwendige Bedingung betrachten, dass der Baustein seine Ausgänge setzt. Und wenn die ChatID stimmt, dann wird der Ausgang A1 auf 1 gesetzt und wenn sie nicht stimmt dann auf 0. In beiden Fällen wird die ChatId des Senders auf A2 gesetzt. Okay?