Weihnachtsangebot 2025! 🎄

[Arnulf]

@ingod:

Das Speak hab ich jetzt nur zum testen eingebaut. :-)

Das funktioniert auch, wenn ich jetzt hier im Wohnzimmer Alexa anspreche kommt auch das Speak. Gehe ich dann ins Schlafzimmer wird auf dem Spot-Bildschirm quittiert aber die Sprachausgabe kommt aus dem Wohnzimmer.

Genauso beim Umschalt-Skript. Bestätigung kommt visuell auf dem Spot Bildschirm aber umgeschaltet wird im Wohnzimmer und "Echo Device Name" bleibt auf Echo-Wohnzimmer stehen.

Irgendwo ist da der Wurm drin. `

Habe das gleiche Problem. Glaube aber zu wissen, warum das so ist:

Sobald ein Speak-Kommando an die Alexa geschickt wird, ist diese Alexa auch wieder die zuletzt verwendete.

Es ist also nicht das Device, das das letzte Sprachkommando von außen erhalten hatte, sondern, das die letzte Anweisung erhalten hat.

Wenn ich also ein Speak unterlasse, stimmt die History.

Nur: Ich wollte tatsächlich das kommando ausgeben

[apollon77]

An sich korrekt. Ein speak Ist nichts anderes wie „Alexa, Sprich mir nach: bla blubb“ das müsstest du ignorieren.

Oder du schaust bei History nur auf die wake wird Kommandos und merkst Dir so wer zuletzt angesprochen wurde in einer Variable und nutzt das dann weiter.

Gesendet vom Handy …

[rewenode]

Da bin ich auch grad am verzweifelt (Anruferliste nur auf dem Gerät bei dem gefragt wurde).

Letztlich hab ich es nur mit einem setTimeout hinbekommen. Vlt. fällt jemandem noch was Besseres ein.

...
on({ id: 'javascript.0.Alexa-trigger.vAnruferliste', change: "any" }, function(obj) {

    ...

    setTimeout(function () {
       setState("alexa2.0.Echo-Devices." + getState('alexa2.0.History.serialNumber').val + ".Commands.speak", volume +";"+alexatext);
    },3000);

});

Ich hab den mal auf 3sec zum Test gesetzt, da scheint das zuverlässig zu gehen. Muss mal testen, wie weit ich da runtergehen kann.

[dslraser]

@rewenode:

Da bin ich auch grad am verzweifelt (Anruferliste nur auf dem Gerät bei dem gefragt wurde).

Letztlich hab ich es nur mit einem setTimeout hinbekommen. Vlt. fällt jemandem noch was Besseres ein.

...
on({ id: 'javascript.0.Alexa-trigger.vAnruferliste', change: "any" }, function(obj) {
   
    ...
    
    
    setTimeout(function () {
       setState("alexa2.0.Echo-Devices." + getState('alexa2.0.History.serialNumber').val + ".Commands.speak", volume +";"+alexatext);
    },3000);

});

Ich hab den mal auf 3sec zum Test gesetzt, da scheint das zuverlässig zu gehen. Muss mal testen, wie weit ich da runtergehen kann. ` zwischen 500 und 650 ms sollte reichen

[rewenode]

Danke,

so rein optisch sieht das ja wirklich fix aus. Die states sind längst aktualisiert, bevor der speak kommt, so dass man denkt, das kann gar nicht sein.

Macht man aber unmittelbar vor dem speak eine log Ausgabe, sieht man ganz klar, dass der speak vor dem getState kommt.

Wenn es stabil läuft, kann ich mit dem setTimeout gut leben.

[Arnulf]

Nach wie vor habe ich Probleme, mein Sprachkommando und die Alexa-Historie zu synchronisieren.

Ich triggere das Kommando über den Wemo-Node.

Aber die Historie werte ich mit Alexa2 aus, weil der Wemo Node das letzte Device nicht weiter gibt. (obwohl als experimantell angegeben).

Damit ergeben sich zwangsläufig Laufzeitprobleme.

Also Wemo trigegrt das Kommando und legt schon los, während Alexa2 erst danach mitbekommt, dass etwas passiert ist.

ein möglicher Workaround könnte sein, einfach nach dem Lommando etwas zu warten.

Das ist aber eher eine Reduzierung der Wahrscheinlichkeit, mit der Auswertung schneller als die Aktualisierung der States zu sein.

Oder aber, man wartet ab, bis das Kommando in der History ankommt.

Das funktioniert aber nur, wenn es nur ein Kommando gibt und das auch nicht unmittelbar nacheinander in verschiedenen Räumen gesprochen wird.

Gibt es noch eine andere Mögllichkeit?

[Arnulf]

Ich glaube jetzt eine Lösung gefunden zu haben:

Ich definiere mir einen Wemo-Knoten, um das Sprachkommando für Alexa zu definieren. Im node-red kommt danach aber kein Knoten mehr.

