[37_echodevice] Amazon Echo Modul (nicht Alexa)

[sash.sc]

Bei der Frage : "alexa wie warm ist es?" wird hier von einer Routine gesprochen.

Ist das eine Routine die über die Alexa app angelegt werden muss?

Habe es so verstanden.

1. Routine in Alexa App anlegen.
2. Angelegte Routine schaltet in ha bridge einen Aktor/Dummy.

3.fhem reagiert per notify auf den geschalteten Dummy /Aktor der ha bridge

4. Das notify auf sich aus den erwähnten Code zusammen.

Code Auswählen Erweitern


echo_.*:voice:..* {
if ($EVENT =~ m/wie warm ist/) {
fhem "set $NAME speak Die Temperatur beträgt [au_Wetterstation:temperature2] Grad";
}
}



Wobei das Gerät noch anzupassen wäre, aus dem die Temperatur kommen soll.


Habe ich da so richtig verstanden?

Gruß Sascha

[MadMax-FHEM]

Hallo Sascha,

fast

Es gibt 2 Notify:

1. reagiert auf das Schalten des Dummy von Alexa (ha-bridge) und setzt ein "get ECHO_IO_DEVICE settings" ab. (ECHO_IO_DEVICE = Anmelde-Device / Haupt-Device wie immer man das nennen will)

2. ist dann wie von dir beschrieben und macht die eigentliche Ausgabe und klar das natürlich anpassen auf das Gerät wo bei dir die Temp her kommt


Für weitere Befehle dann nur den "Code" im Notify "aufbohren", also weitere "ifs" und "Antworten" einbauen...
...oder dann evtl. besser in eine Sub auslagern...

Gruß, Joachim

[sash.sc]

Hallo Sascha,

fast

Es gibt 2 Notify:

1. reagiert auf das Schalten des Dummy von Alexa (ha-bridge) und setzt ein "get ECHO_IO_DEVICE settings" ab. (ECHO_IO_DEVICE = Anmelde-Device / Haupt-Device wie immer man das nennen will)

2. ist dann wie von dir beschrieben und macht die eigentliche Ausgabe und klar das natürlich anpassen auf das Gerät wo bei dir die Temp her kommt


Für weitere Befehle dann nur den "Code" im Notify "aufbohren", also weitere "ifs" und "Antworten" einbauen...
...oder dann evtl. besser in eine Sub auslagern...

Gruß, Joachim

Kann man die beiden notifys in einen zusammen fassen?

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[MadMax-FHEM]

Das wird wohl nicht gehen und ist auch nicht sinnvoll, spätestens wenn mehrere Befehle folgen...

Ein Notify triggert auf den jeweiligen Dummy der eben von ha-bridge per Alexa-Routine (oder auch ihne Routine, die ist ja "nur" wegen der besseren/"freien" Formulierung) geschaltet wird...

Der müsste ja dann statt einem Schaltbefehl ein set voice bekommen, was per ha-bridge nicht geht...
...und auch vom Namen her passen, damit eben das RegEx des Notify passt...

EDIT: also zu dem RegEx des ECHO-DEV-Notifys passt. Dort müsste dann aber unterschieden werden können, ob nun von dem Dummy oder tatsächlich das "voice" des jeweiligen Echo-Gerätes upgedatet wurde

Beides nicht wirklich möglich.

Wenn ein weiterer Befehl kommt, dann braucht es einen weiteren Dummy mit entsprechendem Notify welches das get ECHODEV settings absetzt...

Was man machen kann/sollte (da die Dummys ja nur "Hilfskonstrukte" sind) ist die Namen der "Hilfs-Dummys" so wählen, dass man nur ein Notify braucht, welches eben das "set ECHODEV settings" absetzt...

Dann bleibt es bei den 2 Notify und nur das 2te Notify muss halt entsprechend um weitere "ifs" und "Antworten" erweitert werden...

EDIT2: und mit 2 Notify wenn man es geschickt macht kann man dann alles erschlagen, man braucht halt nur einen Dummy pro Schaltbefehl... Und so zwei Notify tun nicht mehr "weh" als einer

Gruß, Joachim

[call_me_driver]

Servus!

geh ich richtig in der Annahme, dass der Echo Dot Gen 3 noch nicht erkannt wird?
bzw erkannt schon aber ohne Möglichkeit von get und set?

Gruß
Maddin

[tb-killa]

Hallo Michael,
gibt es die Möglichkeit irgendwie den aktuellen Bestand seiner Routinen anzeigen zu lassen?
Damit meine ich nicht die Namen sondern die Informationen innerhalb der Routine selbst, Trigger und Aktion.

