Hauptmenü

Neueste Beiträge

#41
Multimedia / Aw: [Neues Modul] BOSE SoundTo...
Letzter Beitrag von Prof. Dr. Peter Henning - 10 Februar 2026, 20:54:52
Im Fhemwiki habe ich unter "Soundtouch De-Clouding" eine Anleitung eingestellt, wie man modifizierte ST10 wieder zu einem Stereopaar kombiniert. Für den soundcork-Server habe ich rund 450 Zeilen Python angeliefert, um diese Gruppenbildung zu automatisieren. Zweck war weniger das, als den Code zu verstehen, das tue ich jetzt. Und kann nur sagen: Das wird die Zukunft der Bose-Boxen sein.

Ich hatte gehofft, hier noch ein paar Erfolgsmeldungen zum Test der neuen Version von 98_BOSEST.pm zu lesen.

LG

pah
#42
Off-Topic / Aw: Hostname auf Pi plötzlich ...
Letzter Beitrag von TomLee - 10 Februar 2026, 20:54:46
Heute war ein Tag, an dem ich nicht dazu kam mich in Ruhe damit zu beschäftigen, wird heute auch nix mehr.

Was ich sagen kann, das der letzte restart von der Pi war gestern 19:39 Uhr war. Von anderen Geräten sind die Anwendungen weiterhin unter dem Hostnamen erreichbar.

Ich war oben im ersten Post nicht ganz ehrlich, ich hatte vor deiner Antwort in der hosts Datei der Pi

127.0.1.1      fhempi
durch

192.168.188.26       fhempi
ersetzt.

Wie gesagt, nicht weiter mit beschäftigt und auch keiner "KI" vorgeworfen. Kann die Änderung verantwortlich sein das es jetzt wieder klappt?

edit:
nee, kann es nicht.  Heute Morgen klappts schon wieder nicht mehr.
#43
FRITZ!Box / Aw: FRITZ!DECT 350
Letzter Beitrag von Rollo_Wikinger - 10 Februar 2026, 20:36:53
Hallo!

Ich werde aus dem vorigen Post nicht ganz schlau: funktioniert der FRITZ!DECT 350 mit FHEM oder nicht?
Genauer gesagt: Tür auf mit FRITZ!DECT 350 erkennen, dann Licht mit HomeMatic Aktor einschalten, geht das?

Danke im Voraus!
#44
Sonstige Systeme / Aw: shelly - neu dabei und ver...
Letzter Beitrag von passibe - 10 Februar 2026, 20:32:23
Das hier mal sehr aufmerksam lesen:
https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_für_Schritt

Wenn man MQTT einmal kapiert hat, ist es sehr sehr nützlich!

Ich empfehle, wie rabehd schon gesagt hat, zur besseren Übersicht beim Einbinden/Debuggen der Geräte ebenfalls den MQTT-Explorer: https://mqtt-explorer.com

Mit dem MQTT-Explorer und mit der Anleitung im Wiki solltest du zumindest schon einmal Daten vom Shelly lesen können und per autocreate dürfte sich dann auch schon automatisch ein FHEM-Device erstellen.
#45
Anfängerfragen / Aw: Raspberry über Terminal er...
Letzter Beitrag von passibe - 10 Februar 2026, 20:14:23
Hast du den FHEM-Befehl update ausgeführt, bevor der Fehler aufgetreten ist?

Was für eine Perl-Version (oder auch Betriebssystem-Version) nutzt du?

Das sieht für mich so aus als würde deine Perl-Version den keine variable length lookbehind kennen. Bin mir nicht zu 100 % sicher, aber im Zweifel mal Perl updaten. Schadet ja nicht.

EDIT: Siehe auch dieser commit, das ist erst zwei Monate her, dass da was geändert wurde: https://github.com/mhop/fhem-mirror/commit/3953e3e7a948c5bff43baf4f85ab721d14fae531
#46
Anfängerfragen / Aw: Darstellung der Spritpreis...
Letzter Beitrag von ulobo60 - 10 Februar 2026, 19:59:40
Hi,
mit der Zeit kommen ein paar Erinnerungen wieder - ich habe mein Chart-Problem gelöst !!!

