Umkehrfunktion zur Timeout-Funktion...

[Familienvater]

Hallo,

ich mache regen Gebrauch der Timeout-Funktion, allerdings beschleicht mich immer ein ungutes Gefühl, wenn ich ein Timeout von einem Rauchmelder bekomme, weil ich nicht weiss, ob wieder da ist.

Falls von einem HMS100 T nix mehr kommt, und die Timeout Funktion aufgerufen wird, setze ich aus der Timeout-Funktion eine Variable im Makro des HMS100 T und schicke mir eine Mail, das ein Sensor abgängig ist

Wenn jetzt die Haussteuerung wieder einen Wert von dem Sensor empfängt, schicke ich mir eine Entwarnungsmail und setze die TimedOut-Variable wieder zurück.

Leider gibt es beim HMS100 Rauchmelder oder auch beim HMS Wassermelder keine Routine, die beim Empfang eines "ich bin noch da"-Funkpaketes getriggert wird. Könnte man hier noch irgendetwas machen, damit ich/meine Studio-Version den TimedOut Status des Rauchmelders wieder zurücknehmen kann?

Mit freundlichen Grüßen

der Familienvater

[Sanys]

Hallo Familienvater,

schon mal hiermit probiert: (aus der Hilfe)

CHECKTIMEOUT(Objekt)

Diese Funktion wird ausschließlich in Bedingungen verwendet, um zu prüfen ob von einem Modul, das normalerweise in reglemässigen Abständen eine Meldung schickt länger keine Meldung mehr gekommen ist. So kann überprüft werden, ob dieses Modul ordungsgemäss funktioniert und eine Funkkommunikation besteht.
Diese Funktion kann nur für HMS-Sensoren benutzt werden.

Die Funktion ist WAHR, wenn länger als 90 Minuten keine Meldung mehr empfangen wurde.

Ich stelle mir das so vor, daß wenn ein Timeout gemeldet wird, Du dann in den nächsten 100 min mehrfach diese Funktion bemühst, bis der Timeout nicht mehr besteht (folglich der Sensor sich wieder gemeldet hat). Dann weist Du das er geht und kannst Deine Variablen entsprechend setzen.

Das Problem wird nur die Zuordnung bei mehreren Sensoren sein. Die Variable Timeout enthält den Objektnamen, ob die Funktion Checktimeout(Variable) aber geht wage ich zu bezweifeln (geht nicht, habs gerade probiert). Folglich mußt Du wieder Abfragen einbauen um Checktimeout für das richtige Objekt zu verwenden (toll wäre in diesem Zusammenhang eine Case/Select Funktion.)

Probiers mal aus und laß es uns wissen.

Viel Erfolg

sanys

[contronics-RK]

Das Timeoutflag wird gesetzt wenn ein HMS-Modul länger als 90 Minuten keine Meldung bekommt. Es wird rückgesetzt sobald wieder eine Meldung für das Modul kommt. Bei jeder Meldung die kommt, kann das Makro ausgeführt werden (Option "Ausführung bei Empfang"). Im Makro kann also auch die Beendigung eines Timeouts entsprechend behandelt werden. Dass ein Timeout vorlag kann ja über Variablen "gemerkt" werden.

[buempi]

Sehr geehrter Herr Krapoth

Bei jeder Meldung die kommt, kann das Makro ausgeführt werden (Option "Ausführung bei Empfang").

Gilt das wirklich für alle HMS 100 Module? Beim HMS 100 T und beim 100 TF ist das wirklich so. Wie es beim Rauchmelder ist, weiss ich nicht.

Jedenfalls beim HMS 100 TFK wird das Makro nur ausgeführt, wenn sich durch das Signal der Zustand ändert. Bei Zustandsänderung sendet der TFK im Abstand von 17 Sekunden 3 mal und nachher alle knapp 30 Minuten ein "Ich bin noch da". Das Makro wird aber nur beim ersten Signal ausgeführt und nachher erst wieder, wenn der Zustand ändert.

Ich hatte nämlich ein ähnliches Problem wie Familienvater und habe dann auf einem recht komplizierten Umweg eine brauchbare Lösung gefunden (2 HMS 100 TFK-Module mit gleicher Adresse, wo sich der eine immer gleich wieder umschaltet und so den falschen Zustand hat).

Grundsätzlich gibt es gute Gründe, dass das Makro nur bei Zustandsänderung ausgeführt wird. Wenn sich z.B. jemand eine Alarmmeldung schicken lassen will, wenn eine Türe geöffnet wird, benötigt er diese nicht 3 x hintereinander und nachher nochmals alle 30 Minuten. Ein solches Verhalten könnte aber mit "Wenn geschaltet(TFK) dann..." leicht abgefangen werden.

Sollte für den Raummelder das gleiche gelten wie für den TFK ist es hingegen nicht möglich, z.B. einen Timeout zurückzusetzen. Es sei denn, man benutze komplizierte Umwege; z.B. den Vorschlag von Sanys oben.

