OH3 und icalendar

[AndreM77]

Hey,

vielleicht eine dumme Frage, weil ich mich gerade wundere, woher es kommt.

Kann es sein, dass wenn ich ein funktionierendes Thing vom Typ icalendar hab, mit Anweisungen für die z.B. Heizungsthermostate, dass dies (wenn erfolgreich geladen) ohne wenn und aber ausgeführt werden.

Wie packe ich jetzt eine Art Heizung ja/nein drum herum? Oder ist es, der manuelle Weg - Thing aktivieren/deaktivieren?

Danke!

Grüße
André

[udo1toni]

Ich fürchte, Du musst etwas genauer erläutern, was Du gebaut hast.
Grundsätzlich: Wenn Du über einen Kalendereintrag Items setzt, dann wird der Kalendereintrag das ohne Wenn und Aber tun. Soll das nicht so sein, dann musst Du ein Proxy Item dazwischen schalten und das Ganze über eine Rule laufen lassen, also der Kalendereintrag steuert das Proxy Item, welches eine Rule triggert, die nur unter der Voraussetzung, dass bestimme Bedingungen erfüllt sind, die eigentliche Anweisung ausführt.
Aber die Idee des Kalenders ist ja, dass Du bequem über den Kalender Ausnahmen programmieren kannst, z.B. ein wiederkehrendes Event eine bestimmte Zeit aussetzen lassen oder zu einer anderen Uhrzeit ausführen. Da kommt es natürlich auf die Kalender Software an, was da geht.

[AndreM77]

hmm....

das hilft schon mal. Danke!

Könnte man auch eine Regel bauen, welche das Kalenderitem (welches ja letztlich das Kalender auslesen auslöst) per Regel aktiviert & deaktiviert? Aber dann bin ich ja fast dabei, dass ich das Kalenderitem auch manuell aktivieren / deaktivieren kann (wenn ich nur das eine Item für einen Winterbetrieb hab).

Merci!

[AndreM77]

was mir jetzt aufgefallen ist:

der Setpoint wird gesetzt, wird aber binnen Sekunden direkt auf den END Wert gesetzt.

Das steht im Kalendereintrag
BEGIN:EG_Flur_Thermostat_SetpointHeating:20
END:EG_Flur_Thermostat_SetpointHeating:16
Woran kann das liegen?

Der Kalendereintrag ist mehrere Stunden "lang".

Danke & Grüße
André

[udo1toni]

Die Frage ist vor allem, was da umsteuert.
Ich habe das Binding bisher noch nicht selbst benutzt, Siehst Du zum Zeitpunkt BEGIN des Schaltereignisses im log den Trigger received command? Siehst Du auch ein received command für den Zeitpunkt END?

[AndreM77]

Spannend, oder? o)

Das Ende ist auf 19 Uhr eingestellt. Mehr oder weniger pünktlich kommt dann:
2021-10-26 19:01:50.596 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'EG_Flur_Thermostat_SetpointHeating' received command 16
2021-10-26 19:01:50.602 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EG_Flur_Thermostat_SetpointHeating' predicted to become 16
2021-10-26 19:01:50.608 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Flur_Thermostat_SetpointHeating' changed from 20 to 16
Wenn es hier aufhören würde, wäre es ja fein.

Aber plötzlich (scheinbar immer) - ganze 5 Minuten später kommt ein Hin und Her.
2021-10-26 19:06:39.194 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Flur_Thermostat_SetpointHeating' changed from 16 to 20
2021-10-26 19:06:39.361 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Flur_Thermostat_SetpointHeating' changed from 20 to 16

Ich dachte erst, ich kann das predicted beim Item mit "Autoupdate=FALSE" ausschalten. (Soll es halt einfach ausführen/updaten) Das geht auch, aber so richtig scheint das nicht so zu arbeiten, wie ich erwartet hab.

Hat das schon mal jemand gehabt?

[udo1toni]

Der Punkt ist, dass es offensichtlich keinen Befehl für den Wechsel nach 20 gibt. Das heißt, das Ventil schaltet selbst nach 20 zurück.

Wo setzt Du denn "Autoupdate=FALSE"? Falls Du das in einer Textkonfiguration machst, muss der Parameter exakt so aussehen: autoupdate="false"
Ansonsten, falls Du über UI konfiguriert hast, musst Du aufpassen. In den Metadaten lautet es "Force the state to auto-update on command", das heißt, der Haken muss weg, Standard ist der Haken weg und es steht ein - in dem Feld. autoupdate sollte gewöhnlich nicht aktiv sein (das Verhalten an dieser Stelle wurde meines Wissens vor einiger Zeit geändert)