Ich mußte nur die Skalierung der Grids an die aktuellen Werte anpassen. Nun läuft's.
Gut`s Nächtle  ;D
#47
Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...
Letzter Beitrag von Starkstrombastler - 10 Februar 2026, 19:36:23
Zitat von: Jojo11 am 10 Februar 2026, 19:23:40Neustart bringt keine Abhilfe. Selbst ohne dass ich irgendetwas mit dem Device anstelle sendet es diese Meldungen. Bzw. weiß ich eigentlich nicht ob es von diesem Device kommt, da ich noch andere shellys betreibe. Allerdings nur ein RGBW-Device. Bevor ich das in Betrieb genommen habe, habe ich diese Meldungen auch nicht beobachtet.
Vorschlag: Die Definiton des Devices in einem Editor sichern und das Device löschen. Anschließend neu definieren.
#48
Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...
Letzter Beitrag von Jojo11 - 10 Februar 2026, 19:23:40
Neustart bringt keine Abhilfe. Selbst ohne dass ich irgendetwas mit dem Device anstelle sendet es diese Meldungen. Bzw. weiß ich eigentlich nicht ob es von diesem Device kommt, da ich noch andere shellys betreibe. Allerdings nur ein RGBW-Device. Bevor ich das in Betrieb genommen habe, habe ich diese Meldungen auch nicht beobachtet.
#49
EnOcean / Aw: Eltako Baureihe 64
Letzter Beitrag von Flachzange - 10 Februar 2026, 18:48:28
Sie werden die nativen EnOcean-Baureihen wohl weiter vertreiben und die Baureihe 64 nutzen, um den Matter-Markt etwas auszuloten.
#50
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Februar 2026, 18:33:14
Hallo Peter,

ZitatAber - und hier wird meine Vermutung schwammig - die Prognose für die aktuelle Stunde dürfte sich eigentlich nur noch um einen gewissen Anteil der Stundenprognose ändern, der dem zeitlichen Rest der Stunde entspricht.

Kleine Zahlenbeispiel:
Die Prognose für die Stunde zwischen 11 und 12 Uhr sei um 11 Uhr mit 940 Wh berechnet.
Um 11:50 Uhr läuft die Prognose erneut und passt den Wert für die Stunde zwischen 11 und 12 Uhr auf 1060 Wh an.
Da aber 50/60 der Stunde schon rum sind, sollte die Prognose für die Stunde zwischen 11 und 12 Uhr nur um 10/60*(1060-940)=20 Wh, also auf 970 Wh steigen.
Es gibt im Modul die unterschiedlichsten Methoden, Prognosen für die jeweiligen Werte zu berechnen oder zu ermitteln. PV, Consumption, Ladezustand der Batterien und diverse Werte die sich in den special-Readings niederschlagen.
Nicht jeden Wert kann man minutengenau bzw. zeitgewichtet ermitteln, zumindest nicht mit vertretbaren Aufwand der nicht auch die Übersicht über die Logik zerstört.
Grundsätzlich verwende ich im Modul das 1-Stundenraster. Die Wetterlieferanten/API's liefern ihre Werte in der 1-Stundenauflösung. Das FHEM DWD Device ebenso. Dementsprechend normiere ich unsere selbst gemessenen Werte wie SOC, Energieverbrauch der Consumer o.ä. ebenfalls in das 1-Stundenraster.
Man sieht es an den Readings wie z.B. Today_HourXX_.*. Bei manchen Werten errechne ich eine Zeitgewichtung über die laufende Stunde. Das ist aber genau genommen eine Verallgemeinerung. Denn wer sagt denn, dass eine Änderung der PV Prognose der laufenden Stunde sich auf die letzten verbleibenden 15 Minuten bezieht und nicht auf die vergangenen 30 Minuten wenn die Prognose für die gesamte laufende Stunde gilt?
Es gibt also keinen Grund das so anzunehmen.
So gesehen ist eine teilweise vorgenommene Zeitgewichtung nur eine verallgemeinerte Annahme oder Schätzung, die auf einer angenommenen Gleichverteilung einer PV-Erzeugung oder des Hausverbrauches über die Stunde beruht. Diese Annahme wird in der Realität aber nur in seltenen Fällen zu 100% zutreffen. D.h. selbst wenn es gelingen würde die kleine Stufe in der Grafik programmtechnisch "wegzuglätten", hat es für uns - außer einer ästhetischen Komponente - keine oder nur sehr minimale Auswirkungen, die mir momentan aber auch nicht einfallen würden.
Ich glaube da gibt es aktuell wichtigere und interessantere Dinge die uns auch messbare Vorteile bringen können wenn ich sie hinbekomme.  ;)

LG,
Heiko