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

[vento66]

Dann könnte jonofe das eventuell in die Hilfe mit rein. (Liest zwar eh keiner, aber der Vollständigkeit halber )

[jonofe]

Gute Idee, werde ich mal machen.
Evtl. kann ich den LBS auch anpassen, so dass auch der Api-Key auch per iKO funktioniert.

[gulp2k]

mal ne doofe Frage... ich höre/lese jetzt das erstemal davon das es für einen LBS einen Unterschied macht ob der Eingang direkt oder per iKO beschrieben wird... woran liegt das und wie kann man das erkennen?

[jonofe]

kann man nicht erkennen. Liegt an der Implementierung.

[gulp2k]

jetzt lass mich doch nicht doof sterben
Da ich ja auch den ein oder anderen LBS baue würd ich das schon gerne verstehen.

[jonofe]

es liegt halt daran wie du die Eingänge verarbeitest. D.h. du solltest es so machen, dass du jederzeit Änderungen auf den Eingängen verarbeiten kannst.
Ich denke, dass ich bei den Telegramm LBS eine connection aufbaue sobald eine 1 auf E1 anliegt. Wenn zu dem Zeitpunkt der ApiKey nicht da ist, dann geht das schief.
Es liegt also daran, wie sauber es implementiert ist. Und ja, da ist Verbesserungspotenzial bei meinem Telegram LBS diesbezüglich.

Es funktioniert mit der statischen Zuweisung, da EDOMI bei der Aktivierung zunächst alle statischen Eingänge setzt bevor der LBS zum ersten mal aufgerufen wird, d.h. es liegt dann sowohl der API Key als auch die 1 bei Start vor. Somit funktioniert es. Wenn der API Key per iKO kommt der E1 aber statisch mit 1 belegt ist, geht es schief, da der LBS bereits mit der 1 an E1 aufgerufen wird, bevor der API Key vorhanden ist.

Was also auch funktionieren sollte, zuerst die Konfigurationeingänge per iKOs setzen und danach den E1 per iKO auf 1 setzen.

Ich werde das aber mal mit auf die Liste packen, so dass es dann in Zukunft unabhängig funktioniert.

Ein weiteres Beispiel ist die ID der HUE Leuchtmittel. Die muss auch vorab bekannt sein. Dies lässt sich auch nicht so einfach ändern, da hier verschiedene LBS per Message Queue miteinander kommunizieren und dabei sind bestimmt Infos einfach zwingend notwendig bei der Projektaktivierung.

Werde dass aber mal in die Hilfe aufnehmen.

Man könnte mal versuchen, ob es mit einem iKO funktioniert, welches einen Initialwert hat. Ggf. befüllt EDOMI diese Werte auch schon in der Initphase, so dass der Wert dann auch beim initialten Aufruf vorhanden ist.

[gulp2k]

Danke! Das macht so Sinn.
Ich hatte es ursprünglich so verstanden das es einen Unterschied macht wie der Wert rein kommt, unabhängig vom zeitlichen Kontext.
Aber so wie du es erklärt hast macht das auf jedenfall Sinn und war mir auch nicht Bewußt!

[coliflower]

Gute Idee, werde ich mal machen.
Evtl. kann ich den LBS auch anpassen, so dass auch der Api-Key auch per iKO funktioniert.

Mein Api-Key war schon immer in einer iKO gespeichert ...

[jonofe]

Aber der war dann vermutlich als Init Wert vorbelegt und wurde nicht erst zur Laufzeit gesetzt. Ich vermute, dass es deshalb geht. Kann auch sein, dass es eine Reihenfolge gibt, in der EDOMI die Eingänge belegt. dadurch kann es dann auch zu unterschiedlichen Verhaltensweisen kommen. Wenn API zuerst gesetzt wird, bevor die 1 auf E1 ankommt, dann geht alles gut. Wenns andersrum passiert, dann gehts schief.

[coliflower]

Der Wert ist als Initialwert in der iKO gespeichert.

[lordofchaos]

Kann ich bestätigen. Als Initialwert eingetragen funktinoiert es auch bei mir.

[lordofchaos]

Großes Kompliment und herzlichen Dank für diese genialen Bausteine!!!

Ich bin ja dank KNX und EDOMI schon einiges gewohnt, aber wenn man seinem Haus(Bot) schreibt, wie der Fensterstatus ist oder sich nach den aktuellen Verbräuchen erkundigt und man direkt per "Telegram"-Nachricht antwort bekommt, einfach stark!!! Ich stelle jetzt meine Visu erstmal hinten an und kommuniziere per Bot mit meinem Haus

DANKE an jonofe und die ganze Community!!!

IMG_1380.PNG

Wie hast du die ganzen Daten mit Text in einer Message bekommen?
Ich hab mit Stings verbinden schon gemacht aber da bekomme ich die reinen Daten gesendet. Nicht gerade sehr übersichtlich.

[lordofchaos]

Use Case wie oben von fisch3009 beschrieben:

1. Nutzer sendet per Telegram einen Status Anfrage an EDOMI (z.B. 'Status Licht')
2. EDOMI sendet den Licht Status per Telegram Message
3. Die Message enthält eine Tastatur, die mögliche Antworten enthält z.B.: EIN|AUS
4. Der Empfänger muss nun die Antwort nicht selbst verfassen, sondern kann diese nun ganz einfach auswählen
5. Der Telegram-Receiver-LBS empfängt den Antworttext und EDOMI reagiert entsprechend (z.B. Licht ausschalten)

Viel Spaß damit

André

Kurz zum Verständnis mit der Tastertur einblenden. Die Antworten können ja nur einmal vorkommen.
Ich kann ja verschiedene Lichter Abfragen (LICHT BAD, LICHT WOHNZIMMER ...)
Aber ich kann doch die Nachricht an den Bot EIN|AUS nur an ein Licht binden entweder BAD oder WOHNZIMMER, sonst gehen beide an oder aus.
auser der Text würde EIN BAD, EIN WOHNZIMMMER ... sein.
Oder verstehe ich was falsch und die automatische antworten Texte sind auf die davor gesendete Message verknüft?

Hoffe ich habe mich verständlich ausgedrückt

[jonofe]

Die Tastatur ist quasi eine Shortcut für eine Nachricht. D.h. der Text auf der Taste wird als Antwortnachricht gesendet. Wie du dann in EDOMI drauf reagierst bleibt dir überlassen.

[gulp2k]

jonofe
Erstmal super Bausteine hat alles problemlos geklappt!
Vielen Dank für die Arbeit.

Ich bin gerade am ausprobieren und hätte noch einen Featurewunsch
Bei den Keyboards kann man für jeden "Knopf" die Beschriftung und die Callback-Daten vergeben.
Aktuell wird im LBS beides auf den gleichen Wert gesetzt.
Ich würden denn Callback-Wert gerne Selbst bestimmen, dann könnte man etwas mehr Interaktivität rein bringen.

z.B.
User: "licht"
Bot: inline (Wohnzimer,licht_wozi|Küche,licht_küche) erscheint als "(Wohnzimmer) (Küche)"
User: Drückt auf (Wohnzimmer) aber Bot bekommt "licht_wozi"
Bot: message: "Wohnzimmer Licht", inline: (An,licht_wozi_1|Aus,licht_wozi_0) erscheint als "(An) (Aus)"

Man könnte damit verschieden States merken die man sonst umständlich in einer Logik abbilden müsste.