HMIP SWDO Meldeverzögerung bei Schutz ändern

[kruemsen]

Hallo liebe Community,

Ich habe diverse Fensterkontakte im Einsatz und für den Betrieb mit den Heizkörperthermostaten ist die Meldeverzögerung gut.
Jedoch im Voll- oder Hüllschutz möchte ich keine Meldeverzögerung wenn jemand meine Terrassentüre aufbricht.

Ich besitze aktuell noch einen Access Point als Zentrale, daher folgende Frage:
Kann ich in der CCU den Voll- / Hüllschutz so programmieren, dass die Sensoren auf 0sec Verzögerung konfiguriert werden ?

Quasi:
Wenn Hüllschutz aktiviert wird, dann Sensoren 1,2,3 auf Meldeverzögerung 0 sec stellen
Und im Umkehrschschluss:
Wenn Schutz deaktiviert wird, dann Sensoren auf Meldeverzögerung 60 sec stellen

Lieben Gruß

[Baxxy]

Kann ich in der CCU den Voll- / Hüllschutz so programmieren, dass die Sensoren auf 0sec Verzögerung konfiguriert werden ?

Grundsätzlich lässt sich die Frage mit ja beantworten.
Mit einem Script lassen sich die nötigen Master Parameter "EVENT_DELAY_UNIT" und "EVENT_DELAY_VALUE" anpassen.

Aber praktikabel ist das aus meiner Sicht nicht, denn...

• Jede Änderung dieser Parameter muss auf den Sensor (SWDO) übertragen werden. Da es ein Batteriesensor ist geschieht das nur nach Druck auf die Systemtaste des SWDO, beim öffnen / schließen des Fensters oder nach einer zyklischen Datenübertragung vom Sensor zur Zentrale.
• Obwohl die Flashspeicher der Sensoren wohl genug Schreibvorgänge aushalten ist es eher nicht vorgesehen die Konfiguration möglicherweise sogar mehrmals täglich umzuschreiben

[kruemsen]

Moin,

ok, das Problem verstehe ich.

Gibt es denn eine alternative "Lösung" aus eurem Erfahrungsschatz für mein Vorhaben, so dass ich die Meldeverzögerung für die HK Steuerung behalte und die unverzögerte Meldung bei "Einbruch" habe, oder muss ich auf eine der beiden Dinge verzichten?

Lieben Gruß und Happy Day

[Xel66]

Da sich bei IP der Datenpunkt für die Fenster-offen-erkennung beschreiben lässt, einfach ein Programm erstellen, welches verzögert diesen Datenpunkt setzt und die Direktverknüpfung zwischen Thermostat und TFK aufheben.

Gruß Xel66

[kruemsen]

Hey,

danke für die Info, nur das hab ich nicht ganz verstanden.
Könntest du mir das nochmal etwas genauer erklären?

[Xel66]

Du kannst bei IP-Geräten mit einem Programm in der Gruppe den Datenpunkt "Fenster auf" setzen. Einfach ein Programm anlegen, welches bei geöffnetem Fenster verzögert um die gewünschte Zeit diesen Datenpunkt auf "Fenster auf" setzt (und bei geschlossen eben auf "zu"). Somit hast Du Deine Verzögerung des Fensterstatus für die Heizungssteuerung aber ein promptes Ansprechen für andere Szenarien.

Gruß Xel66

[nimmnenkeks]

...
Gibt es denn eine alternative "Lösung" aus eurem Erfahrungsschatz für mein Vorhaben, so dass ich die Meldeverzögerung für die HK Steuerung behalte und die unverzögerte Meldung bei "Einbruch" habe, oder muss ich auf eine der beiden Dinge verzichten?

Jepp, Systemvariable (SysVar) vom Typ (Werteliste) anlegen mit Werten: unbekannt;geschlossen;offen
anlegen.
Dann ein Programm, welches die Zustände des Gerätes auf die Systemvariable-Werte setzt.

Code: Alles auswählen

Wenn 
TFK geschlossen -> Dann: Systemvariable auf geschlossen
Sonst, wenn
TFK geöffnet -> Dann: Systemvariable auf geöffnet
Sonst
Sytemvariable -> unbekannt

Der Wert "unbekannt" dient dazu, nach Reboot der CCU einen Wert zu setzen, bis der Sensor sich wieder gemeldet hat.
Da "ALLE" aktiven Programme während des CCU-Reboots durchlaufen werden bis ggf. ein Auslöser/Trigger greift, der Systemzustand des TFK's noch nicht bekannt ist, wird die SysVar auf "unbekannt" gesetzt.