Der Trick ist jetzt, einen weiteren Flow zu erstellen, der auf das ack im Objekt alexa2.0/History/summary reagiert.

Denn wenn es hier startet, wurde das Objekt von alexa2 neu geschrieben.

Jetzt kann ich von hier aus mit einem Switch-Node prüfen, ob von mir gesprochene Kommandos relevant (heißt: Raumbezogen) erkannt wurden.

In meinem Beispiel ist es das Licht.

Sage ich "Alexa Licht an", kennt Alexa das Wemo-Device Licht und sendet eine Antwort an ioBoroker

Der eigentliche Flow startet dann mit der Statusänderung im Summary-Knoten:

Wurde der Flow gestartet, reagiere ich nur auf Kommandos "alexa licht an" und "alexa licht aus"

Da die Kommandos alleine nix starten, habe ich einen Function-Node hinten dran gestartet, der mir den Payload in einen Booleschen Wert überträgt.

Das ginge zwar auch anders, ich fand das aber so am Besten zu lesen:

(und dann natürlich auch mit false)

Erst jetzt greife ich auf das Objekt serialNumer zu, um zu sehen, welche Alexa das Kommando gehört hat:

Danach kann ich mit dem weiter machen, was mit korrektem Kommando und bekanntem Echo getan werden muss.

Und genau so, wie ich das mit Licht mache, kann ich es natürlich mit allen lokal begrenzten Aktionen machen. Also auch mit TV und Sendern.

:)

[rewenode]

Ich hätte da mal ne Zwischenfrage, wo ich Verständnisprobleme habe.

Warum verwendest du überhaupt den Wemo-Adapter, wenn du dennoch den Alexa2 Adapter verwendest?

Eigentlich kannst du doch alles mit dem Alexa2 Adapter machen.

Den Wemo oder auch Alexa-local zu verwenden kann durchaus Sinn machen, wenn der Alexa2 instabil arbeitet. Aber wenn Beides benutzt wird, multiplizieren sie die Risiken eher.

Oder hab ich da was übersehen ?

[Arnulf]

Ich hatte das Problem, dass ich mit meinem Dot Gen.3 plötzlich im gesamten Heimnetz meine Routinen nicht mehr verwenden konnte.

Heißt: node-red kann nicht mit Gen.3 mit alexa-home oder dem alexa-node

Auf der anderen Seite wollte ich tatsächlich (und das hatte ich vorher nicht implementiert) pro Raum unterschiedliche Dinge tun. Trotz gleichem Kommando.

[umbm]

@rewenode:

Warum verwendest du überhaupt den Wemo-Adapter, wenn du dennoch den Alexa2 Adapter verwendest?

Eigentlich kannst du doch alles mit dem Alexa2 Adapter machen.

Den Wemo oder auch Alexa-local zu verwenden kann durchaus Sinn machen, wenn der Alexa2 instabil arbeitet. Aber wenn Beides benutzt wird, multiplizieren sie die Risiken eher.

Oder hab ich da was übersehen ? `

Der Alexa2 Adapter braucht doch zusätzlich noch den Cloud-Adapter, damit Alexa die Geräte finden kann. Also braucht man die iobroker-Cloud, entweder kostenlos oder die Pro. Znd gerade die kostenlose Version hat öfter mal Probleme.

Durch Nutzung der Emulatoren in nodeRed läuft (bis auf Alexa) alles lokal un man benötigt nicht zusätzlich noch die Iobroker-Cloud.

[Arnulf]

so isses.

Wobei auch bei Pro nicht immer alles reibungslos läuft.

So lange ich nicht dimmen möchte, bin ich mit dem WeMo-Emulator sehr zufrieden.

Die einzigen Probleme, die ich mit dem Node in node-red (noch) habe, ist das Verhalten im Editor.

Hier ist ein nachgeschalteter debug-node nicht immer gleich aktiv. Manchmal braucht es dann einen restart von node-red.

Oder auch das Finden der Geräte ist nicht immer beim ersten Mal korrekt.

Läuft es aber mal, ist es bisher bei mir sehr zuverlässig.

Allerdings nur für Schaltzustände. Mehr kann der Emulator erst mal nicht.

[rewenode]

@umbm:

..Der Alexa2 Adapter braucht doch zusätzlich noch den Cloud-Adapter, damit Alexa die Geräte finden kann. Also braucht man die iobroker-Cloud, entweder kostenlos oder die Pro. Znd gerade die kostenlose Version hat öfter mal Probleme.

Durch Nutzung der Emulatoren in nodeRed läuft (bis auf Alexa) alles lokal un man benötigt nicht zusätzlich noch die Iobroker-Cloud. `

Das der Einsatz der Emulatoren als ALTERNATIVE zum Alexa2 Sinn machen kann hatte ich ja geschrieben, das war nicht meine Frage.

Ich wollte eher wissen, warum man wie im konkreten Fall, Emulator UND Alexa2 verwendet?

