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

[coliflower]

Asche …
Anscheinend habe ich bei dem ganzen Probieren das LIVE-Projekt neu zu starten … Was soll ich sagen … Sorry, es geht :-)

[rene1511]

So ich wollte an dieser Stelle mal unbedingt meinen Dank aussprechen für diesen tollen LBS. Ich dachte ja schon immer prowl wäre gut... Aber Telegram plus die beiden LBS hier setzen dem ja voll die Krone auf. Echt schick (und funktioniert wunderbar )!!

[baumhaus123]

So ich wollte an dieser Stelle mal unbedingt meinen Dank aussprechen für diesen tollen LBS. Ich dachte ja schon immer prowl wäre gut... Aber Telegram plus die beiden LBS hier setzen dem ja voll die Krone auf. Echt schick (und funktioniert wunderbar )!!

Da möchte ich mich gerne meinem Vorredner anschließen! Habe es auch endlich mal geschafft, Telegram auszuprobieren, und es ist wirklich der Knaller!
Jetzt muss ich leider alle meine Prowls rausschmeißen, denn das mit der Antwort an den Bot inkl. Rückantwort mit den Tastaturmöglichkeiten sind schon eine tolle Spielerei!
Vielen Dank für die super Bausteine!

[nno]

@jonofe: Auch von meiner Seite vielen Dank für den LBS 19000303. Funktioniert super cool . Bei der Installation sind mir zwei Kleinigkeiten aufgefallen:

1. Im Hilfetext steht irgendwo "You'll get the API Key during this creation process. Write it down and copy it to input E2." Das müsste aber E1 statt E2 heissen.
2. Habe die PHP Extensions laut Anleitung in der Hilfe installiert, danach hatte ich aber folgende Fehlermeldung im EDOMI Fehler-Log:
   Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000303.php | Fehlercode: 1 | Zeile: 39 | Call to undefined function msg_get_queue()
   Nachdem ich die php-process extension nochmal mit yum install -y php-process installiert hatte, hat es dann geklappt. Kann aber auch gut sein, dass ich davor irgendwas falsch gemacht hatte.

[jonofe]

@jonofe: Auch von meiner Seite vielen Dank für den LBS 19000303. Funktioniert super cool . Bei der Installation sind mir zwei Kleinigkeiten aufgefallen:

1. Im Hilfetext steht irgendwo "You'll get the API Key during this creation process. Write it down and copy it to input E2." Das müsste aber E1 statt E2 heissen.
2. Habe die PHP Extensions laut Anleitung in der Hilfe installiert, danach hatte ich aber folgende Fehlermeldung im EDOMI Fehler-Log:
   Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000303.php | Fehlercode: 1 | Zeile: 39 | Call to undefined function msg_get_queue()
   Nachdem ich die php-process extension nochmal mit yum install -y php-process installiert hatte, hat es dann geklappt. Kann aber auch gut sein, dass ich davor irgendwas falsch gemacht hatte.

Danke für das Feedback. Das mit dem API-Key Eingang werde ich korrigieren.
php-process steht in der aktuellen Doku allerdings drin. Kann es sein, dass du noch eine ältere Version verwendest. Die Version 0.6 habe ich am 22.08.2016 hochgeladen und spätestens dann war es drin. Erinnere mich aber, dass es anfangs in der Doku fehlte.

[ThomasDa]

Hallo zusammen,

versuche gerade den LBS Telegram Contact v0.6 bei mir ans fliegen zu bringen.

Leider scheitere ich schon bei der Installation der additional packages mit wget (Schritt III aus der Hilfe).
Mein Stand ist folgernder:

[root@edomi ~]# yum install -y php-mbstring php-xml git wget php-process
...
Complete!
[root@edomi ~]# cd /tmp
[root@edomi tmp]# wget --no-check-certificate https://getcomposer.org/installer
--2016-10-14 21:22:59--  https://getcomposer.org/installer
Auflösen des Hostnamen »getcomposer.org«.... 87.98.253.108, 2001:41d0:a:7b19::2
Verbindungsaufbau zu getcomposer.org|87.98.253.108|:443... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 293630 (287K) [application/octet-stream]
In »»installer«« speichern.

