Neueste Beiträge

#11

ESP Familie / Aw: BoseFix32 — lokaler SoundT...

Letzter Beitrag von betateilchen - 10 Juni 2026, 20:23:02

Die fl_ST20 habe ich nun ins Arbeitszimmer geholt, da steht sie ca. 1 Meter neben einem WLAN Repeater.

Heute Abend hatte plötzlich eine zweite Box - interessanterweise auch eine ST20 - hier im Arbeitszimmer den Blinker gespielt. Das Blinken bezieht sich übrigens nur auf die Anzeige im WebUI von sixback. Auf die Funktion der Box hat das keinen erkennbaren Einfluß, sie spielt munter vor sich hin.

Dann habe ich den besagten Repeater einmal stromlos gemacht und neu gestartet, jetzt scheint das Blinken an der zweiten Box erstmal verschwunden zu sein.

Die fl_ST20 habe ich inzwischen zurückgesetzt und nun kämpfe ich seit einer ganzen Weile damit, die Box wieder für sixback nutzbar zu machen. Sie ist im WLAN, wird von sixback gefunden und angeblich auch migriert. Danach kann ich die Box auch über sixback ein- und ausschalten, der Status des "Power" Buttons wird aber nicht aktualisiert. Auch sind auf der Box nur 4 von 6 presets angekommen und die Box meldet den Status "Sources not synced". Den Button "Re-Sync Sources" habe ich schon zweimal ausprobiert.

Was bei der Box aber funktioniert hat: Ich konnte sie über sixback umbenennen. Den Namen, den ich in der Bose App bei der Einbindung ins WLAN vergeben hatte, hat die Box nicht übernommen.

Mal schauen, wie weit ich heute noch mit dieser seltsamen Box komme...

#12

DOIF / Aw: Im DOIF einen *-for-timer ...

Letzter Beitrag von fireball - 10 Juni 2026, 20:14:15

Wenn es mega viel war, stelle ich die Bewässerung 2 Tage aus, wenns es die Hälfte war, was mein Garten braucht, dann nur für einen Tag.

Teste doch einfach jeden Tag und teile die Menge durch den zeitlichen Abstand. Bist du unter einem passenden Wert, dann Regner an.

Hi, wenn du dir mein DOIF anschaust, dann siehst du, dass jeden Tag gecheckt wird, wieviel Niederschlag am Vortag gefallen ist und dann wird der Timer neu gesetzt.
Einzige Ausnahme ist die letzte Bedingung, die dafür sorgt, dass wenn es nur kurzzeitig regnet, der Timer nicht überschrieben werden soll.

VG
René

#13

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von cs-online - 10 Juni 2026, 19:59:26

Was bei mir u.a. geholfen hat nachdem es ne Ewigkeit zuerst den Token-Fehler gegeben hat und danach die Geräte angeblich nicht erreichbar waren:

In die Alexa-App gegangen und in die Einstellungen des Alexa-Skills rein (nichts geändert, nur reingegangen). Danach lief alles wieder (seit über 1 Stunde jetzt, hoffe das bleibt so).

Was hat jetzt der Alexa Skill mit diesem Modul zu tun

#14

ESP Familie / Aw: BoseFix32 — lokaler SoundT...

Letzter Beitrag von tostmann - 10 Juni 2026, 19:55:43

@fred

danke — das beantwortet die entscheidende Frage: der Ton läuft durch, nur die Kachel zappelt, also rein kosmetisch. Und dein Hinweis mit den 9–10 Boxen hat mich direkt auf die Ursache gebracht.

Der Fehler war konkret: fällt die Bose-Diagnose-Konsole unter Last kurz aus, weicht die Erreichbarkeits-Probe auf die normale Geräte-API aus — dieser Fallback lief aber auf die falsche Portnummer und lieferte nie ein "lebt noch". Dadurch konnte der weiche "settling"-Zustand nie greifen, und die Kachel sprang bei jedem kurzen Aussetzer direkt auf "offline". Bei zehn nacheinander geprobten Boxen passiert das ständig — genau dein Muster.

