Structure oder gehts anders?

[Christian72D]

Ich habe hier 28 DOIFs für meine tägliche Heizungssteuerung.

Wegen Corona (kein Witz) mache ich jetzt Spätschicht, sprich, meine ganzen Zeiten ändern sich.

Also habe ich die Steurung aufgeteilt und einige DOIFs verdoppelt, dort Zeiten geändert und habe das in drei "structure" gepackt.

Der Gedanke war: eins für die festen Werte und zwei die ich für Früh bzw Spät Dienst wahlweise ein und aus schalten kann.

Aber wenn jetzt ein Device aus der Structure geschaltet wird, ändert sich ja der Status, das hatte ich SO nicht verstanden.

Ich brauche also was, um eine Gruppe von DOIFs von Hand ein und auschalten zu können (gehts ja mit Structure), was aber NICHT durch das Verhalten der integrierten Geräte geändert wird.

[rabehd]

Ich habe hier 28 DOIFs für meine tägliche Heizungssteuerung.

Blickst Du da noch durch? Meine Empfehlung wäre das mal neu anzugehen. So klingt es nicht sinnvoll, aber Deine Technik verräts Du ja nicht.

was aber NICHT durch das Verhalten der integrierten Geräte geändert wird.

Die Geräte, welche durch die DOIF geschaltet werden? Was soll sich nicht ändern, der state der Struktur die DOIFs...?

[Christian72D]

Natürlich blicke ich da noch durch.

Ich habe hier sechs Heizkörper, die werden halt unterschiedlich per Zeit, Wochentag, Anwesendheit und abhängig von anderen Sachen gesteuert, ist eigentlich sehr logisch aufgebaut und läuft von Anfang an perfekt.
Ich habe Homematic, aber ist das wichtig?

Mir geht's darum, daß sich der Status der "Structure" NUR ändert, wenn ich explizit den Befehl dazu gebe, nicht wenn sich der Status von einem der darin befindlichen DOIF sich ändert.

[MadMax-FHEM]

Ich habe Homematic, aber ist das wichtig?

Naja: wenn du Homematic hast -> warum nutzt du dann nicht die Wochenprogramme von Homematic!?

Denn dann laufen die auch (autark), wenn fhem mal nicht tut...

Du kannst Temlist-Templates nutzen, verwalten und einfach einspielen...

EDIT: äh, vorausgesetzt du hast sie mittels CUL_HM und nicht HMCCU eingebunden...

Etc.

Gruß, Joachim

[rabehd]

Ich habe auch 6 Homematic-Thermostate und steuere auch per Schichtplan, Homeoffice... Aber dafür brauche ich keine 56 DOIFs. Mir reichen da viel viel weniger. Aber das ist nicht Dein Thema hier.

Der Status einer Struktur hängt von den Geräten darin ab und ändert sich somit auch. Dein Problem verstehe ich nicht. Da hilft vielleicht ein List der Structure und von mindestens einem Thermostat.

[Christian72D]

Der Status einer Struktur hängt von den Geräten darin ab und ändert sich somit auch. Dein Problem verstehe ich nicht. Da hilft vielleicht ein List der Structure und von mindestens einem Thermostat.

Die Frage ist doch ganz einfach: Wie kann ich eine Gruppe DOIF Befehle manuell ein und aus schalten

[Christian72D]

Naja: wenn du Homematic hast -> warum nutzt du dann nicht die Wochenprogramme von Homematic!?

Denn dann laufen die auch (autark), wenn fhem mal nicht tut...

Du kannst Temlist-Templates nutzen, verwalten und einfach einspielen...

EDIT: äh, vorausgesetzt du hast sie mittels CUL_HM und nicht HMCCU eingebunden...

Etc.

Gruß, Joachim

Die Wochen Programme sind als fail safe eingerichtet.

Aber sag mir bitte, wie diese auf Presence, Residents, verschiedenen ein oder ausgeschaltete Geräte reagieren können?

Sorry, ich hab eine ganz einfache Frage gestellt und will jetzt nicht mein bisher perfekt laufendes Smart Home umkrempeln, nur weil es euch so nicht gefällt.

[rabehd]

Sorry, ich hab eine ganz einfache Frage gestellt

[Christian72D]

Wie gesagt, in der Structure sind ausschließlich die DOIF, die die HKT steuern.
Da ist kein HKT selbst drin.

Und ich habe nirgends etwas von 56 Befehlen gesagt.

[MadMax-FHEM]

Sorry, ich hab eine ganz einfache Frage gestellt und will jetzt nicht mein bisher perfekt laufendes Smart Home umkrempeln, nur weil es euch so nicht gefällt.

Wowow, mal langsam.

Hat ja nichts mit gefallen zu tun...
...und keiner verlangt, dass du umbaust.

Es war lediglich als Hinweis gedacht...

Ansonsten: ja einfache Frage...
...dann ebenso einfache Antwort: lies doch die commandref...

Bzw. wie schon geschrieben: evtl. etwas genauer (und da am besten anhand von lists der "gefragten" Devices) was du willst...

Anders: wenn du keine (angefragte) Info lieferst, wird auch schwer zu helfen sein...

Die Wochen Programme sind als fail safe eingerichtet.

Aber sag mir bitte, wie diese auf Presence, Residents, verschiedenen ein oder ausgeschaltete Geräte reagieren können?

Notify/DOIF/mSwitch/... auf den Status von Presence/Residents etc. und dann das entsprechende vordefinierte TempTemplate laden...

Gruß, Joachim

[Beta-User]

Auch wenn du deine funktionierende Lösung nicht umbauen willst, vielleicht als Anstoß für potentielle Nachahmer:

