39_alexa.pm und alexa-fhem test version

[justme1968]

ich habe eben den start des ssh tunnels von gvzdus in meine GitHub version und die bei npmjs veröffentlichte version gemerged.

d.h. auch für den betrieb mit dem tunnel und proxy über den vereinsserver ist die schnellste version alles zum laufen zu bringen:

- node installieren
- sudo npm install -g Alexa-Fhem
- define alexa alexa

es sollte dann im normalfall alles automatische gehen. wenn die letzten probleme ausgebügelt sind wird dann auch das wiki erweitert bzw. umgestellt.


der skill ist zur zeit auch bei amazon zur zertifizierung. ich denke aber das wird noch mehr als eine iteration brauchen.

[mark79]

Eine Frage zu den automatisch, gilt das auch, wenn man noch die alte alexa Fhem Tunnel Methode am laufen hat, mit den DOIF, Dummy etc.?
Oder sollte ich die vorher besser löschen, wenn ich auf das neue wechseln möchte?

[Loredo]

Kann man den Subprozess auch unter anderer UID/GID starten lassen? Dann wäre tatsächlich zu überlegen, ob ein separater Container überflüssig wäre.

[justme1968]

@mark79: wenn du den neuen start laufen hast am besten alles weg.

@Loredo: noch nicht, für den remote start mit ssh wird das 'automatisch' über den ssh_user gehen. das würde auch für ssh nach localhost gehen.

direkt eine andere uid/gid anzugeben würde nur gehen wenn fhem als root läuft, sonst darf man ja nicht einfach kreuz und quer wechseln.

[MadMax-FHEM]

alles gut. legacy ist bald erledigt

Ok...

für die fälle bei denen weder der lokale noch der remote start über das modul geht wäre es schön deine alternative zu dokumentieren. aber wirklich nur als fallback.

Wo/wie soll ich das machen?

Gruß, Joachim

[MadMax-FHEM]

Hi André,

ich frage mal hier (aber auch im anderen Thread bei Georg, schon geschehen):

aktuell habe ich ja 3 fhem die von 2 alexa-fhem Installationen "bearbeitet" werden...

Also meine bisherige Umgebung:

alexa-fhem "legacy", manuell "installiert" und als Systemdienst eingerichtet bzgl. Start (noch initd aber systemd kein Problem, mir fehlte nur die Zeit und macht ja jetzt keinen Sinn mehr) und "kontrolliert" in fhem mittels serviced-Modul (statt Dummy/DOIF).

Smart Home Skill (V3) + 2x Custom Skill

Mein Haupt-fhem und mein Test-fhem.
Da einige "Devices" noch auf dem Testsystem weilen (keine Zeit für den Umzug) ich diese aber per Alexa steuern will/wollte habe ich einfach eine 2te Connection in die config.json eingetragen: läuft.


Dann habe ich ja für alexa-fhem lazy (und auch für die "Erweiterung" von André) ein weiteres Testsystem aufgesetzt (nur zum Testen).
Aber da wird ja die config.json (jedesmal? auch bei Update?) automatisch geschrieben!?
Wenn ich da nun eine 2te Connection eintrage wird das ja jedesmal? wieder "rausgeworfen" oder liege ich hier falsch?
Bzw. wie trage ich sowas ein damit es bleibt.

Gleiches gilt ja (aktuell noch) für den bzw. die Custom Skill(s), die muss man ja auch weiterhin manuell eintragen oder braucht man dafür extra eine weitere alexa-fhem Installation (wie ich verstanden habe: nein).

Ich weiß evtl. hier an dieser Stelle und beim aktuellen Stand der Dinge "unpassend" aber irgendwann wird es (zumindest für mich) relevant...

Danke, Joachim

[justme1968]

hab im anderen thread geantwortet

[punker]

@justme1968
Hab heute ein FHEM-Update gemacht und feststellen müssen dass dein 39_alexa.pm von einer alten Version überschrieben wurde und danach Alexa mehr lief.
War das ein Versehen dass die neue Version noch nicht mit dem Update kommt oder kommt die erst später ins Update?

