[37_echodevice] Amazon Echo Modul (nicht Alexa)

[webdandy]

Wäre klasse, wenn das Device ,,überall" funktionieren würde

Grüße
Fabian

Die Sprachausgabe sowie Sounds fumktionieren nach dem heutigen Update wieder. Vielen Dank für das Update 

Vielleicht ist es ja möglich,das Device "Überall" mit zu fixen,wenn es denn möglich ist?


Beste Grüße
Falkes

[michael.winkler]

Hallo,

sorry, ich konnte leider nicht mehr dazu sagen, da ich tatsächlich keinen Zusammenhang gefunden habe.

Allerdings scheint es tatsächlich mit dem set routine.play zusammen zu hängen.

Durch folgendes DOIF kam es heute Nachmittag wieder zum Absturz von FHEM:

Code Auswählen Erweitern

define Waschmaschine_Zustand DOIF ([Waschmaschine:ENERGY_Power] > 10)\
(setreading Waschmaschine_Zustand status Waschvorgang läuft)\
\
DOELSEIF ([Waschmaschine:ENERGY_Power] < 6)\
(setreading Waschmaschine_Zustand status Waschvorgang beendet)\
(set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb)\
(set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb-)\
\
\

attr Waschmaschine_Zustand DbLogExclude .*
attr Waschmaschine_Zustand devStateIcon {my $icon = FW_makeImage('scene_washing_machine@red');; $icon = FW_makeImage('scene_washing_machine@green')  if(ReadingsVal($name, "state", "cmd_1") eq "cmd_2");; return "<div>" . $icon . " ".  (ReadingsVal($name,"status","")) .'</div>' ;; }
attr Waschmaschine_Zustand group Waschen+Trocknen
attr Waschmaschine_Zustand room Keller
attr Waschmaschine_Zustand wait 0:0,0,10
#   DEF        ([Waschmaschine:ENERGY_Power] > 10)
#(setreading Waschmaschine_Zustand status Waschvorgang läuft)
#
#DOELSEIF ([Waschmaschine:ENERGY_Power] < 6)
#(setreading Waschmaschine_Zustand status Waschvorgang beendet)
#(set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb-)
#(set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb-)
#
#
#
#   FUUID      67039bea-f33f-a358-2a06-183a98e5c4f36f87
#   MODEL      FHEM
#   NAME       Waschmaschine_Zustand
#   NOTIFYDEV  Waschmaschine,global
#   NR         365
#   NTFY_ORDER 50-Waschmaschine_Zustand
#   STATE      cmd_2
#   TYPE       DOIF
#   VERSION    30377 2025-10-12 09:46:59
#   READINGS:
#     2025-11-09 16:45:50   Device          Waschmaschine
#     2025-11-09 16:20:01   cmd             2.3
#     2025-11-09 16:20:01   cmd_event       Waschmaschine
#     2025-11-09 16:20:01   cmd_nr          2
#     2025-11-09 16:20:01   cmd_seqnr       3
#     2025-11-09 16:45:50   e_Waschmaschine_ENERGY_Power 0
#     2025-10-26 16:32:10   mode            enabled
#     2025-11-09 16:20:01   state           cmd_2
#     2025-11-09 16:19:50   status          Waschvorgang beendet
#   Regex:
#     accu:
#     bar:
#     barAvg:
#     collect:
#     cond:
#       Waschmaschine:
#         0:
#           ENERGY_Power ^Waschmaschine$:^ENERGY_Power:
#         1:
#           ENERGY_Power ^Waschmaschine$:^ENERGY_Power:
#   attr:
#     wait:
#       0:
#         0
#       1:
#         0
#         0
#         10
#   condition:
#     0          ::ReadingValDoIf($hash,'Waschmaschine','ENERGY_Power') > 10
#     1          ::ReadingValDoIf($hash,'Waschmaschine','ENERGY_Power') < 6
#   do:
#     0:
#       0          setreading Waschmaschine_Zustand status Waschvorgang läuft
#     1:
#       0          setreading Waschmaschine_Zustand status Waschvorgang beendet
#       1          set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb
#       2          set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb
#     2:
#   helper:
#     NOTIFYDEV  Waschmaschine,global
#     globalinit 1
#     last_timer 0
#     sleeptimer -1
#   perlblock:
#   readings:
#     all         Waschmaschine:ENERGY_Power
#   uiState:
#   uiTable:
#
setstate Waschmaschine_Zustand cmd_2
setstate Waschmaschine_Zustand 2025-11-09 16:45:50 Device Waschmaschine
setstate Waschmaschine_Zustand 2025-11-09 16:20:01 cmd 2.3
setstate Waschmaschine_Zustand 2025-11-09 16:20:01 cmd_event Waschmaschine
setstate Waschmaschine_Zustand 2025-11-09 16:20:01 cmd_nr 2
setstate Waschmaschine_Zustand 2025-11-09 16:20:01 cmd_seqnr 3
setstate Waschmaschine_Zustand 2025-11-09 16:45:50 e_Waschmaschine_ENERGY_Power 0
setstate Waschmaschine_Zustand 2025-10-26 16:32:10 mode enabled
setstate Waschmaschine_Zustand 2025-11-09 16:20:01 state cmd_2
setstate Waschmaschine_Zustand 2025-11-09 16:19:50 status Waschvorgang beendet