100%[==============================================================================>] 293.630     23,5K/s   in 12s

2016-10-14 21:23:13 (23,5 KB/s) - »»installer«« gespeichert [293630/293630]

[root@edomi tmp]# php installer
[B]None of the 0 stable version(s) of Composer matches your PHP version (5.3.3 / ID: 50303)[/B]

Was läuft denn hier falsch?
Edomi läuft bei mir auf einem S900, installiert mit dem CentOS-Image von der Edomi Homepage.

Gruss Thomas

[jonofe]

Ich habe keine Ahnung was da falsche läuft. Ich habe es gerade noch mal auf einer frisch instellierten EDOMI Instanz getestet:

[root@edomi-staging tmp]# wget --no-check-certificate https://getcomposer.org/installer
--2016-10-15 03:05:03--  https://getcomposer.org/installer
Resolving getcomposer.org... 87.98.253.108, 2001:41d0:a:7b19::2
Connecting to getcomposer.org|87.98.253.108|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 293630 (287K) [application/octet-stream]
Saving to: “installer”

100%[============================================================================================================================================================================================>] 293.630     --.-K/s   in 0,1s    

2016-10-15 03:05:04 (2,63 MB/s) - “installer” saved [293630/293630]

[root@edomi-staging tmp]# php installer
Downloading 1.2.1...

Composer successfully installed to: /tmp/composer.phar
Use it: php composer.phar
Some settings on your machine may cause stability issues with Composer.
If you encounter issues, try to change the following:

Your PHP (5.3.3) is quite old, upgrading to PHP 5.3.4 or higher is recommended.
Composer works with 5.3.2+ for most people, but there might be edge case issues.

[root@edomi-staging tmp]#

Ist

 
 [B]None of the 0 stable version(s) of Composer matches your PHP version (5.3.3 / ID: 50303)[/B]

wirklich die gesamte Meldung, die der Befehl

php installer

zurückliefert?

[ThomasDa]

Hallo Jonofe,

was soll ich sagen...
Ich habe wget einfach nochmal ausgeführt, dann ging es. Linux ist wohl noch nicht mein Freund.

Die Antwort gestern von php Installer war die einzelne Zeile wie in #171 beschrieben.

[root@edomi ~]# wget --no-check-certificate https://getcomposer.org/installer
--2016-10-15 08:46:01--  https://getcomposer.org/installer
Auflösen des Hostnamen »getcomposer.org«.... 87.98.253.108, 2001:41d0:a:7b19::2
Verbindungsaufbau zu getcomposer.org|87.98.253.108|:443... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 293630 (287K) [application/octet-stream]
In »»installer«« speichern.

100%[==============================================================================>] 293.630      900K/s   in 0,3s

2016-10-15 08:46:01 (900 KB/s) - »»installer«« gespeichert [293630/293630]

[root@edomi ~]# php installer
Downloading 1.2.1...

Composer successfully installed to: /root/composer.phar
Use it: php composer.phar
Some settings on your machine may cause stability issues with Composer.
If you encounter issues, try to change the following:

Your PHP (5.3.3) is quite old, upgrading to PHP 5.3.4 or higher is recommended.
Composer works with 5.3.2+ for most people, but there might be edge case issues.