@Arnulf

Wenn ich das richtig sehen, verwendest du den wemo für einfache Sachen (Schalten etc) und beim Dimmen oder Sachen, wo du ne Rückmeldung per history brauchst, nimmst du den Alexa2 zur Hilfe?

Ok, kann Sinn machen.

[Arnulf]

fast

:)

Ich verwende Wemo zum Schalten. Vorher hatte ich den Alexa-node verwendet, der für mich aktuell nicht funktioniert.

Da ich bisher nur schalten möchte, passt das. Bzw. die Sensoren nur Schalt-Events senden. Das Ansteuern der Zielgeräte (Licht o.A.) mache ich dann im ioBroker direkt.

Wemo löst nur den Flow im node-red aus.

Alexa2 verwende ich für die Erkennung der "hörenden Alexa", um raumspezifisch reagieren zu können.

Das Kommando "Alexa, Licht an" soll in jedem Raum andere Lampen schalten.

Und ich verwende Alexa2 für individuelle Sprachausgaben. in meinem fall, wenn ich die Kindersicherung aktiviert habe, soll sie sowas sagen wie "Finger weg von der Alexa". Idealerweise auch im richtigen Raum.

[umbm]

@rewenode:

Das der Einsatz der Emulatoren als ALTERNATIVE zum Alexa2 Sinn machen kann hatte ich ja geschrieben, das war nicht meine Frage. `

Falsch!

Die Emulatoren sind NICHT die Alternative zum Alexa2-Adapter sondern zum Cloud-Adapter weil…

> Ich wollte eher wissen, warum man wie im konkreten Fall, Emulator UND Alexa2 verwendet?
….die Emulatoren stellen nur die Geräte in iobroker für Alexa bereit, damit diese überhaupt gefunden werden, das kann der Alexa2-Adapter allein nicht.

Alexa2 ist der zusätzliche Rückkanal von der Alexa-Cloud zum iobroker, denn der wird durch die Emulatoren nicht abgedeckt, die Emulatoren stellen nur die Verknüpfungen zwischen dem virtuellen Alexa-Gerät und dem eigentlichen ioBroker-Gerät her.

Ohne Emulatoren also keine Geräte für Alexa.

Und ohne Alexa2-Adapter kein Schalten der Geräte über Alexa.

[umbm]

@Arnulf:

So lange ich nicht dimmen möchte, bin ich mit dem WeMo-Emulator sehr zufrieden. `

Ich habe irgendwo über einen workaround zum Dimmen gelesen.

Du könntest für jeden Dimmer-Zustand einen wemo-node als Dummy anlegen, den du dann per Script ansprechen kennst.

Also neben den an/aus wemo für die Lampe z.B. noch einen mit 50%, den kannst du dann über Alexa aufrufen und das Script erledigt dann die entsprechende Schaltung an der eigentlichen Lampe.

Ist zwar etwas umständlich, aber müsste funktionieren.

[Arnulf]

oh, cool. Das muss ich mal schauen.

Da wer Wemo_Node eigentlich nur als Befehlsempfänger dient, könnte es ja sein, dass man auch komplexere Befehle verarbeiten möchte.

also "Lautstärke 50%" könnte sogar raumspezifisch interessant sein

ich such mal….

[umbm]

Ich habe mit dem wemo-node diverse Nicht-Hardware-Schalter realisiert, zB. Ansage der Daten meiner Wetterstation.

Praktisch kannst du da beliebige Funktionen in iobroker ausführen lassen, bis hin zur Sprachausgabe über Alexa.

Einfach einen Datenpunkt als Dummy anlegen und mit einem neuen wemo-node verknüpfen.

Dann per Script/Blockly den Datenpunkt überwachen und die gewünschte Aktion ausführen wenn er durch Alexa geändert wurde.

[rewenode]

@umbm:

..Falsch! `

Danke für die ausführliche Antwort! Da seh ich doch schon viel klarer;-)

[Arnulf]

@umbm:

@Arnulf:

So lange ich nicht dimmen möchte, bin ich mit dem WeMo-Emulator sehr zufrieden. `

Ich habe irgendwo über einen workaround zum Dimmen gelesen.

Du könntest für jeden Dimmer-Zustand einen wemo-node als Dummy anlegen, den du dann per Script ansprechen kennst.

Also neben den an/aus wemo für die Lampe z.B. noch einen mit 50%, den kannst du dann über Alexa aufrufen und das Script erledigt dann die entsprechende Schaltung an der eigentlichen Lampe.

Ist zwar etwas umständlich, aber müsste funktionieren. `
Ich dachte auch, dass ich das schon mal gelesen hätte.

Finde es leider nicht mehr.

Wenn du oder jemand anderes weiß, wo der Thread dazu steht, bin ich für jeden Tipp dankbar.

BTW: hat schon mal jemand diesen node ausprobiert?

https://www.npmjs.com/package/node-red-node-wemo