LBS19000809 - Alexa Control

[jonofe]

Dein normales Amazon Login. Hast du für Alexa ein anderes?

[Winni]

In der login-Funktion ist result[1] und result[2] true, der Rest false. Also wirklich ein Login-Problem.
eMail und Passwort wie auf alexa.amazon.de anzugeben, oder?

Hab's nun auch mit der Telefonnummer probiert, geht genausowenig.

[jonofe]

Winni
es sieht wirklich so aus, als würde es am eigentlichen Login Vorgang scheitern.
Cookie sieht gut aus. CSRF fehlt.
Hast du evtl. ungewöhnliche Zeichen in deinem Passwort?
Nutzt du die Zweifaktor Authentifizierung von Amazon?

[jonofe]

welche Einträge sind denn in der Datei?

[Winni]

jonofe
auch mit leerem E6 keine Besserung, Datei wird angelegt
tger977
Leider hat's auch mit deinen Tipps nicht funktioniert. Keine Ahnung was hier wieder besonderes bei mir ist...

P.S.: Meine Dot's haben in der Bezeichnung ein Hochkomma.... Könnte das Probleme machen?

P.P.S: Auch mit anderen Namen und EDOMI Server Neustart keine Änderung

[tger977]

Hallo Andre,

danke für das Update, funktioniert!

Winni : war bei mir beim ersten Versuch auch so, habe dann nochmal über E1 gestartet und einfach mal eine TuneIn Station an E16 gestartet und dann ging es plötzlich...

[gulp2k]

Hm, schade dann kann ich den LBS so nicht mehr nutzen
Kannst du mir die vorherige Version nochmal posten? Leider hab ich nur noch ne ganz alte bei mir auf der Platte gefunden.

[jonofe]

Könnte man parallel noch mit der Session ID wie vorher arbeiten?

Nein, das geht nicht.

Oder kann man einen Extra Alexa Account irgendwie erzeugen?

Nur bedingt. Kannst zwar einen zweiten Amazon Account anlegen. Wenn du aber Prime auf deinem primären Account hast und deine Echos mit einen anderen Account verbindest, dann kannst du natürlich Prime Music nicht nutzen.

[gulp2k]

jonofe
Könnte man parallel noch mit der Session ID wie vorher arbeiten?
Ich möchte eigendlich nur sehr ungerne mein Amazon Password unverschlüsselt in Edomi ablegen, da hängt einfach zuviel dran...
Oder kann man einen Extra Alexa Account irgendwie erzeugen?

[jonofe]

Kann ich mir gerade keinen Reim drauf machen. Wenn die Kennung stimmt, dann sollte es eigentlich funktionieren.
Welche Eingänge hast du denn belegt? Lasse E6 mal leer.
Kenung ist dein normaler Amazon Account (E-Mail Adresse und Passwort an E3 und E4 und DE an E5)
Am besten noch mal mit 0 und 1 an E1 restarten. Eine 1 an E33 macht auch einen Restart.
Wurde schon ein File /tmp/.alexa.cookie angelegt?

[Winni]

jonofe
Freu mich sehr über das Update und wollte "meine" Version in die Tonne klopfen.... Leider gelingt nichtmal die Anmeldung an Alexa:

2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: LBS started
2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: exec(): Daemon is not running
2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: Starting Alexa Control daemon...
2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: exec(): Daemon is not running
2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: exec(): Starting daemon ...
2018-01-27 19:25:36		23751	debug	LBS19000809 [v0.9]: LBS ended
2018-01-27 19:25:39		26617	debug	EXE19000809 [v0.9]: Amazon Alexa Connection failed

Was kann ich denn da falsch gemacht haben? User-eMail und Passwort zigmal getestet, unter alexa.amazon.de funktioniert es

[jonofe]

Es gibt jetzt das Update den Alexa Control LBS v0.9, welcher jetzt folgende Features hat:

1. Nutzung des Amazon Accounts zur Aktualisierung des Cookies
2. Abspielen von
   1. Amazon tracks, playlists, queues,
   2. Library tracks und playlists
   3. TuneIn stations
3. Steuerung des Player:
   1. Play
   2. Pause
   3. Next/Previous
   4. Fwd/Rev
   5. Repeat
   6. Shuffle
4. Multiroom Support (Gruppieren von Echo Devices)
5. Bluetooth Verbindung
6. Regelmäßiges Update der Statusausgänge

Um dem Memory Leak von curl in PHP5.3.3 entegenzuwirken, gibt es einen Memory Reset Eingang (E33). Dieser sollte z.B. mit dem Stunden-Trigger-iKO von EDOMI verbunden werden.

Bei E16 kann man i.d.R. einen Klartextnamen des Serders verwenden und der LBS versucht dann über eine TuneIn Abfrage die Sender ID zu bestimmen. Funktioniert z.B. mit "1LIVE", "WDR2", "SWR3", etc.

Die notwendigen IDs für E17-E21 können mit dem Skript auf http://blog.loetzimmer.de/2017/10/am...hell-echo.html ermittelt werden. Der LBS basiert auf den Funktionen, die in diesem Skript implementiert sind. Dazu einfach das Skript mit dem entsprechenden Query Parametern starten und in den entsprechenden Temp-Dateien die IDs ermitteln. Ich werde dies ggf. noch im LBS ergänzen.

