search

Apollon77 / ioBroker.alexa2

ioBroker Adapter to control Amazon Alexa/Echo devices
MIT License
160 stars 46 forks source link

Keine Auto-Updates von Todo/Timer/Wcker/Routinen-Erkennung/"alexa2.0.History.summary" #1045

Closed uwe72 closed 1 year ago

uwe72 commented 1 year ago

Habe leider das Problem, dass im "alexa2.0.History.summary" Datenpunkt kein Wert ankommt. War die letzten Tage immer mal wieder so. War nun 4 Tage unterwegs, heute Abend/gerade funktioniert es konstant gar nicht.

Gibts hier einen Workarround/Erklärung?

Danke Euch und VG Uwe

realwax commented 1 year ago

Hallo Liebe ioBroker,

ich steure mit der "History.summary" die Rolläden "Rolläden Süd runter" und "Rolläden stopp", da komme ich mit den 3 Sekunden nicht richtig hin.

Wie kann man die Aktualisierung beschleunigen?

Ideen? Oder hab ich was überlseen?

THX Tom

Verstehe ich richtig, dass du live die Absenkung deiner Rollläden steuern willst, also stopp während sie fährt zeitnahe? Wenn ja ist das sehr ungenau. Wie wäre es wenn du neue states schaffst und die via Alexa steuerst. Rollläden süd 25%, Rollläden süd 50%, Rollläden süd 75% (und vermutlich auch 100%) und je nachdem welche du rufst, hast du das timing in deinem script fixiert. Das wäre vermutlich einfacher. (In deinem script speicherst du wie weit sie aktuell sind, dann funktioniert von 25% auf 50%, 75% oder 100 auch.... Ist gedanklich einfach ein anderer Lösungsansatz. Viel Erfolg!

maniac-on-moon commented 1 year ago

@realwax : hm, das mit den Zwischenstati könnte eine temporäre Lösung sein.

"Eigentlich sollte" es doch soetwas wie Alexa --> AWS IoT-Core MQTT und auf den assigned man sich mit dem MQTT der ioBroker geben. Kennt jemand eine funktionsfähige Lösung und kann diese beschreiben? (OK, ist hier der falsche Ort, zB https://medium.com/digitalfrontiers/heimautomatisierung-mit-alexa-und-raspberry-pi-teil-1-27c301cdbf4a ist schon 5 Jahre alt und nicht mehr so richtig für nen Noob zu gebrauchen.

Apollon77 commented 1 year ago

If there is no change till weekend I will implement workarounds ...

Apollon77 commented 1 year ago

@maniac-on-moon

"Eigentlich sollte" es doch soetwas wie Alexa --> AWS IoT-Core MQTT und auf den assigned man sich mit dem MQTT der ioBroker geben. Kennt jemand eine funktionsfähige Lösung und kann diese beschreiben?

Ja, WENN das hier alles irgendwie offizielle Lösungen wären ... Da aber Amazon den Zugang zu diesen Systemen nicht offenlegt handelt der Adapter in einer großen Grauzone indem er sich der APIs bedient die auch die Alexa App nutzt

cratoo commented 1 year ago

Zwischenzeitlich habe ich für mich ein Lösung gefunden, die auch ohne zeitliches Warten (wie oben beschrieben) funktioniert: Dafür muss man allerdings node-red mit Alexa Anbindung nutzen. Bei mir ist das einer der Haupt-Verwendungszwecke in Verbindung mit iobroker, insofern war es gegeben. In Node-Red hat man dann in der Regel bereits "Fake-Devices", wie z.B. Rolladen, Lampe etc pp. Im Falle, dass man nun Alexa bzgl eines der Geräte ansprich, kann man sich einfach dahinter einen iobroker-output dran hängen und der wird eben erst getriggert, wenn man mit der Spracheingabe fertig ist. Dazu noch ein on-trigger auf den diesen iobroker Status und manuell die History triggern und wie üblich drauf reagieren. Hab ich so seit gestern nachmittag laufen und die Famillie reagierte nur mit "ah geht ja wieder". Keine Kommentare über Verzögerung etc.

Apollon77 commented 1 year ago

Das sollte über iot-Adapter geräte als Trigger genau so gehen, ist aber limitiert auf Routinen

uwe72 commented 1 year ago

Das sollte über iot-Adapter geräte als Trigger genau so gehen, ist aber limitiert auf Routinen

Du schriebst ja weiter oben, dass wenn sich bis zum Wochenende nichts tut, Du einen Workarround einbauen möchtest.

Zu meinem Verständnis, hätte dieser Workarround auch das "Problem" mit der Verzögerung?

Zusatzfrage: Über den iot-Adapter würde es aktuell bereits ohne Verzögerung funktionieren?

Ich bin eben einer Lösung ohne Verzögerung interessiert, deshalb klopfe ich diese 2 Optionen ab.

Danke für deine Einschätzung.

Fontheweg commented 1 year ago

Ich habe für meine Themen den Workarround mit "Dummyschaltern" umgesetzt. Also die Routine hat einen Schalter im Bauch der per IoT-Adapter veröffentlicht ist. So greife ich nicht mehr in die History, sondern gucke auf die "Schalter".

Apollon77 commented 1 year ago

Definiere "Verzögerung"?

In Realtime ging das noch nie... aber meist innerhalb einer Sekunde.

Die Hoffnung wäre das es so funktioniert wie bisher auch, aber wie es geht sehen wir dann. Was dann nicht mehr gehen wird ist zielgerichtet sicherzustellen das wirklich alle Aktionen die Sprachlich gemacht wurden auch abgeholt werden. Sehr schnelle Abfolgen könnten problematisch werden. Aber sehen wir dann. Bisher kam in der Push Meldung halt immer eine ID der Anfrage mit die dann spezifisch gesucht wurde. Das fehlt bei den Workaround Ideen.

Zusatzfrage: Über den iot-Adapter würde es aktuell bereits ohne Verzögerung funktionieren?

Nochmals Definiere Verzögerung". AUch hier steuert Amazon über die Cloud ein gerät bei dir im iobroker ... auch hier gibt es "verzögerungen", aber auch hier meist weit unter 1s ...

solarsnoop commented 1 year ago

Zusatzfrage: Über den iot-Adapter würde es aktuell bereits ohne Verzögerung funktionieren?

Nochmals Definiere Verzögerung". AUch hier steuert Amazon über die Cloud ein gerät bei dir im iobroker ... auch hier gibt es "verzögerungen", aber auch hier meist weit unter 1s ...

Ja das ist auch so (kann ich bestätigen) die Verzögerung (neu) kommt auch nur wegen Abruf der History über den manuellen Trigger zustande, ich habs auch mit einer Pause von 500ms hinbekommen. ich glaube da ist noch potential (Laufzeit abhängig) Die brauch man ja auch nur wenn man mit einem Befehl(routine) unterschiedliche Device steuern möchte (so zumindest mein Verständnis)

uwe72 commented 1 year ago

Vielleicht habe ich den bisherigen Workarround falsch verstanden. Ich dachte ioBroker wird getriggert wenn "ALEXA" gesprochen wird. Dann nach X-Sekunden (bei mir 3 Sekunden) wird per pull das nach Alexa gesprochene in den history Datenpunkt geschrieben. Wenn ich "X" zu kurz wähle, und bis dahin das aktuell gesprochene noch nicht beendet ist, dann nur ein "Zwischenstand" im history Datenpunkt landet. Deswegen um sicher zu gehen, man eben möglichst lange wartet (X, aktuell wie gesagt bei mir 3 Sekunden). Habe ich dies dann falsch verstanden?

Ich habe bei mir viele Leerroutinen in Alexa angelegt, z.B. "Alexa, Büro aus". Ich prüfe dann (on change) ob history-Datenpunkt == "alexa, büro aus" ist und schalte dann per Script das Licht im Büro aus. Habe hier ca. 28 Leerroutinen/Befehle

realwax commented 1 year ago

@uwe72 In den Workarounds von Bakterius und mir gehts genau darum. Der Adapter bekommt mit wenn "Alexa" gesagt wird. Da zwischen "Alexa" sagen und der folgenden Spracheingabe, je nach länge, ein Zeit vergeht, habe ich 3 Sekunden als gute Zeit empfunden, eben genau danach die histrory abfrage zu triggern, weil nach 3 Sekunden das gesagte gesagt wurde, und bei Amazon ankam, so dass es per update in summary kommt.

Leerroutinen habe ich auch viele in der App und eben ein script, dass ein parser/dispatcher ist. Da der auf "summary" change agiert, war der hotfix leicht zu implementieren, da der eben nach "Alexa" sagen plus 3 Sekunden das update macht.

solarsnoop commented 1 year ago

@uwe72 : Wenn du den Skill iobroker.iot in der alexa app installierst dann kannst du virtuelle Geräte in der Alexa app direkt ansprechen (guck mal das Beispiel oben an) dann kannst du ohne Historie direkt das Gerät ansprechen über einen datenpunkt der das Gerät repräsentiert. Z.B. Datenpunkt virtueller Schalter Wohnzimmer Zustand true oder false. Wenn du den Skill aktiv hast und iot adapter installiert hast dann kannst du im IOT adapter das Gerät erstellen und zeigst auf den Datenpunkt den du zuvor angelegt hast. In der Alexa app in der routine erscheint dann dieses Gerät z.B. als Schalter und du setzt den dann auf an . Der datenpunkt im IO Broker wird dann auf true gesetzt dann braust du keine History. Hoffe es war verständlich gibt aber dazu oben hier in der Diskussion mehrere Hinweise dazu.

Ihr müsst umdenken anstelle der History ein virtuelles Geräte ansteuern! Beispiel zuerst mit History Ohne virtuelles Gerät darunter das selbe mit virtuellem Gerät also letztendlich viel einfacher image Beides wird mit dem Sprachbefehl an Alex gesteuert hier gibt es weiterhin die normale Verzögerung

Apollon77 commented 1 year ago

Ok, ja das mit der Verzögerung ist dann so eine Thematik ... ich habe mich noch nicht so tief mit den Ideen und varianten auseinandergesetzt, bin noch zu frustriert über Amazon und das jede Lösung leider probleme haben wird ... Schauen wir mal was mir einfällt wenn ich Zeit finde das anzusehen. Ich bin nur gerade so was von weit weg von diesem Thema. :-(

realwax commented 1 year ago

@solarsnoop Was soll der Vorteil der Lösung sein? Ich empfinde es komplizierter. Nicht jeder hat iot adapter. Ich schon, aber aus dem trigger ein Gerät zu machen und in alle Routinen einzubauen ist viel umständlicher, als der Hotfix, der pauschal nach "Alexa" sagen aktualisiert. ABER wozu es etwas bringt sind die User auf fire sick und app - wo es keine Datenpunkte gibt, die nach "Alexa" sagen, oder Button drücken auf on change überwacht werden können. Dafür ist die Idee eine Lösung, damit es für alle Geräte klappt. Das muss letztendlich jeder auf Basis seines Setup entscheiden.

Wenn @Apollon77 Ingo eine Lösung implementiert, dann wird die jedoch für fire sticks etwas auch funktionieren, weil man den Trigger im Adapter grundsätzlich mitbekommt.

solarsnoop commented 1 year ago

@realwax das sollte eine Hilfe sein , muss man ja nicht so machen...

realwax commented 1 year ago

@solarsnoop Absolut! Jeder Input hilft und ist gut. Da deiner mehr Aufwand bedeutet wollte ich ihn nur differenzieren.

Apollon77 commented 1 year ago

@realwax Ob das tut weiss ich nicht ... sehen wir dann ... wenn es keinerlei solche trigger gibt die noch gehen dann wird auch ggf meine Lösung nicht gehen.

ich kann nur nochmals betonen das alles was der Adapter tut darauf limitiert ist was Amazon für die Alexa App an Möglichkeiten und Daten bereitstellt. Wenn die, wie jetzt, welche wegnehmen weil die App die nicht mehr braucht oder so dann habe ich auch keine Chance. Und ja wenn Amazon die Push-Verbindung ganz einstellt dann geht auch der Workaround gar nicht mehr. Und dann ist das so ... schauen wir mal

realwax commented 1 year ago

@Apollon77 Stimmt natürlich. Aktuell kommt der Trigger ja noch rein. Obgleich des Geräts. Eben App und firestick User können den Bakterius, oder meinen Hotfix nicht verwenden, aber da hat eben @solarsnoop die gute Idee mit iot Adapter und einem Gerät in der Routine. Sollte der trigger ganz verschwinden wird seine Lösung die einzige Alternative werden.

ali86x commented 1 year ago

Ich nutze zur Zeit auch den Workaround. Ich werde aber (wenn ich mal Zeit habe), alle Scripte nach und nach umstellen auf virtuelle Geräte über den Iot. Sicher ist sicher. Aber im Moment geht's ja noch.

MattL0 commented 1 year ago

Would this be implemented into the alexaremote2 library directly? As it is also an issue on nodered .

hbertsch commented 1 year ago

Habe ebenfalls das Problem, dass seit ein paar Tagen die Alexa Datenpunkte unter alexa2/0/History nicht mehr aktuallisiert werden. Die einzige Ausnahme ist alexa2/0/History/creationTime, diese wird interessanterweise weiterhin gepushed. Nur die anderen Werte fehlen leider komplett. Dadurch funktioniert meine Sprachgesteuerte Hausautomatisierung nicht mehr, zum Glück habe ich ein Backup Web UI gebaut.

Wäre aber super toll wenn das wieder laufen würde.

Es scheint sich irgendwas geändert zu haben (vermutlich beim Amazon Backend). Im normalen IOBroker Protokoll ist kein Fehler zu sehen. Ich wüsste gerade nicht wo ich noch nachsehen könnte.

Edit: wenn ich meinen Schaltbefehl gebe und anschließen alexa2.0.History.#trigger für einen Rescan manuel auslöse, dann befüllen sich die restlichen Felder mit dem ApplianceIntent. Also scheint zumindest das Datenformat aus dem Backend nicht das Problem zu sein.

I also have the problem that the Alexa data points under alexa2/0/History have not been updated for a few days. The only exception is alexa2/0/History/creationTime, which interestingly is still being pushed. Unfortunately, all the other values are missing. As a result, my voice-controlled home automation is not working anymore, but thankfully, I have a backup web UI.

It would be really great if this could be fixed and start working again.

It seems that something has changed (probably in the Amazon backend). There are no errors visible in the normal IOBroker protocol. I'm not sure where else to look for the issue right now.

Edit: When I give my switch command and then manually trigger alexa2.0.History.#trigger for a rescan, the remaining fields are populated with the ApplianceIntent. So, at least the data format from the backend doesn't seem to be the issue.

maniac-on-moon commented 1 year ago

Ja, WENN das hier alles irgendwie offizielle Lösungen wären ... Da aber Amazon den Zugang zu diesen Systemen nicht offenlegt handelt der Adapter in einer großen Grauzone indem er sich der APIs bedient die auch die Alexa App nutzt

@Apollon77 : Deine Lösung hat für mich bisher auf Anhieb getan, ein FETTES DANKE dafür auf jeden Fall!!!

Frank795 commented 1 year ago

Hallo zusammen, nutze auch aktuell den Workaround, funktioniert auch fast alle. Fast da bei "Alexa, Stopp" kein stopp mehr im summary ist, andere dinge funktionieren soweit. nur Stopp nicht, was mir bis jetzt aufgefallen ist. Doof da ich mit Stopp morgens meinen Wecker stoppe, und andere dinge Starte ... kann das jemand bestätigen ?

hbertsch commented 1 year ago

Würde ein zyklisches triggern (alle paar Sekunden) von alexa2.0.History.#trigger zu Problemen mit Amazon führen (Sperrung)?

ammawel commented 1 year ago

@realwax Ob das tut weiss ich nicht ... sehen wir dann ... wenn es keinerlei solche trigger gibt die noch gehen dann wird auch ggf meine Lösung nicht gehen.

ich kann nur nochmals betonen das alles was der Adapter tut darauf limitiert ist was Amazon für die Alexa App an Möglichkeiten und Daten bereitstellt. Wenn die, wie jetzt, welche wegnehmen weil die App die nicht mehr braucht oder so dann habe ich auch keine Chance. Und ja wenn Amazon die Push-Verbindung ganz einstellt dann geht auch der Workaround gar nicht mehr. Und dann ist das so ... schauen wir mal

Schlechte Nachricht: Bei mir werden die im Hotfix genutzten Trigger player.muted oder player.volume nicht mehr aktualisiert - andere Datenpunkte der Geräte natürlich auch nicht. Damit funktioniert auch der automatische Hotfix nicht mehr. Ein manuelles oder durch einen Schalter / eine Routine erzwungenes Auslösen von History.#trigger funktioniert - noch...

uwe72 commented 1 year ago

@realwax Ob das tut weiss ich nicht ... sehen wir dann ... wenn es keinerlei solche trigger gibt die noch gehen dann wird auch ggf meine Lösung nicht gehen. ich kann nur nochmals betonen das alles was der Adapter tut darauf limitiert ist was Amazon für die Alexa App an Möglichkeiten und Daten bereitstellt. Wenn die, wie jetzt, welche wegnehmen weil die App die nicht mehr braucht oder so dann habe ich auch keine Chance. Und ja wenn Amazon die Push-Verbindung ganz einstellt dann geht auch der Workaround gar nicht mehr. Und dann ist das so ... schauen wir mal

Schlechte Nachricht: Bei mir werden die im Hotfix genutzten Trigger player.muted oder player.volume nicht mehr aktualisiert - andere Datenpunkte der Geräte natürlich auch nicht. Damit funktioniert auch der automatische Hotfix nicht mehr. Ein manuelles oder durch einen Schalter / eine Routine erzwungenes Auslösen von History.#trigger funktioniert - noch...

Bei mir funktioniert der Hotfix schon noch

padrino-x commented 1 year ago

@Apollon77 Könnte der Adapter nicht einfach die fehlenden Datenpunkte für fire anlegen? Ich kann mir so schwer vorstellen, dass due nicht klappen sollen... Vielleicht könnte es ha gehen, auch wenn das Gerät eigentlich "not supported" zurück gibt? Die Fire Sticks machen doch fast alles, wie ein Echo. 🤷🏻‍♂️

tiigaaa commented 1 year ago

Danke Jungs,

der Hotfix funktioniert 1A und keiner merkt das da was anders ist. Schade das Amazon wie auch Google funktionierende features einfach löscht ohne an die Kunden zu denken. Danke das ihr immer einen Weg sucht und findet :)

hbertsch commented 1 year ago

Danke @realwax für das Beispiel. Das ist tatsächlich interessant, dass hier bei einem Command pauschal der Player gemuted wird. Dadurch habe ich mir jetzt ein Script bauen können, das darauf reagiert und den History.#trigger triggered um die ganzen History Daten zu aktuallisiern. So bekommt man wieder alle Daten geladen und all meine Scripte funktionieren wieder.

Thank you, @realwax, for the example. It's actually interesting that the player is muted universally with a command. As a result, I was able to create a script that reacts to this and triggers the History.#trigger to update all the History data. This way, all the data is loaded again, and all my scripts are working again.

// Whenever Alexa is triggered by her activation keyword, a "mute all players" command is sent 
// (no matter if something is acatualy playing or not). We can makte use of this as an indicator and 
// refresh the History by triggering the refresh button.
// After the .History.#trigger has been triggered, the values are updated and all scripts referencing them
// get notified about the change and can use them as always.

on({ id: [].concat(new RegExp('alexa2.0.Echo-Devices.*.Player.muted')), change: 'any' }, async (obj) => {

    /*Trigger/Rescan*/
    setState('alexa2.0.History.#trigger',true);

});
DonToben commented 1 year ago

Danke @realwax für das Beispiel. Das ist tatsächlich interessant, dass hier bei einem Command pauschal der Player gemuted wird. Dadurch habe ich mir jetzt ein Script bauen können, das darauf reagiert und den History.#trigger triggered um die ganzen History Daten zu aktuallisiern. So bekommt man wieder alle Daten geladen und all meine Scripte funktionieren wieder.

Thank you, @realwax, for the example. It's actually interesting that the player is muted universally with a command. As a result, I was able to create a script that reacts to this and triggers the History.#trigger to update all the History data. This way, all the data is loaded again, and all my scripts are working again.

// Whenever Alexa is triggered by her activation keyword, a "mute all players" command is sent 
// (no matter if something is acatualy playing or not). We can makte use of this as an indicator and 
// refresh the History by triggering the refresh button.
// After the .History.#trigger has been triggered, the values are updated and all scripts referencing them
// get notified about the change and can use them as always.

on({ id: [].concat(new RegExp('alexa2.0.Echo-Devices.*.Player.muted')), change: 'any' }, async (obj) => {

    /*Trigger/Rescan*/
    setState('alexa2.0.History.#trigger',true);

});

Aber es ist noch ein Delay notwendig, um auch den kompletten Befehl in der History sehen zu können, oder?

hbertsch commented 1 year ago

Aber es ist noch ein Delay notwendig, um auch den kompletten Befehl in der History sehen zu können, oder?

Also für mich funktioniert es so. Ohne mich jetzt noch weiter damit beschäftigt zu haben würde ich sagen, dass sich das dann wie ein Push verhält und deine Scripte beim Update eines Feldes entsprechend benachrichtigt werden. Es kommt vermutlich darauf an wie man es nutzt. Ich schaue auf jedes Feld der History jeweils mit einem on({...., change: "any"}.

Da wir hier in einem async scope laufen kannst du aber einfach etwas umbauen und sowas in der Art bauen:

    /*Trigger/Rescan*/
    await setStateAsync('alexa2.0.History.#trigger',true);
    // wait a little
   await sleep(5000);
   // now do whatever you want
   //...
MattL0 commented 1 year ago

From nodered, the ''equalizer state change" is still pushing. I can use that as a trigger to poll the alexa history and get the last command i sent it vocally. This is just the workaround part, the flow I had to get room awareness can still be left intact.

alexa

MattL0 commented 1 year ago

Actually, inspired from this topic, this is even working faster ( and more reliably) than before this whole issue.

and keeping all the rest the same is working perfect

Apollon77 commented 1 year ago

Oookk Leute ... ich brauche mal jemanden der was testet ... Findige Nutzer von dem node-red-modul mit meiner Library habe was rausgefunden. Wenn das geht haben wir vllt eine Lösung (wer weiss wie lange die tut, aber ein erster schritt). Wer testet??

gehts dann wieder?

Wenn ja ist das besser als jede lösung die ich am Wochenende i einigen Stunden ausprobiert hab. Am Ende bin ich auf die gleichen varianten gekommen wie Ihr hier aber keine so wirklich schön .... also ,... vllt haben wir glück.

Streit187 commented 1 year ago

@Apollon77 Bei mir liegt die Datei im zweiten genannten Pfad und ab Zeile 172 sieht es so aus: url = this.connectType1(); } else { url = this.connectType2(); } Soll ich hier die 2 in eine 1 ändern?

Elfe commented 1 year ago

Bei mir tauchen die Sprachbefehle nach der Änderung und Instanzrestart wieder sofort auf.

Apollon77 commented 1 year ago

@Streit187 ja ...

Apollon77 commented 1 year ago

@Elfe

Bei mir tauchen die Sprachbefehle nach der Änderung und Instanzrestart wieder sofort auf.

Danke, mal schauen was andere sagen ... aber das klingt ja schonmal vielversprechend

Streit187 commented 1 year ago

Ich kann ebenfalls Erfolg vermelden! Immer wieder faszinierend was eine Ziffer manchmal so ausmachen kann.

padrino-x commented 1 year ago

@Apollon77 😍 Es funktionert auch hier.

Frank795 commented 1 year ago

@Apollon77 klappt auch bei mir wieder 👍 , selbst Stopp kommt wieder was mit der Lösung oben nicht ging

solarsnoop commented 1 year ago

@Apollon77 Bei mir liegt die Datei im zweiten genannten Pfad und ab Zeile 172 sieht es so aus: url = this.connectType1(); } else { url = this.connectType2(); } Soll ich hier die 2 in eine 1 ändern?

Also bei mir ist das ebenso ich habe jetzt hier stehen : image und darin steht nun: image habe den adapter jetzt 3 mal neu gestartet aber bei mir ändert sich leider nichts ... Habe ich alles richtig verstanden ?

padrino-x commented 1 year ago

@solarsnoop Hast Du dem Adapter nach dem Neustart etwas Zeit gegeben? Hat hier auch eine Weile gedauert....

Frank795 commented 1 year ago

@solarsnoop

hast du bis dahin gewartet ?

alexa2.0 | 2023-08-06 23:32:42.180 | info | Initialization Done ... -- | -- | -- | --
solarsnoop commented 1 year ago

BINGO image Und danach hat es geklappt TOP!

Also auch bei mir die History wieder da!

Bommelpage commented 1 year ago

@Apollon77 Super hat nach einer kurzen Zeit geklappt, Sieht bis jetzt gut aus, Danke :thumbsup:

Negalein commented 1 year ago

@Apollon77 Merci, funktioniert wieder

Kaldesh84 commented 1 year ago
  • sucht im Filesystem nach /opt/iobroker/node_modules/iobroker.alexa2/node_modules/alexa-remote2/alexa-wsmqtt.js (Oder wenn dort nicht dann sollte das in /opt/iobroker/node_modules/alexa-remote2/alexa-wsmqtt.js liegen

Ich hab leider an keinem der beiden Orte das Verzeichnis finden können. Ist das Teil das Standard-Installation vom Alexa2-Adapter oder muss das händisch hinzugefügt werden?

Kann mir da jemand nen kurzen Hinweis geben?

stefan230561 commented 1 year ago

Super, der Datenpunkt summary wird wieder geschrieben.

VIELEN, VIELEN DANK.