[justme1968]

die neue version ist noch nicht eingecheckt.

ich habe noch kein feedback ob bei alten installationen alles problemlos weiter geht.

ich checke sie ein wenn ich bis morgen kein: 'alles schrecklich, nicht einchecken' bekomme.

[sTaN]

In die Falle bin ich gestern beim Installieren auch rein getappt! Wie im Parallelthread beschrieben bin ich auch davon ausgegangen, dass die neue 39_alexa.pm vorhanden ist. Aber ich kann schon mal zurück melden, dass mit Andres aktuellster Version bisher alles gut funktioniert. Verschiedene Devices wie Max! Wandthermostate, Philips Hue Leuchten, FS20 Steckdosen und weitere Devices gut funktionieren. Auch läuft alexa-fhem seit gestern Abend stabil durch und tut für meine anfänglichen Zwecke was es soll!

EDIT: Eine Sache fällt mir doch noch auf. Wenn ich neuen Geräten das Attribut alexaName zuordne, dann reicht ein Reload des MyAlexa Devices nicht aus und ich muss es neustarten! Ist das normal?

[justme1968]

bei neuen geräten ist noch ein set <alexa> restart und eine geräte suche bei amazon nötig.

wenn der alexaName nur geändert wird geht das schon automatisch.

das es beim neu anlegen automatisch geht kommt noch.

[sTaN]

Ihr macht mich glücklich! 
Die Arbeit kann man wirklich nicht genug loben! Ich bin allein auch begeistert, wie schnell die Geräte tatsächlich reagieren. Kaum hat man es ausgesprochen, geht das Licht an, ändert die Farbe oder die Temperatur hat sich geändert. Wirklich genial, wenn man bedenkt welche Wege dazwischen liegen!

Hatte zuvor zwar schon Siri mit der Homebridge von dir aber das ist nach meinem Gefühl wesentlich schlechter und langsamer. Neuerdings geht auch der Befehl "Schalte den Schreibtisch im Büro ein" mit Siri nicht mehr aber der Befehl "Schreibtisch im Büro ein" wiederum ja. Aber auch nicht immer zuverlässig und meistens mit einer merklichen Bedenkzeit. Aber das ist Off-Topic, soll nur noch mal das Projekt hier hervorheben!

Gruß und Danke!

[sTaN]

Hi Andre,

Nachricht war zunächst im falschen Thread. Mir ist soeben aufgefallen, dass ich alle 21-22 Sekunden folgende Fehler im FHEM Web unter Logfile bei verbose 2 erhalte:

Code Auswählen Erweitern

2019.01.10 12:59:31 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:59:10 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:58:48 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:58:27 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg

Dabei ist mir aufgefallen, dass dies erst zum Zeitpunkt auftritt, als mir FHEM abgeschmiert ist während die Philips HUE Bridge ein Update gemacht hat. Während dem HUE Bridge Update (also dem Update über die Philips HUE App) stürzte fhem ab und ich habe es anschließend mittels sudo /etc/init.d/fhem start erneut gestartet. Wurde hier manchmal alexa-fhem doppelt gestartet?

Code Auswählen Erweitern

