[37_echodevice] Amazon Echo Modul (nicht Alexa)

Begonnen von michael.winkler, 12 Januar 2018, 18:20:12

Vorheriges Thema - Nächstes Thema

rs

Zitat von: JudgeDredd am 26 November 2025, 17:32:03
Zitat von: rs am 26 November 2025, 17:08:57Ich habe es auch mit routinplay probiert, das es jetzt leider nicht mehr gibt.
wie kommst Du darauf ?
Zitat von: rs am 26 November 2025, 17:08:57Idee / Anregungen ?
routine_play nehmen 😉
8)
rpi3+ & RaspBee | Phillips, Osram, IKEA, SIlvercrest Devices | FHEM 6.3 | Echo Show 15 | Yamaha YAS| LG TV | Ubuntu 24.10 - NextCloud 30 - OpemVPN - Wordpress - NAS - ...

locodriver

Hallo,

ich möchte nochmals meinen Post hochholen.

Das Problem besteht nach wie vor, allerdings sind mir jetzt auch Funktionsbeeinträchtigungen aufgefallen:
Wenn das echodevice selbständig etwas "sagen" soll, so klappt das nicht mehr (z.B. Fenstermeldungen) - auf voicecommands reagiert es allerdings normal.

Zitat von: locodriver am 19 November 2025, 17:43:17Hallo, 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.

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

Das echodevice Modul ist aktuell:
# $Id: 37_echodevice.pm 30527 2025-11-14 15:49:25Z michael.winkler $

Im alexalog ist folgendes zu finden:
[27.11.2025, 17:30:51] refreshing token
[27.11.2025, 17:30:51] failed to refresh token: Error: connect ECONNREFUSED 2a01:4f8:221:1b5a::f2:443

Der Eintrag ist immer gleich und kommt alle 5 Minuten. Er scheint aber nicht synchron mit den Einträgen im fhem-log zu sein.

Ich bin ziemlich ratlos...
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

Knallfrosch

Leider existiert auch noch bei mir das Problem mit der abstürzenden FHEM Insnatnz, wenn das "routine_play" aus dem DOIF aufgerufen wird und folgender Logeintrag erscheint:

hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/37_echodevice.pm line 1868.
Wenn ich allerdings aus der Kommandozeile die Routine aufrufe, kommt es nicht zum Absturz und die Sprachansage kommt.


Grüße

KölnSolar

Dann kann es doch nur an Deinem doif liegen. :o

Ohne routineplay zu kennen, fällt mir der Unterschied ins Auge
Zitat(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-)\
Das soll/muss so sein ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Knallfrosch

Hallo,

aus diesem mir unwahrscheinlichen Grund habe ich auch das DOIF "veröffentlicht". Es hatte ja vorher fast ein Jahr problemlos funktioniert.
Am DOIF habe ich nichts geändert.

Ja, der doppelte Aufruf wird verzögert durchgeführt. Also die Sprachansage wiederholt. Das hatte auch immmer funktioniert. Bei insgesamt 3 DOIF mit unterschiedlichen Ansagen/Routinen.
Ich habe auch schon versucht die Ansage auf einmal zu reduzieren, aber auch da stürzt FHEM ab.

Ich bin leider absolut ratlos und schiebe den Fehler daher auf das Modul, allerdings bin ich auch nicht in der Lage den Fehler weiter einzugrenzen.

Grüße

JoWiemann

Hallo Knallfrosch,

die Frage von Markus bezog sich nicht auf die doppelte Ausführung, sondern auf das Minus Zeichen am Ende beim zweiten Aufruf.

set ECHO_G090U607835206H1 routine_play fhemwashend@amzn1.alexa.automation.cd0fc0cd-d57f-44fd-8efb- <- dieses Minus Zeichen ist im ersten Aufruf nicht vorhanden!!!

Damit hast Du eine ungültige Referenz.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM