LBS19000809 - Alexa Control

[sepplo815]

Hi, weil der LBS gerade wieder diskutiert wird.
Hätte auch noch eine Frage dazu.
Wäre es möglich, den Status des Echo Device bekannt zu geben?
Also, ob gerade etwas Bestimmtes passiert, z.B. Ansage läuft, oder Musik wird gespielt, es wurde was gefragt…
Oder auch nur generell, ist aktiviert bzw. Ton wird ausgegeben?

Wäre dann wol ein eigener LBS fällt mir gerade auf.
"Alexa Status" oder so...

Gruß
Seppl

[jonofe]

Nein, meines Wissens ist das nicht möglich.

[sepplo815]

Schade, trotzdem danke für die Antwort

[ThorstenGehrig]

Okay... wenn die Cookies nur bei mir ein Problem sind ... ist es sinnvoller dieses Problem bei mir zu lösen.
Generell ist das schonmal eine gute Nachricht das es Grundsätzlich dauerhaft funktionieren sollte.
Vielleicht liegt es irgendwo an den langen "offline" Zeiten (die Kisten sind im Smarthome z.T. mehrere Wochen vom Strom getrennt) - oder an anderen "spielereien".
Die Spottify API hab ich mir noch nicht im detail angeschaut - mangels möglichkeiten in den nächsten 5-6 Monaten kommt das bei mir frühestens in 2018 auf die prioritäten-Liste.... :-)
Gruß
Thorsten

[Jurkoe]

Hallo André,
seit ein paar Wochen bekomme ich folgende Fehlermeldung wenn ich die Alexa steuern möchte: file_get_contents(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution.

Habe den Fehler nicht gefunden, weißt Du vielleicht an was das liegen kann?

LG Eneriko

[jonofe]

Bei welcher Funktion erscheint der Fehler?
In welchem Log taucht er auf?
Wie lautet der genaue Fehler inkl. Zeilennummer?
Poste doch mal das Logfile.
Sieht nach DNS aus. Evtl. hat sich an den Amazon Servernamen etwas geändert.

[Jurkoe]

Hallo André,
anbei die Infos aus den Log Files.

2017-11-25 05:51:23	501600	?	2165	Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000809.php | Fehlercode: 2 | Zeile: 135 | file_get_contents(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution	ERROR
2017-11-25 05:51:23	502130	?	2165	Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000809.php | Fehlercode: 2 | Zeile: 135 | file_get_contents(http://tunein.com/search/?query=ORF+Radio+Vorarlberg): failed to open stream: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution

Log19000809.PNG
LG Eneriko

[jonofe]

Habs mir mal im Sourcecode angeschaut. Der Fehler tritt bei der Sendersuche via http://tunein.com in Zeile 300 auf. Scheint ein DNS Problem auf deiner Seite zu sein, dass der Servername tunein.com nicht aufgelöst werden kann. Bei mir funktioniert es fehlerfrei. Am besten mal prüfen, ob dein DNS auf dem EDOMI Server richtig konfiguriert ist.

[Jurkoe]

Hallo André,
du hattest Recht. Nach dem ich in der /etc/resolv.conf den nameserver aktualisiert habe, war das Problem weg.
Danke für den Hinweis.
LG Eneriko

[ThorstenGehrig]

Hi jonofe,
einen Spottify baustein hast du ja schon gebaut - danke dafür :-)
(ich hatte noch keine Zeit ihn anzuschauen).
Ich habe auf meine "basic-shell-scripte" vor kurzem ein gutes input auf Gut-Hub bekommen: das dortige "alexa-remote-controll" kann jetzt die cookies automatisch extrahieren.
Außerdem sind etliche weitere Befehle eingebaut worden:

https://github.com/thorsten-gehrig/alexa-remote-control

-e : run command <pause|play|next|prev|fwd|rwd|shuffle|vol:<0-100>
-q : query queue
-b : connect/disconnect bluetooth device
-r : play tunein radio
-s : play library track
-t : play Prime playlist
-u : play Prime station
-v : play Prime historical queue
-w : play library playlist
-i : list imported library tracks
-p : list purchased library tracks
-P : list Prime playlists
-S : list Prime stations
-a : list available devices
-m : delete multiroom and/or create new multiroom containing devices
-l : logoff
-h : help

Zugehöriger Blog-Eintrag: http://blog.loetzimmer.de/2017/10/am...hell-echo.html

Einige funktionen benötigen einen Jason-Parser (jq) der nicht standardmäßig auf dem EDOMI ist, es gibt aber auch eine Plain-Version ohne jq dafür mit eingeschränkten funktionsumpfang:
https://loetzimmer.de/patches/alexa_...ntrol_plain.sh

Die Code-Erweiterungen kommen Alexander Noack - scheinbar kein KNX User (eher FHEM wenn ich das recht lese) => der open source & community gedanke greift hier exzellent :-)

Nun zu meinem Punkt: ich habe weiterhin immerwieder den bedarf den Cookie und CSFR auszulesen... könntest du evtl. das automatische auslesen in deinen Baustein übernehmen?
Neben meiner "persönlichen Problemstellung" denke ich das es für andere Anwende auch schönder&einfacher ist dort Amazon-ID und Passwort zu hinterlegen...

Gruß
Thorsten

[jonofe]

Ich habe einen Baustein für Alexa auf deinem aufgesetzt, der den aktuellen Status zurückgibt, also Titel / Radiostation, Bild....
Willst du die Logik in deinen mit aufnehmen?

Winni ,

super, ja ich denke das macht Sinn, es in den bestehenden LBS zu integrieren.
Das habe ich mal in v0.2 umgesetzt.

Danke für die Erweiterung.

[Winni]

jonofe

Danke für's einbauen, evtl. eine Frage: ich habe "dein" Result verwendet um bei Befehlen aus der Visu möglichst schnell zu refreshen. Du hast jetzt "mein" Result auf den gleichen Ausgang gelegt, wäre es Evtl. möglich ein Befehls-Result und ein Refresh-Result zu haben um eine Endlos-Schleife zu verhindern?
Oder hast du auf die Schnelle eine andere Idee das zu unterscheiden ?
Wir können aus meiner Sicht auch darauf verzichten das Refresh-Result auszugeben, mach halt Sinn wenn jemand evtl. extern noch weitere Infos benutzen will.

Winni

[jonofe]

Ich sehe 3 Möglichkeiten:

1. Zwei separate Ausgänge (A1 kann Refresh triggern)
2. Refresh Result gar nicht ausgeben (A1 kann Refresh triggern)
3. Nach jedem Command automatisch ein Refresh machen (A1 muss kein Refresh triggern)

[Winni]

Intern wäre natürlich auch ne gute Idee. Um flexibel zu bleiben ein Eingang mit fester Refreshzeit | Refreshzeit nach Befehl? Also zwei Werte, wobei der erste eine zyklische Abfrage triggert, der zweite die Wartezeit nach Befehl (0=ausgeschaltet). Die externen Sytemtrigger triggern immer viele Bausteine gleichzeitig, was man so umgehen könnte.

[jonofe]

Zyklisch ist eher schwierig und würde ein Redesign erfordern, da der LBS dann als Daemon laufen müsste. Das würde ich gerne vermeiden. D.h. ich würde den Triggereingang so lassen wie er ist und er kann von extern zyklisch getriggert werden. Um den Systemtrigger zu umgehen kann man ja auch einen Telegrammgenerator verwenden. Und den automatischen Refresh werde ich dann nach einem Befehl machen. Zusätzlich den Ausgang mit dem Status-JSON String.