Wenn man die Kontrolle über die Thermostate mittels manueller Temperatur-Setz-Befehle flexibel haben will (und nicht die internen Programme jeweils tauschen, was die Alternative wäre, s.u.), kann man das ganze so organisieren:

- ein weekprofile-Device anlegen, das "Topics" verwendet;
- dort die Wochenprofile anlegen (beliebig viele), dabei können z.B. bestimmte Anwesenheitsszenarien als "Topic" benannt werden (Normal, Früh-, Spätschicht, Urlaub, Homeoffice, Besuch, Party...)
- für jeden Thermostat (bzw. lies: für Gruppen, die gleich sein sollen => eine structure) einen WeekdayTimer anlegen, der auf obiges weekprofile-Device "zeigt".

Für Änderungen im Anwesenheitsstatus braucht man dann noch einen oder mehrere Eventhandler, der das Topic im weekprofile-Device umstellt => weekprofile verteilt das dann an alle WDT.
Wer das direkt auf den Thermostaten gespeichert haben will, kann auch einfach den WDT "dazwischen" weglassen, weekprofile kann nämlich auch "direkt" mit MAX; CUL_HM und HMCCU.*-Geräten...
Vorteil von WDT: $we kann man dabei auch automatisch berücksichtigen lassen (und dann das So.-Profil verwenden, bzw. einen "Feiertags"-Topic, wer es anders haben will).

Wenn man es lieber auf einzelne HK beziehen will, kann man auch die einzelnen WDT anweisen, sich ein bestimmtes Profil aus dem weekprofile-Device zu holen.

WDT kann erkennen, wenn z.B. zugehörige Fenster offen sind und dann solange nicht umschalten, falls (!) man die FK's nicht direkt gepeert hat und die Solltemperatur über Eventhandler absenkt - das will man sich ja nicht zerschießen.

Der Mechanismus mittels weekprofile ist noch recht neu, aber die, die das ausgetestet haben, scheinen sehr (!) zufrieden mit dieser Lösung zu sein. (WDT wurde mal als Heating_Control entwickelt, weitere Details stehen unter diesem Stichwort auch noch im Wiki, und man kann identische Ergebnisse auch mit WDT erreichen).

Aber jeder, wie er kann und mag .

[Christian72D]

a) hatte ich merhfach gelesen, daß es oft Probleme gibt, wenn ein komplettes Profil übertragen wird

b) finde ich meine DOIFs immer noch übersichtlicher. Ein Kriterium, was morgens runter fährt muß nicht zwangsläufig nachmittags hoch fahren, also sparen würde ich mir da nichts.

[Beta-User]

ad a)
Verstehe den Bezug nicht ganz:

- Es scheint um die Übertragung von kompletten Profilen zu den Thermostaten zu gehen? weekprofile ermittelt vorab Differenzprofile und überträgt auch nur die... (Wenn aber alles geändert wird, ist die Funklast entsprechend, und mir ist auch nicht klar, inwieweit es einen "wear-out" bei dem Speicher auf der Hardware gibt; mMn. ist dann die Änderung der Profile auf den Thermostaten selbst nur sinnvoll, wenn es um längerfristige Aktionen geht (Wechsel Ferienzeit und zurück usw., was eben alle paar Wochen passiert).
- Was WeekdayTimer angeht, sind mir keine Fehler bei der Übertragung von Profilen von weekprofile zu WeekdayTimer bekannt (es wird aus technischen Gründen lediglich der erste Schatzeitpunkt eines Tages modifiziert, aber darauf beziehst du dich ziemlich sicher nicht, oder?).

ad b)
Da verstehe ich schlicht nicht, was gemeint ist. Man setzt zu einem bestimmten Zeitpunkt eine bestimmte Temperatur, zum nächsten Zeitpunkt eine andere usw.. Da gibt es kein "korrespondierendes Paar" "runter" und "hoch"...?
Wechselt man zwischendurch das Profil, gilt eben ab da dieses Profil (bzw. der Wert, der nach diesem Profil derzeit gilt, falls der letzte Schaltzeitpunkt in der Vergangenheit liegt.)

Aber ich sehe schon, wir sprechen nicht dieselbe Sprache, und das war auch ausdrücklich an "potentielle Nachahmer" gerichtet...

[alanblack]

Ich habe hier 28 DOIFs für meine tägliche Heizungssteuerung.
[...]
Ich brauche also was, um eine Gruppe von DOIFs von Hand ein und auschalten zu können (gehts ja mit Structure), was aber NICHT durch das Verhalten der integrierten Geräte geändert wird.

Wenn die Namen der DOIFs sonst für Deine Steuerung keine Bedeutung haben, benenn sie doch einfach "DOIF_...._1", "DOIF_...._2" und"DOIF_...._3". Dann kannst Du bspw mit "attr NAME=DOIF_.*_1 disable 1"die erste Gruppe ausschalten.

Grüße

[MadMax-FHEM]

Wenn die Namen der DOIFs sonst für Deine Steuerung keine Bedeutung haben, benenn sie doch einfach "DOIF_...._1", "DOIF_...._2" und"DOIF_...._3". Dann kannst Du bspw mit "attr NAME=DOIF_.*_1 disable 1"die erste Gruppe ausschalten.

Grüße

Oder mittels:

Code Auswählen Erweitern

set DOIF_.*_1 disable

Code Auswählen Erweitern

set DOIF_.*_1 enable

Dann kommt kein "rotes Fragezeichen" und man "muss" nicht "save drücken"...

EDIT: und weil du schreibst "einfache Frage"... und ich will das so auch wenn ihr... Dann einfach mal den Thread-Titel lesen: oder gehts anders?

EDIT2: der "Trick" hier (von alanblack) heißt übrigens devSpec und da geht noch mehr... https://fhem.de/commandref_DE.html#devspec

Gruß, Joachim