[root@edomi ~]# mv composer.phar /usr/local/bin/composer
[root@edomi ~]# cd /usr/local/edomi/main/include/php
[root@edomi php]# git clone https://github.com/jonofe/php-telegram-bot
Initialized empty Git repository in /usr/local/edomi/main/include/php/php-telegram-bot/.git/
remote: Counting objects: 3250, done.
remote: Total 3250 (delta 0), reused 0 (delta 0), pack-reused 3249
Receiving objects: 100% (3250/3250), 721.91 KiB | 694 KiB/s, done.
Resolving deltas: 100% (2281/2281), done.
[root@edomi php]# cd php-telegram-bot
[root@edomi php-telegram-bot]# composer install
Your version of PHP, 5.3.3, is affected by CVE-2013-6420 and cannot safely perform certificate validation, we strongly suggest you upgrade.
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
  - Installing psr/log (1.0.0)
    Downloading: 100%

  - Installing monolog/monolog (1.19.0)
    Downloading: 100%

  - Installing phpdocumentor/reflection-docblock (2.0.4)
    Downloading: 100%

  - Installing phpunit/php-token-stream (1.4.8)
    Downloading: 100%

  - Installing symfony/yaml (v2.6.13)
    Downloading: 100%

  - Installing sebastian/version (1.0.6)
    Downloading: 100%

  - Installing sebastian/global-state (1.1.1)
    Downloading: 100%

  - Installing sebastian/recursion-context (1.0.2)
    Downloading: 100%

  - Installing sebastian/exporter (1.2.1)
    Downloading: 100%

  - Installing sebastian/environment (1.3.7)
    Downloading: 100%

  - Installing sebastian/diff (1.4.1)
    Downloading: 100%

  - Installing sebastian/comparator (1.2.0)
    Downloading: 100%

  - Installing phpunit/php-text-template (1.2.1)
    Downloading: 100%

  - Installing doctrine/instantiator (1.0.5)
    Downloading: 100%

  - Installing phpunit/phpunit-mock-objects (2.3.8)
    Downloading: 100%

  - Installing phpunit/php-timer (1.0.8)
    Downloading: 100%

  - Installing phpunit/php-file-iterator (1.4.1)
    Downloading: 100%

  - Installing phpunit/php-code-coverage (2.2.4)
    Downloading: 100%

  - Installing phpspec/prophecy (v1.6.1)
    Downloading: 100%

  - Installing phpunit/phpunit (4.8.26)
    Downloading: 100%

  - Installing squizlabs/php_codesniffer (2.6.1)
    Downloading: 100%

monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB)
monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server)
monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required))
monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server)
monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server)
monolog/monolog suggests installing mongodb/mongodb (Allow sending log messages to a MongoDB server via PHP Driver)
monolog/monolog suggests installing php-amqplib/php-amqplib (Allow sending log messages to an AMQP server using php-amqplib)
monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome)
monolog/monolog suggests installing raven/raven (Allow sending log messages to a Sentry server)
monolog/monolog suggests installing rollbar/rollbar (Allow sending log messages to Rollbar)
monolog/monolog suggests installing ruflin/elastica (Allow sending log messages to an Elastic Search server)
phpdocumentor/reflection-docblock suggests installing dflydev/markdown (~1.0)
phpdocumentor/reflection-docblock suggests installing erusev/parsedown (~1.0)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/php-code-coverage suggests installing ext-xdebug (>=2.2.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
Generating autoload files
[root@edomi php-telegram-bot]#

Danach erstes Telegram gesendet und funktioniert!

Danke für Deine Hilfe.

PS:
Die folgende Zeile kann ich wohl ignorieren oder

Your version of PHP, 5.3.3, is affected by CVE-2013-6420 and cannot safely perform certificate validation, we strongly suggest you upgrade.

[jonofe]

ja, diese Warning kannst du ignorieren. Schön, dass es jetzt funktioniert.
VG
André

[starwarsfan]

Hallo André,

bin gerade am herumspielen mit dem Telegram-Validator.

Was ich dabei vermisse ist die Möglichkeit, bei einer nicht-validen Message die Ausgänge wieder zurückzusetzen auf 0 (A1) bzw auf leer (A2). Aktuell ist es bei mir so, dass die Ausgänge nach einer validen Message auf 1 gesetzt bleiben (bzw. die valide Chat-ID auf A2), auch wenn eine nicht valide Meldung eingeht. Damit geht ein anderer Baustein auf 1 und schlussendlich sind dann alle Bausteine auf 1.

Würden die Ausgänge bei einer nicht validen Meldung (gern auch optional) zurückgesetzt werden, könnte man auch darauf mit irgendwelchen Aktionen reagieren. Zudem wäre es im Logik-Editor in der Live-Ansicht sehr viel einfacher nachzuvollziehen, was gerade passiert...

[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?

[jonofe]

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

[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]

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

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.