- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von betateilchen - 11 Juni 2026, 09:00:58Der Blinker ist wieder da, hier im Arbeitszimmer bei az_ST20.
Der Repeater sollte nicht überlastet sein, da sind gerade mal 6 Clients angemeldet.
Es ist ja nur ein optisches "Problem", die Funktion der Box ist gegeben.
Trotzdem ein merkwürdiges Phänomen.
--
Der Repeater sollte nicht überlastet sein, da sind gerade mal 6 Clients angemeldet.
Es ist ja nur ein optisches "Problem", die Funktion der Box ist gegeben.
Trotzdem ein merkwürdiges Phänomen.
--
#2
Server - Linux / Aw: [Docker / Container] echod...
Letzter Beitrag von rabehd - 11 Juni 2026, 08:11:21Zitat von: Sidey am 10 Juni 2026, 21:37:50Nein, das ist nicht in Ordnung. Kannst Du bitte einmal das komplette log vom alexa-cookie-service container bereitstellen, wenn er startet?Reicht das?
Code Auswählen
> alexa-cookie-service@0.3.1 start
> node src/server.js
[2026-06-11T06:04:36,531 UTC] [INFO] alexa-cookie-service listening on 0.0.0.0:58080
[2026-06-11T06:04:36,575 UTC] [INFO] Log timestamps use timezone UTC
[2026-06-11T06:04:40,729 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:04:40 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:04:45,820 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:04:45 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:04:50,896 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:04:50 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:04:55,992 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:04:55 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:05:26,067 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:05:26 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:05:56,165 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:05:56 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:06:26,321 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:06:26 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:06:56,411 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:06:56 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:07:26,493 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:07:26 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:07:56,567 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:07:56 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:08:26,712 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:08:26 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:08:56,810 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:08:56 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
[2026-06-11T06:09:26,909 UTC] [INFO] 127.0.0.1 - - [11/Jun/2026:06:09:26 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"
Wie gesagt, ich habe nur den Container angelegt und im bestehenden System nichts angepasst. #3
FHEM Code changes / Revision 31350: controls_fhem....
Letzter Beitrag von System - 11 Juni 2026, 08:01:03Revision 31350: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31350: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31350: controls_fhem.txt: fhemupdate checkin
#4
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von betateilchen - 11 Juni 2026, 07:49:04Moin,
Das Problem hat sich über Nacht offenbar selbst geheilt. Inzwischen ist die Meldung nicht mehr vorhanden.
Snapshot von der Box mit dem Problem hatte ich gestern Abend schon geschickt.
Ok, mag sein. Aber wieso trat der Effekt auch bei LAN-Verbindung auf, wo der Repeater gar nicht im Spiel war? Wird von der Box grundsätzlich WLAN bevorzugt, wenn beide Verbindungen bestehen?
Zitat von: tostmann am 10 Juni 2026, 23:47:18,,Sources Not Synced" + dass erst 4 von 6 Presets ankamen: das ist ein anderer Punkt — die Box hat ihre Account-Quellen nicht vollständig registriert. Der Re-Sync soll genau das nachholen; bleibt er bei dir nach zwei Versuchen hängen, schick mir bitte einen Diagnostic-Snapshot der fl_ST20 (Diagnose-Sharing an, dann Snapshot-Knopf). Dann sehe ich an ihrem /sources, woran die Registrierung klemmt, statt zu raten.
Das Problem hat sich über Nacht offenbar selbst geheilt. Inzwischen ist die Meldung nicht mehr vorhanden.
Snapshot von der Box mit dem Problem hatte ich gestern Abend schon geschickt.
Zitat von: tostmann am 10 Juni 2026, 23:47:18Blinken: dass dein Repeater-Neustart der zweiten Box geholfen hat, zeigt, dass da ein Teil schlicht schwaches bzw. überlastetes Netz war.
Ok, mag sein. Aber wieso trat der Effekt auch bei LAN-Verbindung auf, wo der Repeater gar nicht im Spiel war? Wird von der Box grundsätzlich WLAN bevorzugt, wenn beide Verbindungen bestehen?
#5
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von Snocksman - 11 Juni 2026, 07:32:10Zitat von: stoney am 11 Juni 2026, 07:01:03Das echodevice hatte nach einem
Code Auswählen ErweiternCode AuswählenNPM_login newwieder connected. Danach konnte ich die Geräte aber nicht über den Echo Dot schalten ("Gerät antwortet nicht"). Nach der Prozedur ging es aber wieder, wieso auch immer. Ist unwahrscheinlich, dass es ein Timing-Problem war, das echodevice war zu diesem Zeitpunkt 1 Stunde connected.
Ich glaube was dir @cs-online damit sagen wollte ist, dass das echodevice-Modul nichts mit der Steuerung von FHEM über Alexa zu tun hat... Das echodevice-Mudul bedient quasi die umgekehrte Richtung... Du kannst deine echodevices über dieses Modul z.B. Erinnerungen sprechen lassen usw.
#6
Automatisierung / Aw: Neues Modul - 74_Unifi - F...
Letzter Beitrag von Wolle02 - 11 Juni 2026, 07:08:46Bei mir stelle ich alle 30 Sekunden diesen Eintrag im Log fest:
Dazu verliert Fhem regelmäßig einmal am Tag die Verbindung zur UDM. Nur ein Löschen des Device und Neuanlage mit den Zugangsdaten lässt wieder eine Verbindung entstehen.
Auch bei mir läuft Unifi OS 5.1.15 und Netzwork 10.4.57
Code Auswählen
Error: >< has no TYPE, but following keys: >unifi<Dazu verliert Fhem regelmäßig einmal am Tag die Verbindung zur UDM. Nur ein Löschen des Device und Neuanlage mit den Zugangsdaten lässt wieder eine Verbindung entstehen.
Auch bei mir läuft Unifi OS 5.1.15 und Netzwork 10.4.57
#7
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von stoney - 11 Juni 2026, 07:01:03Zitat von: cs-online am 10 Juni 2026, 19:59:26Was hat jetzt der Alexa Skill mit diesem Modul zu tun
Folgender Effekt war bei mir:
Das echodevice hatte nach einem
Code Auswählen
NPM_login new wieder connected. Danach konnte ich die Geräte aber nicht über den Echo Dot schalten ("Gerät antwortet nicht"). Nach der Prozedur ging es aber wieder, wieso auch immer. Ist unwahrscheinlich, dass es ein Timing-Problem war, das echodevice war zu diesem Zeitpunkt 1 Stunde connected. #8
Server - Linux / Aw: [Docker / Container] echod...
Letzter Beitrag von FlatTV - 11 Juni 2026, 04:57:43Was mir gerade aufgefallen ist.
im Verzeichnis Cache liegt aber ein altes Cookie mit der NR 45
Code Auswählen
[2026-06-11T04:53:29,536 Europe/Berlin] [INFO] 172.27.0.2 - - [11/Jun/2026:02:53:29 +0000] "POST /api/cookie/refresh?save=44result.json HTTP/1.0" 200 4355 "-" "fhem"im Verzeichnis Cache liegt aber ein altes Cookie mit der NR 45
#9
Server - Linux / Aw: [Docker / Container] echod...
Letzter Beitrag von FlatTV - 11 Juni 2026, 03:37:46Zitat von: FlatTV am 10 Juni 2026, 17:50:16,
ich lass das jetzt mal einige Zeit laufen...
Hmmm, so sah der Auto-Refresh aus.
Code Auswählen
[2026-06-10T22:59:23,143 Europe/Berlin] [INFO] Starting refresh (api)
[2026-06-10T22:59:23,143 Europe/Berlin] [INFO] Alexa-Cookie: Use as Login-Amazon-URL: amazon.de
[2026-06-10T22:59:23,144 Europe/Berlin] [INFO] Alexa-Cookie: Use as Base-Amazon-URL: amazon.com
[2026-06-10T22:59:23,144 Europe/Berlin] [INFO] Alexa-Cookie: Use as Device-App-Name: FHEM EchoDevice Cookie Service
[2026-06-10T22:59:23,144 Europe/Berlin] [INFO] Alexa-Cookie: Use as User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
[2026-06-10T22:59:23,144 Europe/Berlin] [INFO] Alexa-Cookie: Use as Accept-Language: de-DE
[2026-06-10T22:59:23,144 Europe/Berlin] [INFO] Alexa-Cookie: Proxy-Mode enabled if needed: 192.168.178.188:58090 to listen on 0.0.0.0
[2026-06-10T22:59:23,146 Europe/Berlin] [INFO] Alexa-Cookie: Refresh Token
...
[2026-06-10T22:59:23,603 Europe/Berlin] [INFO] Alexa-Cookie: Response (200)
[2026-06-10T22:59:23,609 Europe/Berlin] [INFO] Refresh Token Response:...
...
[2026-06-10T22:59:23,875 Europe/Berlin] [INFO] Alexa-Cookie: Add Cookie session-id = xxx-xxxx-xxxx
[2026-06-10T22:59:23,876 Europe/Berlin] [INFO] Alexa-Cookie: Add Cookie session-id-time = 2411845163l
[2026-06-10T22:59:23,876 Europe/Berlin] [INFO] Alexa-Cookie: Add Cookie ubid-main = xxx-xxxx-xxxx
[2026-06-10T22:59:23,877 Europe/Berlin] [INFO] Alexa-Cookie: Add Cookie session-token = xxxx
...
[2026-06-10T22:59:23,879 Europe/Berlin] [INFO] Alexa-Cookie: Add Cookie sess-at-main = "xxxxxx="
[2026-06-10T22:59:23,880 Europe/Berlin] [INFO] Handle token registration Start: {...
...
[2026-06-10T22:59:23,881 Europe/Berlin] [INFO] Alexa-Cookie: Register App
[2026-06-10T22:59:23,882 Europe/Berlin] [INFO] {"host":"api.amazon.com",...
...
[2026-06-10T22:59:23,883 Europe/Berlin] [INFO] Alexa-Cookie: Sending Request with {"host":"api.amazon.com","path...
...
[2026-06-10T22:59:24,041 Europe/Berlin] [INFO] Alexa-Cookie: Response (400)
[2026-06-10T22:59:24,042 Europe/Berlin] [INFO] Register App Response: {"response":{"error":{"code":"InvalidToken","index":"xxxxxxg==","message":"Auth time of the token is expired."}},"request_id":"xxxxxxx"}
[2026-06-10T22:59:24,045 Europe/Berlin] [ERROR] Refresh request failed: No tokens in Register response
[2026-06-10T22:59:24,046 Europe/Berlin] [INFO] 172.27.0.2 - - [10/Jun/2026:20:59:24 +0000] "POST /api/cookie/refresh?save=44result.json HTTP/1.0" 500 42 "-" "fhem"
[2026-06-10T22:59:24,069 Europe/Berlin] [INFO] 172.27.0.2 - - [10/Jun/2026:20:59:24 +0000] "GET /api/status HTTP/1.0" 200 4435 "-" "fhem"
Grüße
Jörg
#10
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von tostmann - 10 Juni 2026, 23:47:18Hi,
danke fürs gründliche Durchtesten — betateilchen und fred, dein Punkt von gerade eben gehört direkt dazu. Der Reihe nach:
Umbenennen (das betrifft euch beide): das ist ein echter Bug, kein Bedienfehler — und fred hat den Finger genau draufgelegt, es scheitert ja sogar in der Bose-App. Der Grund: eine an die Cloud gebundene (migrierte) Box wendet einen Rename nicht lokal an, sondern delegiert ihn an ihre Cloud — die Box feuert dabei selbst einen Account-Aufruf ab. Genau diesen Endpoint hat SixBack bisher nicht bedient, also lief der Rename ins Leere (die Box meldet ,,ok", ändert aber nichts). Dass sich deine fl_ST20 nach dem Reset umbenennen ließ, betateilchen, passt ins Bild: frisch zurückgesetzt war sie kurz nicht gebunden, da greift der lokale Rename direkt — die noch gebundenen Boxen (und freds 3 von 10) scheitern. Ich hab den fehlenden Handler ergänzt und auf echter Hardware geprüft: Umbenennen greift dann wieder, in SixBack wie in der Bose-App. Kommt mit einem der nächsten Updates.
,,Sources Not Synced" + dass erst 4 von 6 Presets ankamen: das ist ein anderer Punkt — die Box hat ihre Account-Quellen nicht vollständig registriert. Der Re-Sync soll genau das nachholen; bleibt er bei dir nach zwei Versuchen hängen, schick mir bitte einen Diagnostic-Snapshot der fl_ST20 (Diagnose-Sharing an, dann Snapshot-Knopf). Dann sehe ich an ihrem /sources, woran die Registrierung klemmt, statt zu raten.
Power-Button-Status aktualisiert nicht: die Status-Anzeige ist eine periodische Abfrage, kein Push vom Speaker. Einen physischen Tastendruck am Gerät meldet die Bose-Firmware gar nicht nach außen — deshalb kann die Kachel den Power-Zustand nicht in Echtzeit spiegeln. Das ist eine Grenze der Geräte-Firmware, kein Wackler in SixBack.
Blinken: dass dein Repeater-Neustart der zweiten Box geholfen hat, zeigt, dass da ein Teil schlicht schwaches bzw. überlastetes Netz war. Daneben gab es aber auch einen echten Bug bei uns — die Erreichbarkeits-Probe lief im Fallback auf eine falsche Portnummer und sprang deshalb bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling". Der ist gefixt, und die Anzeige ist zusätzlich entprellt. Kommt im selben Update.
Danke euch beiden — Rename und Probe-Port hätte ich ohne eure Meldungen nicht so schnell gefunden.
Dirk
danke fürs gründliche Durchtesten — betateilchen und fred, dein Punkt von gerade eben gehört direkt dazu. Der Reihe nach:
Umbenennen (das betrifft euch beide): das ist ein echter Bug, kein Bedienfehler — und fred hat den Finger genau draufgelegt, es scheitert ja sogar in der Bose-App. Der Grund: eine an die Cloud gebundene (migrierte) Box wendet einen Rename nicht lokal an, sondern delegiert ihn an ihre Cloud — die Box feuert dabei selbst einen Account-Aufruf ab. Genau diesen Endpoint hat SixBack bisher nicht bedient, also lief der Rename ins Leere (die Box meldet ,,ok", ändert aber nichts). Dass sich deine fl_ST20 nach dem Reset umbenennen ließ, betateilchen, passt ins Bild: frisch zurückgesetzt war sie kurz nicht gebunden, da greift der lokale Rename direkt — die noch gebundenen Boxen (und freds 3 von 10) scheitern. Ich hab den fehlenden Handler ergänzt und auf echter Hardware geprüft: Umbenennen greift dann wieder, in SixBack wie in der Bose-App. Kommt mit einem der nächsten Updates.
,,Sources Not Synced" + dass erst 4 von 6 Presets ankamen: das ist ein anderer Punkt — die Box hat ihre Account-Quellen nicht vollständig registriert. Der Re-Sync soll genau das nachholen; bleibt er bei dir nach zwei Versuchen hängen, schick mir bitte einen Diagnostic-Snapshot der fl_ST20 (Diagnose-Sharing an, dann Snapshot-Knopf). Dann sehe ich an ihrem /sources, woran die Registrierung klemmt, statt zu raten.
Power-Button-Status aktualisiert nicht: die Status-Anzeige ist eine periodische Abfrage, kein Push vom Speaker. Einen physischen Tastendruck am Gerät meldet die Bose-Firmware gar nicht nach außen — deshalb kann die Kachel den Power-Zustand nicht in Echtzeit spiegeln. Das ist eine Grenze der Geräte-Firmware, kein Wackler in SixBack.
Blinken: dass dein Repeater-Neustart der zweiten Box geholfen hat, zeigt, dass da ein Teil schlicht schwaches bzw. überlastetes Netz war. Daneben gab es aber auch einen echten Bug bei uns — die Erreichbarkeits-Probe lief im Fallback auf eine falsche Portnummer und sprang deshalb bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling". Der ist gefixt, und die Anzeige ist zusätzlich entprellt. Kommt im selben Update.
Danke euch beiden — Rename und Probe-Port hätte ich ohne eure Meldungen nicht so schnell gefunden.
Dirk