im Log dann wieder folgende Meldung:

Code Auswählen Erweitern

hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/37_echodevice.pm line 1868.
Bis zu dem Update funktionierte das problemlos. Seit dem Update stürzt FHEM dann bei der Auslösung ab.


Grüße

gibt es die Routinen, die du hier ansprichst, noch?

[locodriver]

Hallo, seit dem letzten update durch Michael, läuft Alexa bzw. echodevice wieder.

Allerdings habe ich gerade folgende Einträge im log (reverse) entdeckt, die schon seit 10.11. (letztes fhem-update) auftreten.

Code Auswählen Erweitern

Node.js v18.20.4

}
  syscall: 'write'
  code: 'EPIPE',
  errno: -32,
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at emitErrorNT (node:internal/streams/destroy:151:8)
Emitted 'error' event on Socket instance at:
    at /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js:499:41
    at console.log (node:internal/console/constructor:380:26)
    at console.value (node:internal/console/constructor:305:16)
    at Writable.write (node:internal/streams/writable:337:10)
    at _write (node:internal/streams/writable:333:10)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at Socket._write (node:net:975:8)
    at Socket._writeGeneric (node:net:963:11)
    at writeGeneric (node:internal/stream_base_commons:151:3)
    at afterWriteDispatched (node:internal/stream_base_commons:160:15)
Error: write EPIPE

      ^
      throw er; // Unhandled 'error' event
node:events:495
Zeitweise sind mehr solche Einträge vorhanden als normale Logzeilen.

Die Funktion scheint aber nicht beeinträchtigt zu sein.
Sowohl das account device als auch die Echos sind connected.

Was ist da "los" und wie bekomme ich das weg?

Dankeschön.

Uwe

[Knallfrosch]

[/quote]
gibt es die Routinen, die du hier ansprichst, noch?
[/quote]

Ja, an den Routinen habe ich nichts verändert.

[KölnSolar]

An dieser Stelle nur kurz die Verlinkung auf den Beitrag mit Sicherheitshinweis zu npm

Grüße Markus

[passibe]

Ich sehe keinen Grund, diesbezüglich derart besorgt zu sein.

Wie oft aktualisieren Leute denn alexa-cookie2? Ich würde wetten, dass das, außer bei Neuinstallationen, quasi nie passiert. Dass die Neuinstallation ausgerechnet in einen Zeitraum fällt, in dem zufällig gerade ein supply chain attack läuft, d.h. die bösartige Version noch nicht zurückgezogen ist, halte ich jetzt auch mal für eher unwahrscheinlich.

Das ganz abgesehen davon, dass alexa-cookie2 auch kein wirklich lukratives Ziel ist, weil es selbst keine dependency von tausenden anderer Pakete ist.