Man könnte diese Daten nutzen um sich eine Sicherung seiner Routinen anzulegen, denn unter anderem hat man schon mitunter mehr als 40 Routinen für seine bestimmten Zwecke.
Schade dass man Routinen noch nicht automatisiert anlegen lassen kann.

Grüße

[tb-killa]

Das wird wohl nicht gehen und ist auch nicht sinnvoll, spätestens wenn mehrere Befehle folgen...

Ein Notify triggert auf den jeweiligen Dummy der eben von ha-bridge per Alexa-Routine (oder auch ihne Routine, die ist ja "nur" wegen der besseren/"freien" Formulierung) geschaltet wird...

Der müsste ja dann statt einem Schaltbefehl ein set voice bekommen, was per ha-bridge nicht geht...
...und auch vom Namen her passen, damit eben das RegEx des Notify passt...

EDIT: also zu dem RegEx des ECHO-DEV-Notifys passt. Dort müsste dann aber unterschieden werden können, ob nun von dem Dummy oder tatsächlich das "voice" des jeweiligen Echo-Gerätes upgedatet wurde

Beides nicht wirklich möglich.

Wenn ein weiterer Befehl kommt, dann braucht es einen weiteren Dummy mit entsprechendem Notify welches das get ECHODEV settings absetzt...

Was man machen kann/sollte (da die Dummys ja nur "Hilfskonstrukte" sind) ist die Namen der "Hilfs-Dummys" so wählen, dass man nur ein Notify braucht, welches eben das "set ECHODEV settings" absetzt...

Dann bleibt es bei den 2 Notify und nur das 2te Notify muss halt entsprechend um weitere "ifs" und "Antworten" erweitert werden...

EDIT2: und mit 2 Notify wenn man es geschickt macht kann man dann alles erschlagen, man braucht halt nur einen Dummy pro Schaltbefehl... Und so zwei Notify tun nicht mehr "weh" als einer

Gruß, Joachim

Hallo Joachim,

wichtig ist auch, vorab einen filter im Verarbeitungsprozess vom notify einzubauen, welcher nur Bearbeitungen zulässt, wenn im Voice-String NICHT "sprich mir nach" mit vorkommt, ansonsten bekommt man eine nett klingende Wiederholung (Loop) hin.

Gruß

[MadMax-FHEM]

Wenn man das "Feature" nur mittels Regeln und Dummy nutzt sollte da nichts passieren, da ja im 2ten Notify (auf voice-Reading) geprüft wird, welcher Befehl denn bearbeitet werden soll...

Die "Abfrage/Prüfung" muss nat. passen...

Wenn das dann doch mit einem Dummy zur Befehlszwischenspeicherung arbeitet (wie meine erste Überlegung), dann kann da gar nichts passieren, weil nur ein Befehl "gespeichert" wird, wenn auch ein Schaltbefehl gekomme ist.
(Löschen des Befehls nach der Auführung halt nicht vergessen   )

Was man noch tun könnte (weil ich grad so drüber nachdenke) ist den empfangenen Befehl dann von anderen Modulen auswerten zu lassen, als da wären: TEERKO, Talk2Fhem, Babble, ...

Gruß, Joachim

[awel]

Ja die Sprachausgabe über speak wird mit der Lautstärke vom Alarmvolumen angespielt wenn die größer des normalen Volume ist.Steht so auch in der Doku

Danke, habe ich wohl übersehen, sorry.
Könntest Du das optional machen? Wenn man den Alarm lauter eingestellt hat als die übliche Wiedergabe, gibt es vor und nach jeder Speak-Anweisung die Signaltöne der Lautstärkeänderung. Außerdem muss sicher nicht jede Speak-Anweisung mit Alarmlautstärke erfolgen.

Danke!
VG Achim

[sinus61]

Was man machen kann/sollte (da die Dummys ja nur "Hilfskonstrukte" sind) ist die Namen der "Hilfs-Dummys" so wählen, dass man nur ein Notify braucht, welches eben das "set ECHODEV settings" absetzt...

Man braucht ja eh nur einen Hilfs-Dummy, der aus allen Routinen angesprochen wird. Der hat ja nur die eine Aufgabe das notify zu triggern, der Befehl an die ha-bridge ist immer gleich. An dieser Stelle wird ja noch keine Auswertung der Frage gemacht.

[sinus61]

wichtig ist auch, vorab einen filter im Verarbeitungsprozess vom notify einzubauen, welcher nur Bearbeitungen zulässt, wenn im Voice-String NICHT "sprich mir nach" mit vorkommt, ansonsten bekommt man eine nett klingende Wiederholung (Loop) hin.