Kommentare/Anregungen wie immer gerne hier ...

[wintermute]

Ich verstehe den Hintergrund der Sache durchaus, aber dass der Speicher voll bei einem Linux-System "voll" ist, ist nun wirklich nix ungewoehnliches. Die Ursache fuer Deine Probleme liegt sicher woanders.
Beispiele - jeweils die Ausgabe von "top" weil die faelschlicherweise so oft herangezogen wird (Prozentwerte muss sich jeder selber ausrechnen, da bin ich jetzt zu faul zu ):

Edomi - Test-VM, 512MB, Uptime 42 Tage:

Mem:    501824k total,   490748k used,    11076k free,    98144k buffers
Swap:  1048572k total,    32172k used,  1016400k free,   161920k cached

Edomi - Produktivsystem, 2GB, Uptime 24 Tage:

Mem:   1921384k total,  1745564k used,   175820k free,    97800k buffers
Swap:  2097148k total,    39320k used,  2057828k free,  1130012k cached

Linux-Fileserver, 16GB, Uptime 92 Tage:

KiB Mem:  16325204 total, 16145760 used,   179444 free,   957360 buffers
KiB Swap:  8388604 total,    14856 used,  8373748 free. 11069692 cached Mem

Linux-Bastel-VM, 2GB, Uptime 51 Tage:

Mem:   2054064k total,  1987548k used,    66516k free,    14636k buffers
Swap:  2064380k total,  1262764k used,   801616k free,   127860k cached

Linux-MTA, 3GB, Uptime 92 Tage:

Mem:   2955976k total,  2724892k used,   231084k free,    62352k buffers
Swap:  2097148k total,   588304k used,  1508844k free,   153140k cached

Ich haette noch ein paar andere Maschinen, aber solange die im "normalen Wirkbetrieb" laufen (also zB keine grossen Speicherfresser die kuerzlich gestartet wurden und ein Leeren der Caches erzwungen haben) wird da keine bei sein wo die Speicherauslastung unter 80% liegt - wahrscheinlich sogar bei allen signifikant hoeher.
Wenn die dauerhafte Speicherauslastung bei 20% liegt, kannst du 3/4 deines Speicher ausbauen weil der schlicht nie gebraucht wird. 80% ist normal, 18% ist dekadent

[Winni]

Mag ja alles richtig sein, ich versuche halt aktuell dem Problem auf den Grund zu gehen, warum ich immer wieder Probleme mit KNX Verbindung und Speicherbedarf bis 80% habe. Beides geht irgendwie Hand in Hand und beginnt spätestens bei 20% und immer häufiger muss ich Edomi mehrfach täglich neu starten, weil ich nichts mehr auf den Bus bekomme, das kann ja nicht Sinn und Zweck sein.
Ich hatte Zeiten, da lief der Server wochenlang ohne irgendwelche Mucken.

[wintermute]

fürchte der LBS 19000523 von wintermute könnte das gleiche Problem haben

Das ist aber kein Problem, das ist einfach Absicht und hat schlicht mit dem Speichermanagement des Kernels zu tun...
Erstmal stellt sich ja fuer den unwissenden Beobachter die Frage: wieso baut ihr 8x soviel Speicher wie benoetigt in euren Edomi-Rechner um euch dann zu beschweren dass 20% davon auch tatsaechlich benutzt werden obowhl 5% ja auch reichen wuerden... was soll das System mit den ueberfluessigen 95% am Speicher denn anstellen? Fuer schlechte Zeiten aufbewahren?

Ansonsten: wenn Speicher zur Verfuegung steht, dann wird der Kernel den auch benutzen. Im haeufigsten (und am einfachsten zu verstehenden Fall) wird er als Cache fuer I/O Operationen benutzt. Der obigen Befehl mit dem /proc/blah/fasel fuehrt auch deswegen zur gefuehlten Verbesserung weil eben genau die Caches geleert werden und alle ausstehenden I/O-Operation gezwungen beendet werden. Wuerde es sich um ein Memory-Leak handeln, wuerde der Befehl garnix bringen denn dadurch wird einem Prozess kein Speicher weggenommen. Wie soll sowas auch funktionieren ohne den Prozess zu stoeren oder abstuerzen zu lassen? Genau deswegen kann man Memory-Leaks auch nur dadurch aus dem Weg raeumen indem man den betreffenden Prozess beendet.
Im uebrigen ist es nicht so trivial wie es scheint den tatsaechlichen Speicherverbrauch eines Prozesses festzustellen, wer das machen moechte kann aus /proc/<PID>/stat bzw /proc/<PID>/statm recht ausfuehrliche Informationen ueber das Speichernutzungsverhalten einzelner Prozesse rauslesen, angefangen von tatsaechlich belegten Pages, der Anzahl an Pages die der Prozess gern haben moechte, die Anzahl an Pages die der Kernel gern abgeben moechte, die Anzahl an Pages die im Swap liegen und noch viel mehr anderes, nicht nur ueber Pages

Wer noch keinen echten Memory-Leak gesehen hat dem sei gesagt: das ist keiner.

Weiterhin als gut gemeinten Rat: wenn ihr euren Speicher nicht braucht (oder brauchen wollt), dann verkauft ihn. Der ist ja von Tag zu Tag weniger wert