Und alexa-cookie2 wird sowieso vom Entwickler sehr sehr selten aktualisiert (inzwischen Monate bis Jahre), d.h. der Schadcode aus einer bösartigen dependency würde auch nicht von dem typischen Überraschungseffekt durch auto-dependency-updates profitieren.

[KölnSolar]

Wie oft aktualisieren Leute denn alexa-cookie2? Ich würde wetten, dass das, außer bei Neuinstallationen, quasi nie passiert.

Liege ich falsch, dass das cookie abläuft und deshalb automatisch regelmäßig erneuert wird ?

Zumindest das manuelle cookie hat eine "Haltbarkeitsdauer" von 7-10 Tagen.

Und alexa-cookie2 wird sowieso vom Entwickler sehr sehr selten aktualisiert

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !
(ich habe mir aber nicht angeguckt, worin die Sicherheitslücke überhaupt besteht: Lücke in veralteten Modulen oder Schadsoftware in aktuellen Modulen)

[JudgeDredd]

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !
(ich habe mir aber nicht angeguckt, worin die Sicherheitslücke überhaupt besteht: Lücke in veralteten Modulen oder Schadsoftware in aktuellen Modulen)

So wie ich das Verstanden habe, geht es hier um das Modul "alexa-cookie2". Durch Lücken in NPM kann der Quellcode von eben diesem Modul manipuliert werden.
Bei Aktualisierung oder Installation wird nun der manipulierte Quellcode anstatt des originalen geladen.

Mit der eigentlichen Aktualisierung des Cookies hat die Sicherheitlücke nichts zu tun.

Wenn ich hier eine Gefahr sehen würde, dann eher in den Abhängigkeiten die das Modul verwendet. Da ich den Umfang nicht kenne, wieviele da verwendet werden.

[passibe]

Liege ich falsch, dass das cookie abläuft und deshalb automatisch regelmäßig erneuert wird ?

Die Aktualisierung des Cookies hat damit überhaupt nichts zu tun.

Es ist doch keine "Sicherheitlücke" in alexa-cookie2, sondern in npm !

Nein. npm hat keine Sicherheitslücke in dem Sinne, sondern es werden einfach die Konten der Entwickler "beliebter" Pakete durch Social Engineering, Phishing usw. gekapert und dann wird Schadcode in deren Projekte eingefügt. Man kann sich das ungefähr so vorstellen, als würde jemand deinen Account hier im Forum kapern und dann darüber Links zu irgendwelche Betrugswebsites verbreiten.


Ansonsten: Es handelt sich hier um einen Supply-Chain-Angriff. Da gibt es jetzt im Hinblick auf alexa-cookie2 zwei Möglichkeiten:

1. Der Entwickler von alexa-cookie2 selbst wird Ziel des Angriffs. Angreifer erhalten Zugriff auf sein npm-Konto und veröffentlichen eine neue alexa-cookie2-Version, die Schadcode enthält.
Dass das passiert ist aber eher unwahrscheinlich, weil alexa-cookie2 jetzt keine große Bibliothek ist, die anderswo haufenweise als dependency verwendet wird.
Zudem ist unwahrscheinlich, dass, selbst wenn das passieren würde, das den FHEM-Nutzer betrifft, weil der FHEM-Nutzer ja erstmal diese neue (schädliche) Version von alexa-cookie2 überhaupt installieren müsste. Und ich bin der Meinung, dass viele Nutzer alexa-cookie2 einmal beim Einrichten von echodevice installieren und danach eben nicht mehr aktualisieren, außer etwas funktioniert nicht oder man installiert das gesamte System neu. Typischerweise wird aber einigermaßen schnell bemerkt, dass das Konto gekapert wurde, sodass dann die schädliche Version wieder zurückgerufen wird und das Zeitfenster, in dem die überhaupt verfügbar ist, recht klein ist. Dementsprechend ist es auch relativ unwahrscheinlich, dass ein FHEM-Nutzer genau in diesem Zeitraum alexa-cookie2 aktualisiert bzw. neu installiert.