019.01.10 12:59:53 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:59:31 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:59:10 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:58:48 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:58:27 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:58:20 2: Stereoanlage: second attempt to read timed out, this is an unrecoverable error.
2019.01.10 12:58:20 1: Stereoanlage: Can't connect to 192.168.XXX.XXX:XX: Connection timed out
2019.01.10 12:58:17 2: Stereoanlage: first attempt to read timed out, trying to close and open the device.
2019.01.10 12:58:06 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:57:44 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:57:18 2: AttrTemplates: got 35 entries
2019.01.10 12:57:18 1: Stereoanlage: Can't connect to 192.168.XXX.XXX:XX: 192.168.XXX.XXX: No route to host
2019.01.10 12:57:18 1: Stereoanlage: Can't connect to 192.168.XXX.XXX:XX: Illegal seek
2019.01.10 12:57:17 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:57:16 0: Server started with 222 defined entities (fhem.pl:18111/2019-01-01 perl:5.024001 os:linux user:fhem pid:1991)
2019.01.10 12:57:16 0: Featurelevel: 5.9
2019.01.10 12:57:16 1: usb create end
2019.01.10 12:57:09 1: usb create starting
2019.01.10 12:57:08 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_HUEDevice.pm line 1261.
2019.01.10 12:57:08 2: Bad_WEEKPROFILE(assignDev): device BA_Wandthermostat not supported or defined
2019.01.10 12:57:08 1: Including ./log/fhem.save
2019.01.10 12:57:08 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:57:08 2: MyAlexa: created default configfile: ./alexa-fhem.cfg
2019.01.10 12:57:07 2: EGPM2LAN Powerstate: 0,0,0,0
2019.01.10 12:57:02 1: Including fhem.cfg
2019.01.10 12:52:32 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
'(HUEDevice_devStateIcon($name),"toggle")' is an unknown bound type in regex; marked by <-- HERE in m/\b{(HUEDevice_devStateIcon($name),"toggle") <-- HERE }:([^ ]*)/ at ./FHEM/01_FHEMWEB.pm line 1769.
2019.01.10 12:41:39 2: MyAlexa: starting alexa-fhem: /usr/bin/alexa-fhem -c ./alexa-fhem.cfg
2019.01.10 12:39:07 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:39:07 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:39:02 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:39:02 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:39:02 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:58 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:54 2: harmonyhub: disconnect
2019.01.10 12:38:54 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:50 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:46 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/lights: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:42 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/lights: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:38 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:34 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:30 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:26 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:21 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80
2019.01.10 12:38:21 1: HUEBridge_HTTP_Request http://192.168.XXX.XXX/api/07d74638e634312ffe0e26c1d2bf5e3f/sensors/12: Can't connect to http://192.168.XXX.XXX:80

Gruß sTaN

[sTaN]

Es wird noch besser. Ich hatte mein MyAlexa Device im Raum Wohnzimmer und dort war es verschwunden. Nun taucht unter unsorted scheinbar ein neues MyAlexa auf, ohne meine Attribute und auch ohne bearerToken und SSH Key! Aber es funktioniert noch alles. Ich werde wohl mal einen erneuten Pi Neustart machen.

EDIT: Leider ein sehr unschönes Verhalten:
Nachdem ich nun den Raspberry Pi neugestartet hatte, läuft augenscheinlich wieder alles. ABER: der SSH Key hat sich geändert und somit sind meine ganzen Geräte und Szenen und Routinen in der Alexa App nicht mehr ansprechbar. Muss den Skill vermutlich deaktivieren, aktivieren und alles neu suchen und einrichten. Für mich sieht es also aus, wenn FHEM mal abstürzen sollte, dass er einen komplett neuen SSH Key generiert, was sicher nicht gewünscht ist?!

EDIT2: Okay die Geräte und Szenen blieben erhalten und funktionieren auch nach dem deaktivieren und erneutem aktivieren des Skills. Aber es wurde ein neuer SSH Key generiert, welcher bei der erneuten Aktivierung eingegeben werden muss.

[sTaN]

Okay es hat sich also bewahrheitet. Nach jedem Neustart des Rasberry Pi wird automatisch ein neues MyAlexa Device angelegt und ein neuer bearerToken und SSH Key vergeben. Weiterhin werden alle nachträglich gesetzten Attribute wie in meinem Fall:

Code Auswählen Erweitern


attr MyAlexa room Wohnzimmer
attr MyAlexa group Systeme
attr MyAlexa stateFormat alexaFHEM
attr MyAlexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
gelöscht. Kurz nachdem Neustart muss also in FHEM Web auf Save config geklickt werden und der neue SSH Key in der Alexa Skill Konfiguration durch de- und aktivieren des Skills gesetzt werden. Habe also bereits den 4. SSH Key