Einladung zum Beta-Test: "FHEMlazy" zur einfacheren Alexa-Integration

Begonnen von gvzdus, 23 Dezember 2018, 15:30:36

Vorheriges Thema - Nächstes Thema

gvzdus

Tja, so war das gemeint... Aber >>>> heisst eigentlich: Antwort geht raus.

Es gibt ein gewisses Zeit-Gap: Zu der geloggten Zeit sehe ich auf dem Server keinen Request. Aber das ist wohl ein Genauigkeitsproblem der Uhrzeit.

Ich würde mal das Device RGBWW rauswerfen, weil das retrievable false hat.

Und dann - solange zumindest sauber etwas rein- und rausgeht, die Anzahl der Geräte reduzieren, bis es funktioniert.

Aber Dein Connect-Problem ist jetzt weg? Mit dem key.pem? Da hatte ich eigentlich einen konkreten Verdacht...

Lucky2k12

Der connect geht jetzt reibungslos. Die Meldung mit dem key.pem kommt möglicherweise davon, dass ich nach dem Update erstmal noch den alten key drinhatte...
Macht das Sinn?
HP T610, HM, Jeelink, LGW, mapleCUL868+434

gvzdus

Nee, die Meldung dürfte dann kommen, wenn unter

{ "alexa": {

entweder "ssl" komplett fehlt, vielleicht aber auch "false" als String geschrieben ist.

Auf jeden Fall versuchte er, SSL hochzuziehen.


mark79

Zitat von: gvzdus am 03 Januar 2019, 22:33:08
Smarthome-Skill-API macht bei Amazon der Praktikant, und der hat sich da noch etwas verzettelt. Fragen im Amazon-Developerforum (auch auf Englisch) nach dem Motto
Kostprobe? Siehe hier:
https://forums.developer.amazon.com/questions/186240/rooms-support-with-groups-and-devices-duplicate-na.html

Der Praktikant, schön beschrieben. ;D Das ganze hat schon seine Eigenheiten die man erst mal kennen lernen muss.
So wie sich das für mich im Link ließt, rühren die Probleme daher, das die Leute dort mehrere gleiche Räume + Geräte haben und dazu zu viele Benutzer die eine Alexa haben.
Das ist bei mir nicht der Fall. Seit dem ich die Gruppen in der alexa APP angelegt habe, läuft es gut und ist es ein schönes upgrade zur ha-bridge.
Neue Geräte alexa fähig zu machen, ist einfacher und vor allem schneller geworden. Ich bin bisher begeistert, danke dafür an alle. :)
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

desmoloch

Mein Alexa Prozess macht nach 2 Stunden zusammen mit dem SSH immer einen Abgang... Er beendet sich einfach. Im Log steht nichts drin was die Ursache sein kann. Er geht einfach zu... :(

gvzdus

Dann wird node die Ursache sein ("alexa"), denn ein beendeter SSH-Prozess wird von Alexa nach Zeit X (15-135 Sekunden) neu gestartet.

Variante 1) Aktuell ist noch das Winston-Logging-Framework drin, das schreibt aber nicht die Todesursache weg. Falls unter /tmp kein Logging liegt: Wenn Du es Dir zutraust, so starten, dass stdout weggeschrieben wird.

Variante 2) Die nächste Version stützt sich auf Andres neues 39_alexa.pm, wenn installiert. Das startet ggf. alles automatisch neu.

Lucky2k12

#81
Zitat von: gvzdus am 04 Januar 2019, 23:22:22
Nee, die Meldung dürfte dann kommen, wenn unter

{ "alexa": {

entweder "ssl" komplett fehlt, vielleicht aber auch "false" als String geschrieben ist.

Auf jeden Fall versuchte er, SSL hochzuziehen.
HM, die config.json hatte ich nicht angefasst, nur ein 'git pull' für das Update.
Merkwürdig.
HP T610, HM, Jeelink, LGW, mapleCUL868+434

desmoloch

Zitat von: gvzdus am 04 Januar 2019, 23:40:03
Dann wird node die Ursache sein ("alexa"), denn ein beendeter SSH-Prozess wird von Alexa nach Zeit X (15-135 Sekunden) neu gestartet.

Variante 1) Aktuell ist noch das Winston-Logging-Framework drin, das schreibt aber nicht die Todesursache weg. Falls unter /tmp kein Logging liegt: Wenn Du es Dir zutraust, so starten, dass stdout weggeschrieben wird.

Variante 2) Die nächste Version stützt sich auf Andres neues 39_alexa.pm, wenn installiert. Das startet ggf. alles automatisch neu.