Beides ist hier behoben: der Fallback trifft jetzt den richtigen Port, und die Anzeige ist entprellt (kippt erst nach mehreren Fehl-Proben). Ich teste den Fix gerade. Danke fürs Melden — der Fall hat einen echten Bug aufgedeckt.

Dirk

#15

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von Bartimaus - 10 Juni 2026, 19:49:58

@Starkstrombastler

Hallöle,

ich habe mir mal wieder ein neues Shelly-Device gegönnt. Bin scheinbar wieder der Erste.
Der Gerät nennt sich "Shelly The Pill"

Beim Versuch dieses über das ShellyModul einzubinden habe ich folgende Fehlermeldung bekommen:

Code Auswählen Erweitern

[Shelly_getModel] /shelly: device Shelly.ThePill is of type 'S3SN-0U53X' but we have no key of that name, proposed model is 'generic'
Falls es keinen zu grossen Aufwand macht, würde ich mich freuen wenn Du das ins Modul einbinden könntest. Bis dahin werde ich es via MQTT benutzen (was ich aber nicht sooo mag )

Für Rückfragen stehe ich selbstverständlich zur Verfügung...

LG

#16

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von gent - 10 Juni 2026, 19:48:31

Hi,

eine defekte Hardware eines Shelly Dimmer (1. Generation) und ein freundliches Entgegenkommen seitens Shelly hat mir nun ein Shelly Dimmer gen3 beschert. Diesen habe ich mit dem Shelly Modul (wie immer) eingebunden und ein Device wurde angelegt. Allerdings steht als model Attribut da nun "shellyprodm1pm" In den Readings sehe ich aber

model_ID S3DM-0A101WWL
model_family Gen3
model_function dimmer
model_name Shelly Dimmer Gen3

Beim alten Device stand im model Attribut noch "shellydimmer" drin.

Soweit ich es sehen kann funktioniert das neue Device aber. Zumindest geht es an und aus und es dimmt auch.

Ist das ein Schönheitsfehler oder ist es etwas, um das es sich zu kümmern lohnt?

Liebe Grüße

#17

ESP Familie / Aw: BoseFix32 — lokaler SoundT...

Letzter Beitrag von betateilchen - 10 Juni 2026, 19:29:03

Aus demselben Fall eine Erkenntnis, die vielleicht dein fl_ST20-"Blinken" erklärt:

Die fl_ST20 ist inzwischen per LAN Kabel angeschlossen. Auch da macht sie den Blinker.
Jetzt werde ich tatsächlich mal das Factory Reset machen.

Was mir noch aufgefallen ist: Das Umbenennen eines (anderen) Speakers, was seit 0.8.18 funktionieren soll, klappt hier nicht. Das mit dem Reboot habe ich natürlich schon mehrfach probiert.


--

#18

Solaranlagen / Aw: [23_BYDBox] - Modul für BY...

Letzter Beitrag von Parallix - 10 Juni 2026, 18:58:55

Ja, OptPower nutze ich eh schon. Daher kommen die 300W her (pinreduced).
Ich werds mal versuchen mit der Spannungebegrenzung anstatt einer SOC Begrenzung.

Wenn Du die Spannungsbegrenzung drin hast, dann kannst Du oben gerne mit noch geringerer Leistung laden. Im Idealfall so, dass der Balancer die Zellen mit zu hoher Spannung sehr absenkt, während die anderen Zellen langsam geladen werden.

Das die Zellen etwas unterschiedlich sind verstehe ich schon, aber meine Zellen waren nicht stark unterschiedlich. Es täuscht vielleicht etwas weil an dem Tag manchmal größere Leistungen gezogen wurden.

Die Unterschiede werden auch nur im im oberen und unteren Spannungsbereich gut sichtbar. Hattest Du früher denn auch oben (bei 3450mV) noch ein perfekt balanciertes System?

Was ich nicht verstehe ist, das das BMS die Batterie so leer werden hat lassen.