2. Die zweite Möglichkeit ist, dass das Konto des Entwicklers einer der dependencies (Abhängigkeiten) von alexa-cookie2 (klick) gekapert wird. Wie man aber sieht, sind die Versionen der dependencies da einigermaßen fix und, soweit ich sehe, aktualisiert der Entwickler von alexa-cookie2 diese dependencies auch stets manuell (klick) und sowieso auch nicht so häufig. Dass diese seltene, manuelle Aktualisierung dann ausgerechnet in einen Zeitraum fällt, in dem eine der dependencies über ein gekapertes Entwicklerkonto eingefügten Schadcode enthält, ist also erneut relativ unwahrscheinlich. Zumal auch dann der FHEM-Nutzer immer noch alexa-cookie2 manuell aktualisieren (oder neu installieren) müsste.

Diese Supply-Chain-Angriffe zielen a) auf Pakete ab, die bei ganz vielen anderen Paketen als dependency benutzt werden und b) auf Umgebungen, in denen dependencies automatisch aktualisiert und dann auch automatisch das "Endpaket" aktualisiert wird. Beides ist hier nicht der Fall.

Ich hoffe, das klärt es ein bisschen auf.

FHEM betreffend sind sicherheitsmäßige Probleme eher anderswo zu finden. Nämlich z.B. darin, dass Leute Port 8083 ohne Weiteres ins Netz stellen oder generell ihr Betriebssystem überhaupt nicht aktualisieren. Diese Sache mit npm fällt angesichts dessen (und auch angesichts der sonst geringen Wahrscheinlichkeit, wie dargestellt) nach meiner Auffassung ganz ganz untergeordnet ins Gewicht.

[KölnSolar]

Ich widerspreche

Die Aktualisierung des Cookies hat damit überhaupt nichts zu tun.

Möglicherweise hast Du mich missverstanden, aber der Zweck von alexa-cookie2 ist doch so beschrieben:

This library can be used to get the cookies needed to access Amazon Alexa services from outside. It authenticates with Amazon and gathers all needed details. These details are returned in the callback. If the automatic authentication fails (which is more common case in the meantime because of security checks from amazon like a needed Captcha or because you enabled two factor authentication) the library can also setup a proxy server to allow the manual login and will catch the cookie by itself. Using this proxy you can enter needed 2FA codes or solve captchas and still do not need to trick around to get the cookie.

Starting with version 2.0 of this library the proxy approach was changed to be more "as the Amazon mobile Apps" which registers a device at Amazon and uses OAuth tokens to handle the automatic refresh of the cookies afterwards. This should work seamless. A cookie is valid for 14 days, so it is preferred to refresh the cookie after 5-13 days (please report if it should be shorter).

Mir ging es eher um

Die zweite Möglichkeit ist, dass das Konto des Entwicklers einer der dependencies (Abhängigkeiten) von alexa-cookie2 (klick) gekapert wird. Wie man aber sieht, sind die Versionen der dependencies da einigermaßen fix und, soweit ich sehe, aktualisiert der Entwickler von alexa-cookie2 diese dependencies auch stets manuell (klick) und sowieso auch nicht so häufig

Und dank Deiner ausführlichen Erläuterung ist mir klar geworden, dass die "dependencies" Versionsnr. haben und daher nur eine Aktualisierung erfolgt, wenn der Entwickler sie ändert.
Ich hatte angenommen, dass es ähnlich zu perl ist, wo Versionen keine Rolle spielen und immer die gerade aktuellste bei einem Update gezogen würde.

Wir sind uns also einig, das Risiko für "Altanwender" ist fast nicht vorhanden.
Bei

neu installieren

liegt aber die Gefahr. Und

Typischerweise wird aber einigermaßen schnell bemerkt, dass das Konto gekapert wurde, sodass dann die schädliche Version wieder zurückgerufen wird und das Zeitfenster, in dem die überhaupt verfügbar ist, recht klein ist.

hilft wenig, wenn einmal befallen.