Das Notify wertet die Frage aus, im Voice Reading erscheint ja die Antwort. Wenn man relativ viele Sachen da einbauen will, muss an natürlich drauf achten, dass nicht irgendwann Antworten wieder als Frage aufgefasst werden. Daher sollte man am besten im Notify auf den ganzen Satz der Routine prüfen, nicht nur einfach z.B. auf "warm".

Aber wenn man mehr machen will wäre es wohl tatsächlich einfacher das dann an eines der Sprachmodule weiter zu reichen und dort auszuwerten.

[MadMax-FHEM]

Man braucht ja eh nur einen Hilfs-Dummy, der aus allen Routinen angesprochen wird. Der hat ja nur die eine Aufgabe das notify zu triggern, der Befehl an die ha-bridge ist immer gleich. An dieser Stelle wird ja noch keine Auswertung der Frage gemacht.

Das ist mir schon klar.
Ist/wäre nur eine "Zusatzsicherung" um zu vermeiden, dass irgendwas Gesprochenes ohne tatsächlichen Sprachbefehl eine zufällig in einer voice-Reading-Abfrage passenden Schaltung/Ansage führt...

P.S.: führt aber wohl langsam am eigentlichen Thema des Threads vorbei...

Gruß, Joachim

[miche]

hallo,

die neueste Version funktioniert. Jedoch wird der playStatus nicht aktualisiert!

[StephanFHEM]

Hallo Michael,

unabhängig von meinem Sonos Beam (der leider immer noch nicht geht) hat sich in einer der letzten Versionen ein Bug eingeschlichen mit dem ich zu kämpfen habe. Ich habe im TabletUI Popups die auf Timer reagieren was bisher auch super geklappt hat. Leider ist das jetzt nicht mehr sehr. Hintergrund ist, dass die alten Timer auf Null laufen aber nie rausgeschlöscht werden.
Wenn ich einen neuen Timer setze macht er dann immer einen weiteren Index im Reading auf ...z.B.: timer_03_remaining. das Reading Timer_Count geht dann auch auf 3 hoch obwohl ich nur einen Timer habe.

Kannst du dir das bitte mal anschauen? Sollte bei jedem nachstellbar sein aber fällt wahrscheinlich nicht weiter auf bei "normaler" Nutzung.

Grüße
Stephan

[awel]

Ist/wäre nur eine "Zusatzsicherung" um zu vermeiden, dass irgendwas Gesprochenes ohne tatsächlichen Sprachbefehl eine zufällig in einer voice-Reading-Abfrage passenden Schaltung/Ansage führt...

Ich habe etwas gespielt und ein "ignoreVoiceCommand"-Attribut in meine Modul-Version eingebaut. Allerdings mit anderer Motivation
Als Inhalt des Attributes wird eine regulärer Ausdruck akzeptiert, der Inhalt wird nicht als voice-Befehl interpretiert, löst kein Ereignis aus und wird nicht als voice-Reading angezeigt.

Meine Motivation / Beispiel:

• Routinen werden entweder mit Alexas OK oder im Kurzmodus mit einem Signalton abgeschlossen.
• Diese Rückmeldung unterbleibt, wenn man in der Routine Alexa einen freien Text sagen lässt, z.B. "einen Moment"
  Ergebnis: "Alexa, wie warm ist es" - "einen Moment" -"die Aussentemperatur beträgt 2 Grad" ohne Signalton oder "OK"
• Dieser freie Text erscheint im voice-Reading immer mit "sprich mir nach <freier Text>", damit ist der eigentliche Befehl, den man auswerten will, aber überschrieben.
  ... es sei denn, "sprich mir nach" wird vom Modul ignoriert, dann steht wieder der gewünschte Befehl im Reading.

Lösung, meine Veränderungen im Modul v0.0.49:

Code Auswählen Erweitern

Zeile 329, einfügen:
"intervalvoice:slider,0,1,100 ".
-> "ignoreVoiceCommand ".
"server ".

Zeile 2505/6, einfügen:
my $timestamp = int(ReadingsVal($echohash->{NAME},'voice_timestamp',time));
-> my $IgnoreVoiceCommand = AttrVal($name,"ignoreVoiceCommand","");
#Log3 $name, 3, "[$name] [echodevice_Parse] [" . $echohash->{NAME} . "] timestamp = $timestamp / " . int($card->{creationTimestamp});

Zeile 2513, einfügen:
next if($card->{description} !~ /firstUtteranceId/);
-> next if($IgnoreVoiceCommand ne "" && $card->{description} =~ m/$IgnoreVoiceCommand/i);
               
Michael, ich hoffe, das ist so richtig. Falls nicht, wäre ich für eine Korrektur dankbar.

Vielen Dank, Grüße
Achim

Edit, ich vergaß: Das Attribut ist im Account zu setzen, nicht in den einzelnen Geräten