39_alexa.pm und alexa-fhem test version

[gvzdus]

Ich weiß nicht: Auf der Kommandozeile fühlst Du Dich nicht so wohl, oder?

Konkret gäbe es m.E. nur eine Erklärung für Deine Beobachtung auf einem Unix-System:
Das Home-Directory für den User ("fhem" typsicherweise) liegt unter "/tmp".

Es gibt weder bei mir noch bei Andre eine Routine, die SSH-Keys wegmüllert!

Ändern sich denn tatsächlich mit jedem neuen Schlüssel die ersten 5-6-Zeichen bis zum "-"?

[justme1968]

also.... das klingt alles sehr komisch.

- meine aktuelle version (per sudo npm install -g alexa-fhem) sollte bemerken wenn fhem abschmiert und sich selber beendet

- bitte schau im log in dem die alexa ausgabe landet warum der prozess nicht weiter läuft.

- nach dem erzeugen der Keys und speichern im fhem reading muss man tatsächlich ein mal save sagen sonst werden ja die readings nicht gespeichert. ich weiss nicht ob gvzdus das schon automaisch macht wenn autosave gesetzt ist

- kann es sein das aus irgendeinem grund bei dir zumindest zeitweise zwei unterschiedliche alexa-fhem versionen liefen?

[sTaN]

Ich weiß nicht: Auf der Kommandozeile fühlst Du Dich nicht so wohl, oder?

Ja doch es geht. Kein Profi aber schon recht komfortabel mit dem Nötigsten.

Ändern sich denn tatsächlich mit jedem neuen Schlüssel die ersten 5-6-Zeichen bis zum "-"?

Nein die ersten 6 Zeichen bis zum Minus sind immer identisch aber alles danach ändert sich. Aber reicht es dem Alexa Skill aus, dass die ersten 6 Stellen gleich bleiben?
Es gab bei mir ja noch das:
#define FHEM.Alexa.autostart notify global:INITIALIZED.* set FHEM.Alexa Start
welches ich nun in der fhem.cfg aus kommentiert habe, da es glaube noch aus deiner ursprünglichen Installation war. Aber auch nach dem ich dies getan und den RPi neugestartet habe, wurde mir ein neues MyAlexa Device angelegt und meine gesetzten Attribute siehe Beitrag zuvor waren wieder gelöscht.

[gvzdus]

1) Also, neue SSH-Keys generiert er nicht. Sonst hätten sich die ersten Zeichen geändert.
2) Lösch bitte das Device "autostart" komplett weg - macht jetzt alles der Andre . Am besten auch FHEM.Alexa, so noch da, u.s.w.
3) Du hast auch definitiv keine Alt-Installation mit Systemd o.ä., die noch hochfährt?
4) Den "Lizenz-Key" brauchst Du nur, um den Skill zu verknüpfen. Theoretisch also nur einmal im Leben. Der SSH-Proxy geht dumpf nach Deinem SSH-Key vor, und der hat sich nicht geändert. Deswegen "klappt es" auch.

[gvzdus]

P.S. Was aber nicht klappt: Das "bearerToken" muss überleben, weswegen Du auch "Save Config" klicken solltest. Denn das liegt bei Amazon, und der Alexa-Prozess bei Dir lokal muss es überprüfen. Er holt es aus dem Alexa-Device. Wenn es da aber nicht zu finden ist, kann er keine Anfragen von Alexa annehmen.

Dann musst Du tatsächlich einen neuen Zugangs-Key generieren, den Skill entknüpfen und neu verbinden.

Lies Dir bitte mal die Erläuterungen auf der Wiki-Seite durch (zu dem Schlüssel, unten), dann verstehst Du das Prinzip

[sTaN]

Ich habe mir mal das FHEM Verzeichnis angeschaut und stelle fest, dass sich die Berechtigungen der fhem.cfg von fhem dailout auf fhem root geändert haben. Weiterhin gibt es vom letzten Neustart um 16.20 Uhr eine alexa-fhem.cfg.previous.

Es läuft aktuell nur ein Prozess:

Code Auswählen Erweitern

ps -ef | egrep '(alexa|ssh)'

root       498     1  0 16:21 ?        00:00:00 /usr/sbin/sshd -D
root       573   498  0 16:21 ?        00:00:00 sshd: pi [priv]
pi         615   573  0 16:21 ?        00:00:00 sshd: pi@pts/0
fhem       650   594  0 16:21 ?        00:00:03 node /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
fhem       681   650  0 16:21 ?        00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:3000 -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
pi         742   618  0 16:55 pts/0    00:00:00 grep -E --color=auto (alexa|ssh)

Okay Zusammenspiel bearerToken und RegKey/Anmelde Secret ist klar. Also ist nicht der SSH Key das Problem, sondern der neu erstellte bearerToken. Dadurch, dass also scheinbar das MyAlexa Device nach jedem Pi Neustart neu generiert wird, ändert sich der bearerToken und ich muss somit den neuen RegKey dem Alexa Skill bekannt machen.