Wenn die einzelnen Zellen sehr unterschiedlich geladen sind, dann verschätzt sich das BMS mitunter ordentlich. Sobald die erste Zelle an der unteren Grenze angekommen ist, während die anderen vielleicht noch deutlich drüber liegen, im Mittel also eine höhere Energiemenge und damit ein theoretisch hörere SOC vorliegt, korrigiert das BMS seine Schätzung nach unten. Das ist das, was bei Dir der Fall war.

Selbst mit den aus dem BMS ausgelesenen Energiewerten fällt sofort auf das wenn ich mehrmals mehr Energie aus der Batterie rausnehme als ich reinstecke, ich mit Sicherheit nicht den gleichen SOC wieder erreiche.
Das hat er drei Tage lang gemacht, und dann aber "richtigerweise" am vierten Tag den SOC so schnell fallen lassen das es für den Laien wie ein lineares leeren des Akkus aussieht. Das ging bis zur unteren Grenze mit anschließender Notladung. Ich unterstelle hier dem BMS mal teilweise Vorsatz... aber warum?
Warscheinlich ging es schon 4 Tage vorher dem ersten roten Pfeil los, da dort das letzte mal ein Ballancing gemacht wurde.
Das war als der Akku einmal von der Wallbox mit maximaler Leistung leer gezogen wurde, weil ich übernacht laden musste.

Aus diesem Grund verlasse ich mich auch unten nicht auf den SOC, sondern schalte die Entladung ab, sobald ich im unteren Bereich eine hohe Zellspannungsdifferenz sehe. Denn es gibt vermutlich nichts sinnfreieres, als eine Elektroauto aus einem Heimspeicher zu laden, der dann wieder durch Netzstrom aufgeladen werden muss.

#19

DOIF / Aw: Im DOIF einen *-for-timer ...

Letzter Beitrag von rabehd - 10 Juni 2026, 18:15:55

Teste doch einfach jeden Tag und teile die Menge durch den zeitlichen Abstand. Bist du unter einem passenden Wert, dann Regner an.

Ich halte meinen Ansatz für den richtigen und werde es auch so lassen...

#20

Server - Linux / Aw: [Docker / Container] echod...

Letzter Beitrag von rabehd - 10 Juni 2026, 18:14:09

Ich bin leider kein Systemadmin und taste mich oft an Dinge ran.
Ich nutze FHEM im Docker. Bisher funktioniert echodrive. Ich halte diesen Container für langfristig besser.
Also habe ich das mal im Stack eingefügt.

Code Auswählen Erweitern

########################
  FHEM:
    container_name: fhem_main
    hostname: fhem_main
    image: ghcr.io/fhem/fhem-docker:4-bullseye
    restart: always
    networks:
      fhem-network:
        ipv4_address: 172.31.31.60
    ports:
      - 8083:8083
      - 1883:1883 # MQTT
      - 3002:3002
    environment:
    - FTP_PASSIVE=1
    volumes:
    - /docker/fhem:/opt/fhem/
    - /docker/fhem-backup/MAIN:/backup
    - /docker/Logs:/log
    - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - FHEM-DB
      - FHEM-alexa
      - FHEM-Homematic

########################
  alexa-cookie-service:
    image: ghcr.io/fhem/alexa-cookie-service:0.3.1
    container_name: fhem_alexa_cookie_service
    volumes:
      - /docker/alexa-cookie-data:/data
      - /docker/fhem/cache/alexa-cookie:/opt/fhem/cache/alexa-cookie
    environment:
      AUTH_TOKEN: change-me
      COOKIE_EXPORT_DIR: /opt/fhem/cache/alexa-cookie
      PROXY_PUBLIC_HOST: 192.168.31.60
    ports:
      - "58090:58090"
    networks:
    fhem-network:
        ipv4_address: 172.31.31.63
    restart: unless-stopped
    user: "6061:6061"     

Der Container startet und geht dann auf unhealthy.
Ist das erstmal ok? Vermutlich nicht.

[2026-06-10T16:03:45,958 UTC] [INFO] 127.0.0.1 - - [10/Jun/2026:16:03:45 +0000] "GET /healthz HTTP/1.1" 503 141 "-" "-"

Danke