Optimal wäre es wohl, wenn man zwischen "Ausführen bei Empfang" und "Ausführen bei Zustandsänderung" wählen könnte.

Freundliche Grüsse
Bümpi

[contronics-RK]

Richtig! Da habe ich nicht aufgepasst. Bei HMS-Zustandsmeldern wird das Makro nur bei Änderung ausgeführt. Es gibt aber eine Lösung, die das Problem wie ich meine zufriedenstellend löst (so habe ich es bei mir zuhause gemacht):
Für den TFK (bzw. andere HMS-Melder) eigene Type definieren, z.B. "zu","offen","Störung" und diesen Typ dem HMS-Modul zuweisen (in der Objektdefinition).
Wenn nun ein Timeout eintritt den Zustand auf Störung setzen (z.B. im Makro des Objekts Timeout ).

Code: Alles auswählen

wenn Timeout = "Kellerfenster" dann
  Kellerfenster:="Störung"
endewenn

oder

Code: Alles auswählen

wenn Timeout = "Kellerfenster" dann
  Kellerfenster:=2
endewenn

(diese zweite Variante mit direkter Zuweisung des Indexes (Achtung: beginnt bei 0) ist schlechter zu lesen aber von der Ausführung her erheblich schneller, da der Textwert nicht erst in einen Zahlenwert konvertiert werden muss, so ist z.B. auch <Licht einschalten> erheblich schneller als <Licht:="an">).

Wenn jetzt eine Meldung vom HMS-Modul kommt kann diese ja nur einen "normalen" Wert haben und das Makro wird ausgeführt.
Diese Lösung hat den Vorteil, dass die Störung des Moduls auch direkt visualisiert wird.

[buempi]

So einfach geht's.....! Man muss nur drauf kommen!

Da werde ich mich gleich mal an die Überarbeitung meiner komplizierten Konstruktion mit zwei Modulen mit gleicher Adresse machen.

Vielen Dank für die blitzartige Antwort!

Bümpi

[squeeezer]

hallo herr krapoth,

ist es performance-technisch wirklich empfehlenswert, mit index-ziffern zu arbeiten? ich hab mein gesamtes projekt im grunde genommen mit

Lich1 := "an"

gespickt. lohnt sich das umstellen auf index-werte? in welchem faktor würde das system schneller laufen, wenn index-werte verwendet werden? (mir ist klar, dass das natürlich abhängig von der anzahl der zuweiseungen ist, aber gibts da schätz/erfahrungswerte?)

viele liebe grüße und danke für die antwort ...

[contronics-RK]

Hallo Herr K...

die Speicherung von Zuständen erfolgt immer als Index des Zustands innerhalb der Zustandsliste des Typs. Daher sind direkte Zuweisungen des Index wie Licht1 einschalten bzw. Licht1:=1 erheblich schneller als Zuweisungen von Text, da der Text erst in der Liste gesucht werden muss, um den Index zuweisen zu können.
Das gleiche gilt analog auch für Vergleiche "wenn Licht eingeschaltet.." ist schneller als "wenn Licht = "an".
Direkte Zuweisungen/Vergleiche sind schätzungsweise um den Faktor 3-5 schneller.
Aber... dabei muss man natürlich auch die tatsächlichen Ausführungzeiten sehen, und die sind minimal.
Da der erzeugte Code sehr effizient ist, merkt man selbst bei vielen Objekten und grossen Makros eigentlich keinen Unterschied. Auch bei grösseren Makros mit mehreren solcher Zuweisungen/Vergleiche in einem Makro dürfte der Zeitunterschied (je nach Rechner /Auslastung) schätzungsweise kleiner als 1/10.000 Sekunde je Makro sein.
Selbst bei grösseren Projekten also letztlich kein merklicher Unterschied.
Ausser...
Bei sehr grossen Projekten, in denen viele Makos im Zeitintervall laufen. Es gibt Projekte mit über 5.000 (in Worten fünftausend) Objekten (allerdings nicht in FHZ- bzw. Funk-Anwendungen). Da können sich die Differenzzeiten dann zu merklichen Sekundenbruchteilen addieren.

Bei diesen Überlegungen muss man auch bedenken, dass der Quellcode durch die Verwendung von der Text-Zuständen oftmals lesbarer sein kann.
Unterm Strich aber kann man sagen, dass sich eine "Umstellung" im Normallfall nicht lohnt, da es zu keiner merkliche Zeitdifferenz (also letztlich schätzungsweise im 1/1000-Sekunden Bereich) führt und der Vorteil besserer Lesbarkeit wichtiger sein kann.

[squeeezer]

hallo herr krapoth,

und wieder mal herzlichen dank für die sehr ausführliche antwort :-) ...

viele liebe grüße ...