DOIF und eckige Klammern im Ausführungsteil

[Damian]

DOIF hat die Mächtigkeit ohne defmods auszukommen. defmod wird benötigt um eine Definition abzuändern, wenn der jeweilige Befehl nicht die Flexibilität mitbringt dynamisch auf Änderungen zu reagieren. Häufiges Anwendungsbeispiel ist der at-Befehl.

Bei DOIF kannst du indirekte Zeiten angeben oder feste Grenzwerte in Readings ablegen.

[Peter_Listig]

Hallo
zusammen

@Otto

du schreibst doch aber statischen Text in das DOIF? Wie sieht denn die Urform aus die Du mit defmod überschreibst?

Es gab nie eine Urform ... das defmod sollte die Urform anlegen und bei Bedarf die Temperatur ändern.

Das Warmwasser wird 3 x täglich auf 42 ° zu Duschen erwärmt.
Dieser Wert ist fest eingestellt. Er wird auch nicht verändert, wenn ich an der Heizungssteuerung die Einmallade-
Funtion (ebenefalls vereingestellt 30 Minuten Dauer) einschalte. Wie gesagt, zum Baden sollte das Wasser bis auf
55 ° erwärmt werden. Dazu jedesmal in Keller wetzen ist lästig ... und abschalten tut es auch stur nach 30 Min.,
sodass manchmal auch über 60 ° - 65 ° vorkommen.

@Damian

ein Hallo an den Entwickler des genialen Tools.

Du hast mich auf eine Idee gebracht - eigentlich will ich nur, dass nach 25 Minuten immer wieder geprüft
wird, ob die 3 Bedingungen zutreffen und dann die Abschaltung erfolgt.

Startzeit für die Bedingungen nach 25 Minuten
1 Modul ist im Zustand Standby
2 Momentan wird Einmalladung ausgeführt
3 Zieltemperatur ist errreicht

Kann man mein Problem möglicherweise mit einem DOELSEIF lösen ?

etwa so:

Code Auswählen Erweitern


DOLSEIF ([+00:25] and ... 3 Bedingungen


oder mit

Code Auswählen Erweitern


attr wait 1,1,1:1500


DO Teil im Sekundentakt:DOELSEIF Teil nach 1500 Sekunden

Mit den Readings und weiteren Möglichkeiten muss ich mich erst
noch auseinandersetzen.

Danke Euch

LG Peter

[Otto123]

Gut ich verstehe es nicht. Du schreibst ein statisch definiertes DOIF ich sehe da keine Veränderung. Du verwendest DOIF scheinbar wie ein dynamisches at.
Du könntest ein DOIF aktivieren und deaktivieren. Oder einfach die richtigen Bedingungen formulieren.

Entweder hast Du einen Knoten im Kopf oder ich oder wir beide 

Gruß Otto

[Damian]

Ich würde die Sache logisch trennen. Ein Modul soll eine bestimmte Temperatur halten und ein weiteres Modul steuert das erste Modul, indem es die Vorgabetemperatur verändert.

Für die erste Aufgabe ist das THRESHOLD-Modul prädestiniert, wenn man einen Schwellenschalter in Software realisieren will. Für die zweite Aufgabe würde ich dann DOIF nehmen, welches Abhängig von Schaltern oder sonstwas die Vorgabetemperatur des THRESHOLD-Moduls ändert. Dazu muss man auch nicht in irgendwelchen Abständen pollen, denn DOIF reagiert ereignisgesteuert sofort und macht, das was man möchte, hier also die Temperatur verändern.

[Peter_Listig]

Hallo nochmal,

ich glaube Otto liegt richtig - der Knoten liegt so wie es
aussieht bei mir  und wird immer verworrener  . Ich
schau mir mal das TRESHOLD Modul und die Readings an
und melde mich Morgen wieder.

Vielen Dank einstweilen
... aber ich bin hartnäckig 

LG
Peter

[Otto123]

Hallo Peter,

THRESHOLD ist für die Regelung zumindest ein guter Plan. Wobei ich dachte die Regelung macht doch Deine Heizung?

Du willst doch der Heizung nur "zuschauen" und wenn jemand den Sollwert der Warmwassererzeugung hochgedreht hat diesen nach Zeit x wieder zurücksetzen - oder?

Gruß Otto

[Peter_Listig]

Hallo Otto,

zuschauen ist nicht  .

Bei der Heizung sind am Tag 2 oder auch 3 Heizzeiten für Warmwasser mit Zieltemperatur
(42 °) und Heizdauer (2) was 2 x 15 Minuten also 30 Minuten bedeutet, vorbelegt.
Readings:
/dhwCircuits/dhw1/singleChargeSetpoint 42
/dhwCircuits/dhw1/chargeDuration 2

Wenn jemand ausserhalb der vorbelegten Zeiten Duschen oder Baden will ist meist
die anliegende Temperatur (z.B. 33.6 °) zu gering.

Wird die Einstellung "Einmalladung" an er Schalteinheit im Wohnzimmer eingeschaltet,
so wird /dhwCircuits/dhw1/charge auf "start" gesetzt und 30 Minuten bis zur Ziel-
temperatur von 42 ° aufgeheizt. Das Reading /dhwCircuits/dhw1/currentSetpoint enthält
während dieser Zeit automatisch den Wert 42 ° zugewiesen und hat ansonsten 10 °.

Für das Anschalten dieser "Einmalladung" über das Modul KM200 ist es nur erforderlich
das Reading /dhwCircuits/dhw1/charge auf "start" zu setzen.

Will ich die Aufheizdauer oder die Temperatur ändern muss ich in den Keller und die
Einstellungen direkt am Steuergerät der Heizung ändern.

Für das "Badewasser" kann ich dem Reading /dhwCircuits/dhw1/currentSetpoint
noch den gewünschten Wert (55 °) zuweisen und mit den Gang in den Keller sparen.

Am Wochenende ist mit jedoch aufgefallen, dass die relevanten Readings nicht immer
zur Verfügung stehen (nicht angezeigt werden) und damit auch nicht beschreibbar sind.

Woran das liegt kann ich nicht sagen, ob es am Modul liegt werde ich Sailor fragen,
der das Modul gestrickt hat aber ich glaube eher es liegt am Gateway der Buderus.

Da Änderungen sowieso nur im Modulzustand "Standby" möglich sind, macht das
die Sache noch komplizierter, wenn nicht sogar unmöglich.

Sollte sich dieses Problem nicht lösen lassen, wäre auch eine Steuerung über
Fhem obsolet.

Auf alle Fälle melde ich mich zum Rapport

Gruß
Peter