- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von michael.winkler - 11 Juni 2026, 13:32:25Leider gibt es noch keinen offiziellen Patch für das Problem. Aber ich kann euch schon mal einen Workaround Bereitstellen.
Wichtig ist, dass bei einem "get status" am Account Device hier bei "NPM Cookie Version Reading"=5.0.3 steht. Wenn Ihr nicht die Version 5.0.3 habt. Dann müsst Ihr zuerst eine Aktualisierung machen! Doku: https://www.mwinklerblog.de/modul-echodevice-npm/
Wenn die Version passt, müsst Ihr folgende Datei anpassen: /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js
Ich würde euch empfehlen vorab eine Kopie von der Datei anzufertigen
Suche dort nach der Zeile " loginData.deviceSerial = deviceSerial;" (Müsste Zeilennummer 423 sein)
direkt danach dann bitte folgende Code einfügen:
Nach der Änderung die Datei speichern. Ich würde Euch dann empfehlen der FHEM Server einmal neu zu starten. Danach sollte das ganze wieder normal laufen.
Wichtig ist, dass bei einem "get status" am Account Device hier bei "NPM Cookie Version Reading"=5.0.3 steht. Wenn Ihr nicht die Version 5.0.3 habt. Dann müsst Ihr zuerst eine Aktualisierung machen! Doku: https://www.mwinklerblog.de/modul-echodevice-npm/
Wenn die Version passt, müsst Ihr folgende Datei anpassen: /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js
Ich würde euch empfehlen vorab eine Kopie von der Datei anzufertigen
Suche dort nach der Zeile " loginData.deviceSerial = deviceSerial;" (Müsste Zeilennummer 423 sein)
direkt danach dann bitte folgende Code einfügen:
Code Auswählen
if (loginData.accessToken) {
return callback(null, loginData);
}
Nach der Änderung die Datei speichern. Ich würde Euch dann empfehlen der FHEM Server einmal neu zu starten. Danach sollte das ganze wieder normal laufen.
#2
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von michael.winkler - 11 Juni 2026, 13:32:17Leider gibt es noch keinen offiziellen Patch für das Problem. Aber ich kann euch schon mal einen Workaround Bereitstellen.
Wichtig ist, dass bei einem "get status" am Account Device hier bei "NPM Cookie Version Reading"=5.0.3 steht. Wenn Ihr nicht die Version 5.0.3 habt. Dann müsst Ihr zuerst eine Aktualisierung machen! Doku: https://www.mwinklerblog.de/modul-echodevice-npm/
Wenn die Version passt, müsst Ihr folgende Datei anpassen: /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js
Ich würde euch empfehlen vorab eine Kopie von der Datei anzufertigen
Suche dort nach der Zeile " loginData.deviceSerial = deviceSerial;" (Müsste Zeilennummer 423 sein)
direkt danach dann bitte folgende Code einfügen:
Nach der Änderung die Datei speichern. Ich würde Euch dann empfehlen der FHEM Server einmal neu zu starten. Danach sollte das ganze wieder normal laufen.
Wichtig ist, dass bei einem "get status" am Account Device hier bei "NPM Cookie Version Reading"=5.0.3 steht. Wenn Ihr nicht die Version 5.0.3 habt. Dann müsst Ihr zuerst eine Aktualisierung machen! Doku: https://www.mwinklerblog.de/modul-echodevice-npm/
Wenn die Version passt, müsst Ihr folgende Datei anpassen: /opt/fhem/cache/alexa-cookie/node_modules/alexa-cookie2/alexa-cookie.js
Ich würde euch empfehlen vorab eine Kopie von der Datei anzufertigen
Suche dort nach der Zeile " loginData.deviceSerial = deviceSerial;" (Müsste Zeilennummer 423 sein)
direkt danach dann bitte folgende Code einfügen:
Code Auswählen
if (loginData.accessToken) {
return callback(null, loginData);
}
Nach der Änderung die Datei speichern. Ich würde Euch dann empfehlen der FHEM Server einmal neu zu starten. Danach sollte das ganze wieder normal laufen.
#3
Automatisierung / Aw: Neues Modul - 74_Unifi - F...
Letzter Beitrag von eisman - 11 Juni 2026, 11:58:33hi,
habe die UDM PM
Version: 5.1.15
Netzwerk: 10.4.57
und keine Probleme, nur beim Start die Meldung siehe:
#1724 "PERL WARNING: Use of uninitialized value in string ne at /usr/share/fhem/FHEM/74_Unifi.pm line 939."
was aber nicht groß stört
gruss
habe die UDM PM
Version: 5.1.15
Netzwerk: 10.4.57
und keine Probleme, nur beim Start die Meldung siehe:
#1724 "PERL WARNING: Use of uninitialized value in string ne at /usr/share/fhem/FHEM/74_Unifi.pm line 939."
was aber nicht groß stört
gruss
#4
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von betateilchen - 11 Juni 2026, 11:56:09Moin Dirk,
Die Presets standen auch vorher schon aus "synced" als die Meldung "Sources not synced" angezeigt wurde.
Das Update auf .22 hatte ich heute morgen schon eine Stunde vor dem Entstehen der beiden Screenshots durchgeführt.
Aktuell ist das Blinken wieder ohne jegliches Zutun meinerseits verschwunden, es sind jetzt aber auch nur 4 der 11 Boxen im Netzwerk angemeldet. Heute morgen waren noch alle 11 in Betrieb.
Der Test mit dem LAN Kabel war gestern Abend, heute morgen waren alle Boxen nur per WLAN angebunden.
Bezüglich der IP: Als die Box mit LAN Kabel angeschlossen war, hatte sie ja für den LAN port eine andere IP Adresse, das wurde von sixback auch korrekt erkannt. Hat jetzt vermutlich auch nichts mit dem Flackern zu tun, aber ich wollte das zumindest noch als "Positivmeldung" erwähnt haben.
Was wollen mir die Meldungen im Anhang eigentlich sagen?
Was ich gemacht habe: die 7 zusätzlichen Boxen wieder mit Strom versorgt, weil ich testen wollte, ob das Blinken bei 11 aktiven Boxen wieder auftritt.
--
Zitat von: tostmann am 11 Juni 2026, 11:21:02Erstens ,,Sources Not Synced": in deinen Bildern stehen die Presets jetzt auf ,,synced", die Meldung ist weg.
Die Presets standen auch vorher schon aus "synced" als die Meldung "Sources not synced" angezeigt wurde.
Zitat von: tostmann am 11 Juni 2026, 11:21:02Genau da steckte ein Bug: fiel die Bose-Diagnose-Konsole kurz aus, wich die Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und meldete deshalb nie ,,lebt noch". Folge: die Kachel sprang bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling", egal wie gut die Verbindung ist.
Das ist in v0.8.22 behoben (seit gestern Abend draußen): richtiger Port plus Entprellung, die Kachel kippt erst nach mehreren Fehl-Proben in Folge. Zieh das Update auf az_ST20, dann sollte das Flackern dort verschwinden. Hörbar war es ja ohnehin nie — die Box spielt unbeeindruckt weiter, die Kachel ist nur eine periodische Abfrage.
Das Update auf .22 hatte ich heute morgen schon eine Stunde vor dem Entstehen der beiden Screenshots durchgeführt.
Aktuell ist das Blinken wieder ohne jegliches Zutun meinerseits verschwunden, es sind jetzt aber auch nur 4 der 11 Boxen im Netzwerk angemeldet. Heute morgen waren noch alle 11 in Betrieb.
Zitat von: tostmann am 11 Juni 2026, 11:21:02Zur LAN-Frage: dein Repeater-Bild beantwortet sie fast selbst. az_ST20 taucht dort weiterhin über WLAN auf (5 GHz, 150 Mbit/s), obwohl du das Kabel gesteckt hattest
...
es spricht sie nur über die IP an, unter der sie im Netz auftaucht,
Der Test mit dem LAN Kabel war gestern Abend, heute morgen waren alle Boxen nur per WLAN angebunden.
Bezüglich der IP: Als die Box mit LAN Kabel angeschlossen war, hatte sie ja für den LAN port eine andere IP Adresse, das wurde von sixback auch korrekt erkannt. Hat jetzt vermutlich auch nichts mit dem Flackern zu tun, aber ich wollte das zumindest noch als "Positivmeldung" erwähnt haben.
Was wollen mir die Meldungen im Anhang eigentlich sagen?
Was ich gemacht habe: die 7 zusätzlichen Boxen wieder mit Strom versorgt, weil ich testen wollte, ob das Blinken bei 11 aktiven Boxen wieder auftritt.
--
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 11 Juni 2026, 11:53:56Hallo Gisbert,
ich nutze mal wieder eine kurze Regenphase ...
Du hast eine Wärmepumpe und ich vermute die hohen Verbrauchserwartungen kommen daher. Das sind nur Annahmen, denn ich kenne deinen Haushalt nicht. Ich würde dir raten einzustellen:
aiConTrainLimit=5000 (bzw. testen mit 4000 ... 5000)
Dadurch schneiden wir ein Stück der saisonalen Einflüsse des Winters im Training weg.
Weiterhin erscheint mir das Momentum zu hoch. Ich es reduzieren auf:
aiConMomentum=0.5 (so zwischen 0.4 ... 0.7)
Dann gibt es den Hinweis "Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)".
Das bedeutet, das neuronale Netz kann einen beträchtlichen Teil des Verbrauches nicht anhand von Abhängigkeiten einorden. Das reguliere ich durch Features soweit ich es kann. Diese Features werden durch die Profile zu- oder abgeschaltet. Dir würde ich deswegen raten noch zu setzen:
aiConProfile=v1_heatpump_active_pv
Das passt nicht wirklich wegen dem Zusatz "_pv". Ich bemerke gerade, dass ein Profil v1_heatpump_active fehlt, was für dich und andere WP-User treffender wäre. Das bessere ich nach.
Dann trainiere damit und schau dir die Ergebnisse an.
Weiterhin kann es hilfreich sein, die Contrib Version 2.7.0 zu laden und dort einzustellen:
aiConProfile=v1_sandbox
Das aktiviert Features die ich demnächst produktiv einführen werde. Vllt. führt das bei dir bereits etwas näher zum Ziel.
LG,
Heiko
ich nutze mal wieder eine kurze Regenphase ...
Du hast eine Wärmepumpe und ich vermute die hohen Verbrauchserwartungen kommen daher. Das sind nur Annahmen, denn ich kenne deinen Haushalt nicht. Ich würde dir raten einzustellen:
aiConTrainLimit=5000 (bzw. testen mit 4000 ... 5000)
Dadurch schneiden wir ein Stück der saisonalen Einflüsse des Winters im Training weg.
Weiterhin erscheint mir das Momentum zu hoch. Ich es reduzieren auf:
aiConMomentum=0.5 (so zwischen 0.4 ... 0.7)
Dann gibt es den Hinweis "Rauschen Bewertung: merkliches Rauschen, Interpretation mit Vorsicht (borderline)".
Das bedeutet, das neuronale Netz kann einen beträchtlichen Teil des Verbrauches nicht anhand von Abhängigkeiten einorden. Das reguliere ich durch Features soweit ich es kann. Diese Features werden durch die Profile zu- oder abgeschaltet. Dir würde ich deswegen raten noch zu setzen:
aiConProfile=v1_heatpump_active_pv
Das passt nicht wirklich wegen dem Zusatz "_pv". Ich bemerke gerade, dass ein Profil v1_heatpump_active fehlt, was für dich und andere WP-User treffender wäre. Das bessere ich nach.
Dann trainiere damit und schau dir die Ergebnisse an.
Weiterhin kann es hilfreich sein, die Contrib Version 2.7.0 zu laden und dort einzustellen:
aiConProfile=v1_sandbox
Das aktiviert Features die ich demnächst produktiv einführen werde. Vllt. führt das bei dir bereits etwas näher zum Ziel.
LG,
Heiko
#6
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von tostmann - 11 Juni 2026, 11:21:02Hi betateilchen,
danke für die Screenshots — die helfen sehr, da steckt die halbe Antwort schon drin.
Erstens ,,Sources Not Synced": in deinen Bildern stehen die Presets jetzt auf ,,synced", die Meldung ist weg. Das passt — die Box hatte ihre Account-Quellen anfangs nicht vollständig registriert, der periodische Abgleich holt das im Hintergrund nach. Hier hat er ohne dein Zutun gegriffen.
Zweitens das Blinken: deine beiden Aufnahmen 16 Sekunden auseinander zeigen genau das Kippen grau→grün, während die Box ungestört weiterspielt. Und dein Repeater-Bild ist der entscheidende Hinweis: az_ST20 hängt dort mit 5 GHz und 150 Mbit/s, also bestens angebunden. Damit ist klar, dass es NICHT am schwachen oder überlasteten Funk liegt, sondern an der Erreichbarkeits-Probe selbst. Genau da steckte ein Bug: fiel die Bose-Diagnose-Konsole kurz aus, wich die Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und meldete deshalb nie ,,lebt noch". Folge: die Kachel sprang bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling", egal wie gut die Verbindung ist.
Das ist in v0.8.22 behoben (seit gestern Abend draußen): richtiger Port plus Entprellung, die Kachel kippt erst nach mehreren Fehl-Proben in Folge. Zieh das Update auf az_ST20, dann sollte das Flackern dort verschwinden. Hörbar war es ja ohnehin nie — die Box spielt unbeeindruckt weiter, die Kachel ist nur eine periodische Abfrage.
Zur LAN-Frage: dein Repeater-Bild beantwortet sie fast selbst. az_ST20 taucht dort weiterhin über WLAN auf (5 GHz, 150 Mbit/s), obwohl du das Kabel gesteckt hattest — die Box hat ihre WLAN-Verbindung also nicht aufgegeben. Heißt: dein ,,LAN-Test" hat den Repeater vermutlich gar nicht aus dem Spiel genommen, die Box lief die ganze Zeit über WLAN. Für SixBack ist es ohnehin einerlei, welchen Weg die Box nimmt — es spricht sie nur über die IP an, unter der sie im Netz auftaucht, und das Flackern kommt von der Probe, nicht vom Verbindungsweg.
Danke fürs gründliche Dokumentieren — sag gern, ob das Flackern nach dem v0.8.22-Update auf az_ST20 weg ist.
Dirk
danke für die Screenshots — die helfen sehr, da steckt die halbe Antwort schon drin.
Erstens ,,Sources Not Synced": in deinen Bildern stehen die Presets jetzt auf ,,synced", die Meldung ist weg. Das passt — die Box hatte ihre Account-Quellen anfangs nicht vollständig registriert, der periodische Abgleich holt das im Hintergrund nach. Hier hat er ohne dein Zutun gegriffen.
Zweitens das Blinken: deine beiden Aufnahmen 16 Sekunden auseinander zeigen genau das Kippen grau→grün, während die Box ungestört weiterspielt. Und dein Repeater-Bild ist der entscheidende Hinweis: az_ST20 hängt dort mit 5 GHz und 150 Mbit/s, also bestens angebunden. Damit ist klar, dass es NICHT am schwachen oder überlasteten Funk liegt, sondern an der Erreichbarkeits-Probe selbst. Genau da steckte ein Bug: fiel die Bose-Diagnose-Konsole kurz aus, wich die Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und meldete deshalb nie ,,lebt noch". Folge: die Kachel sprang bei jedem kurzen Aussetzer direkt auf ,,offline" statt auf das weiche ,,settling", egal wie gut die Verbindung ist.
Das ist in v0.8.22 behoben (seit gestern Abend draußen): richtiger Port plus Entprellung, die Kachel kippt erst nach mehreren Fehl-Proben in Folge. Zieh das Update auf az_ST20, dann sollte das Flackern dort verschwinden. Hörbar war es ja ohnehin nie — die Box spielt unbeeindruckt weiter, die Kachel ist nur eine periodische Abfrage.
Zur LAN-Frage: dein Repeater-Bild beantwortet sie fast selbst. az_ST20 taucht dort weiterhin über WLAN auf (5 GHz, 150 Mbit/s), obwohl du das Kabel gesteckt hattest — die Box hat ihre WLAN-Verbindung also nicht aufgegeben. Heißt: dein ,,LAN-Test" hat den Repeater vermutlich gar nicht aus dem Spiel genommen, die Box lief die ganze Zeit über WLAN. Für SixBack ist es ohnehin einerlei, welchen Weg die Box nimmt — es spricht sie nur über die IP an, unter der sie im Netz auftaucht, und das Flackern kommt von der Probe, nicht vom Verbindungsweg.
Danke fürs gründliche Dokumentieren — sag gern, ob das Flackern nach dem v0.8.22-Update auf az_ST20 weg ist.
Dirk
#7
TabletUI / Aw: [FTUI3] Button sendet an S...
Letzter Beitrag von caldir65 - 11 Juni 2026, 10:45:50Ganz kurios, ich habe es jetzt dadurch gelöst, daß ich den ShellyPlugS 1:1 durch einen Anderen ersetzt habe mit den gleichen Einstellungen - und plötzlich funktioniert es.
Gruß
Christoph
Gruß
Christoph
#8
Hard- und Firmware / Aw: Firmware zu CUL, CUNX und ...
Letzter Beitrag von noansi - 11 Juni 2026, 10:20:05Hallo Eckart,
die Registerwerte, die mit dem Delayed Hinweis kommen, sehen normal aus. Er sollte empfangen.
Auch noch möglich, dass Du einen "babbling idiot" auf 868.3MHz hast (muss nicht HM sein), der wegen z.B. schwacher Batterie in einen ständigen Sendezustand verfällt und damit die Frequenz zeitweise stört.
Z.B. der Lichtsensor, der Batterien frisst (vielleicht weil er viel sendet?). Nimm dem mal temporär die Batterien raus und schau, ob die Meldungen verschwinden.
Andere Störer, die z.B. nur zeitweise eingeschaltet sind, wären auch noch möglich.
Und natürlich kann ich einen Defekt am CUL nicht ausschließen. Sind die RSSI Werte insgesammt für alle devices schlechter geworden? Nahe HM devices im selben Raum wie der CUL sollten prächtige RSSI Werte zeigen.
Gruß, Ansgar.
die Registerwerte, die mit dem Delayed Hinweis kommen, sehen normal aus. Er sollte empfangen.
ZitatIch habe einen Temperatursensor Aussen, einen für das Bad und einen für das Wohnzimmer. Keine Ahnung ob die ständig Funken (sind alles HM Geräte).Sollten sie. Wann hast Du von denen zuletzt was empfangen? Wie sieht der RSSI bei den devices aus? Wenn alle sehr schwach rein kommen, dann kann der Zufall solche Delayed Meldungen erzeugen, weil von allen gerade nicht kommt.
Auch noch möglich, dass Du einen "babbling idiot" auf 868.3MHz hast (muss nicht HM sein), der wegen z.B. schwacher Batterie in einen ständigen Sendezustand verfällt und damit die Frequenz zeitweise stört.
Z.B. der Lichtsensor, der Batterien frisst (vielleicht weil er viel sendet?). Nimm dem mal temporär die Batterien raus und schau, ob die Meldungen verschwinden.
Andere Störer, die z.B. nur zeitweise eingeschaltet sind, wären auch noch möglich.
Und natürlich kann ich einen Defekt am CUL nicht ausschließen. Sind die RSSI Werte insgesammt für alle devices schlechter geworden? Nahe HM devices im selben Raum wie der CUL sollten prächtige RSSI Werte zeigen.
Gruß, Ansgar.
#9
TabletUI / Aw: [ftui3] Button sendet an S...
Letzter Beitrag von caldir65 - 11 Juni 2026, 10:04:49Moin,
kann es sein, das das Problem direkt mit Shelly bzw. dem entsprechenden fhem-Modul dafür zusammen hängt?
Ich habe auch noch einen Button angelegt, der über FritzSmart das GuestWlan ein- bzw. ausschalten soll - und der funktioniert einwandfrei.
Bei Shelly kann ja auch noch eine channel-Angabe hinzugefügt werden, ist aber bei Einkanalgeräten wie dem hier genutzten ShellyPlugS nicht notwendig.
Gruß, Christoph
kann es sein, das das Problem direkt mit Shelly bzw. dem entsprechenden fhem-Modul dafür zusammen hängt?
Ich habe auch noch einen Button angelegt, der über FritzSmart das GuestWlan ein- bzw. ausschalten soll - und der funktioniert einwandfrei.
Code Auswählen
<ftui-button [(value)]="Fritzbox:guestWlan"
[fill]="Fritzbox:box_guestWlan | map('off:outline, on:solid')"
[color]="Fritzbox:box_guestWlan | map('off:white, on:primary')"
size="large" @hold="box_guestWlan.open()">
<ftui-icon name="it_router" color="white" path="../images/openautomation/"></ftui-icon>
</ftui-button>
<ftui-label size="1" color="white">Gast-WLan</ftui-label>
Bei Shelly kann ja auch noch eine channel-Angabe hinzugefügt werden, ist aber bei Einkanalgeräten wie dem hier genutzten ShellyPlugS nicht notwendig.
Gruß, Christoph
#10
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.
--