Neueste Beiträge

#1

DOIF / Aw: Wie gestalte ich die Bedin...

Letzter Beitrag von Damian - 17 Februar 2026, 08:50:22

Ich würde eher die zweite Methode favorisieren, da ich es gerne so genrisch wie möglich halten möchte um unabhängig zu bleiben. Außerdem war der Sonntag nur als Beispiel gedacht und noch nicht der endgültig gewählte Tag. Mir war nicht bewusst, dass der Tag so einen Unterschied machen kann, da ich den ja im Trigger mit der Uhrzeit festlege (Meine Idee ).

Der Wert "3" zum Vergleichen gilt aber nur für 2026, da es davon abhängig ist, mit welchem Wochentag das Jahr begonnen hat.

Wieso macht der erste Wochentag einen Unterschied?

Hab es mit einem Test-DOIF mit einer KI-Lösung wie folgt probiert:

Code Auswählen Erweitern

([00:01|2] and ($week % 2 == 0))Zumindest das aktivieren hat schon mal funktioniert. Frage ist, ob das DOIF morgen oder wann auch immer wieder zurück auf einen anderen Zweig schaltet. Das darf nämlich nicht passieren, da es sich um einen Alarmgeber handelt, der nur durch manuelle Aktion zurückgesetzt werden darf.

Dein DOIF wird jeden Tag getriggert, danach wird geschaut, welcher Wochentag es ist, wenn die Bedingungen wahr sind, geht es in die Auswertung der ganzen Bedingung. Wenn die Wochenabfrage nicht wahr ist (hier bei ungerader Woche), wird der Zweig nicht ausgeführt und es geht weiter mit der nächsten DOELSEIF-Abfrage bzw. zu DOELSE am Ende.

Möchtest du die Zweige unabhängig voneinander haben, musst du mehrere DOIFs definieren oder DOIF-Perl verwenden.

#2

DOIF / Aw: Wie gestalte ich die Bedin...

Letzter Beitrag von betateilchen - 17 Februar 2026, 08:47:33

Wieso macht der erste Wochentag einen Unterschied?

Weil sich daraus die Differenz zum ersten Sonntag im Jahr ergibt.
Und darauf wird in der Modulo-Rechnung getestet.


01.01.2026 -> Donnerstag -> $yday=0 -> erster Sonntag: $yday=3
01.01.2027 -> Freitag    -> $yday=0 -> erster Sonntag: $yday=2

mit einer KI-Lösung wie folgt

🤮

Sowas ist nie eine "intelligente" Lösung, sondern immer nur eine statistische Annahme.

[Revision 30863: controls_fhem.txt: fhemupdate checkin]

#3

FHEM Code changes / Revision 30863: controls_fhem....

Letzter Beitrag von System - 17 Februar 2026, 08:40:07

Revision 30863: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 30863: controls_fhem.txt: fhemupdate checkin

[Revision 30862: 76_SolarForecast: contrib version 2.276_SolarForecast: contrib ...]

#4

FHEM Code changes / Revision 30862: 76_SolarForeca...

Letzter Beitrag von System - 17 Februar 2026, 08:40:07

Revision 30862: 76_SolarForecast: contrib version 2.2
76_SolarForecast: contrib ...

76_SolarForecast: contrib version 2.2
76_SolarForecast: contrib version 2.2.0

Source: Revision 30862: 76_SolarForecast: contrib version 2.2
76_SolarForecast: contrib ...

#5

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von TheTrumpeter - 17 Februar 2026, 08:04:48

Sofern myGekko das nicht wieder (temporär) ändert, sollte es den Heizstab-Einsatz unterbinden.

Eingestellt sind 45 °C (Tag) und 43 °C (Nacht), dennoch erscheinen zwischenzeitlich abweichende Werte, beispielsweise 34 °C. Auch beim Thema Heizstäbe scheint es entsprechende Überschreibungen zu geben.

Daher gehe ich davon aus, dass in myGEKKO eine übergeordnete Logik, Programmierung oder ein Parameter hinterlegt ist, der diese Sollwerte aktiv vorgibt beziehungsweise überschreibt.

q.e.d.

#6

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von Gernertst - 17 Februar 2026, 07:14:27

Also ich habe gestern die entsprechenden Werte angepasst und heute Abend einen gezielten Test durchgeführt:

Zunächst habe ich an der Wärmepumpe im Heizkreis eine Solltemperatur von 22 °C eingestellt. Anschließend habe ich in myGEKKO (Slide 2) die Raumtemperatur auf 24 °C erhöht. Kurz darauf wurde in der Wärmepumpe die HK1-Solltemperatur ebenfalls automatisch auf 24 °C angepasst.

Für mich zeigt das eindeutig, dass die Werte von myGEKKO direkt und vollständig an die Wärmepumpe übergeben werden. Die Wärmepumpe arbeitet somit nicht eigenständig auf Basis ihrer internen Einstellungen, sondern wird aktiv durch myGEKKO übersteuert.

Ein vergleichbares Verhalten beobachte ich beim Warmwasser: 
Eingestellt sind 45 °C (Tag) und 43 °C (Nacht), dennoch erscheinen zwischenzeitlich abweichende Werte, beispielsweise 34 °C. Auch beim Thema Heizstäbe scheint es entsprechende Überschreibungen zu geben.

Daher gehe ich davon aus, dass in myGEKKO eine übergeordnete Logik, Programmierung oder ein Parameter hinterlegt ist, der diese Sollwerte aktiv vorgibt beziehungsweise überschreibt.

#7

Sprachsteuerung / Aw: Rhasspy, mein Weg zu neuen...