Die SysVar erhält ihren korrekten Wert entweder durch zyklische Statusmeldung, oder durch manuelle Betätigung (währen Reboot bekommt die CCU ja nicht mit, ob das Ding betätigt wurde. Somit können z.B. die Rollladen runterfahren, weil SysVar noch falschen Wert enthält).

Somit kann man im Programm dieSysVar nutzen (ggf. mit frei wählbarer Verzögerung) und Programme damit auslösen, während die direkten Verbindungen sofort greifen.

Man könnte auch die SysVar direkt verknüpfen und somit das Programm sparen (Forensuche), ist aber bei Gerätetausch "kagge", da SysVar dann nicht mehr weiß, mit welchem Gerät es verknüpft ist (auch wenn Name gleich wieder angelegt wurde), da dies über die ID geschieht. Also wieder neu machen...

[kruemsen]

Ahh ich verstehe. Das ist ja ne gute Lösung für meinen Case!

Danke, dann werd ich mir mal ne CCU beschaffen!

[nimmnenkeks]

Wenn Du mit einer CCU anfängst, hier noch ein Tip, der nicht in den Anfängertips aufgeführt ist

"Reboot mit System und Ablauflogik"
viewtopic.php?f=31&t=39187&p=386406&hil ... nd#p386406

Man "kann", muss jedoch nicht 10 VT's (virtuelle Tasten) einsetzen.
Es erleichtert bei wachsenden Systemen die Sache natürlich.

Sobald man die SysVar (SYS True aus dem Fred) auf "false" stellt, werden Programme, welche nach o.g. Beitrag aufgebaut sind
NICHT mehr ausgeführt. Ebenfalls eine Erleichterung bei Programmerstellung.
Ebenfalls kann man die Programme über die jeweils darin genutzten VT's (langer Tastendruck starten) in der UI starten, so dass sie auch korrekt durchlaufen werden und nicht nur das "erste DANN" ausführen.

Da ALLE Auslöser/Trigger eines Programms in EINEM Block stehen,
hat man bei größeren Programmen immer die Übersicht.
Selbstverständlich muss man nicht alle Programme so aufbauen (z.B. für zyklisch Meldende Sensoren, o.ä.)

Der Fred ist nicht so "mal eben" umgesetzt, aber so kann man auch Programme mit über 100 Triggern umsetzen.

Beiträge des Author des Beitrages ist nur noch über die Suche zu finden.
In seinen Beiträgen findest Du auch ein Programmbeispiel für den Einsatz einer SysVar mit einem TFK.

[Xel66]

Da "ALLE" aktiven Programme während des CCU-Reboots durchlaufen werden bis ggf. ein Auslöser/Trigger greift, der Systemzustand des TFK's noch nicht bekannt ist, wird die SysVar auf "unbekannt" gesetzt.

Nein, auch bei der tausendundelften Wiederholung gewinnt diese Aussage nicht an Wahrheitsgehalt. Aber ich habe keine Lust, das immer und immer wieder ausführlich darzulegen. Kurzversion: Es findet lediglich eine Bedingungsprüfung statt und zusätzlich werden Programme durch die Statusübermittlung von netzversorgten Aktoren (werden bei Systemstart abgefragt) getriggert.

"Reboot mit System und Ablauflogik"

Wenn man solche Konstrukte einsetzt, sollte man auch ganz genau wissen, was man tut und vor allem mal das System wenigstens ansatzweise verstanden haben. Ansonsten legt man sein System nämlich vorzüglich auf die Nase. Wären solche Winkelzüge wirklich notwendig, hätte der Ersteller der Firmwarelogik diese eingebaut. Und nicht umsonst ist dieses Konstrukt bis eben in den Tiefen des Forums verschwunden. Solche Lösungsansätze benötigt man nur, wenn m an nicht in der Lage ist, die Programmabläufe z.B. auch beim Systemstart nachzuvollziehen. Viele der angeblichen Probleme kann durch eine geeignete Statusabfrage lösen.

Eine wirklich zielführende Empfehlung wäre der dringende Rat gewesen, sich den Einsteigerthread anzusehen und zu verstehen, sowie das WebUI-Handbuch zu laden und sich ab Seite 77ff. die Art und Weise der Programmtriggerung und -ausführung zu Gemüte zu führen. Ein Verständnis hilft ungemein, um den Spagat zwischen erwarteter Logik und der Art und Weise, wie die CCU die Programme abarbeitet, zu überbrücken. Der Hintergrund dieser Eigenart ist einfach, dass das System ausschließlich ereignisorientiert arbeitet (es zum Triggern immer ein Ereignis wie Zeitpunkt, Statusübermittlung und/oder Grenzwertüber- oder -unterschreitung benötigt) und nicht in Schleifen irgendwelche Regeln abarbeitet werden.

Gruß Xel66