Alte Devices von dir sind gelöscht. (war nur noch das FHEM.Alexa.autostart vorhanden)
Hast du noch einen Tipp, wo ich auf der Kommandozeile prüfen kann, ob von dir noch alte "Leichen", systemd Prozess etc. laufen oder irgendwo versteckt sind, die ggf. rein pfuschen?

Gruß und Danke!

EDIT: Sobald ich auch nur in die fhem.cfg rein gehe und dort manuell eine Änderung mache, generiert sich der bearerToken und RegKey neu mit aktuellem Zeitstempel, wo die fhem.cfg gespeichert wurde. Auch dann muss ich im Alexa Skill den RegKey neu eingeben.
Verstehe nicht, was das in diesem Fall nur auslösen kann?!

[gvzdus]

Auaah!!!

Mein Riesenfehler.
Ich dachte, mit "setreading" hätte ich "bei Andre" einen Permanent-Speicher, sofern die Nase vor dem Bildschirm auch "Speichern" druckt
Dem ist aber nicht so! Verflixte Axt!

Deswegen ist Deine Beobachtung völlig richtig, normal und genau so, wie es der Programmierer geschrieben (aber nicht gewollt) hat.

Puh, jetzt muss ich mal mit Andre überlegen, wo das BearerToken langfristig und sicher gespeichert werden kann. Natürlich sind auch Meinungen von anderen gefragt
Meine Zielsetzung war immer, dass es im (einfachen) User-Zugriff sein sollte, damit jeder eine Idee hat, wie er im Zweifelsfall der Lady den Zugang von außen abklemmt...

[sTaN]

Puh danke Georg....Hab echt ein wenig an mir gezweifelt, was aber auch nichts heißen mag! Aber mein letzter EDIT im oberen Beitrag beweist, dass es sogar nach dem fhem.cfg save passiert. 
Hauptsache Fehler gefunden!

EDIT: Das dürfte ja dann auch die Ursache sein, dass die ganzen gesetzten Attribute ebenfalls gelöscht werden, richtig?

[justme1968]

doch. mit setreading uns save ist alles sicher gespeichert. readings und attribute.

wenn das nicht geht stimmt etwas nicht. vermutlich dir permissions vom fhem save file.

wenn deine config falsche permissions hat deutet das auch darauf hin.

am besten auch die config niemals von hand editieren. es geht alles über fhemweb.

[dominik]

@justme1968, da ich gerade an einer einfachen Lösung für Google Assistant dran bin, hättest du Interesse ähnliches auch dafür umzusetzen? Oder eine generische Lösung daraus zu machen?

Ich bräuchte nur einen Prozessstart und die config.json Einträge durch FHEM geregelt, da wäre den Usern dann zukünftig sehr geholfen.

[justme1968]

ja. gerne.

lass uns die alexa version so weit fertig bekommen das sie per update raus geht.

danach passe ich es auf eine google version an.

[dominik]

Perfekt, danke!

Ein Punkt ist wahrscheinlich etwas anders als bei der Alexa Integration:
- Beim ersten Start muss der User eine URL in seinen Browser eingeben und sich einloggen
- Dort erhaelt er einen Code der aktuell in die Console kopiert werden muss
- Danach wird ein Refresh Token gespeichert und dieses Prozedere ist kein weiteres Mal notwendig

Meine Überlegung ist über ein setreading die URL in FHEM anzeigen lassen und den Code über einen set Befehl eingeben lassen. Damit muss der User nie auf die Console.

[justme1968]

kein problem.

[justme1968]

es gibt im ersten post hier: https://forum.fhem.de/index.php/topic,95272.msg880923.html#msg880923 ein letztes update bevor die neue version morgen normalen fhem update mit kommt.

wichtigste änderung: es gibt ab sofort einen regulären öffentlichen FHEM Connector skill.

[Spezialtrick]

Ich habe die finale Installationsmethode sofort mal ausprobiert. 

Das Handling ist wirklich spitze. In der Summe hat die Installation auf meinem NUC nur wenige Sekunden dauert.

Leider erhalte ich dennoch eine kleineren Fehler, der wahrscheinlich unbewusst von mir verursacht wird. 

Nach der Definition des Alexa Devices in FHEM sollten ja eigentlich die Keys als Readings erscheinen. Dies passiert leider nicht.
Das AlexaFhemLog zeigt mir folgenden Fehler an:

Code Auswählen Erweitern

[2019-1-12 19:42:50] Server listening on: http://127.0.0.1:39363 for proxy connections
[2019-1-12 19:42:50] Passed config: {"sshproxy":{"ssh":"/usr/bin/ssh","description":"FHEM Connector","bind-ip":"127.0.0.1","port":39363},"connections":[{"webname":"fhem","uid":1000,"name":"FHEM","filter":"alexaName=..*","server":"127.0.0.1","port":"8083"}]}
[2019-1-12 19:42:50] [FHEM] longpoll error: Error: self signed certificate, retry in: 5000msec
(node:6166) UnhandledPromiseRejectionWarning: ReferenceError: reject is not defined
    at runAutoconfig (/usr/lib/node_modules/alexa-fhem/lib/user.js:310:7)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
(node:6166) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:6166) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.


Liegt es möglicherweise daran, dass bisher nicht die Credentials meiner FHEM Umgebung in der Config angegeben habe?