Letzter Beitrag von Beta-User - 17 Februar 2026, 06:48:45

ich hab deine Infos kurz überflogen und schließe daraus, dass es noch nichts gibt, was fertig ist (oder so gut wie) und einfach zu implementieren wäre.

Ähm, da fällt mir ein: Es gibt noch die Android-Apps, ich habe auch diese hier installiert: https://play.google.com/store/apps/details?id=org.rhasspy.mobile.android&hl=de, Konfiguration ist in etwa hier beschrieben: https://community.rhasspy.org/t/new-rhasspy-mobile-app-beta/4263/64
Es gibt noch eine etwas ältere, allerdings bin ich mit diesen Apps nie allzu warm geworden, aber das sollte nach wie vor funkitionieren.

Soweit ich das in Erinnerung habe, hast du via AMAD allerdings nicht nur die Sprachausgabe bei RHASSPY gemacht, sondern auch sonst.

Das müßte* im Großen und Ganzen mit FULLY (PLUS-Version) gehen, und um den als 2. Audio für RHASSPY einzurichten, braucht es vermutlich nur "etwas cloding" im RHASSPY-Modul (sollte nicht allzu kompliziert sein). Allerdings: FULLY erwartet im Moment eine statische IP-Adresse, was bei meinem ersten Test gleich nicht geklappt hat. Auch da kann man (via MQTT) einen workaround bauen, falls das nicht mit Bordmitteln des Routers zu schaffen ist. Hat nur bisher auch keinen interessiert, so dass das auf meinem persönlichen Prioritätenstapel auch "sehr low" ist...

(Und das Coding von FULLY ist imo allgemein verbesserungswürdig, dafür gilt das gleiche bzgl. Prio)

#8

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von TheTrumpeter - 17 Februar 2026, 06:37:37

NE Warmwasser und NE Heizen von 1 auf => 0 gestellt

Sofern myGekko das nicht wieder (temporär) ändert, sollte es den Heizstab-Einsatz unterbinden.

2. folgende Einstellungen direkt an der WP
  2.1 Steigung HK1 von 0,27 auf => 0,24
  2.2 Fusspunkt HK1 von 0 auf => 1Grad
  2.3 Anteil Vorlauf HK1 von 20% auf => 0%

Das hat exakt 0,0 mit dem eigentlichen Problem zu tun.


Es ist immer gut an möglichst vielen Stellschrauben gleichzeitig zu drehen, denn dann weiß man am Ende genau, welche Stellschraube das Problem verursacht bzw. gelöst hat. 

#9

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von Prof. Dr. Peter Henning - 17 Februar 2026, 03:43:19

Ich benötige mal Hilfe.

Da ich zwei ST10 als Stereopaar betreibe, habe ich mir den Spaß gemacht und rund 500 Zeilen Python für den soundcork-Server beigesteuert, um dort den group-endpoint zu implementieren. Das funktioniert auch ganz gut, allerdings noch nicht so, wie es soll.

Ein github-User "gmuth" behauptet: prima, damit ist das ganze grouping erledigt.

Allerdings ist es das bei mir nicht, ich muss nach wie vor die GroupService.xml per direktem REST-Call auf die Boxen übertragen - während er behauptet, dass die sich das beim Booten selbst holen. Die Diskussion ist hier zusammengefasst: https://github.com/deborahgu/soundcork/issues/167

Das Vertrackte ist: Als ich den Code das erste Mal ausprobiert habe, wurde tatsächlich ein DELETE-Befehl für eine Gruppe von der EINEN Stereobox auf die ANDERE StereoBox UND den soundcork-Server übertragen. Seitdem aber nur noch auf die andere Stereobox. Aus irgendeinem Grund kontaktieren die beiden Boxen nicht mehr den group-endpoint auf dem soundcork-Server, obwohl dieser bestens funktioniert.

Ich stehe also vor einem Rätsel und suche jemanden, der den soundcork-Sever mit integriertem group-endpoint ausprobiert und versucht, den Prozess zur Etablierung eines Stereopaars nachzuvollziehen. Der code ist noch nicht in den main-Branch von soundcork integriert, sondern befindet sich hier: https://github.com/pahenning/soundcork.

Gegenwärtig ist er so eingestellt, dass das "paaren" nur für ST10-Boxen funktioniert. Das geht aber offensichtlich auch mit anderen Devices - dafür müsste ich zwei Zeilen aus dem Code herausnehmen.

LG

pah

#10

DOIF / Aw: Wie gestalte ich die Bedin...

Letzter Beitrag von Marko1976 - 17 Februar 2026, 00:23:05

Ich würde eher die zweite Methode favorisieren, da ich es gerne so genrisch wie möglich halten möchte um unabhängig zu bleiben. Außerdem war der Sonntag nur als Beispiel gedacht und noch nicht der endgültig gewählte Tag. Mir war nicht bewusst, dass der Tag so einen Unterschied machen kann, da ich den ja im Trigger mit der Uhrzeit festlege (Meine Idee ).

Der Wert "3" zum Vergleichen gilt aber nur für 2026, da es davon abhängig ist, mit welchem Wochentag das Jahr begonnen hat.

Wieso macht der erste Wochentag einen Unterschied?

Hab es mit einem Test-DOIF mit einer KI-Lösung wie folgt probiert:

Code Auswählen Erweitern

([00:01|2] and ($week % 2 == 0))Zumindest das aktivieren hat schon mal funktioniert. Frage ist, ob das DOIF morgen oder wann auch immer wieder zurück auf einen anderen Zweig schaltet. Das darf nämlich nicht passieren, da es sich um einen Alarmgeber handelt, der nur durch manuelle Aktion zurückgesetzt werden darf.