Danke für die Rückmeldung. Ich habe die neuste alexa-fhem Version aus GitHub jetzt erstmal wieder laufen. Die Latenz merke ich nicht und der Skill war eh schon eingerichtet :)
Ich schwenke wieder in ein paar Wochen um, jetzt ist erstmal das Ziel der Frau das Ganze schmackhaft zu machen ;)

desmoloch

Zitat von: gvzdus am 04 Januar 2019, 23:40:03
Dann wird node die Ursache sein ("alexa"), denn ein beendeter SSH-Prozess wird von Alexa nach Zeit X (15-135 Sekunden) neu gestartet.

Variante 1) Aktuell ist noch das Winston-Logging-Framework drin, das schreibt aber nicht die Todesursache weg. Falls unter /tmp kein Logging liegt: Wenn Du es Dir zutraust, so starten, dass stdout weggeschrieben wird.

Variante 2) Die nächste Version stützt sich auf Andres neues 39_alexa.pm, wenn installiert. Das startet ggf. alles automatisch neu.

Leider stürzt auch das "normale" alexa-fhem irgendwann ab. Meinste du mit Variante 1) so einen Start: bin/alexa > /tmp/alexa.stdout.log 2>&1 & ? Damit steht leider in der stdout.log nichts drin...

gvzdus

Ja. Das war gemeint. Vielleicht schreibt der Kernel gute Gründe für das aktive Abschießen ins Log? Wenn Du mir (ggf. per Privatnachricht) Deinen Präfix schickst (die erste Gruppe aus dem langen Schlüssel), kann ich Dir ein Logfile der Zugriffe von Alexa schicken (denn Amazon macht ab und zu einen Discover). Vielleicht korreliert das mit dem Todeszeitpunkt.

MarkusN

Wollte nur mal kurz Rückmeldung geben dass bei mir seit einigen Tagen alles wunderbar funktioniert.
Ich mache zwar viel selber, aber alexa-fhem einzurichten war mir immer zuviel Aufwand. Habe bisher ha-bridge benutzt, aber diese Lösung gefällt mir deutlich besser.
Danke für deine Arbeit Georg!

gvzdus

Moin,

ich habe eine neue Version fertig und nach GitHub und Co. hochgeladen.

Einerseits sind die Bugfixes von gestern drin.

Zweitens ist das Logging jetzt anständiger: Nutzt man weiterhin FHEM.Alexa.DOIF als Mechanismus, wird mit "-l" gestartet, und

  • die Logs landen unter /opt/fhem/log/alexafhem.log im Standardfall
  • Was der Prozess sonst beim Sterben schreit etc. unter /tmp/alexa.stdout.log

... womit wir zu Drittens kommen:

Das Modul soll und wird künftig unter Andre / justme1968 neuem 39_alexa.pm laufen. Muss es aber noch nicht.
Deswegen zieht "bin/alexa -A" die beiden Settings unter FHEM.Alexa "zu Andre" in das MyAlexa-Modul um. Natürlich automatisch, aber nicht darüber wundern. Auch, wer das bisherige Modul 39_alexa.pm verwendet, wird zumindest die Settings dort finden.

Also, nach dem Laufenlassen von "alexa -A" der neuen Version:

Wer das neue Modul 39_alexa.pm installiert hat:

  • Settings sind umgezogen]
  • Start-Mechanismus zieht zu "Andre" um
  • Logging ist in FHEM

Wer das Modul nicht installiert hat:

  • Settings sind umgezogen
  • Start-Mechanismus bleibt in FHEM.Alexa
  • Logging ist in /opt/fhem/log/alexafhem.log (o.ä.)

Den Wiki werde ich jetzt anpassen.

P.S.: Ab dieser Version keine Angst vor "bin/alexa -A". Wenn alles gut ist, läuft das so durch:
FHEM-Connectivity fine, CSRF-Token: csrf_4227.......199
existing config.json seems fine
SSH key seems to exist
Our SSH key is known at the reverse proxy, good!
[user]   executing: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_422787832422199&XHR=1

justme1968

im anderen thread: https://forum.fhem.de/index.php/topic,95272.msg880923.html#msg880923 gibt es auch ein update zum starten/stoppen, log file handling und default config erzeugen :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gvzdus

Okay, Dein "-c" war inkompatibel zu mir :-)

Version seit 21:11 Uhr funktioniert aber wieder.

Wer eine schöne config.json hat, und schon auf das neue Modul updated: Bitte config.json nach FHEM-ROOT: alexa-fhem.cfg kopieren.

Denn der Prozess möchte beim Start durch 39_alexa.pm die neue (durchaus logischere) Namensgebung /opt/fhem/alexa-fhem.cfg verwenden.

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968